一、 获取服务
在Native层的服务注册,我们选择以media为例来展开讲解,先来看看media的类关系图。
1.1 类图
图解:
蓝色: 代表获取MediaPlayerService服务相关的类;
绿色: 代表Binder架构中与Binder驱动通信过程中的最为核心的两个类;
紫色: 代表注册服务和获取服务的公共接口/父类;
二. 获取Media服务
2.1 getMediaPlayerService
[-> framework/av/media/libmedia/IMediaDeathNotifier.cpp]
其中defaultServiceManager()过程在上一篇文章获取ServiceManager已讲过,返回BpServiceManager。
在请求获取名为”media.player”的服务过程中,采用不断循环获取的方法。由于MediaPlayerService服务可能还没向ServiceManager注册完成或者尚未启动完成等情况,故则binder返回为NULL,休眠0.5s后继续请求,直到获取服务为止。
2.2 BpSM.getService
[-> IServiceManager.cpp ::BpServiceManager]
通过BpServiceManager来获取MediaPlayer服务:检索服务是否存在,当服务存在则返回相应的服务,当服务不存在则休眠1s再继续检索服务。该循环进行5次。为什么是循环5次呢,这估计跟Android的ANR时间为5s相关。如果每次都无法获取服务,循环5次,每次循环休眠1s,忽略checkService()的时间,差不多就是5s的时间
2.3 BpSM.checkService
[-> IServiceManager.cpp ::BpServiceManager]
检索指定服务是否存在, 其中remote()为BpBinder。
2.4 BpBinder::transact
[-> BpBinder.cpp]
Binder代理类调用transact()方法,真正工作还是交给IPCThreadState来进行transact工作,
2.4.1 IPCThreadState::self
[-> IPCThreadState.cpp]
TLS是指Thread local storage(线程本地储存空间),每个线程都拥有自己的TLS,并且是私有空间,线程之间不会共享。通过pthread_getspecific/pthread_setspecific函数可以获取/设置这些空间中的内容。从线程本地存储空间中获得保存在其中的IPCThreadState对象。
2.4.2 IPCThreadState初始化
[-> IPCThreadState.cpp]
每个线程都有一个IPCThreadState,每个IPCThreadState中都有一个mIn、一个mOut。成员变量mProcess保存了ProcessState变量(每个进程只有一个)。
mIn 用来接收来自Binder设备的数据,默认大小为256字节;
mOut用来存储发往Binder设备的数据,默认大小为256字节。
2.5 IPC::transact
[-> IPCThreadState.cpp]
2.6 IPC.writeTransactionData
[-> IPCThreadState.cpp]
其中handle的值用来标识目的端,注册服务过程的目的端为service manager,此处handle=0所对应的是binder_context_mgr_node对象,正是service manager所对应的binder实体对象。binder_transaction_data结构体是binder驱动通信的数据结构,该过程最终是把Binder请求码BC_TRANSACTION和binder_transaction_data结构体写入到mOut。
2.7 IPC.waitForResponse
[-> IPCThreadState.cpp]
2.8 IPC.talkWithDriver
[-> IPCThreadState.cpp]
binder_write_read结构体用来与Binder设备交换数据的结构, 通过ioctl与mDriverFD通信,是真正与Binder驱动进行数据读写交互的过程。 先向service manager进程发送查询服务的请求(BR_TRANSACTION),见Binder系列3—启动ServiceManager。当service manager进程收到该命令后,会执行do_find_service() 查询服务所对应的handle,然后再binder_send_reply()应答 发起者,发送BC_REPLY协议,然后调用binder_transaction(),再向服务请求者的Todo队列 插入事务。
接下来,再看看binder_transaction过程。
2.8.1 binder_transaction
这个过程非常重要,分两种情况来说:
当请求服务的进程与服务属于不同进程,则为请求服务所在进程创建binder_ref对象,指向服务进程中的binder_node;
当请求服务的进程与服务属于同一进程,则不再创建新对象,只是引用计数加1,并且修改type为BINDER_TYPE_BINDER或BINDER_TYPE_WEAK_BINDER。
2.8.2 binder_thread_read
2.9 readStrongBinder
[-> Parcel.cpp]
2.9.1 unflatten_binder
[-> Parcel.cpp]
2.9.2 getStrongProxyForHandle
[-> ProcessState.cpp]
readStrongBinder的功能是flat_binder_object解析并创建BpBinder对象.
2.9.3 lookupHandleLocked
根据handle值来查找对应的handle_entry.
二. 总结
请求服务(getService)过程,就是向servicemanager进程查询指定服务,当执行binder_transaction()时,会区分请求服务所属进程情况。
当请求服务的进程与服务属于不同进程,则为请求服务所在进程创建binder_ref对象,指向服务进程中的binder_node;
最终readStrongBinder(),返回的是BpBinder对象;
当请求服务的进程与服务属于同一进程,则不再创建新对象,只是引用计数加1,并且修改type为BINDER_TYPE_BINDER或BINDER_TYPE_WEAK_BINDER。
最终readStrongBinder(),返回的是BBinder对象的真实子类;