借助 AIDL 理解 Android Binder 机制——Binder 来龙去脉-CFANZ编程社区

内核程序将内核缓存区中通过 copy_to_user 函数将数据拷贝到数据接收方进程的内存缓存区

通过以上过程，一次 IPC 就完成了，但是这种传统的 IPC 机制有两个问题：

性能比较低：整个过程数据的传递需要经历发送方内存缓存区——内核缓存区——接收方内存缓存区的过程
接收方进程事先不知道需要开辟多大的内存用于存放数据，因此需要开辟尽可能大的空间或者事先调用 API 来解决这个问题，这两种方式不是浪费空间就是浪费时间。

Binder IPC 原理

为了克服 Linux 传统的 IPC 机制中的不足之处，Android 系统引入了 Binder 机制，从字面上看 Binder 是胶水的意思，在这里，Binder 的职责是在不同的进程之间扮演一个桥梁的角色，让它们之间能够相互通信。从上一小节内容可以了解到，进程间的通信少不了 Linux 内核的支持，而 Binder 并不属于内核的一部分，但是，得益于 Linux 的 LKM(Loadable Kernel Module) 机制：

因此，Binder 作为这种模块存在于内核之中，也称为 Binder 驱动。回顾上一小节的内容，传统 Linux IPC 的过程需要经历两次数据拷贝，Binder 借助 Linux 的另一个特性，只用一次数据拷贝，就能实现 IPC 过程，这就是内存映射：

内存映射能减少数据拷贝次数，实现用户空间和内核空间的高效互动。两个空间各自的修改能直接反映在映射的内存区域，从而被对方空间及时感知。也正因为如此，内存映射能够提供对进程间通信的支持。

Binder IPC 通信过程如下：

Binder 驱动在内核空间创建一个数据接收缓存区
然后在内核空间开辟一块内存缓存区并与数据接收缓存区建立映射关系，同时，建立数据接收缓存区与数据接收方的内存缓存区的映射关系
数据发送方通过系统调用 copy_from_user 函数将数据从内存缓存区拷贝到内核缓存区，由于内核缓存区通过数据接收缓存区跟数据接收方的内存缓存区存在间接的映射关系，相当于将数据直接拷贝到了接收方的用户空间，这样便完成了一次 IPC 的过程。

Binder 通信模型和通信过程

在进行 Binder IPC 的时候，实际情况比上面介绍的要复杂，Binder 通信模型是基于 C/S 架构的，通信调用方进程称为 Client 进程，被调用方称为 Server 进程，除此之外还需要 ServiceManager 和 Binder 驱动的参与，它们都是通过 open/mmap/iotl 等系统调用来访问设备文件 dev/binder 来实现 IPC 过程的。