AIDL 是 Android Interface Definition Language（Android 接口定义语言）的缩写，它是 Android 进程间通信的接口语言。由于 Android 系统的内核是 Linux，它采用了进程隔离机制，使得不同的应用程序运行在不同的进程当中，有时候两个应用之间需要传递或者共享某些数据，就需要进行进程间的通信讯。

Android 进程间通信的方式有很多种，比如 Messenger、文件（SharePreference）、AIDL、Socket 和 Content Provider 等，它们当中 Messenge、AIDL 和 Content Provider 的底层都是依赖于 Binder 机制去实现的。除此之外，Android 四大组件的启动和通信的核心过程也是通过 Binder 机制去实现的，这里，我们借助 AIDL 来了解 Binder 的实现机制。

在了解 AIDL 机制和用法之前，首先要了解几个概念，这对后续的深入理解有较大的帮助。

进程隔离

以下内容来自维基百科：

进程隔离是为保护操作系统中进程互不干扰而设计的一组不同硬件和软件的技术。这个技术是为了避免进程 A 写入进程 B 的情况发生。 进程的隔离实现，使用了虚拟地址空间。进程 A 的虚拟地址和进程B的虚拟地址不同，这样就防止进程 A 将数据信息写入进程 B。

Linux IPC 原理

由于 Linux 采用了虚拟地址空间技术，操作系统在逻辑上将虚拟内存分为用户空间（User Space）和内核空间（Kernel Space），普通应用程序运行在用户空间，系统内核运行在内核空间，为了控制应用程序的访问范围、保证系统安全，用户空间只能通过系统调用的方式去访问内核空间。当进程执行系统调用而陷入内核代码的时候，该进程则进入了内核态，相比之下，进程在用户空间执行自己的代码的时候，则是处于用户态。

由于进程 A 和进程 B 的虚拟地址不同，因此它们之间是相互透明的，都以为自己独享了系统的资源，当然也不能直接跟对方交互。但是，有些情况下有些进程难免会需要跟其他进程进行交互，这个交互过程就叫 IPC(Inter-Process Communication，进程间通信)。IPC 的实质就是数据的交互，因此我们这里将进行 IPC 过程中的通信调用方和被调用放分别称为数据发送方和数据接收方，IPC 通信的过程如下：

1. 数据发送方进程将数据放在内存缓存区，通过系统调用陷入内核态
2. 内核程序在内核空间开辟一块内核缓存区，通过 copy_from_user 函数将数据从数据发送方用户空间的内存缓存区拷贝到内核空间的内核缓存区中
3. 数据接收方进程在自己的用户空间开辟一块内存缓存区
4. 内核程序将内核缓存区中通过 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 机制中涉及到的内存映射通过 mmap() 来实现，mmap() 是操作系统中一种内存映射的方法。内存映射简单的讲就是将用户空间的一块内存区域映射到内核空间，映射关系建立后，用户对这块内存区域的修改可以直接反应到内核空间；反之内核空间对这段区域的修改也能直接反应到用户空间。

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

Binder IPC 通信过程如下：

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

Binder 通信模型和通信过程

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

其中，Client、Server 和 ServiceManager 运行在用户空间，Binder Driver 运行在内核空间，Client 和 Server 需由用户自己实现，ServiceManager 和 Binder Driver 则由系统提供。

Android Binder 设计与实现 文章中对 Client 和 Server 等角色有详细的描述：

Binder 驱动： Binder 驱动就如同路由器一样，是整个通信的核心；驱动负责进程之间 Binder 通信的建立，Binder 在进程之间的传递，Binder 引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。

ServiceManager 与实名 Binder： ServiceManager 和 DNS 类似，作用是将字符形式的 Binder 名字转化成 Client 中对该 Binder 的引用，使得 Client 能够通过 Binder 的名字获得对 Binder 实体的引用。注册了名字的 Binder 叫实名 Binder，就像网站一样除了除了有 IP 地址意外还有自己的网址。Server 创建了 Binder，并为它起一个字符形式，可读易记得名字，将这个 Binder 实体连同名字一起以数据包的形式通过 Binder 驱动发送给 ServiceManager ，通知 ServiceManager 注册一个名为“张三”的 Binder，它位于某个 Server 中。驱动为这个穿越进程边界的 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager。ServiceManger 收到数据后从中取出名字和引用填入查找表。

