首页 > 软件编程 > Android > Android Binder

Android 图文详解Binder进程通信底层原理

2021-10-23 10:32:59 作者：帅次

Android系统中，多进程间的通信都是依赖于底层Binder IPC机制，Binder机制是一种RPC方案。例如：当进程A中的Activity与进程B中的Service通信时，就使用了binder机制

之前了解到进程与多进程，涉及多进程不可避免的遇到了进程间通信，说到进程间通信，Binder 成了一道绕不过的坎。接下来咱们逐一了解。

🔥 什么是进程间通信

进程间通信(IPC，Inner Process Comunication)，就是指不同进程之间的信息传递。

进程是系统进行资源分配和调度的基本单位，是操作系统的结构的基础；一个应用至少有一个进程，一个进程中有包含了多个线程(线程是CPU调度的最小单位)，进程相当于是线程的ViewGroup，线程相当于操作系统分配个进程的View。

🔥 什么是 Binder

Binder 是 Android 系统中进程间通信机制(IPC)的一种方式，它是这些进程间通讯的桥梁。正如其名"粘合剂"一样，它把系统中各个组件粘合到了一起，是各个组件的桥梁。

应用层：是一个能发起通信的Java类。

Client：是对 Binder 代理对象，是 Binder 实体对象的一个远程代理。
Server：是 Server 中的 Binder 实体对象。

机制：是一种进程间通信机制。

驱动：是一个虚拟物理设备驱动；

如startActivity的简图：

这里就用到了 Binder 通信，你会发现这里还有 Socker 通信，那我为什么要用 Binder 而不用 Socket。

🔥 Android 中 IPC 的方式

名称	特点	使用场景
Bundle	只能传输实现了序列化或者一些Android支持的特殊对象	适合用于四大组件之间的进程交互
文件	不能做到进程间的即时通信，并且不适合用于高并发的场景	适合用于SharedPreference以及IO操作
ContentProvider	可以访问较多的数据，支持一对多的高并发访问，因为ContentProvider已经自动做好了关于并发的机制	适合用于一对多的数据共享并且需要对数据进行频繁的CRUD操作
Socket	通过网络传输字节流，支持一对多的实时通信，但是实现起来比较复杂	适合用于网络数据共享
Messenger	底层原理是AIDL，只是对其做了封装，但是不能很好的处理高并发的场景，并且传输的数据只能支持Bundle类型	多进程、单线程且线程安全
AIDL	功能强大，使用Binder机制,支持一对多的高并发实时通信，但是需要处理好线程同步	一对多并且有远程进程通信的场景

🔥 Binder 优势

出发点	Binder	共享内存	Socket
性能	拷贝一次	无需拷贝	拷贝两次
特点	基于C/S架构，易用性高	控制复杂，易用性差	基于C/S架构，通用接口，传输效率低、开销大
安全	每个APP分配UID，同时支持实名和匿名	依赖上层协议，访问接入点是开放的不安全	依赖上层协议，访问接入点是开放的不安全

通过以上对比，Android 最终选择了自建一套兼顾好用、高效、安全的 Binder。

好用：基于C/S架构，易用性高
高效：用 mmap() 进行内存映射，只需一次拷贝
安全强：每个 APP 分配UID(进程的身份证号)，同时支持实名(系统服务)和匿名(自己创建的服务)

可以让自己的服务前往 ServiceManager 注册，注册后实名。

🔥 Linux 传统的 IPC 原理

了解 Linux IPC 相关的概念和原理有助于我们理解 Binder 通信原理。因此，在介绍 Binder 跨进程通信原理之前，我们先聊聊 Linux 系统下传统的进程间通信是如何实现。

💥 基本概念

由上图看出：

进程隔离。
进程空间划分：用户空间(User Space)/内核空间(Kernel Space)。
系统调用：用户态/内核态。

🌀 进程隔离

操作系统中，进程与进程间内存是不共享的。SCC 进程无法直接访问 Service 进程的数据。SCC 进程和 Service 进程之间要进行数据交互就得采用进程间通信(IPC)。

