Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> 關於Android編程 >> Android系統進程間通信(IPC)機制Binder中的Server和Client獲得Service Manager接口之路

Android系統進程間通信(IPC)機制Binder中的Server和Client獲得Service Manager接口之路

編輯:關於Android編程

        在前面一篇文章淺談Service Manager成為Android進程間通信(IPC)機制Binder守護進程之路中,介紹了Service Manager是如何成為Binder機制的守護進程的。既然作為守護進程,Service Manager的職責當然就是為Server和Client服務了。那麼,Server和Client如何獲得Service Manager接口,進而享受它提供的服務呢?本文將簡要分析Server和Client獲得Service Manager的過程。

        在閱讀本文之前,希望讀者先閱讀Android進程間通信(IPC)機制Binder簡要介紹和學習計劃一文提到的參考資料Android深入淺出之Binder機制,這樣可以加深對本文的理解。

        我們知道,Service Manager在Binder機制中既充當守護進程的角色,同時它也充當著Server角色,然而它又與一般的Server不一樣。對於普通的Server來說,Client如果想要獲得Server的遠程接口,那麼必須通過Service Manager遠程接口提供的getService接口來獲得,這本身就是一個使用Binder機制來進行進程間通信的過程。而對於Service Manager這個Server來說,Client如果想要獲得Service Manager遠程接口,卻不必通過進程間通信機制來獲得,因為Service Manager遠程接口是一個特殊的Binder引用,它的引用句柄一定是0。

        獲取Service Manager遠程接口的函數是defaultServiceManager,這個函數聲明在frameworks/base/include/binder/IServiceManager.h文件中:

          sp<IServiceManager> defaultServiceManager();  

      實現在frameworks/base/libs/binder/IServiceManager.cpp文件中:

sp<IServiceManager> defaultServiceManager() 
{ 
 
 if (gDefaultServiceManager != NULL) return gDefaultServiceManager; 
 
 { 
  AutoMutex _l(gDefaultServiceManagerLock); 
  if (gDefaultServiceManager == NULL) { 
   gDefaultServiceManager = interface_cast<IServiceManager>( 
    ProcessState::self()->getContextObject(NULL)); 
  } 
 } 
 
 return gDefaultServiceManager; 
} 

        gDefaultServiceManagerLock和gDefaultServiceManager是全局變量,定義在frameworks/base/libs/binder/Static.cpp文件中:

Mutex gDefaultServiceManagerLock; 
sp<IServiceManager> gDefaultServiceManager; 

        從這個函數可以看出,gDefaultServiceManager是單例模式,調用defaultServiceManager函數時,如果gDefaultServiceManager已經創建,則直接返回,否則通過interface_cast<IServiceManager>(ProcessState::self()->getContextObject(NULL))來創建一個,並保存在gDefaultServiceManager全局變量中。

       在繼續介紹interface_cast<IServiceManager>(ProcessState::self()->getContextObject(NULL))的實現之前,先來看一個類圖,這能夠幫助我們了解Service Manager遠程接口的創建過程。


        參考資料Android深入淺出之Binder機制一文的讀者,應該會比較容易理解這個圖。這個圖表明了,BpServiceManager類繼承了BpInterface<IServiceManager>類,BpInterface是一個模板類,它定義在frameworks/base/include/binder/IInterface.h文件中:

template<typename INTERFACE> 
class BpInterface : public INTERFACE, public BpRefBase 
{ 
public: 
 BpInterface(const sp<IBinder>& remote); 
 
protected: 
 virtual IBinder* onAsBinder(); 
}; 

        IServiceManager類繼承了IInterface類,而IInterface類和BpRefBase類又分別繼承了RefBase類。在BpRefBase類中,有一個成員變量mRemote,它的類型是IBinder*,實現類為BpBinder,它表示一個Binder引用,引用句柄值保存在BpBinder類的mHandle成員變量中。BpBinder類通過IPCThreadState類來和Binder驅動程序並互,而IPCThreadState又通過它的成員變量mProcess來打開/dev/binder設備文件,mProcess成員變量的類型為ProcessState。ProcessState類打開設備/dev/binder之後,將打開文件描述符保存在mDriverFD成員變量中,以供後續使用。

        理解了這些概念之後,就可以繼續分析創建Service Manager遠程接口的過程了,最終目的是要創建一個BpServiceManager實例,並且返回它的IServiceManager接口。創建Service Manager遠程接口主要是下面語句:

gDefaultServiceManager = interface_cast<IServiceManager>( 
    ProcessState::self()->getContextObject(NULL));  

        看起來簡短,卻暗藏玄機,具體可閱讀Android深入淺出之Binder機制這篇參考資料,這裡作簡要描述。

        首先是調用ProcessState::self函數,self函數是ProcessState的靜態成員函數,它的作用是返回一個全局唯一的ProcessState實例變量,就是單例模式了,這個變量名為gProcess。如果gProcess尚未創建,就會執行創建操作,在ProcessState的構造函數中,會通過open文件操作函數打開設備文件/dev/binder,並且返回來的設備文件描述符保存在成員變量mDriverFD中。

        接著調用gProcess->getContextObject函數來獲得一個句柄值為0的Binder引用,即BpBinder了,於是創建Service Manager遠程接口的語句可以簡化為:

