Android : 跟我学Binder ---- 什么是Binder机制？

Posted 2021-01-25 sheldon_blogs

一、引言

　　如果把android系统比作一幅精美绝伦的画，那Binder则是其浓墨重彩的独特一笔。初步了解过的人应该知道Binder是Android核心进程间通信(IPC:Internet Process Connection)手段之一，它是基于开源的 OpenBinder 实现，OpenBinder 起初由 Be Inc. 开发，后由 Plam Inc. 接手。从字面上来解释 Binder 有胶水、粘合剂的意思，顾名思义就是粘和不同的进程，使之实现通信。而日常开发中涉及到的如：AIDL、插件化编程技术 等等，底层通信实现都离不开Binder，所以如果想在“Android系统开发工程师”的头衔前面加上“高级”两个字，那理解、掌握Binder机制是必经之路。

 

二、Linux 下传统的进程间通信原理

　　首先了解一下 Linux IPC 相关的概念和原理有助于理解 Binder 通信原理。

　　1.Liunx 中跨进程通信涉及到的一些基本概念：

　　　　①进程隔离：进程间不可直接相互访问资源

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

 

　　　　②进程空间划分：用户空间(User Space)/内核空间(Kernel Space)

　　　　　　现在操作系统都是采用的虚拟存储器，对于 32 位系统而言，它的寻址空间（虚拟存储空间）就是 2 的 32 次方，也就是 4GB。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也可以访问底层硬件设备的权限。为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用户空间（User Space）和内核空间（Kernel Space）。针对 Linux 操作系统而言，将最高的 1GB 字节供内核使用，称为内核空间；较低的 3GB 字节供各进程使用，称为用户空间，它们在自己的空间运行，相互隔离。

 

　　　　③系统调用：用户态/内核态

　　　　　　虽然从逻辑上进行了用户空间和内核空间的划分，但不可避免的用户空间需要访问内核资源，比如文件操作、访问网络等等。为了突破隔离限制，就需要借助系统调用来实现。系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。当一个任务（进程）执行系统调用而陷入内核代码中执行时，称进程处于内核运行态（内核态），执行的内核代码会使用当前进程的内核栈，每个进程都有自己的内核栈。当进程在执行用户自己的代码的时候，则称其处于用户运行态（用户态）。系统调用主要通过如下两个函数来实现，在编写Linux设备驱动程序时经常用到：

　　　　　　copy_from_user() //将数据从用户空间拷贝到内核空间
　　　　　　copy_to_user() //将数据从内核空间拷贝到用户空间

　　2.Linux 下的传统 IPC 通信原理：

 

　　　　Linux的IPC通常做法是消息发送方将要发送的数据存放在内存缓存区中，通过系统调用进入内核态。然后内核程序在内核空间分配内存，开辟一块内核缓存区，调用 copy_from_user() 函数将数据从用户空间的内存缓存区拷贝到内核空间的内核缓存区中。同样的，接收方进程在接收数据时在自己的用户空间开辟一块内存缓存区，然后内核程序调用 copy_to_user() 函数将数据从内核缓存区拷贝到接收进程的内存缓存区。这样数据发送方进程和数据接收方进程就完成了一次数据传输。

 

　　但是这种传统的 IPC 通信方式有两个显著缺点：

 

1. 一次数据传递需要经历：内存缓存区 --> 内核缓存区 --> 内存缓存区，需要 2 次数据拷贝，效率低，可能此时会想到共享内存方式，但是其难于控制不稳定；
2. 接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用 API 接收消息头来获取消息体的大小，对于手机这种资源紧张的嵌入式移动设备来说无疑是巨大负担；

 

　　可见传统IPC效率低，占资源，除此之外还有安全、稳定性等缺点不足以胜任Android的核心进程间通信方式，下面正式介绍Binder机制，看其有何过人之处。

 

三、为何要用Binder通信机制？

　　Android系统的内核Linux已经有很多进程间通信的方式，比如：管道（Pipe）、信号（Signal）和跟踪（Trace）、插口（Socket）、报文队列（Message）、共享内存（Share Memory）和信号量（Semaphore）等 IPC 机制，那Android为何还要再实现一个Binder IPC 呢？主要是基于高效性、稳定性和安全性几方面原因。

　　1.高效性：对于手机移动通信设备来说，是基于Client-Server即C/S架构的通信方式，而上面提到的Linux传统IPC中只有socket支持Client-Server的通信方式，但是socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。

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

　　2.稳定性：Binder 基于 C/S 架构，客户端（Client）有什么需求就丢给服务端（Server）去完成，架构清晰、职责明确又相互独立，自然稳定性更好。所以从稳定性的角度讲，Binder 机制是也优于内存共享的复杂控制缺点。

