應用程式程序與SurfaceFlinger的連接配接過程

我們從SurfaceComposerClient對象的建立開始分析應用程式與SurfaceFlinger的連接配接過程．每一個需要SurfaceFlinger渲染的應用程式都會建立一個SurfaceComposerClient對象，是這樣麼，我不确定，需要驗證．

SurfaceComposerClient類的聲明(在SurfaceComposerClient.h檔案中)如下：

class SurfaceComposerClient : public RefBase

SurfaceComposerClient類的構造函數定義如下:

SurfaceComposerClient::SurfaceComposerClient()

: mStatus(NO_INIT), mComposer(Composer::getInstance())

{

}

關于SurfaceComposerClient類的構造函數的詳細分析可以參考page2檔案．

因為SurfaceComposerClient繼承自RefBase，那麼當隻能指針第一次被引用時，就會調用onFirstRef函數, 我們就來看一下SurfaceComposerClient的onFirstRef函數的實作:

1void SurfaceComposerClient::onFirstRef() {

2 sp<ISurfaceComposer> sm(ComposerService::getComposerService());

3 if (sm != 0) {

4 sp<ISurfaceComposerClient> conn = sm->createConnection();

5 if (conn != 0) {

6 mClient = conn;

7 mStatus = NO_ERROR;

8 }

9 }

10}

關于SurfaceComposerClient的onFirstRef函數的實作的分析,可以參考page3檔案．

當調用完onFirstRef函數之後, SurfaceComposerClient對象的成員變量mClient就被初始化指向一個ISurfaceComposerClient的Binder代理對象，這樣SurfaceComposerClient對象就能通過這個ISurfaceComposerClient接口來請求SurfaceFlinger的服務了．

以上就是應用程式與SurfaceFlinger服務的連接配接過程的分析, 通過以上的分析, 我們可以得出以下結論:

No.1 每一個需要渲染UI的應用程式都會建立一個SurfaceComposerClient對象. 這是正确的麼?

No.2 每一個需要SurfaceFlinger服務的應用程式都會在SurfaceFlinger這一側建立一個Client對象, 并在應用程式這一側拿到一個ISurfaceComposerClient類型的Binder代理對象．

SurfaceComposerClient類的構造函數定義如下:

SurfaceComposerClient::SurfaceComposerClient()

: mStatus(NO_INIT), mComposer(Composer::getInstance())

{

}

在SurfaceComposerClient類中一個成員變量mComposer, 類型為Composer類的一個引用, 定義如下:

Composer& mComposer;

那麼這個mComposer的作用是什麼呢?且慢, 我們一點點的來分析．

我們先來看一下Composer類的定義,

Composer類的聲明如下:

class Composer : public Singleton<Composer>

由此可見Composer是一個單例的．

Composer的構造函數定義如下:

Composer() : Singleton<Composer>(),

mForceSynchronous(0), mTransactionNestCount(0),

mAnimation(false)

{

}

我們還是不知道mComposer是幹什麼的啊？那日後在分析吧．＾－＾

SurfaceComposerClient的onFirstRef函數的實作如下

1void SurfaceComposerClient::onFirstRef() {

2 sp<ISurfaceComposer> sm(ComposerService::getComposerService());

3 if (sm != 0) {

4 sp<ISurfaceComposerClient> conn = sm->createConnection();

5 if (conn != 0) {

6 mClient = conn;

7 mStatus = NO_ERROR;

8 }

9 }

10}

第一行(SurfaceComposerClient::onFirstRef)首先調用ComposerService::getComposerService()來獲得一個ISurfaceComposer的Binder代理對象.

我們首先看一下ComposerService類的聲明，位于frameworks/native/include/private/gui/ComposerService.h檔案中:

class ComposerService : public Singleton<ComposerService>

由此可見, ComposerService是一個單例的.

分析完ComposerService類的聲明, 我們看一下ComposerService的getComposerService函數的實作, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp檔案中, 定義如下:

1sp<ISurfaceComposer> ComposerService::getComposerService() {

2 ComposerService& instance = ComposerService::getInstance();

3 Mutex::Autolock _l(instance.mLock);

4 if (instance.mComposerService == NULL) {

5 ComposerService::getInstance().connectLocked();

6 assert(instance.mComposerService != NULL);

7 ALOGD("ComposerService reconnected");

8 }

9 return instance.mComposerService;

10}

