Binder通信学习总结

本文是笔者学习Binder通信机制的要点总结，并没有对Binder通信机制进行详细的介绍。

在开始本文之前，给大家推荐两篇文章，第一篇是Android Binder设计与实现 – 设计篇，该文从宏观上讲解了Binder通信机制的四个模块，各个模块之间的关系以及各个模块设计的原则，遗憾的是半部残书，只有设计篇没有实现篇；第二篇是Android进程间通信（IPC）机制Binder简要介绍和学习计划老罗的Binder通信机制系列博客，该文详细的讲解了Binder通信的流程。

Binder通信是Android系统中跨进程通信中最常用的方式。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中，以至于在写应用程序的时候都感觉不到Binder的存在，其实Binder通信无处不在。

Binder这个概念比较难理解，它既不是指一个具体的对象也不是指一个具体的服务。Binder是一种跨进程通信的机制，它有四个模块组成：Client、Server、ServiceManager、Binder驱动。对Server而言，Binder可以看成访问Server的某个特定服务的接入点， Client通过这个‘地址’向Server发送请求来使用该服务；对Client而言，Binder可以看成是通向Server的管道入口，要想和某个Server通信首先必须建立这个管道并获得管道入口。ServiceManager相当于一个注册表，Server启动成功后都会注册在ServiceManager中。Binder驱动是Binder通信中最重要的部分，驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持，Binder线程池的管理等。
Binder跨进程通信的主要特点有两个：

（1）Binder通信是单项的，例如Activity与AMS通信的时候，Activity进程中有AMS的代理ActivityManagerProxy，AMS进程中有ApplicationThread的代理ApplicationThreadProxy。
笔者认为，由于google的大牛们从易用性、安全性等方面出发设计Android系统的跨进程通信Binder机制，导致了Binder通信的单向性。

（2）Binder跨进程通信只需要一次数据拷贝，这里的一次拷贝是指有效数据(binder_write_read数据对象的write_buffer字段中)进行了一次拷贝，而消息头（binder_write_read、binder_transaction_data）还是拷贝了两次。数据的拷贝使用的copy_from_user()和copy_to_user()这两个跨空间拷贝方法。

下面分析Binder通过一次数据传递实现跨进程通信的原因。Binder驱动程序位于内存的内核空间，Binder服务程序位于位于内存的用户空间，为Binder驱动和Binder服务分配了同一块物理内存地址，它们的虚拟地址有一个proc->user_buffer_offset大小的距离。所以首先，Client的数据从用户空间通过copy_from_user()函数传递到Binder驱动的内核空间中，这个过程中数据的物理地址发生了变化；然后，数据从Binder驱动的内核空间中通过copy_to_user()函数传递到Server的用户空间中，这个过程中只传递了数据的虚拟地址，数据的物理地址没有变化。