新人阿彡的Android多媒体学习之路

🚄🚄🚄 第一章 Android Binder通信机制学习之Binder基本原理
 🚄🚄🚄 第二章 Android Binder通信机制学习之Binder基本架构
 🚄🚄🚄 第三章 Android Binder通信机制学习之ServiceManager流程分析

本章目录

新人阿彡的Android多媒体学习之路

0、前言

主要参考：https://zhuanlan.zhihu.com/p/35519585

作为一名新步入Android领域的职场老鸟，奈何最近环境不好，整体越来越卷的大背景下，本老鸟又新进入Android开发这个领域，后续工作基本应该是主攻Android Framework层的开发，辅助Android Applicatios层的开发，在这里记录一下个人的学习之旅，一方面方便自己学习总结，另一方面也方便后续的查漏补缺。整体学习基于Android 12 版本的代码。

1、Android为什么选择Binder通信

Android是基于Linux内核的，所以Android要实现进程间的通信，其实大可使用linux原有的一些手段，比如管道，共享内存，socket等方式，但是Android还是采用了Binder作为主要机制，主要是基于性能、稳定性和安全性几方面的原因。

性能
传统的管道队列模式采用内存缓冲区的方式，数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程，而Socket都知道传输效率低，开销大，用于跨网络进程交互比较多，共享内存虽然无需拷贝，但是实现过于复杂，难以使用。而Binder只需要一次拷贝，性能仅次于共享内存。
稳定性
Binder 基于 C/S 架构，客户端（Client）有什么需求就丢给服务端（Server）去完成，架构清晰、职责明确又相互独立，自然稳定性更好。共享内存虽然无需拷贝，但是控制负责，难以使用。从稳定性的角度讲，Binder 机制是优于内存共享的。
安全性
另一方面就是安全性。Android 作为一个开放性的平台，市场上有各类海量的应用供用户选择安装，因此安全性对于 Android 平台而言极其重要。作为用户当然不希望我们下载的 APP 偷偷读取我的通信录，上传我的隐私数据，后台偷跑流量、消耗手机电量。传统的 IPC 没有任何安全措施，完全依赖上层协议来确保。首先传统的 IPC 接收方无法获得对方可靠的进程用户ID/进程ID（UID/PID），从而无法鉴别对方身份。Android 为每个安装好的 APP 分配了自己的 UID，故而进程的 UID 是鉴别进程身份的重要标志。传统的 IPC 只能由用户在数据包中填入 UID/PID，但这样不可靠，容易被恶意程序利用。可靠的身份标识只有由 IPC 机制在内核中添加。其次传统的 IPC 访问接入点是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。同时 Binder 既支持实名 Binder，又支持匿名 Binder，安全性高。

综上所述，Android需要一种高效率，安全性高的进程通信方式，也就是Binder，Binder只需要一次拷贝，性能仅次于共享内存，而且采用的传统的C/S结构，稳定性也是没得说，发送添加UID/PID，安全性高。

2、Linux下进程间通信原理回顾

在这里插入图片描述
图片来源：https://zhuanlan.zhihu.com/p/35519585

基本概念：

进程隔离:
简单的说就是操作系统中，进程与进程间内存是不共享的。两个进程就像两个平行的世界，A 进程没法直接访问 B 进程的数据，这就是进程隔离的通俗解释。A 进程和 B 进程之间要进行数据交互就得采用特殊的通信机制：进程间通信（IPC）。
进程空间划分：用户空间（User Space）/内和空间（Kernel Space）
现在操作系统都是采用的虚拟存储器，对于 32 位系统而言，它的寻址空间（虚拟存储空间）就是 2 的 32 次方，也就是 4GB。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也可以访问底层硬件设备的权限。为了保护用户进程不能直接操作内核，保证内核的安全，操作系统从逻辑上将虚拟空间划分为用户空间（User Space）和内核空间（Kernel Space）。针对 Linux 操作系统而言，将最高的 1GB 字节供内核使用，称为内核空间；较低的 3GB 字节供各进程使用，称为用户空间。

图片来源：https://zhuanlan.zhihu.com/p/35519585

简单的说就是，内核空间（Kernel）是系统内核运行的空间，用户空间（User Space）是用户程序运行的空间。为了保证安全性，它们之间是隔离的。