ComposerService的getComposerService函數的主要邏輯是得到ComposerService執行個體,并判斷ComposerService執行個體的mComposerService是否為null, 如果是則表示還沒有得到SurfaceFlinger服務，那麼就會調用ComposerService執行個體的connectLocked函數來得到SurfaceFlinger服務, 如果不為null, 表示已經獲得了SurfaceFlinger服務，那麼直接傳回SurfaceFlinger.

是以我們接下來看一下ComposerService的connectLocked函數的實作, 位于frameworks/native/libs/gui/SurfaceComposerClient.cpp檔案中, 定義如下:

void ComposerService::connectLocked() {

const String16 name("SurfaceFlinger");

while (getService(name, &mComposerService) != NO_ERROR) {

usleep(250000);

}

assert(mComposerService != NULL);

// Create the death listener.

class DeathObserver : public IBinder::DeathRecipient {

ComposerService& mComposerService;

virtual void binderDied(const wp<IBinder>& who) {

ALOGW("ComposerService remote (surfaceflinger) died [%p]",

who.unsafe_get());

mComposerService.composerServiceDied();

}

public:

DeathObserver(ComposerService& mgr) : mComposerService(mgr) { }

};

mDeathObserver = new DeathObserver(*const_cast<ComposerService*>(this));

IInterface::asBinder(mComposerService)->linkToDeath(mDeathObserver);

}

在ComposerService的connectLocked函數中, 主要完成了兩件事:　第一，不斷地從ServiceManager中擷取SurfaceFlinger服務. 第二, 注冊一個Binder死亡通知．

我們回到SurfaceComposerClient::onFirstRef函數的分析中, 當得到SurfaceFlinger服務之後, 第4-8行(SurfaceComposerClient::onFirstRef)會調用SurfaceFlinger的createConnection函數，createConnection函數的定義如下：

1sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()

2{

3 sp<ISurfaceComposerClient> bclient;

4 sp<Client> client(new Client(this));

5 status_t err = client->initCheck();

6 if (err == NO_ERROR) {

7 bclient = client;

8 }

9 return bclient;

10}

createConnection函數的詳細分析可以參考page4檔案。

第6行(SurfaceComposerClient::onFirstRef)就把createConnection函數傳回的ISurfaceComposerClient的Binder接口儲存起來，這樣以後就能通過這個接口來請求SurfaceFlinger服務了。

SurfaceFlinger的createConnection函數的實作如下:

1sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()

2{

3 sp<ISurfaceComposerClient> bclient;

4 sp<Client> client(new Client(this));

5 status_t err = client->initCheck();

6 if (err == NO_ERROR) {

7 bclient = client;

8 }

9 return bclient;

10}

第4行(SurfaceFlinger::createConnection)首先建立了一個Client類型的對象，傳入的參數就是SurfaceFlinger對象。

Client類的聲明如下，位于frameworks/native/services/surfaceflinger/Client.h檔案中：

class Client : public BnSurfaceComposerClient

由此可見Client是一個Binder的本地對象。

Client類的構造函數定義如下, 位于frameworks/native/services/surfaceflinger/Client.cpp:

1Client::Client(const sp<SurfaceFlinger>& flinger)

2: mFlinger(flinger), mNameGenerator(1)

3{

4}

Client的構造函數隻是将Client的成員變量mFlinger指向SurfaceFlinger服務。

當構造完Client對象之後, 會在第5行(SurfaceFlinger::createConnection)調用Client的initCheck函數，initCheck的函數的定義如下：

status_t Client::initCheck() const {

return NO_ERROR;

}

可以看到initCheck函數隻是簡單的傳回了NO_ERROR。

最後會傳回這個Client對象。

由此可見, 每一個與SurfaceFlinger連接配接的應用程式在SurfaceFlinger這一側都會有一個Client對象，也就是ISurfaceComposerClient的Binder本地對象。

最後将這個ISurfaceComposerClient的Binder接口傳回給應用程式，這樣應用程式就可以用這個Binder接口來請求SurfaceFlinger為其服務了，這樣應用程式就和SurfaceFlinger建立了連接配接。