如何获取ServiceManager的?
Client 与Server的通信是ServiceManager来管理的,那Client与Server通信的第一步就是获得ServiceManager了。下面，我们就来看看Client是如何获取ServiceManager的。
defaultServiceManager
我们知道，Service Manager在Binder机制中既充当守护进程的角色，同时它也充当着Server角色，然而它又与一般的Server不一样。对于普通的Server来说，Client如果想要获得Server的远程接口，那么必须通过Service Manager远程接口提供的getService接口来获得，这本身就是一个使用Binder机制来进行进程间通信的过程。而对于Service Manager这个Server来说，Client如果想要获得Service Manager远程接口，却不必通过进程间通信机制来获得，因为Service Manager远程接口是一个特殊的Binder引用，它的引用句柄一定是0。
先来看看ServiceManager在Jni层的实现IServiceManager.cpp
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
{
AutoMutex _l(gDefaultServiceManagerLock); //加锁
while (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));
if (gDefaultServiceManager == NULL)
sleep(1); //休眠1秒，往往在系统刚启动过程可能会第一次获取失败
}
}
return gDefaultServiceManager;
}
可以发现上面获取ServiceManager对象采用了单例模式，当gDefaultServiceManager存在，则直接返回，否则创建一个新对象。 发现与一般的单例模式不太一样，里面多了一层while循环，这是google在2013年1月Todd Poynor提交的修改。当尝试创建或获取ServiceManager时，ServiceManager可能尚未准备就绪，这时通过sleep 1秒后，循环尝试获取直到成功。
defaultServiceManager()最为核心的代码：
interface_cast<IServiceManager>(
ProcessState::self()->getContextObject(NULL));
分解为以下3个步骤：
- ProcessState::self()：用于获取ProcessState对象(也是单例模式)，每个进程有且只有一个ProcessState对象，存在则直接返回，不存在则创建;
- getContextObject()： 用于获取BpBiner对象，对于handle=0的BpBiner对象，存在则直接返回，不存在才创建;
- interface_cast<IServiceManager>()：创建BpServiceManager对象.
ProcessState::self()
sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex); //加锁
if (gProcess != NULL) {
return gProcess;
}
gProcess = new ProcessState; //创建对象
return gProcess;
}
self函数是ProcessState的静态成员函数，它的作用是返回一个全局唯一的ProcessState实例变量，这也就是单例模式，这个变量名为gProcess。其中gProcess和gProcessMutex是保存在Static.cpp类的全局变量。如果gProcess尚未创建，就会执行创建操作.
下面来看看ProcessState的构造函数
ProcessState::ProcessState()
: mDriverFD(open_driver()) // 打开Binder驱动
, mVMStart(MAP_FAILED)
, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
, mExecutingThreadsCount(0)
, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
, mManagesContexts(false)
, mBinderContextCheckFunc(NULL)
, mBinderContextUserData(NULL)
, mThreadPoolStarted(false)
, mThreadPoolSeq(1)
{
if (mDriverFD >= 0) {
//采用内存映射函数mmap，给binder分配一块虚拟地址空间,用来接收事务
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
if (mVMStart == MAP_FAILED) {
close(mDriverFD); //没有足够空间分配给/dev/binder,则关闭驱动
mDriverFD = -1;
}
}
}
在ProcessState的构造函数中，会通过open文件操作函数打开设备文件/dev/binder，并且返回来的设备文件描述符保存在成员变量mDriverFD中。
- 由于ProcessState的单例模式的惟一性，因此一个进程只打开binder设备一次,其中ProcessState的成员变量mDriverFD记录binder驱动的fd，用于访问binder设备。
- open_driver作用是打开/dev/binder设备，设定binder支持的最大线程数。
- BINDER_VM_SIZE = (1*1024*1024) - (4096 *2), binder分配的默认内存大小为1M-8k。
- DEFAULT_MAX_BINDER_THREADS = 15，binder默认的最大可并发访问的线程数为16。
opendriver 函数:
static int open_driver()
{
// 打开/dev/binder设备，建立与内核的Binder驱动的交互通道
int fd = open("/dev/binder", O_RDWR);
if (fd >= 0) {
fcntl(fd, F_SETFD, FD_CLOEXEC);
int vers = 0;
status_t result = ioctl(fd, BINDER_VERSION, &vers);
if (result == -1) {
close(fd);
fd = -1;
}
if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) {
close(fd);
fd = -1;
}
size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;
// 通过ioctl设置binder驱动，能支持的最大线程数
result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
if (result == -1) {
ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno));
}
} else {
ALOGW("Opening '/dev/binder' failed: %s\n", strerror(errno));
}
return fd;
}
这个函数的作用主要是通过open文件操作函数来打开/dev/binder设备文件，然后再调用ioctl文件控制函数来分别执行BINDER_VERSION和BINDER_SET_MAX_THREADS两个命令来和Binder驱动程序进行交互，前者用于获得当前Binder驱动程序的版本号，后者用于通知Binder驱动程序，MediaPlayerService最多可同时启动15个线程来处理Client端的请求。
getContextObject()
来看看getContextObject的源码:
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& )
{
return getStrongProxyForHandle(0);
}
sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
sp<IBinder> result;
AutoMutex _l(mLock);
//查找handle对应的资源项
handle_entry* e = lookupHandleLocked(handle);
if (e != NULL) {
IBinder* b = e->binder;
if (b == NULL || !e->refs->attemptIncWeak(this)) {
if (handle == 0) {
Parcel data;
//通过ping操作测试binder是否准备就绪
status_t status = IPCThreadState::self()->transact(
0, IBinder::PING_TRANSACTION, data, NULL, 0);
if (status == DEAD_OBJECT)
return NULL;
}
//当handle值所对应的IBinder不存在或弱引用无效时，则创建BpBinder对象【
b = new BpBinder(handle);
e->binder = b;
if (b) e->refs = b->getWeakRefs();
result = b;
} else {
result.force_set(b);
e->refs->decWeak(this);
}
}
return result;
}
当handle值所对应的IBinder不存在或弱引用无效时会创建BpBinder，否则直接获取。针对handle==0的特殊情况(servicemanager对应的handle值)，通过PING_TRANSACTION来判断是否准备就绪。如果在context manager还未生效前，一个BpBinder的本地引用就已经被创建，那么驱动将无法提供context manager的引用。
总结一下,getContextObject函数来获得一个句柄值为0的Binder引用，即BpBinder了，于是创建Service Manager远程接口的语句可以简化为：
gDefaultServiceManager = interface_cast<IServiceManager>(new BpBinder(0));
来看看bpbinder:
BpBinder::BpBinder(int32_t handle)
: mHandle(handle)
, mAlive(1)
, mObitsSent(0)
, mObituaries(NULL)
{
extendObjectLifetime(OBJECT_LIFETIME_WEAK); //延长对象的生命时间
IPCThreadState::self()->incWeakHandle(handle); //handle所对应的bindle弱引用 + 1
}
interface_cast<IServiceManager>()
来看看函数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文件中：
#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();
ServiceManager::asInterface的实现是通过IMPLEMENT_META_INTERFACE(ServiceManager, "[Android](http://lib.csdn.net/base/15).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() { }
再来看看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;
}
ServiceManager的Binder对象所在进程肯定不是当前进程,所以返回null。
由此可见，在IServiceManager::asInterface函数中，最终会调用下面语句：
intr = new BpServiceManager(obj);
创建BpServiceManager对象的过程，会先初始化父类BpInterface：
inline BpInterface<INTERFACE>::BpInterface(const sp<IBinder>& remote)
:BpRefBase(remote)
{
}
再初始化BpInterface的父类BpRefBase
BpRefBase::BpRefBase(const sp<IBinder>& o)
: mRemote(o.get()), mRefs(NULL), mState(0)
{
extendObjectLifetime(OBJECT_LIFETIME_WEAK);
if (mRemote) {
mRemote->incStrong(this);
mRefs = mRemote->createWeak(this);
}
}
new BpServiceManager()，在初始化过程中，比较重要工作的是类BpRefBase的mRemote指向new BpBinder(0)，从而BpServiceManager能够利用Binder进行通过通信。
回到defaultServiceManager函数中，最终结果为：
gDefaultServiceManager = new BpServiceManager(new BpBinder(0));
这样，Service Manager远程接口就创建完成了，它本质上是一个BpServiceManager，包含了一个句柄值为0的Binder引用。
总结
defaultServiceManager<==>sp<IServiceManager> sm = new BpServiceManager(new BpBinder(0));ProcessState::self()主要工作：调用open()，打开/dev/binder驱动设备；
再利用mmap()，创建大小为1M-8K的内存地址空间；
设定当前进程最大的最大并发Binder线程个数为16。BpServiceManager巧妙将通信层与业务层逻辑合为一体，通过继承接口IServiceManager
实现了接口中的业务逻辑函数；
通过成员变量mRemote= new BpBinder(0)进行Binder通信工作。BpBinder是通过handle(值为0)来得到的所对应BBinder的代理对象, 在整个Binder系统中handle=0代表ServiceManager所对应的BBinder。
