深入浅出Binder进程间通信机制

Posted 2023-04-01

参考技术A Linux传统IPC机制主要有已下几种：管道、消息队列、共享内存Socket等。消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。

同时从安全性角度考虑，android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。传统IPC没有任何安全措施，完全依赖上层协议来确保。首先传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID，但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。

由于传统的IPC机制有这样那样不让人满意的原因。Android自己开发了一套进程间通信机制Binder通信。Binder机制起源于一个简单的想法：将申请服务的请求和对应的响应信息，写入一个所有进程均能够访问的地址空间中。当进程需要使用这些数据时，只需要访问对应的内存地址，以减小内容复制引入的开销。为此，Binder机制利用kernel空间作为共享区域，并由Binder driver来建立起每个进程的内存地址与kernel空间中存储地址的映射。从而使数据只要拷贝一次就可以。同时为发送方添加UID/PID身份，既支持实名Binder也支持匿名Binder，提高安全性。

Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及Binder驱动，其中ServiceManager用于管理系统中的各种服务。如上图所示Binder在Framework层和Native层分别有对应的客户端（Client）、服务（Server）的和服务管理器（Service Manager）。同时在Kernel层（内核空间）有Binder的驱动设备。

这四个角色的作用分别是：

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

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

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

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

首先需要注册服务端，只有注册了服务端，客户端才有通讯的目标，服务端通过 ServiceManager 注册服务，注册的过程就是向 Binder 驱动的全局链表 binder_procs 中插入服务端的信息（binder_proc 结构体，每个 binder_proc 结构体中都有 todo 任务队列），然后向 ServiceManager 的 svcinfo 列表中缓存一下注册的服务。

注册完服务后客户端就能够查询并获取注册了的服务了。客户端向ServiceManager 发起获取服务的请求，传递要获取服务的名称。ServiceManager 从服务列表中查找到Client需要的对应服务信息，将该服务的代理Binder（BinderProxy）返回给客户端。其实查询服务相当于ServiceManager 作为服务端，客户端进行使用。所以这也是一次Binder使用服务的过程。

使用服务的过程如上图。

① Binder驱动为跨进程通信做准备：通过调用mmap()系统函数实现内存映射。在Binder驱动中创建一块接收缓存区。同时将内核缓存区地址和Server端中用户空间一块地址同时都映射到该接收缓存区中。这时候就创建了虚拟区间和映射的关系。

② Client进程将数据发送到Server进程。Client进程通过调用copy_from_user()发送数据拷贝到内核中（Binder驱动）的缓存区中，此时Client发起请求的线程会被挂起。由于在①中构建了映射关系，此时相当于也将数据发送到了Server端的用户空间中。之后Binder驱动通知Server端进程执行解包。

③ Server进程根据Client进程发送来的数据，调用目标方法。收到Binder驱动通知后，Server进程对数据进行解包，并调用相关方法处理。

④ Server进程将目标方法处理结果返回给Client进程。将处理结果放回自己的共享空间（即①中映射的Binder驱动缓存区中）。Binder驱动通知Client进程获取返回结果，此时②中被挂起的线程会被重新唤醒。Client进程通过系统调用copy_to_user(),从内核缓存区拷贝Server进程返回的结果。

从上面使用服务的过程可以看到，整个过程只拷贝了一次发送的数据和一次接收的数据。而正如开头所述，消息队列和管道这两种IPC拷贝次数为2次。

Binder模型的线程管理采用Binder驱动线程池，由Binder驱动进行管理，而不是由Server进程来管理。而一个进程的Binder线程默认线程数默认最大是16。也就是说Client的请求数一旦超过16个会被阻塞直到有空间的Binder线程。