首页 / 操作系统 / Linux / 浅谈Android系统进程间通信（IPC）机制Binder中的Server和Client获得Service Manager接口之路

在前面一篇文章浅谈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。相关阅读：Android进程间通信（IPC）机制Binder简要介绍和学习计划  http://www.linuxidc.com/Linux/2011-07/39269.htm获取Service Manager远程接口的函数是defaultServiceManager，这个函数声明在frameworks/base/include/binder/IServiceManager.h文件中：

1. sp<IServiceManager> defaultServiceManager（）;  

实现在frameworks/base/libs/binder/IServiceManager.cpp文件中：

1. sp<IServiceManager> defaultServiceManager（）  
2. {  
3.   
4.     if （gDefaultServiceManager ！= NULL） return gDefaultServiceManager;  
5.   
6.     {  
7.         AutoMutex _l（gDefaultServiceManagerLock）;  
8.         if （gDefaultServiceManager == NULL） {  
9.             gDefaultServiceManager = interface_cast<IServiceManager>（  
10.                 ProcessState::self（）->getContextObject（NULL））;  
11.         }  
12.     }  
13.   
14.     return gDefaultServiceManager;  
15. }  

       gDefaultServiceManagerLock和gDefaultServiceManager是全局变量，定义在frameworks/base/libs/binder/Static.cpp文件中：

1. Mutex gDefaultServiceManagerLock;  
2. 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文件中：

1. template<typename INTERFACE>  
2. class BpInterface : public INTERFACE, public BpRefBase  
3. {  
4. public:  
5.     BpInterface（const sp<IBinder>& remote）;  
6.   
7. protected:  
8.     virtual IBinder* onAsBinder（）;  
9. };  

        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远程接口主要是下面语句：

1. gDefaultServiceManager = interface_cast<IServiceManager>（  
2.     ProcessState::self（）->getContextObject（NULL））;  

看起来简短，却暗藏玄机，具体可阅读Android深入浅出之Binder机制这篇参考资料，这里作简要描述。