　　3.安全性：Android 作为一个开放性的平台，市场上有各类海量的应用供用户选择安装，因此安全性对于 Android 平台而言极其重要。作为用户当然不希望我们下载的 APP 偷偷读取我的通信录，上传我的隐私数据，后台偷跑流量、消耗手机电量。传统的 IPC 没有任何安全措施，完全依赖上层协议来确保。首先传统的 IPC 接收方无法获得对方可靠的进程用户ID/进程ID（UID/PID），从而无法鉴别对方身份。Android 为每个安装好的 APP 分配了自己的 UID，故而进程的 UID 是鉴别进程身份的重要标志。传统的 IPC 只能由用户在数据包中填入 UID/PID，但这样不可靠，容易被恶意程序利用。可靠的身份标识只有由 IPC 机制在内核中添加。其次传统的 IPC 访问接入点是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。同时 Binder 既支持实名 Binder，又支持匿名 Binder，安全性高。

　　　　

　　Binder优势总结：

优势	描述
性能	只需要一次数据拷贝，性能上仅次于共享内存
稳定性	基于 C/S 架构，职责明确、架构清晰，因此稳定性好
安全性	为每个 APP 分配 UID，进程的 UID 是鉴别进程身份的重要标志

 

 

  另外上面讲过Linux IPC的通信原理，现在介绍一下Binder IPC 的通信原理：

　　正如前面所说，跨进程通信是需要内核空间做支持的。传统的 IPC 机制如管道、Socket 都是内核的一部分，因此通过内核支持来实现进程间通信自然是没问题的。但是 Binder 并不是 Linux 系统内核的一部分，那怎么办呢？这就得益于 Linux 的动态内核可加载模块（Loadable Kernel Module，LKM）的机制；模块是具有独立功能的程序，它可以被单独编译，但是不能独立运行。它在运行时被链接到内核作为内核的一部分运行。这样，Android 系统就可以通过动态添加一个内核模块运行在内核空间，用户进程之间通过这个内核模块作为桥梁来实现通信，此内核模块就叫 Binder 驱动（Binder Dirver）。

　　那么在 Android 系统中用户进程之间是如何通过这个内核模块（Binder 驱动）来实现通信的呢？难道是和前面说的传统 IPC 机制一样，先将数据从发送方进程拷贝到内核缓存区，然后再将数据从内核缓存区拷贝到接收方进程，通过两次拷贝来实现吗？显然不是，否则也不会有开篇所说的 Binder 在性能方面的优势了。这就不得说到 Linux 下的另一个概念：内存映射（mmap）：将用户空间的一块内存区域映射到内核空间。映射关系建立后，用户对这块内存区域的修改可以直接反应到内核空间；反之内核空间对这段区域的修改也能直接反应到用户空间，内存映射能减少数据拷贝次数，实现用户空间和内核空间的高效互动。两个空间各自的修改能直接反映在映射的内存区域，从而被对方空间及时感知。

　　但是 mmap() 通常是用在有物理介质的文件系统上的，比如对flash的操作，因为进程中的用户区域是不能直接和物理设备打交道的，如果想要把flash上的数据读取到进程的用户区域，需要两次拷贝（flash-->内核空间-->用户空间），通常在这种场景下 mmap() 就能发挥作用，通过在物理介质和用户空间之间建立映射，减少数据的拷贝次数，用内存读写取代I/O读写，提高文件读取效率。而 Binder 并不存在物理介质，因此 Binder 驱动使用 mmap() 并不是为了在物理介质和用户空间之间建立映射，而是用来在内核空间创建数据接收的缓存空间。

　　一次完整的 Binder IPC 通信过程通常是这样：

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

 

三、Binder通信模型

　　通过介绍、对比Android Binder IPC和Linux 传统IPC之间的差异，Binder IPC的各优点已经凸显出来，接下来看看实现层面是如何设计的？

　　一次完整的进程间通信必然至少包含两个进程，通常我们称通信的双方分别为客户端进程（Client）和服务端进程（Server），由于进程隔离机制的存在，通信双方必然需要借助 Binder 来实现。

4.1 Client/Server/ServiceManager/驱动

前面我们介绍过，Binder 是基于 C/S 架构的。由一系列的组件组成，包括 Client、Server、ServiceManager、Binder 驱动。其中 Client、Server、Service Manager 运行在用户空间，Binder 驱动运行在内核空间。其中 Service Manager 和 Binder 驱动由系统提供，而 Client、Server 由应用程序来实现。Client、Server 和 ServiceManager 均是通过系统调用 open、mmap 和 ioctl 来访问设备文件 /dev/binder，从而实现与 Binder 驱动的交互来间接的实现跨进程通信。

Client、Server、ServiceManager、Binder 驱动这几个组件在通信过程中扮演的角色就如同互联网中服务器（Server）、客户端（Client）、DNS域名服务器（ServiceManager）以及路由器（Binder 驱动）之前的关系。

通常我们访问一个网页的步骤是这样的：首先在浏览器输入一个地址，如 www.google.com 然后按下回车键。但是并没有办法通过域名地址直接找到我们要访问的服务器，因此需要首先访问 DNS 域名服务器，域名服务器中保存了 www.google.com 对应的 ip 地址 10.249.23.13，然后通过这个 ip 地址才能放到到 www.google.com 对应的服务器。