Android系统进程间通信（系统进程间通信（IPC）机制）机制Binder中的中的Server和和Client获得获得
Service Manager接口之路接口之路
本文主要介绍Android IPC通信Binder中的Server和Client获得Service Manager接口，这里详细的说明了如何实现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远程接口的创建过程。
资源评论
