Android中的IPC方式——Binder（一）

简单来说，Binder是Android中使用最广泛的IPC（进程间通信）机制。Linux中本身已经拥有了经典的进程间的通信方式，如信号量、管道、消息队列、贡献内存、scoket等。那么Android还是创造了新的IPC方式，主要是基于性能、稳定性和安全性方面考虑。

• 性能

  性能上的优势。Socket 作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。Binder 只需要一次数据拷贝，性能上仅次于共享内存。

  IPC方式	数据拷贝次数
  共享内存	0
  Binder	1
  Socket/管道/消息队列	2

• 安全性

  传统的 IPC 没有任何安全措施，完全依赖上层协议来确保。Android 作为一个开放性的平台，市场上有各类海量的应用供用户选择安装，所以Android 为每个安装好的 APP 分配了自己的 UID，故而进程的 UID 是鉴别进程身份的重要标志来鉴别身份。

• 稳定性

  基于C/S架构，客户端有什么需求丢给服务端来处理，架构清晰、职责明确又相互独立，自然稳定性更好。虽然贡献内存无需拷贝，但是控制复杂难以使用。

Linux进程间通信

基本概念介绍

上图展示了 Liunx 中跨进程通信涉及到的一些基本概念：

• 进程隔离

  进程与进程间内存是不共享的。两个进程就像两个平行的世界，A 进程没法直接访问 B 进程的数据，这就是进程隔离的通俗解释。A 进程和 B 进程之间要进行数据交互就得采用特殊的通信机制：进程间通信（IPC）。

• 进程空间划分

  操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也可以访问底层硬件设备的权限。为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用户空间（User Space）和内核空间（Kernel Space）。

• 系统调用

  从逻辑上进行了用户空间和内核空间的划分，但不可避免的用户空间需要访问内核资源，比如文件操作、访问网络等等。就需要借助 系统调用 来实现，这样保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。

Linux 下的传统 IPC 通信原理

消息发送方将要发送的数据存放在内存缓存区中，通过系统调用进入内核态。然后内核程序在内核空间分配内存，开辟一块内核缓存区，调用 copy_from_user() 函数将数据从用户空间的内存缓存区拷贝到内核空间的内核缓存区中。

同样的，接收方进程在接收数据时在自己的用户空间开辟一块内存缓存区，然后内核程序调用 copy_to_user() 函数将数据从内核缓存区拷贝到接收进程的内存缓存区。

传统的 IPC 通信方式有两个问题:

• 性能低下，一次数据传递需要经历：内存缓存区 --> 内核缓存区 --> 内存缓存区，需要 2 次数据拷贝
• 接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用 API 接收消息头来获取消息体的大小，这两种做法不是浪费空间就是浪费时间。

Binder 跨进程通信原理

从上面看出传统的跨进程通信是需要内核空间做支持的，但是Binder并不是 Linux 系统内核的一部分，这样怎么办呢？ Linux 有 动态内核可加载模块 （Loadable Kernel Module，LKM）的机制，模块是具有独立功能的程序，它可以被单独编译，但是不能独立运行。它在运行时被链接到内核作为内核的一部分运行。这样，Android 系统就可以通过动态添加一个内核模块运行在内核空间，用户进程之间通过这个内核模块作为桥梁来实现通信。

在 Android 系统中，这个运行在内核空间，负责各个用户进程通过 Binder 实现通信的内核模块就叫 Binder 驱动 （Binder Dirver）。

Binder IPC 方式主要是通过内存映射 mmap( ) 来实现， mmap() 是操作系统中一种内存映射的方法。内存映射简单的讲就是将用户空间的一块内存区域映射到内核空间。

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

一次完整的Binder IPC过程：

• 首先 Binder 驱动在内核空间创建一个数据接收缓存区；
• 接着在内核空间开辟一块内核缓存区，建立 内核缓存区 和 内核中数据接收缓存区 之间的映射关系，以及 内核中数据接收缓存区 和 接收进程用户空间地址 的映射关系；
• 发送方进程通过系统调用 copy_from_user() 将数据 copy 到内核中的 内核缓存区 ，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。

Binder 通信模型

Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager以及Binder驱动，其中ServiceManager用于管理系统中的各种服务。其中 Client、Server、 Service Manager 运行在用户空间 (存疑)，Binder 驱动运行在内核空间。

统观Binder中的各个组成元素，发现它和TCP/IP网络又很多相同之处。

• Binder驱动——路由器；
• Service Manager ——DNS;
• Binder Client ——客户端；
• Binder Server —— 服务端；

TCP/IP一个典型的连接过程

client和server建立连接通常有以下几个步骤：

• Client向DNS查询Google.com的IP地址。

  首先Client要知道DNS的IP地址才可以，这个是在Client接入网络之前就完成的。

  如果Client已经知道了Server的IP自然可以跳过这一个步骤直接与Server连接。比如windows下提供了一个hosts文件用于查询常用域名与IP的对应关系。

• DNS将查询到的结果返回给Client。

• Client得知Googlde.com的IP后，向Google服务器发起连接。

• 在这一系列流程中没有谈到Router，因为它的作用就是将数据包投递给目标IP。

在以上整个TCP/IP的模型中，IP地址是彼此间沟通的唯一凭证。其次Router是构建一个通信网络的基础，它根据用户的目标IP来把数据包正确的送达。最后DNS不是必须的。

类比下 Binder的流程：

进程1(客户端)想要和进程2(服务端)进行访问，因为他们之间是 跨进程的(跨网络)所以需要Binder驱动(Router)来把请求正确的投递到对方所在的进程(服务端)中，而参与通信的进程都需要持有Binder"颁发"的唯一标志(IP地址)。同样的Binder中的ServiceManager(DNS)也不是必须的，前提是Client能记住进程的Binder标志(IP地址)。特别注意的是这个Binder标志是”动态IP“，意味这每次访问都需要重新获取，而DNS可以完美的解决这个问题，用于管理Binder标志和域名之间的对应关系。

DNS有自己的IP地址， 那么ServiceManager在Binder的通信过程的唯一标志永远是0。