Android應用程序與SurfaceFlinger服務的連接過程分析

        前文在描述Android應用程序和SurfaceFlinger服務的關系時提到,每一個有UI的Android應用程序都需要與SurfaceFlinger服務建立一個連接,以便可以通過這個連接來請求SurfaceFlinger服務為它創建和渲染Surface。在本文中,我們將以Android系統的開機動畫應用程序為例,詳細描述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中,如下所示:

[cpp] 
BootAnimation::BootAnimation() : Thread(false) 

    mSession = new SurfaceComposerClient(); 

        mSession是BootAnimation類的成員變量,它是一個類型為SurfaceComposerClient的強指針,即sp<SurfaceComposerClient>。Android系統的智能指針的相關知識,可以參考Android系統的智能指針(輕量級指針、強指針和弱指針)的實現原理分析一文。
        在SurfaceComposerClient類內部,有一個類型為sp<ISurfaceComposerClient>的成員變量mClient,如圖1所示:

 

圖1 SurfaceComposerClient的結構示意圖

 

        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中,如下所示:

[cpp] 
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; 
    …… 
 
}; 
       其中,成員函數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所示:


圖4 Android應用程序與SurfaceFlinger服務的連接過程
        接下來,我們就詳細分析每一個步驟。

        Step 1. SurfaceComposerClient::onFirstRef

[cpp] 
void SurfaceComposerClient::onFirstRef() 

    sp<ISurfaceComposer> sm(getComposerService()); 
    if (sm != 0) { 
        sp<ISurfaceComposerClient> conn = sm->createConnection(); 
        if (conn != 0) { 
            mClient = conn; 
            …… 
            mStatus = NO_ERROR; 
        } 
    } 

       SurfaceComposerClient類的成員函數onFirstRef實現在文件frameworks/base/libs/surfaceflinger_client/SurfaceComposerClient.cpp文件中。

       SurfaceComposerClient類的成員函數getComposerService用來獲得SurfaceFlinger服務的一個代理接口,它的實現如下所示:

[cpp] 
sp<ISurfaceComposer> ComposerService::getComposerService() { 
    return ComposerService::getInstance().mComposerService; 

        ComposerService類是單例模式,當我們第一次調用它的靜態函數getInstance的時候,它就會在構造函數中獲得SurfaceFlinger服務的一個代理接口,並且保存在它的成員變量mComposerService中,如下所示:

[cpp] 
ComposerService::ComposerService() 
: Singleton<ComposerService>() { 
    const String16 name("SurfaceFlinger"); 
    while (getService(name, &mComposerService) != NO_ERROR) { 
        usleep(250000); 
    } 
    mServerCblkMemory = mComposerService->getCblk(); 
    mServerCblk = static_cast<surface_flinger_cblk_t volatile *>( 
            mServerCblkMemory->getBase()); 

       在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

[cpp] 
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; 

        SurfaceFlinger類的成員函數createConnection實現在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中,它的實現很簡單,隻是創建瞭一個類型為Client的Binder對象client,並且獲得它的一個ISurfaceComposerClient接口,最後將這個ISurfaceComposerClient接口,即一個Client代理對象,返回給開機動畫應用程序bootanimation。

        接下來,我們再繼續分析Client對象的創建過程,,即Client類的構造函數的實現。

        Step 3. new Client

[cpp] 
Client::Client(const sp<SurfaceFlinger>& flinger) 
    : mFlinger(flinger), mNameGenerator(1) 


        Client類有兩個成員變量mFlinger和mNameGenerator,它們的類型分別為sp<SurfaceFlinger>和int32_t,前者指向瞭SurfaceFlinger服務,而後者用來生成SurfaceFlinger服務為Android應用程序所創建的每一個Surface的名稱。例如,假設一個Android應用程序請求SurfaceFlinger創建瞭兩個Surface,那麼第一個Surface的名稱就由數字1來描述,而第二個Surface就由數字2來描述,依次類推。從前面Android應用程序與SurfaceFlinger服務的關系概述和學習計劃這篇文章可以知道,一個Android應用程序最多可以創建31個Surface。

        回到SurfaceFlinger類的成員函數createConnection中,它將一個指向瞭一個Client對象的ISurfaceComposerClient接口返回到開機動畫應用程序bootanimation之後,開機動畫應用程序bootanimation就可以將它封裝成一個類型為BpSurfaceComposerClient的Binder代理對象。

        Step 4. return BpSurfaceComposerClient

        類型為BpSurfaceComposerClient的Binder代理對象的封裝過程實現在SurfaceFlinger服務的Binder代理對象類BpSurfaceComposer的成員函數createConnection中,如下所示:

[cpp]
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()); 
    } 
 
    …… 

        interface_cast是一個模板函數,它定義在framework/base/include/binder/IInterface.h文件中:

[cpp] 
template<typename INTERFACE>   
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)   
{   
    return INTERFACE::asInterface(obj);   
}   
        從這裡就可以看出,當模板參數為ISurfaceComposerClient的時候,模板函數interface_cast實際就是通過調用ISurfaceComposerClient類的靜態成員函數asInterface來將參數obj所描述的一個Binder代理對象,即一個BpBinder對象,封裝成一個BpSurfaceComposerClient對象。

        ISurfaceComposerClient類的靜態成員函數asInterface是由frameworks/base/libs/surfaceflinger_client/ISurfaceComposerClient.cpp文件中的IMPLEMENT_META_INTERFACE宏來定義的,如下所示:

[cpp] 
IMPLEMENT_META_INTERFACE(SurfaceComposerClient, "android.ui.ISurfaceComposerClient"); 
      
       IMPLEMENT_META_INTERFACE宏展開後,得到ISurfaceComposerClient類的靜態成員函數asInterface的實現如下所示:

[cpp]
android::sp<ISurfaceComposerClient> ISurfaceComposerClient::asInterface(const android::sp<android::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;                                     
}      
        參數obj是從BpSurfaceComposer類的成員函數createConnection傳進來的,它指向的實際上是一個BpBinder對象。當我們調用一個BpBinder對象的成員函數queryLocalInterface時,獲得的是一個NULL指針,因此,ISurfaceComposerClient類的靜態成員函數asInterface最後就會將參數obj所指向的一個BpBinder對象封裝成一個BpSurfaceComposerClient對象,並且返回給調用者。

        BpSurfaceComposerClient對象的更具體封裝過程可以參考前面淺談Android系統進程間通信(IPC)機制Binder中的Server和Client獲得Service Manager接口之路一文中所描述的BpServiceManager對象的封裝過程。

        至此,開機動畫應用程序bootanimation就通過SurfaceComposerClient類來與SurfaceFlinger服務建立一個連接瞭。

        在前面Android應用程序與SurfaceFlinger服務的關系概述和學習計劃一文中提到,一個Android應用程序除瞭需要與SurfaceFlinger服務建立連接之外,還需要有一塊用來傳遞UI元數據的匿名共享內存,即一個SharedClient對象,因此,在接下來的一篇文章中,我們就繼續分析這塊匿名共享內存的創建過程,敬請期待!

發佈留言