淺談Android系統進程間通信（IPC）機制Binder中的Server和Client獲得Service Manager接口之路 · 老羅的Android之旅（總結）

原文出處——>[淺談Android系統進程間通信（IPC）機制Binder中的Server和Client獲得Service Manager接口之路](http://blog.csdn.net/luoshengyang/article/details/6627260) 在前面一篇文章淺談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遠程接口的創建過程。 ![](http://hi.csdn.net/attachment/201107/22/0_1311363642X5Cd.gif) 參考資料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進程間通信機制，敬請關注。