🌀 进程空间划分

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

内核空间(Kernel Space)：是系统内核运行的空间;
用户空间(User Space)：是用户程序运行的空间。

所有内核空间(虚拟地址)都映射在同一块物理内存，这样就实现了内存共享(所有进程可通过IPC访问)。

为了保证安全性，它们之间是隔离的。即使用户程序蹦了，内核也不受影响。

🌀 系统调用

进程内用户空间 & 内核空间进行交互需通过系统调用，主要通过函数：

copy_from_user()：将用户空间的数据拷贝到内核空间；
copy_to_user()：将内核空间的数据拷贝到用户空间。

用户态：当进程在执行用户自己的代码的时候，我们称其处于用户运行态(用户态)；

内核态：当一个进程执行系统调用而陷入内核代码中执行时，称进程处于内核运行态(内核态)。

系统调用是用户空间访问内核空间的唯一方式。

💥 传统 IPC 通信原理

如图，这就是 Sokcet的拷贝两次。

当然目前 Linux 已经引入 Binder 通信机制。

🔥 Binder IPC原理

上面整了一堆 Linux 下的 IPC 相关概念及原理，接下来我们正式介绍下 Binder IPC 的原理。

💥 Binder 采用分层架构设计

应用层: 对于应用通过调用startActivity()然后调用 AMP.startService , 经过层层调用,最终必然会调用到AMS.startService。
Framework: 客户类BinderProxy和服务类Binder(Binder通信是采用C/S架构, Android系统的基础架构便已设计好Binder在Java )。
Native层: 对于Native层,可以直接使用BpBinder和BBinder(当然这里还有JavaBBinder)即可, 对于上一层Framework 的通信也是基于这个层面。
Kernel: 这里是Binder Driver, 前面3层都跑在用户空间,对于用户空间的内存资源是不共享的,每个Android的进程只能运行在自己进程所拥有的虚拟地址空间, 而内核空间却是可共享的. 真正通信的核心环节还是在Binder Driver。

💥 Binder 驱动

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

💥 Binder IPC 内存映射

Binder IPC 正是基于内存映射（mmap）来实现的，一次完整的 Binder IPC 通信过程通常是这样：

1、Binder 驱动在内核空间创建一个数据接收缓存区；

2、在内核空间开辟一块内核缓存区，

建立内核缓存区和内核中数据接收缓存区之间的映射关系；
内核中数据接收缓存区和接收进程用户空间地址的映射关系；

3、发送数据完成了一次进程间的通信。

发送方进程通过系统调用 copy_from_user() 将数据拷贝到内核中的内核缓存区；
由于内核缓存区和数据接收缓存区存在内存映射，因此也就相当于把数据发送到了数据接收缓存区；
由于数据接收缓存区和进程的用户空间存在内存映射因此也就相当于把数据发送到了接收进程的用户空间。

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

Binder传值限制：

原来的 BINDER_VM_SIZE：((1 * 1024 * 1024) - 4096 * 2)
现在的BINDER_VM_SIZE：((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2)

sysconf(_SC_PAGE_SIZE)：这个函数用来获取系统执行的配置信息。例如页大小、最大页数、cpu个数、打开句柄的最大个数等等。

这个值表示你Binder最多传这么多，超出就失败。

💥 Android Binder 原理图

🌀 Bind 原理图

Binder通信采用C/S架构，从组件视角来说，包含Client、Server、ServiceManager 以及 Binder 驱动，其中 ServiceManager 用于管理系统中的各种服务。

此处的ServiceManager是指Native层的ServiceManager（C++），并非指framework层的ServiceManager(Java) 原因：

所以，原理图可表示为以下：

🌀 Bind 原理图交互

Client、Server、ServiceManager属于进程空间的用户空间，不可进行进程间交互(下图虚线表示)。

所以他们都通过与 Binder 驱动进行交互的，从而实现IPC通信方式。