一、 获取服务
在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对象的真实子类；