gDefaultServiceManager = interface_cast<IServiceManager>(new BpBinder(0));  

        再來看函數interface_cast<IServiceManager>的實現,它是一個模板函數,定義在framework/base/include/binder/IInterface.h文件中:

template<typename INTERFACE> 
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj) 
{ 
 return INTERFACE::asInterface(obj); 
} 

    這裡的INTERFACE是IServiceManager,於是調用了IServiceManager::asInterface函數。IServiceManager::asInterface是通過DECLARE_META_INTERFACE(ServiceManager)宏在IServiceManager類中聲明的,它位於framework/base/include/binder/IServiceManager.h文件中:

DECLARE_META_INTERFACE(ServiceManager);  

        展開即為:

#define DECLARE_META_INTERFACE(ServiceManager)        \ 
 static const android::String16 descriptor;       \ 
 static android::sp<IServiceManager> asInterface(     \ 
 const android::sp<android::IBinder>& obj);       \ 
 virtual const android::String16& getInterfaceDescriptor() const; \ 
 IServiceManager();             \ 
 virtual ~IServiceManager();           
  

  IServiceManager::asInterface的實現是通過IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager")宏定義的,它位於framework/base/libs/binder/IServiceManager.cpp文件中:

IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");  

       展開即為:

#define IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager")     \ 
 const android::String16 IServiceManager::descriptor("android.os.IServiceManager");  \ 
 const android::String16&         \ 
 IServiceManager::getInterfaceDescriptor() const {          \ 
 return IServiceManager::descriptor;             \ 
 }                      \ 
 android::sp<IServiceManager> IServiceManager::asInterface(        \ 
 const android::sp<android::IBinder>& obj)            \ 
 {                      \ 
 android::sp<IServiceManager> intr;              \ 
 if (obj != NULL) {                  \ 
 intr = static_cast<IServiceManager*>(             \ 
 obj->queryLocalInterface(                \ 
 IServiceManager::descriptor).get());             \ 
 if (intr == NULL) {                 \ 
 intr = new BpServiceManager(obj);              \ 
 }                      \ 
 }                      \ 
 return intr;                   \ 
 }                      \ 
 IServiceManager::IServiceManager() { }             \ 
 IServiceManager::~IServiceManager() { }  

         估計寫這段代碼的員工是從Microsoft跳槽到Google的。這裡我們關注IServiceManager::asInterface的實現:

android::sp<IServiceManager> IServiceManager::asInterface(const android::sp<android::IBinder>& obj)            
{                      
 android::sp<IServiceManager> intr;              
  
 if (obj != NULL) {                  
  intr = static_cast<IServiceManager*>(             
     obj->queryLocalInterface(IServiceManager::descriptor).get()); 
   
  if (intr == NULL) {     
   intr = new BpServiceManager(obj);           
  }           
 } 
 return intr;         
}  

         這裡傳進來的參數obj就則剛才創建的new BpBinder(0)了,BpBinder類中的成員函數queryLocalInterface繼承自基類IBinder,IBinder::queryLocalInterface函數位於framework/base/libs/binder/Binder.cpp文件中:

sp<IInterface> IBinder::queryLocalInterface(const String16& descriptor) 
{ 
 return NULL; 
} 

         由此可見,在IServiceManager::asInterface函數中,最終會調用下面語句:

                    intr = new BpServiceManager(obj);   

         即為:

                    intr = new BpServiceManager(new BpBinder(0));   

        回到defaultServiceManager函數中,最終結果為:

           gDefaultServiceManager = new BpServiceManager(new BpBinder(0));  

       這樣,Service Manager遠程接口就創建完成了,它本質上是一個BpServiceManager,包含了一個句柄值為0的Binder引用。

        在Android系統的Binder機制中,Server和Client拿到這個Service Manager遠程接口之後怎麼用呢?

        對Server來說,就是調用IServiceManager::addService這個接口來和Binder驅動程序交互了,即調用BpServiceManager::addService 。而BpServiceManager::addService又會調用通過其基類BpRefBase的成員函數remote獲得原先創建的BpBinder實例,接著調用BpBinder::transact成員函數。在BpBinder::transact函數中,又會調用IPCThreadState::transact成員函數,這裡就是最終與Binder驅動程序交互的地方了。回憶一下前面的類圖,IPCThreadState有一個PorcessState類型的成中變量mProcess,而mProcess有一個成員變量mDriverFD,它是設備文件/dev/binder的打開文件描述符,因此,IPCThreadState就相當於間接在擁有了設備文件/dev/binder的打開文件描述符,於是,便可以與Binder驅動程序交互了。

       對Client來說,就是調用IServiceManager::getService這個接口來和Binder驅動程序交互了。具體過程上述Server使用Service Manager的方法是一樣的,這裡就不再累述了。

      IServiceManager::addService和IServiceManager::getService這兩個函數的具體實現,在下面兩篇文章中,會深入到Binder驅動程序這一層,進行詳細的源代碼分析,以便更好地理解Binder進程間通信機制,敬請關注。

        以上就是對Android Binder 通信資料的整理,後續繼續補充相關資料,謝謝大家對本站的支持!

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved