Android binder 设计思想

Android 的binder算得上十分复杂，各个击破固然能解决，但是我觉得其实当你理解了binder的设计思想后再去看代码感觉其实会发现binder不过如此而已：

1.binder中能跨进程通信的只有int/string/boolean等普通数据结构及IBinder的子类，如果需要跨进程传一个数据结构需要他是Parcelable的子类，即类似Java中的可序列化的。

2.一个类，继承了Binder，那么它的对象就可以被远程的进程使用了(前提是远程进程获取了这个类的对象【对象的引用】）比如：匿名binder。

3.一个Binder的proxy想调用对应的service的方法时，proxy与binder驱动的交互流程：BpBinder::transact() ---> IPCThreadState::transact() ---->writeTranscationData() 然后把数据和命令封装成一个binder_tansaction_data结构体。

4.binder通信的数据在binder驱动的流转过程：首先service有一个read线程在那里阻塞，等待一个新的待处理的task。proxy将数据封装好拷贝到驱动内核空间（这个空间是之前用mmap已经映射到目标进程了的），进而封装成一个事务挂到目标service进程的待处理链表上，唤醒service阻塞的进程，将数据映射到service的进程空间（这里采用共享内存的方式）。

5.binder proxy如何找到binder实体所在的进程？一个是查询ServiceManager，之前service已经将相关信息注册进去了，所以这个是ok的，另一个假设一个binder是通过作为数据传输到另一进程，这里比如注册回调。因为binder驱动会对binder数据做特殊的处理，在传过去的时候就记录好他的来源进程的信息，自然可以容易找到的。

6.binder 实体对象线程对接收到的请求的处理流程：IPCThreadState::executeCommand() -->BBinder::transact() -->  BBinder::onTranscact() 这里的onTransact（）其实是被重载了的比如BnMediaPlayerService。

7.BpInterface继承自BpRefBase，它里面有一个mRemote对象，他的类型是IBinder，实际指向一个BpBinder对象。应用与binder驱动的交互是通过IPCThreadState 进而通过ProcessState与binder驱动进行交互。

8.在binder驱动中每个进程有一个binder_proc结构体，每个线程有个binde_thread结构体，每个binder实体有个binder_node结构体，在传输一个binder给一个目标进程时，会检查目标进程的binder_procd对象是否有这个binder的应用binder_ref，如果没有就创建一个，并将binder实体所在进程的binder_proc对象挂载在binder_ref上，这样client进程就可以通过handler在自己的binder_ref上查找到对应的binder_proc,进而知道目标进程的binder_proc就可以把内容发给他了。

9.用户给binder驱动的数据，首先封装成一个binder_write_read,binder_write_read的write_buffer和read_buffer都是指向类型为binder_transaction_data的数据结构，这个才是真正要传输的数据。而binder_transaction_data的data.buffer指向传输的数据，data.offsets指向binder在数据中的偏移，所有跨进程传输的binder对象都封装成一个flat_binder_object对象，为什么这里要特别记住binder的位置，因为驱动会对传输的binder对象做特殊的处理包括为它在目标进程的binder_proc对象中创建一个引用。使client知道binder实体的所在的进程，实现实名/匿名的跨进程调用。