小旭的专栏

当一个 Launcher 启动一个 APP 的时候，AMS 会通知 Zygote 进程 fork 出一个 APP 进程，然后加载 APP 进程的功能类 ActivityThread。APP 进程初始化（1）调用到 Native 层的 ProcessState 来获得 Binder 驱动的设备文件"/dev/binder"的文件描述符，并内存映射。（2）通过ProcessState启动Binder线程池，并且创建Binder主线程。该线程池对于当前进程有且仅有一个。

上一篇我们对 Parcel 进行了简单的介绍。这里我们选两个代表性的数据类型（String 和 Binder）来分析 Parcel 的处理流程，对应的接口分别是：writeString() / readString() 和 writeStrongBinder() / readStrongBinder()。接着上一篇从 Parcel C++ 类的构造过程开始分析。

同一进程间的对象传递都是通过引用来做的，因而本质上就是传递了一个内存地址。而跨进程采用了虚拟内存机制，两个进程都有自己独立的内存地址空间，所以跨进程传递的地址值是无效的。进程间的数据传递是 Binder 机制中的重要一环，Android 系统中担负这一重任的就是 Parcel。Parcel 是一种数据的载体，用于承载希望通过 IBinder 发送的相关信息（包括数据和对象引用）。正是基于 Parcel 这种跨进程传输数据的能力，进程间的 IPC 通信才能更加平滑可靠。

一个从 Client 到 Server 的调用流程总结如下：通过 bindService() 让 Zygote 进程 fork 出 Server 进程，完成 Server 进程的初始化功能加载。同时建立 Client 和 Server 的关系；

AIDL（Android Interface Definition Language）其实就是对 Binder 通信的一个封装，方便在开发中对 Binder 通信的使用，这里我们就从头开始来看一下 AIDL 通信的创建过程。

在 APP 开发中，四大组件中的 Activity 和 Service 是其中最常见的，在 Activity 启动 Service 的时候经常用到 bindService() 方法，而这就是建立 Binder 通信的过程。这一篇内容我们就来分析一下这里的 Binder 通信。

对于获取服务应该比较熟悉了吧，前面的很多内容都有获取系统服务的调用，这一篇我们就来详细介绍一下获取服务的流程。

前面的文章中我们介绍了 Java 层服务的注册流程，以及代理文件的查找。这里我们看一个 Binder 通信的实例，为了方便我们就以 Android 源码中现有的功能 PMS 的 install 为例，PMS 在进行 APK 安装时，会进行 dex 的翻译，依赖守护进程 installd 完成。

上一篇文章介绍到 ServiceManager 的 addService() 方法最终调用到 BinderProxy 的 addService() 方法。这里我们继续分析。

对于 Java 端使用 Binder 服务，主要就是注册服务和获取服务，入口都是通过 ServiceManager.java 中的对应方法实现。这里我们就先介绍一下 Java 注册 Binder 服务的流程。

通过 defaultServiceManager() 获取到 servciemanager 的代理 BpServiceManager；通过代理 BpBinder 调用 getService()，而 service 的 Binder 通过checkServcie() 获取；调用 BpBinder->transact() 将 code 、data、reply 传入，IPCThreadState->transact() 会 talkWithDriver() 调用；

前面几篇内容都介绍了 C++ 中新增服务的调用流程，这里我们看一个 Android 源码中的实例进一步熟悉 C++ 服务的添加流程，这里以 MediaPlayerService 为例。

上一篇我们介绍到，C++ 层通过代理调用 addService 最终调用到了 ServiceManager.cpp 的 addService() 方法，这里我们继续分析。

上一篇文章我们介绍了 Native 层获取 binder 的代理服务，这里我们针对注册服务流程接着往下看。

Client 端通过 defaultServiceManager() 接口调用获取到 sp 实例，而这个实例是全局变量 gDefaultServiceManager，其实就是 ServiceManagerShim 类型的对象；使用 ServiceManagerShim 类型的目的其实就是为了封装 AidlServiceManager，即该类中的成员变量 mTheRealServiceManager；

APP 进程 Binder 初始化过程和 ServiceManager 进程相差不大：（1）通过 open_driver() 打开设备文件 "dev/binder"，获得该设备文件描述符，和 Binder 驱动进行交互；（2）与 ServiceManager 进程打开设备文件不同的是，APP 进程使用的是系统默认的最大线程数 15，而 servicemanager 设置为 0；

Android Binder 的 Kernel 层也就是 Binder 的驱动层，位于 Binder 结构的最底层，这部分用于实现 Binder 的设备驱动。

上一篇文章介绍到 servicemanager 的 main 函数中主要做了四件事：1）初始化 binder 驱动。2）将自身以“manager”添加到 servicemanager 中的 map 集合中。3）注册成为 binder 驱动的上下问管理者。4）给 Looper 设置 callback，进入无限循环，处理 client 端发来的请求。这里我们对其进行详细介。

Binder Native 层主要负责实现进程间通信（IPC）和远程过程调用（RPC）的机制。在 Native 层中，Binder 架构主要包括服务端和客户端两部分。服务端存在一个 Binder 实体（BBinder）和对应的实体接口（BnInterface），而客户端存在一个 Binder 代理（BpBinder）和对应的代理接口（BpInterface）。服务端通过 Binder 驱动向 ServiceManager 进行注册，将 BBinde r的实体对象存入 ServiceManage r中。

JNI（Java Native Interface）是 Java 平台提供的一种机制，允许 Java 代码与本地应用程序（如C/C++）进行交互。在 Android 中，JNI 层主要用于实现 Java 层与底层 C/C++ 代码之间的通信。通过 JNI，Android 系统可以将一些性能要求较高的功能（如图像处理、音频处理等）用 C/C++ 实现，以提高系统的运行效率。本地方法实现：Java 层通过 JNI 调用底层 C/C++ 代码实现的方法。这些方法可能涉及到底层硬件操作、性能优化等。数据转换。

对于 Android 系统，一般是从 java 层到 native 层，再到 kernel 驱动层，形成一个完整的软件架构。Android 系统中的 Binder IPC 通信机制的整体架构也是如此，Java 和 C++ 层都定义有同样功能的供应用程序使用的 Binder 接口。

在 Android 系统中，在各个层次都有和 Binder 有关的实现。其中主要的 Binder 库由本地原生代码实现。Binder 库核心部分的各个头文件结构如下所示：Parcel.h：定义类 Parcel，为在 IPC 中传输的数据定义容器。IBinder.h：定义类 IBinder，是 Binder 对象的抽象接口。Binder.h：定义类 BBinder 和 BpRefBase 分别为 IBinder 类的继承者和服务器端使用的基类。

Binder 是 Android 系统中的一种进程间通信（IPC）机制，用于实现不同进程之间的通信和数据传递。它是一种高效、安全和稳定的机制，被广泛应用于 Android 系统中的各种组件和服务，包括 Activity、Service、ContentProvider 等。