细心的读者可能会发现，ServierManager 是一个进程，Server 是另一个进程，Server 向 ServiceManager 中注册 Binder 必然涉及到进程间通信。当前实现进程间通信又要用到进程间通信，这就好像蛋可以孵出鸡的前提却是要先找只鸡下蛋！Binder 的实现比较巧妙，就是预先创造一只鸡来下蛋。ServiceManager 和其他进程同样采用 Bidner 通信，ServiceManager 是 Server 端，有自己的 Binder 实体，其他进程都是 Client，需要通过这个 Binder 的引用来实现 Binder 的注册，查询和获取。ServiceManager 提供的 Binder 比较特殊，它没有名字也不需要注册。当一个进程使用 BINDERSETCONTEXT_MGR 命令将自己注册成 ServiceManager 时 Binder 驱动会自动为它创建 Binder 实体（这就是那只预先造好的那只鸡）。其次这个 Binder 实体的引用在所有 Client 中都固定为 0 而无需通过其它手段获得。也就是说，一个 Server 想要向 ServiceManager 注册自己的 Binder 就必须通过这个 0 号引用和 ServiceManager 的 Binder 通信。类比互联网，0 号引用就好比是域名服务器的地址，你必须预先动态或者手工配置好。要注意的是，这里说的 Client 是相对于 ServiceManager 而言的，一个进程或者应用程序可能是提供服务的 Server，但对于 ServiceManager 来说它仍然是个 Client。

Client 获得实名 Binder 的引用： Server 向 ServiceManager 中注册了 Binder 以后， Client 就能通过名字获得 Binder 的引用了。Client 也利用保留的 0 号引用向 ServiceManager 请求访问某个 Binder: 我申请访问名字叫张三的 Binder 引用。ServiceManager 收到这个请求后从请求数据包中取出 Binder 名称，在查找表里找到对应的条目，取出对应的 Binder 引用作为回复发送给发起请求的 Client。从面向对象的角度看，Server 中的 Binder 实体现在有两个引用：一个位于 ServiceManager 中，一个位于发起请求的 Client 中。如果接下来有更多的 Client 请求该 Binder，系统中就会有更多的引用指向该 Binder ，就像 Java 中一个对象有多个引用一样。

因此，ServiceManager 是 Binder IPC 通信过程的核心，是上下文的管理者，Binder 服务端必须先向 ServerManager 注册才能够为客户端提供服务，Binder 客户端在与服务端通信之前需要从 ServerManager 中查找并获取 Binder 服务端的引用。Binder IPC 过程可以总结成以下步骤：

1. 某个进程使用 BINDER_SET_CONTEXT_MGR 命令通过 Binder 驱动将自己注册成 ServiceManager，负责管理所有的 Service
2. 各个 Server 通过 Binder 驱动向 ServiceManager 注册 Binder 实体，表明自己可以对外提供服务，这时 Binder 驱动会为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对该节点的引用，并将名字和该引用打包给 ServiceManager，ServiceManager 接收到数据包后将数据包中的名字和引用填入查找表中
3. Client 通过上面 Server 的名字在 Binder 驱动的帮助下从 ServiceManager 中获取到该 Server 对应的 Binder 引用对象，由于该引用对象同样具有 Server 的能力，因此 Client 可以通过这个引用与真实的 Server 进行交互

还是universus 老师的图：

总结

进程隔离虽然使操作系统的安全性和应用程序的稳定性得到了提升，但同时也给 IPC 带来了一定的难度，Android 系统巧妙地应用了 Binder 机制，使得系统得于在存储空间和硬件性能等有限的移动设备上能够流畅地运行。关于 Binder 在应用层的使用和分析，请看下一篇文章内容：借助 AIDL 理解 Android Binder 机制——AIDL 的使用和原理分析

参考文章

写给 Android 应用工程师的 Binder 原理剖析

Binder学习指南

如果你对文章内容有疑问或者有不同意见，欢迎留言，我们一同探讨。