Android系統(tǒng)進(jìn)程間通信（IPC）機制Binder中的Server和Client獲得Service Manager接口之路

更新時間：2016年08月29日 10:39:04 作者：羅升陽

本文主要介紹Android IPC通信Binder中的Server和Client獲得Service Manager接口，這里詳細(xì)的說明了如何實現(xiàn)Service Manager接口，對研究Android源碼的朋友提供幫助，有需要的小伙伴可以參考下

在前面一篇文章淺談Service Manager成為Android進(jìn)程間通信（IPC）機制Binder守護(hù)進(jìn)程之路中，介紹了Service Manager是如何成為Binder機制的守護(hù)進(jìn)程的。既然作為守護(hù)進(jìn)程，Service Manager的職責(zé)當(dāng)然就是為Server和Client服務(wù)了。那么，Server和Client如何獲得Service Manager接口，進(jìn)而享受它提供的服務(wù)呢？本文將簡要分析Server和Client獲得Service Manager的過程。

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

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

獲取Service Manager遠(yuǎn)程接口的函數(shù)是defaultServiceManager，這個函數(shù)聲明在frameworks/base/include/binder/IServiceManager.h文件中：

sp<IServiceManager> defaultServiceManager();

實現(xiàn)在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;

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

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

參考資料Android深入淺出之Binder機制一文的讀者，應(yīng)該會比較容易理解這個圖。這個圖表明了，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*，實現(xiàn)類為BpBinder，它表示一個Binder引用，引用句柄值保存在BpBinder類的mHandle成員變量中。BpBinder類通過IPCThreadState類來和Binder驅(qū)動程序并互，而IPCThreadState又通過它的成員變量mProcess來打開/dev/binder設(shè)備文件，mProcess成員變量的類型為ProcessState。ProcessState類打開設(shè)備/dev/binder之后，將打開文件描述符保存在mDriverFD成員變量中，以供后續(xù)使用。

理解了這些概念之后，就可以繼續(xù)分析創(chuàng)建Service Manager遠(yuǎn)程接口的過程了，最終目的是要創(chuàng)建一個BpServiceManager實例，并且返回它的IServiceManager接口。創(chuàng)建Service Manager遠(yuǎn)程接口主要是下面語句：

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

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

首先是調(diào)用ProcessState::self函數(shù)，self函數(shù)是ProcessState的靜態(tài)成員函數(shù)，它的作用是返回一個全局唯一的ProcessState實例變量，就是單例模式了，這個變量名為gProcess。如果gProcess尚未創(chuàng)建，就會執(zhí)行創(chuàng)建操作，在ProcessState的構(gòu)造函數(shù)中，會通過open文件操作函數(shù)打開設(shè)備文件/dev/binder，并且返回來的設(shè)備文件描述符保存在成員變量mDriverFD中。

接著調(diào)用gProcess->getContextObject函數(shù)來獲得一個句柄值為0的Binder引用，即BpBinder了，于是創(chuàng)建Service Manager遠(yuǎn)程接口的語句可以簡化為：

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

再來看函數(shù)interface_cast<IServiceManager>的實現(xiàn)，它是一個模板函數(shù)，定義在framework/base/include/binder/IInterface.h文件中：

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

這里的INTERFACE是IServiceManager，于是調(diào)用了IServiceManager::asInterface函數(shù)。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的實現(xiàn)是通過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的。這里我們關(guān)注IServiceManager::asInterface的實現(xiàn)：

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;         
}

這里傳進(jìn)來的參數(shù)obj就則剛才創(chuàng)建的new BpBinder(0)了，BpBinder類中的成員函數(shù)queryLocalInterface繼承自基類IBinder，IBinder::queryLocalInterface函數(shù)位于framework/base/libs/binder/Binder.cpp文件中：

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

由此可見，在IServiceManager::asInterface函數(shù)中，最終會調(diào)用下面語句：

intr = new BpServiceManager(obj);

即為：

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

回到defaultServiceManager函數(shù)中，最終結(jié)果為：

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

這樣，Service Manager遠(yuǎn)程接口就創(chuàng)建完成了，它本質(zhì)上是一個BpServiceManager，包含了一個句柄值為0的Binder引用。

在Android系統(tǒng)的Binder機制中，Server和Client拿到這個Service Manager遠(yuǎn)程接口之后怎么用呢？

對Server來說，就是調(diào)用IServiceManager::addService這個接口來和Binder驅(qū)動程序交互了，即調(diào)用BpServiceManager::addService 。而BpServiceManager::addService又會調(diào)用通過其基類BpRefBase的成員函數(shù)remote獲得原先創(chuàng)建的BpBinder實例，接著調(diào)用BpBinder::transact成員函數(shù)。在BpBinder::transact函數(shù)中，又會調(diào)用IPCThreadState::transact成員函數(shù)，這里就是最終與Binder驅(qū)動程序交互的地方了?；貞浺幌虑懊娴念悎D，IPCThreadState有一個PorcessState類型的成中變量mProcess，而mProcess有一個成員變量mDriverFD，它是設(shè)備文件/dev/binder的打開文件描述符，因此，IPCThreadState就相當(dāng)于間接在擁有了設(shè)備文件/dev/binder的打開文件描述符，于是，便可以與Binder驅(qū)動程序交互了。

對Client來說，就是調(diào)用IServiceManager::getService這個接口來和Binder驅(qū)動程序交互了。具體過程上述Server使用Service Manager的方法是一樣的，這里就不再累述了。

IServiceManager::addService和IServiceManager::getService這兩個函數(shù)的具體實現(xiàn)，在下面兩篇文章中，會深入到Binder驅(qū)動程序這一層，進(jìn)行詳細(xì)的源代碼分析，以便更好地理解Binder進(jìn)程間通信機制，敬請關(guān)注。

以上就是對Android Binder 通信資料的整理，后續(xù)繼續(xù)補充相關(guān)資料，謝謝大家對本站的支持！

您可能感興趣的文章: