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。

        获取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 通信资料的整理，后续继续补充相关资料，谢谢大家对本站的支持！