Binder机制的原理

Android系统中，涉及到多进程间的通信底层都是依赖于Binder 机制。例如当进程A中的Activity要向进程B中的Service通信，这便需要依赖于Binder IPC。

1.IPC原理

从进程角度来看IPC机制

 

每个 Android的进程，只能运行在自己进程所拥有的虚拟地址空间。对应一个4GB的虚拟地址空间，其中3GB是用户空间，1GB是内核空间，当然内核空间的大小是可以通过参数配置调整的。对于用户空间，不同进程之间彼此是不能共享的，而内核空间却是可共享的。Client进程向Server进程通信，恰恰是利用进程间可共享的内核内存空间来完成底层通信工作的，Client端与Server端进程往往采用ioctl等方法跟内核空间的驱动进行交互。

2.Binder原理

（1）Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及binder驱动，其中ServiceManager用于管理系统中的各种服务。架构图如下所示：

 

（2）Binder通信的四个角色

Client进程：使用服务的进程。

Server进程：提供服务的进程。

ServiceManager进程：ServiceManager的作用是将字符形式的Binder名字转化成Client中对该Binder的引用，使得Client能够通过Binder名字获得对Server中Binder实体的引用。

Binder驱动：驱动负责进程之间Binder通信的建立，Binder在进程之间的传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。

（3）Binder运行机制

注册服务(addService)：Server进程要先注册Service到ServiceManager。该过程：Server是客户端，ServiceManager是服务端。

获取服务(getService)：Client进程使用某个Service前，须先向ServiceManager中获取相应的Service。该过程：Client是客户端，ServiceManager是服务端。

使用服务：Client根据得到的Service信息建立与Service所在的Server进程通信的通路，然后就可以直接与Service交互。该过程：client是客户端，server是服务端。

图中的Client,Server,Service Manager之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过与Binder驱动进行交互的，从而实现IPC通信方式。其中Binder驱动位于内核空间，Client,Server,Service Manager位于用户空间。Binder驱动和Service Manager可以看做是Android平台的基础架构，而Client和Server是Android的应用层，开发人员只需自定义实现client、Server端，借助Android的基本平台架构便可以直接进行IPC通信。

进程间通信Scoket和Binder的区别：

（1）传输性能:

socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。

消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。

   共享内存虽然无需拷贝，但控制复杂，难以使用。

（2）安全性考虑:

Android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据，连接无线网络，长期操作底层设备导致电池很快耗尽等等。

      传统IPC没有任何安全措施，完全依赖上层协议来确保。

      首先，传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID，但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。

      其次，传统IPC访问接入点是开放的，无法建立私有通道。比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。

　　基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。

       Binder基于 Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。

（ 3）传输数据量：

      Socket TCP的传输方式假如发送的数据过大，linux kernel 下面的TCP/IP stack 会重新分成小包发送的,对于应用程序来说，不需要关心数据大小。

       在UDP的方式下面，会由于发送的数据大小超过了内核缓冲区的最大限制,这个限制好象是65535（默认情况下是64K），导致UDP通信收不到包，阻塞在recvfrom()。

       UDP方式传输一段完整数据的大小时受内核缓冲区限制的，比如在默认情况下缓冲区大小是64K，所以对于该情况下的socket接收或者发送方，最大可以一次性发送一个64K的数据。而对于socket底层的具体实现是将64K的数据拆分成N个小数据包，内部提供机制保证数据的可靠性，例如每个包的大小为1K，则分成64个包，从服务器端发送到客户端，客户端在本地缓冲区重新组成完整的数据提交给用户。底层的实现方式应该各不相同，但是对于上层结果都是一样的。如果超过了缓冲区大小则无法完成组包出现丢包等等现象。同理，对于200K则可以发送接收200K大小的数据。

       binder的数据是有大小限制的，在传输的时候，会先把数据从binder client拷贝到内核，然后从内核拷贝到binder server,数据的大小貌似是：4M