Android系统工程师--小馬佩德罗

其实，Android系统的基础是Linux，它本可以使用Linux体系下的IPC机制，为什么还要再实现一个Binder机制呢？Binder更加灵活并节省内存；Binder还解决和避免了传统的进程间通信可能会增加进程开销的问题，也避免了进程过载和安全漏洞等方面的风险；用驱动程序来推动进程间通信；通过共享内存来提高性能；为进程请求分配每个进程的线程池；针对系统中的对象引入了引用计数和跨进程的对象引用映射；进程间同步调用；这几条听起来有点太学术了。

上一篇提到过，Android的系统服务运行在system_server进程的上下文中，因为大部分框架服务十分的简单，并不需要一个专门的进程，只需要以线程的形式承载就够了。system_server就被设计为这些线程的宿主进程。system_server是个容器进程。在Android中这样做甚至带来了一个更为重要的好处：尽管Dalvik虚拟机己经为共享内存做了大量的优化，但是在由同一个虚拟机可执行文件启动的另一个进程中运行各个服务，更有利于保护各类资源。

通过getSystemService()方法返回的对象只是一个系统服务的“代理”（Proxy），在这个对象内部记录着一个通过调用binder获得的指向实际服务的引用，而该对象导出的各个方法，在大多数情况下实际上也只是一些stub容器（Parcel），其中存放的是被顺序打包（序列化）到Binder消息里去的，需要传递给远程方法的各个参数。远程调用的各种方法及其参数就是以这一方式使用AIDL序列化的。

这种跨进程的通信方式依赖于Binder的用户空间为每个进程维护一个可用的线程池，IPC以及进程的本地消息等交由线程池处理和执行。:如前文所述，生成获取被调用方法的参数，并将其序列化（serialize)（即把它们顺序打包到内存里的一个结构体中去）或是解序列化（deserialize)（即把结构体中各个参数逐个还原出来）的代码的任务是由AIDL来完成的。Binder驱动用于实现Binder的设备驱动，主要负责组织Binder的服务节点，调用Binder相关的处理线程，完成实际的Binder传输等。

可以想象下，同一进程间的对象传递都是通过引用来做的，因而本质上就是传递了一个内存地址。这种方式在跨进程的情况下就无能为力了。由于采用了虚拟内存机制，两个进程都有自己独立的内存地址空间，所以跨进程传递的地址值是无效的。进程间的数据传递是 Binder 机制中的重要一环，Android系统中担负这一重任的就是 Parcel。Parcel 是一种数据的载体，用于承载希望通过 IBinder 发送的相关信息(包括数据和对象引用)。

Binder 实体对象binder_node的定义在内核代码 binder.c 中。//调试id struct binder_work work;//描述一个待处理的工作项 union {//挂载到宿主进程binder_proc的成员变量nodes红黑树的节点 struct hlist_node dead_node;//当宿主进程死亡，该Binder实体对象将挂载到全局binder_dead_nodes 链表中 };

声明其实对于Android系统Binder通信的机制早就有分析的想法，记得2019年6、7月份Mr.Deng离职期间约定一起对其进行研究的，但因为我个人问题没能实施这个计划，留下些许遗憾…文中参考了很多书籍及博客内容，可能涉及的比较多先不具体列出来了；本文使用的代码是LineageOS的cm-14.1，对应Android 7.1.2，可以参考我的另一篇博客：cm-14.1 Android系统启动过程分析（1）-如何下载Nexus5的LineageOS14.1(cm-14.1)系统源码并编译、刷机