系统调用：用户态/内核态
虽然从逻辑上进行了用户空间和内核空间的划分，但不可避免的用户空间需要访问内核资源，比如文件操作、访问网络等等。为了突破隔离限制，就需要借助系统调用来实现。系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。Linux 使用两级保护机制：0 级供系统内核使用，3 级供用户程序使用。当一个任务（进程）执行系统调用而陷入内核代码中执行时，称进程处于内核运行态（内核态）。此时处理器处于特权级最高的（0级）内核代码中执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。当进程在执行用户自己的代码的时候，我们称其处于用户运行态（用户态）。此时处理器在特权级最低的（3级）用户代码中运行。系统调用主要通过如下两个函数来实现：
copy_from_user() // 将数据从用户空间拷贝到内核空间
copy_to_user() // 将数据从内核空间拷贝到用户空间

传统IPC通信原理
通常的做法是消息发送方将要发送的数据存放在内存缓存区中，通过系统调用进入内核态。然后内核程序在内核空间分配内存，开辟一块内核缓存区，调用 copy_from_user() 函数将数据从用户空间的内存缓存区拷贝到内核空间的内核缓存区中。同样的，接收方进程在接收数据时在自己的用户空间开辟一块内存缓存区，然后内核程序调用 copy_to_user() 函数将数据从内核缓存区拷贝到接收进程的内存缓存区。这样数据发送方进程和数据接收方进程就完成了一次数据传输，我们称完成了一次进程间通信。如下图：
在这里插入图片描述
图片来源：https://zhuanlan.zhihu.com/p/35519585

这种传统的 IPC 通信方式有两个问题：

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

3、Binder跨进程通信原理

传统的 IPC 方式如Pipe、Socket 都是内核的一部分，通过内核支持来实现进程间通信，自然没问题。但是 Binder 并不是 Linux 系统内核的一部分，因此，需要借助 Linux 的动态内核可加载模块（Loadable Kernel Module，LKM）的机制，动态添加一个内核模块运行在内核空间中，这个内核模块就是Binder 驱动（Binder Dirver）。
Binder Dirver是通过内存映射，来进行进程通讯的。系统对外提供了一个函数mmap()，来做内存映射。它的原理是，将用户空间的一块内存区域映射到内核空间。用户对这块内存区域的修改，就可以直接反应到内核空间；同样的，内核空间对这块内存的修改，也能直接反应到用户空间。

但mmap通常用在有物理介质的文件系统上。因为，进程中的用户空间是不能直接访问物理设备的，所以，通常情况下，我们对磁盘上一个文件进行I/O读写时，系统先把磁盘的数据拷贝到内核空间，再从内核空间把数据拷贝到用户区域。这种情况下，就可以通过mmap来做映射，用内存读写取代I/O读写，省去了数据拷贝，提高效率。

#include <stdio.h>
#include <stdlib.h>
#include <cstring>
#include <sys/mman.h>
#include <unistd.h>
#include <fcntl.h>

int main()
{
    // 打开磁盘上的文件
    int fd = open("test.txt", O_RDWR|O_TRUNC|O_CREAT, 0664);
    // 指定文件大小
    ftruncate(fd, 15);
    // 获取文件长度
    int len = lseek(fd, 0, SEEK_END);
    // 映射地址
    char *memp = (char *)mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
    if (memp == MAP_FAILED) {
        perror("mmap error");
        exit(1);
    }

    // 关闭文件
    close(fd);
    // 将数据写入内存
    strcpy(memp, "hello world\n");
    // 关闭内存映射
    int ret = munmap(memp, len);
    if (ret == -1) {
        perror("munmap error");
        exit(1);
    }
    return 0;
}

如上代码，我们将一个文件映射到内存中，然后往内存中写入一串数据，数据将会同步写入文件中。
而 Binder 并不存在物理介质，因此 Binder 驱动使用 mmap() 并不是为了在物理介质和用户空间之间建立映射，而是用来在内核空间创建数据接收的缓存空间。一次完整的 Binder IPC 通信过程通常是这样：

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

图片来源：https://zhuanlan.zhihu.com/p/35519585

4、Binder通信基本模型

