Android系統的開機動畫是由應用程序bootanimation來實現的，它位於/system/bin目錄下，它的具體實現可以參考Android系統的開機畫面顯示過程分析一文。為什麼要選擇Android系統的開機動畫來分析Android應用程序與SurfaceFlinger服務的連接過程呢？首先，負責實現開機動畫的應用程序bootanimation也是一個Android應用程序，只不過它是使用C++語言來開發的；其次，應用程序bootanimation是與UI相關的，即它與使用Java語言來開發的標準Android應用程序一樣，都需要使用SurfaceFlinger服務來創建和渲染自己的Surface，即開機動畫；第三，由於應用程序bootanimation不涉及用戶輸入，即不需要與用戶進行交互（觸摸屏、鍵盤等），因此它能夠以最簡潔的方式來體現Android應用程序與SurfaceFlinger服務的關係。
從前面Android系統的開機畫面顯示過程分析一文可以知道，Android系統的開機動畫是主要一個BootAnimation對象來實現，這個BootAnimation對象在構造的時候，會在內部創建一個SurfaceComposerClient對象來負責創建一個到SurfaceFlinger服務的連接。
BootAnimation類的構造函數實現在文件frameworks/base/cmds/bootanimation/BootAnimation.cpp中，如下所示：
<code>Android應用程序與SurfaceFlinger服務的連接過程分析
Android系統的開機動畫是由應用程序bootanimation來實現的，它位於/system/bin目錄下，它的具體實現可以參考Android系統的開機畫面顯示過程分析一文。為什麼要選擇Android系統的開機動畫來分析Android應用程序與SurfaceFlinger服務的連接過程呢？首先，負責實現開機動畫的應用程序bootanimation也是一個Android應用程序，只不過它是使用C++語言來開發的；其次，應用程序bootanimation是與UI相關的，即它與使用Java語言來開發的標準Android應用程序一樣，都需要使用SurfaceFlinger服務來創建和渲染自己的Surface，即開機動畫；第三，由於應用程序bootanimation不涉及用戶輸入，即不需要與用戶進行交互（觸摸屏、鍵盤等），因此它能夠以最簡潔的方式來體現Android應用程序與SurfaceFlinger服務的關係。
從前面Android系統的開機畫面顯示過程分析一文可以知道，Android系統的開機動畫是主要一個BootAnimation對象來實現，這個BootAnimation對象在構造的時候，會在內部創建一個SurfaceComposerClient對象來負責創建一個到SurfaceFlinger服務的連接。
BootAnimation類的構造函數實現在文件frameworks/base/cmds/bootanimation/BootAnimation.cpp中，如下所示：
BootAnimation::BootAnimation() : Thread(false)
{
mSession = new SurfaceComposerClient();
}
mSession是BootAnimation類的成員變量，它是一個類型為SurfaceComposerClient的強指針，即sp<surfacecomposerclient>。Android系統的智能指針的相關知識，可以參考Android系統的智能指針（輕量級指針、強指針和弱指針）的實現原理分析一文。
在SurfaceComposerClient類內部，有一個類型為sp<isurfacecomposerclient>的成員變量mClient，如圖1所示：
image
SurfaceComposerClient類的成員變量mClient指向的實際上是一個類型為BpSurfaceComposerClient的Binder代理對象，而這個類型為BpSurfaceComposerClient的Binder代理對象引用的是一個類型為Client的Binder本地對象。在前面Android應用程序與SurfaceFlinger服務的關係概述和學習計劃一文中提到，類型為Client的Binder本地對象是由SurfaceFlinger服務來負責創建的，並且運行在SurfaceFlinger服務中，用來代表使用SurfaceFlinger服務的一個客戶端，即一個與UI相關的Android應用程序。
由於Client類和BpSurfaceComposerClient類分別是一個Binder本地對象類和一個Binder代理對象類，它們都是根據Android系統在應用程序框架層提供的Binder進程間通信庫來實現的，它們的實現結構圖分別如圖2和圖3所示：/<isurfacecomposerclient>/<surfacecomposerclient>/<code>
mSession是BootAnimation類的成員變量，它是一個類型為SurfaceComposerClient的強指針，即sp<surfacecomposerclient>。Android系統的智能指針的相關知識，可以參考Android系統的智能指針（輕量級指針、強指針和弱指針）的實現原理分析一文。/<surfacecomposerclient>
在SurfaceComposerClient類內部，有一個類型為sp<isurfacecomposerclient>的成員變量mClient，如圖1所示：/<isurfacecomposerclient>
SurfaceComposerClient類的成員變量mClient指向的實際上是一個類型為BpSurfaceComposerClient的Binder代理對象，而這個類型為BpSurfaceComposerClient的Binder代理對象引用的是一個類型為Client的Binder本地對象。在前面Android應用程序與SurfaceFlinger服務的關係概述和學習計劃一文中提到，類型為Client的Binder本地對象是由SurfaceFlinger服務來負責創建的，並且運行在SurfaceFlinger服務中，用來代表使用SurfaceFlinger服務的一個客戶端，即一個與UI相關的Android應用程序。
由於Client類和BpSurfaceComposerClient類分別是一個Binder本地對象類和一個Binder代理對象類，它們都是根據Android系統在應用程序框架層提供的Binder進程間通信庫來實現的，它們的實現結構圖分別如圖2和圖3所示：
圖2 Client類的實現結構圖
圖3 BpSurfaceComposerClient類的實現結構圖
在圖2和圖3中，涉及到了比較多的Binder進程間通信庫的類，需要讀者對Android系統的Binder進程間通信機制有一定的理解和認識。在前面的Android進程間通信（IPC）機制Binder簡要介紹和學習計劃一系列文章，我們已經學習過Android系統的Binder進程間通信機制了，這裡不再詳述。
圖2和圖3給我們最重要的信息是Client類和BpSurfaceComposerClient類均實現了類型為ISurfaceComposerClient的Binder接口。ISurfaceComposerClient接口有兩個重要的成員函數getControlBlock和createSurface，它們定義在文件frameworks/base/include/surfaceflinger/ISurfaceComposerClient.h中，如下所示：
<code>class ISurfaceComposerClient : public IInterface
{
public:
......
virtual sp<imemoryheap> getControlBlock() const = 0;
......
/*
* Requires ACCESS_SURFACE_FLINGER permission
*/
virtual sp<isurface> createSurface( surface_data_t* data,
int pid,
const String8& name,
DisplayID display,
uint32_t w,
uint32_t h,
PixelFormat format,
uint32_t flags) = 0;
......
};
/<isurface>/<imemoryheap>/<code>
其中，成員函數getControlBlock用來獲得由SurfaceFlinger服務創建的一塊用來傳遞UI元數據的匿名共享內存，而成員函數createSurface用來請求SurfaceFlinger服務創建一個Surface.從前面Android應用程序與SurfaceFlinger服務的關係概述和學習計劃一文可以知道，用來傳遞UI元數據的匿名共享內存最終會被結構化為一個SharedClient對象，這個SharedClient對象在每個應用程序進程中至多存在一個。在接下來的兩篇文章中，我們再詳細分析ISurfaceComposerClient接口的成員函數getControlBlock和createSurface的實現。
理解了SurfaceComposerClient、Client以及BpSurfaceComposerClient這三個類的關係之後，接下來我們就可以分析Android系統的開機動畫應用程序bootanimation是如何與SurfaceFlinger服務建立連接的。
從圖1可以知道，SurfaceComposerClient類繼承了RefBase類，因此，當BootAnimation類在構造函數創建了一個SurfaceComposerClient對象，並且將這個對象賦值給類型為sp<surfacecomposerclient>的智能指針mSession時，就會導致SurfaceComposerClient類的成員函數onFirstRef被調用，而SurfaceComposerClient類的成員函數onFirstRef在調用的過程中，就會在應用程序bootanimation與SurfaceFlinger服務建立一個連接，這個過程如圖4所示：/<surfacecomposerclient>
圖4 Android應用程序與SurfaceFlinger服務的連接過程
接下來，我們就詳細分析每一個步驟。
Step 1. SurfaceComposerClient::onFirstRef
<code>void SurfaceComposerClient::onFirstRef()
{
sp<isurfacecomposer> sm(getComposerService());
if (sm != 0) {
sp<isurfacecomposerclient> conn = sm->createConnection();
if (conn != 0) {
mClient = conn;
......
mStatus = NO_ERROR;
}
}
}
/<isurfacecomposerclient>/<isurfacecomposer>/<code>
SurfaceComposerClient類的成員函數onFirstRef實現在文件frameworks/base/libs/surfaceflinger_client/SurfaceComposerClient.cpp文件中。
SurfaceComposerClient類的成員函數getComposerService用來獲得SurfaceFlinger服務的一個代理接口，它的實現如下所示：
<code>sp<isurfacecomposer> ComposerService::getComposerService() {
return ComposerService::getInstance().mComposerService;
}
/<isurfacecomposer>/<code>ComposerService類是單例模式，當我們第一次調用它的靜態函數getInstance的時候，它就會在構造函數中獲得SurfaceFlinger服務的一個代理接口，並且保存在它的成員變量mComposerService中，如下所示：
<code>ComposerService::ComposerService()
: Singleton<composerservice>() {
const String16 name("SurfaceFlinger");
while (getService(name, &mComposerService) != NO_ERROR) {
usleep(250000);
}
mServerCblkMemory = mComposerService->getCblk();
mServerCblk = static_cast<surface>(
mServerCblkMemory->getBase());
}
/<surface>/<composerservice>/<code>
在ComposerService類的構造函數中，除了會獲得SurfaceFlinger服務的代理接口之外，還會通過這個代理接口的成員函數getCblk來獲得一塊匿名共享內存mServerCblkMemory。這塊匿名共享內存是由SurfaceFlinger服務創建的，用來描述系統顯示屏的信息，例如，顯示屏的個數、大小、方向、密度等等信息。由於這些信息可以通過一個surface_flinger_cblk_t對象來描述，因此，ComposerService類的構造函數最後就將前面從SurfaceFlinger服務獲得的一塊匿名共享內存結構化為一個surface_flinger_cblk_t對象，並且保存在ComposerService類的成員變量mServerCblk中。
回到SurfaceComposerClient類的成員函數onFirstRef中，由於SurfaceFlinger服務實現了ISurfaceComposer接口，因此，我們可以將前面獲得的SurfaceFlinger服務的代理接口賦值給一個類型為ISurfaceComposer的強指針sm，並且調用它的成員函數createConnection來請求SurfaceFlinger服務創建一個連接，即創建一個類型為Client的Binder對象，並且將這個Binder對象的一個代理接口conn返回來。SurfaceComposerClient類獲得了SurfaceFlinger服務返回來的Client代理接口conn之後，就將它保存自己的成員變量mClient中，這樣開機動畫應用程序bootanimation後續就可以通過它來請求SurfaceFlinger創建和渲染Surface了。
接下來，我們就繼續分析SurfaceFlinger服務的成員函數createConnection的實現，以便可以瞭解它是如何為Android應用程序創建一個連接的。
Step 2. SurfaceFlinger::createConnection
<code>sp<isurfacecomposerclient> SurfaceFlinger::createConnection()
{
sp<isurfacecomposerclient> bclient;
sp<client> client(new Client(this));
status_t err = client->initCheck();
if (err == NO_ERROR) {
bclient = client;
}
return bclient;
}
/<client>/<isurfacecomposerclient>/<isurfacecomposerclient>/<code>
SurfaceFlinger類的成員函數createConnection實現在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中，它的實現很簡單，只是創建了一個類型為Client的Binder對象client，並且獲得它的一個ISurfaceComposerClient接口，最後將這個ISurfaceComposerClient接口，即一個Client代理對象，返回給開機動畫應用程序bootanimation。
接下來，我們再繼續分析Client對象的創建過程,，即Client類的構造函數的實現。
Step 3. new Client
<code>Client::Client(const sp<surfaceflinger>& flinger)
: mFlinger(flinger), mNameGenerator(1)
{
}
/<surfaceflinger>/<code>
Client類有兩個成員變量mFlinger和mNameGenerator，它們的類型分別為sp<surfaceflinger>和int32_t，前者指向了SurfaceFlinger服務，而後者用來生成SurfaceFlinger服務為Android應用程序所創建的每一個Surface的名稱。例如，假設一個Android應用程序請求SurfaceFlinger創建了兩個Surface，那麼第一個Surface的名稱就由數字1來描述，而第二個Surface就由數字2來描述，依次類推。從前面Android應用程序與SurfaceFlinger服務的關係概述和學習計劃這篇文章可以知道，一個Android應用程序最多可以創建31個Surface。/<surfaceflinger>
回到SurfaceFlinger類的成員函數createConnection中，它將一個指向了一個Client對象的ISurfaceComposerClient接口返回到開機動畫應用程序bootanimation之後，開機動畫應用程序bootanimation就可以將它封裝成一個類型為BpSurfaceComposerClient的Binder代理對象。
Step 4. return BpSurfaceComposerClient
類型為BpSurfaceComposerClient的Binder代理對象的封裝過程實現在SurfaceFlinger服務的Binder代理對象類BpSurfaceComposer的成員函數createConnection中，如下所示：
<code>class BpSurfaceComposer : public BpInterface<isurfacecomposer>
{
public:
......
virtual sp<isurfacecomposerclient> createConnection()
{
uint32_t n;
Parcel data, reply;
data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
remote()->transact(BnSurfaceComposer::CREATE_CONNECTION, data, &reply);
return interface_cast<isurfacecomposerclient>(reply.readStrongBinder());
}
......
}
/<isurfacecomposerclient>/<isurfacecomposerclient>/<isurfacecomposer>/<code>
interface_cast是一個模板函數，它定義在framework/base/include/binder/IInterface.h文件中：
<code>template<typename>
inline sp<interface> interface_cast(const sp<ibinder>& obj)
{
return INTERFACE::asInterface(obj);
}
/<ibinder>/<interface>/<typename>/<code>
從這裡就可以看出，當模板參數為ISurfaceComposerClient的時候，模板函數interface_cast實際就是通過調用ISurfaceComposerClient類的靜態成員函數asInterface來將參數obj所描述的一個Binder代理對象，即一個BpBinder對象，封裝成一個BpSurfaceComposerClient對象。
ISurfaceComposerClient類的靜態成員函數asInterface是由frameworks/base/libs/surfaceflinger_client/ISurfaceComposerClient.cpp文件中的IMPLEMENT_META_INTERFACE宏來定義的，如下所示：
<code>IMPLEMENT_META_INTERFACE(SurfaceComposerClient, "android.ui.ISurfaceComposerClient");
/<code>
IMPLEMENT_META_INTERFACE宏展開後，得到ISurfaceComposerClient類的靜態成員函數asInterface的實現如下所示：
<code>android::sp<isurfacecomposerclient> ISurfaceComposerClient::asInterface(const android::sp<:ibinder>& obj) {
android::sp<isurfacecomposerclient> intr;
if (obj != NULL) {
intr = static_cast<isurfacecomposerclient>(
obj->queryLocalInterface(ISurfaceComposerClient::descriptor).get());
if (intr == NULL) {
intr = new BpSurfaceComposerClient(obj);
}
｝
return intr;
}
/<isurfacecomposerclient>/<isurfacecomposerclient>/<isurfacecomposerclient>/<code>參數obj是從BpSurfaceComposer類的成員函數createConnection傳進來的，它指向的實際上是一個BpBinder對象。當我們調用一個BpBinder對象的成員函數queryLocalInterface時，獲得的是一個NULL指針，因此，ISurfaceComposerClient類的靜態成員函數asInterface最後就會將參數obj所指向的一個BpBinder對象封裝成一個BpSurfaceComposerClient對象，並且返回給調用者。
BpSurfaceComposerClient對象的更具體封裝過程可以參考前面淺談Android系統進程間通信（IPC）機制Binder中的Server和Client獲得Service Manager接口之路一文中所描述的BpServiceManager對象的封裝過程。
至此，開機動畫應用程序bootanimation就通過SurfaceComposerClient類來與SurfaceFlinger服務建立一個連接了。
閱讀更多 linux內核 的文章