介绍完 Binder IPC 的底层通信原理，接下来我们看看实现层面是如何设计的。一次完整的进程间通信必然至少包含两个进程，通常我们称通信的双方分别为客户端进程（Client）和服务端进程（Server），由于进程隔离机制的存在，通信双方必然需要借助 Binder 来实现。
前面我们介绍过，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 驱动的交互来间接的实现跨进程通信。
在这里插入图片描述
图片来源：https://zhuanlan.zhihu.com/p/35519585

Client、Server、ServiceManager、Binder 驱动这几个组件在通信过程中扮演的角色就如同互联网中服务器（Server）、客户端（Client）、DNS域名服务器（ServiceManager）以及路由器（Binder 驱动）之前的关系。
在这里插入图片描述
图片来源：https://zhuanlan.zhihu.com/p/35519585

我们知道ServerManager也是属于用户空间的一个进程，主要作用就是作为Server和Client的桥梁，Client可以从ServerManager拿到Server中Binder实体的引用，这么说可能有点模糊，举个简单的例子，我们访问，www.google.com，谷歌首页页面就显示出来了，首先我们知道，这个页面肯定是发布在谷歌某个服务器上的，DNS通过这个网址，解析出对应的ip地址，再根据ip地址去访问对应的页面，然后再把数据返回给客户端，完成交互。这个和Binder的C/S非常类似，这里的DNS就是对应的ServerManager，首先，Server中的Binder实体对象，将自己的引用（也就是ip地址）注册到ServerManager，Client通过特定的key（也就是谷歌这个网址）和这个引用进行绑定，ServerManager内部自己维护一个类似MAP的表来一一对应，通过这个key就可以向ServerManager拿到Server中Binder的引用，对应到Android开发中，我们知道很多系统服务都是通过Binder去和AMS进行交互的，比如获取音量服务：AudioManager am = (AudioManager)context.getSystemService(Context.AUDIO_SERVICE);

但是这里ServerManager和Server也是两个不同的进程，Server要向ServerManager去注册不是也要涉及到进程间的通信吗？当前实现进程间通信又要用到进程间的通信？Binder的巧妙之处在于，当ServerManager作为Serve端的时候，它提供的Binder比较特殊，它没有名字也不需要注册，当一个进程使用BINDER_SET_CONTEXT_MGR命令将自己注册成ServerManager时Binder驱动会自动为它创建Binder实体，这个Binder的引用在所有Client中都固定为0而无须通过其它手段获得。也就是说，一个Server若要向ServerManager注册自己的Binder就必需通过0这个引用号和ServerManager的Binder通信，这里Server和Client属于两个不同的进程，Client怎么能拿到Server中对象，不妨先看看下面的交互图
在这里插入图片描述

Binder 通信中的代理模式
前面我们介绍过跨进程通信的过程都有 Binder 驱动的参与，因此在数据流经 Binder 驱动的时候驱动会对数据做一层转换。当 Client 进程想要获取Server进程中的 Object时，驱动并不会真的把Object返回给 Client ，而是返回了一个跟Object看起来一模一样的代理对象ProxyObject，这个ProxyObject具有和Object一摸一样的方法，但是这些方法并没有Server进程中Object对象那些方法的能力，这些方法只需要把请求参数交给驱动即可。对于Client进程来说和直接调用Object中的方法是一样的。当Binder驱动接收到Client进程的消息后，发现这是个ProxyObject就去查询自己维护的数据结构，一查发现这是Server进程Object的代理对象。于是就会去通知Server进程调用Object的方法，并要求Server进程把返回结果发给自己。当驱动拿到Server进程的返回结果后就会转发给Client进程，一次通信就完成了。

至此，我们大致能总结出 Binder 通信过程：

首先，一个进程使用BINDER_SET_CONTEXT_MGR命令通过 Binder 驱动将自己注册成为 ServiceManager；
Server 通过驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），表明可以对外提供服务。驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
Client 通过名字，在 Binder 驱动的帮助下从 ServiceManager 中获取到对应 Binder 实体的引用，通过这个引用就能实现和 Server 进程的通信。

我们看到整个通信过程都需要 Binder 驱动的接入。下图能更加直观的展现整个通信过程(为了进一步抽象通信过程以及呈现上的方便，下图我们忽略了 Binder 实体及其引用的概念)：
在这里插入图片描述
图片来源：https://zhuanlan.zhihu.com/p/35519585