前言
Binder机制可谓是Android 知识体系里的重中之重，作为偏底层的基础组件，平时我们很少关注它，而它却是无处不在，也是Android 面试易考察的点之一。网上很多文章，要么知识点比较陈旧，要么源码贴一堆，要么没有成体系地分析，导致读者一知半解，似是而非。
本篇将从流程上将Binder通信过一遍，尽量多用图展示。
通过本篇文章，你将了解到：
- Binder的作用
- 进程与Binder驱动如何通信
- ServiceManager进程的作用
- 进程添加服务到ServiceManager的流程
- 进程从ServiceManager获取服务的流程
- Binder服务端数据接收
- Binder 通信全流程图
1. Binder的作用
先看Linux下进程地址映射关系：
image.png
我们知道，对象调用本身就是地址空间的访问。
如上，进程之间各自访问各自的内存地址，它们之间无法直接访问对方的地址，也就是说微信不能直接调用支付宝提供的接口。而内核具有访问其它进程地址空间的权限，因此微信可以将消息发送给内核，让内核帮忙转发给支付宝，这种方式叫做：存储/转发方式。
由此衍生的几种IPC(进程间通信)如：管道、消息队列、socket等，而Android 上采用了新的机制：Binder，相比传统的方式，Binder只需要一次数据拷贝，并且Binder更安全。
Binder机制是Android 里用来做IPC的主要方式。
2. 进程与Binder驱动如何通信
既然得要内核进行消息中转，那么Binder驱动得运行在内核空间，而事实上也确实如此，Binder驱动加载后在内核空间运行，进程只需要和Binder驱动取得联系，通过Binder驱动联系另一个进程，那么一次消息的传送过程就可以实现了。
image.png
内核提供提供一系列的系统调用接口给用户进程使用，当用户进程想要访问内核时，只需要调用对应的接口，此时代码就会从用户空间切换到内核空间执行。
常见的系统调用函数如：open/read/write/ioctl/close/mmap/fork 等。
与Binder驱动通信分两步：
- 打开Binder驱动：open("/dev/binder", O_RDWR | O_CLOEXEC)
- 通过ioctl 与Binder驱动进行数据通信：ioctl(mDriverFD, BINDER_WRITE_READ, &bwr)
bwr 为读写数据结构
3. ServiceManager进程的作用
Binder Client、Binder Server、ServiceManager关系
为方便起见，ServiceManager简称SM。
Binder 设计为C/S架构，C为Client(客户端)，S为Server(服务端），Server端提供接口(服务)给Client端使用，而这个服务是以Binder引用的形式提供的。
由之前的知识可知，C和S是不同的进程，那么C如何拿到S的Binder引用呢？
你可能会说，当然是SM了，S先将Binder引用存放在SM里，当C需要的时候向SM查询即可。
这么看似乎讲得通了，那问题又来了，SM也是一个单独的进程，那S、C如何与SM进行通信呢？这就陷入了先有鸡还是先有蛋的死循环了。
实际上C、S、SM之间都是依靠Binder通信，只是SM作为特殊的Binder(handle=0)提前放入了Binder驱动里，当C、S想要获取SM的Binder引用，只需要获取handle=0的Binder即可。
这么说没有太直观的印象，我们一步步剖析。
ServiceManager注册进Binder
image.png
SM 注册进Binder驱动后就会等待来自Binder驱动的消息，这里列出了两个最常见的处理消息的Case：
- 其它进程添加服务到SM里
- 其它进程向SM查询服务
SM里维护着一个链表，链表的元素是结构体：
image.png
主要记录的是name和handle字段。
当SM收到添加服务的指令后，从Binder驱动里取出handle和name，并构造结构体插入到链表。
当SM收到查询服务的指令后，从Binder驱动里取出name，并找到链表里相同的name，找到后取出handle，最后写入到Binder驱动。
4. 进程添加服务到ServiceManager的流程
其它进程找到SM
现在SM已经翘首以盼其它进程的请求了，接着来看看如何添加一个服务到SM里。
以Java层添加服务为例，我们选择振动服务作为切入点分析。
image.png
在system_server 进程里构造振动服务(VibratorService继承自Binder)，并添加到SM里。
image.png
可以看出，分两步：
- 先找到ServiceManager
- 往ServiceManager里添加服务
getIServiceManager()继续往下：
image.png
BinderInternal.getContextObject() 是native方法，后续流程较多，我们用图表示。
image.png
寻找ServiceManager的过程涉及到Java层和Native层，主要的重点在Native层查找ServiceManager对应的BpBinder对象，没有找到的话则创建新的并存入缓存里以备下次直接获取。
- ProcessState里维护了一个单例，每个进程只有一个ProcessState对象，创建ProcessState时候就会去打开Binder驱动，同时会设置Binder线程池里线程个数等其它参数
- Native层构造BpBinder(handle=0表示该BpBinder是ServiceManager在客户端的引用)，再构造BinderProxyNativeData持有BpBinder。
- 构造BinderProxy对象并持有BinderProxyNativeData，也就是间接持有BpBinder
- 最后构造了ServiceManagerProxy对象，它实现了IServiceManager接口，它的成员变量mRemote指向了BinderProxy
可以看出，获取ServiceManager的过程并不是真正去获取ServiceManager的Binder对象，而是获取它在当前进程的代理：BpBinder
添加服务到ServiceManager
既然找到了SM的Binder代理，接下来看看如何使用它给SM添加服务。
#ServiceManagerNative.ServiceManagerProxy
public void addService(String name, IBinder service, boolean allowIsolated, int dumpPriority)
throws RemoteException {
//构造Parcel
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IServiceManager.descriptor);
data.writeString(name);
//写入Binder
data.writeStrongBinder(service);
data.writeInt(allowIsolated ? 1 : 0);
data.writeInt(dumpPriority);
//通过BinderProxy发送
mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
reply.recycle();
data.recycle();
}
image.png
其中IPCThreadState与线程相关，不同的线程会维护一个单例。
由此可见，最终还是通过BpBinder发送消息，进而发送到Binder驱动。
此时驱动收到的信息包括不限于：
- 服务的名字
- ServiceManager的handle
- BBinder对象指针
驱动建立服务handle和BBinder对象指针的映射关系，并将服务的名字和服务的handle传递给ServiceManager(通过ServiceManager handle查找)。
ServiceManager拿到消息后建立映射关系，等待其它进程的请求。
至此，进程添加服务到ServiceManager过程已经分析完毕，用图表示如下：
image.png
BBinder作用
Java层传递的是Binder对象，如何与Native的BBinder关联起来呢？
重点在：
Parcel.writeStrongBinder(Binder)
image.png
也即是说Server端的Java Binder对象在Native层的代表是BBinder。
Binder驱动记录了BBinder的地址，当有消息过来时通过找到BBinder对象进而找到Java层的Binder对象，最终调用Binder.onTransact()。
5. 进程从ServiceManager获取服务的流程
其它进程找到SM
振动服务添加完成后，某些进程想要获取振动服务进行振动，比如微信收到消息后需要振动用以提示用户。
接着来看看如何获取振动服务。
private void vibrate() {
//获取振动服务
Vibrator vibrator = (Vibrator)getSystemService(Context.VIBRATOR_SERVICE);
//开始振动
vibrator.vibrate(1000);
}
与添加服务类似，想要获取服务先要找到SM，找SM的过程上边分析过了，此处不再细说。
从ServiceManager获取服务
#ServiceManagerNative.ServiceManagerProxy
public IBinder getService(String name) throws RemoteException {
//构造Parcel
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IServiceManager.descriptor);
//写入名字
data.writeString(name);
//通过BinderProxy发送
mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
IBinder binder = reply.readStrongBinder();
reply.recycle();
data.recycle();
return binder;
}
image.png
由此可见，最终还是通过BpBinder发送消息，进而发送到Binder驱动。
此时驱动收到的信息包括不限于：
- 服务的名字
- ServiceManager的handle
Binder驱动收到消息后，找到SM，并将服务的名字传给SM，SM从自己维护的链表里找到服务名相同的节点，最终取出该服务的handle，发送给Binder驱动。
用图表示如下：
image.png
对比添加服务流程和获取服务流程，两者前半部分都很相似，都是先拿到SM的BpBinder引用，然后写入驱动，最后由SM进程处理。只是对于获取服务流程来说，还需要将查询的结果(handle)写入驱动返回给调用方（对应图上红色部分）。
到这，大家可能会有疑惑了："handle是整形值，而微信获取的振动服务是一个Binder对象，这两者是怎么结合起来的呢？"
handle转换为Binder对象
handle表示的即是Binder服务端在客户端的索引句柄，只要客户端拿到了handle，它就能通过Binder驱动调用到服务端。
mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
IBinder binder = reply.readStrongBinder();
再回过头看看获取服务的代码，当微信进程将查询命令发给Binder驱动后就等待驱动回复的结果，SM查询到结果后将handle写入驱动，而后微信进程从驱动将结果读出并将结果存入reply字段。
最后通过reply拿到Binder引用，也就是说重点在reply.readStrongBinder()方法。
直接看图：
image.png
如上，通过驱动返回的handle构造BpBinder，最终封装为Java层的BinderProxy。
至此，获取服务流程就结束了，用图展示简化的流程
image.png
6. Binder服务端数据接收
微信进程拿到振动服务(在system_server进程里)的Binder(BinderProxy)后，就可以调用振动方法了，而后指令发送给驱动，驱动通过振动服务的handle找到对应的服务BBinder指针，从而调用服务的接收方法。
微信进程发送指令给Binder驱动前面已经分析过，重点来看看system_server进程是如何接收并处理指令的。
image.png
system_server进程启动的时候就会开启Binder线程池，并等待驱动数据到来。
当system_server进程添加振动服务到SM时，会将Java层的Binder转为Native层的BBinder，并将BBinder对象指针写入Binder驱动。
当微信进程调用system_server接口时：
- 微信进程调用BpBinder.transact()将handle和数据写入Binder驱动
- Binder驱动根据handle找到system_server进程
- system_server进程从驱动拿到数据，并取出BBinder指针，最终调用到system_server进程Java层的Binder.onTransact()
如此一来，微信成功调用了振动服务，也就是说一次Client到Server端的通信就完成了。
7. Binder 通信全流程图
纵观Binder机制设计，最核心的点是handle。
- 通过handle构造Client端的BpBinder(Native层)，与此对应的是Java层的BinderProxy
- 通过handle，驱动找到Server端进程，进而调用BBinder(Native层)，与此对应的是Java层的Binder
- 通过handle的一系列中转，Client.transact()成功调用了Server.onTransact()，一次Binder通信就过程就完成了
最后，用一张图总结Binder机制的全过程：
image.png
以上就是整个Binder机制的梳理过程，此间省略了Binder驱动里的映射逻辑，可以将Binder驱动当做一个黑盒，而更重要的是Binder客户端和服务端是如何进行映射的。
Binder流程比较绕，尤其是IPCThreadStsate作为客户端的发送和服务端的数据接收的实体，需要区分不同的场景。
当然，jni基础知识必不可少。
本文基于Android 10
限于篇幅并没有一步步列出源码，对源码细节有疑惑之处欢迎留言讨论。
您若喜欢，请点赞、关注、收藏，您的鼓励是我前进的动力
持续更新中，和我一起步步为营系统、深入学习Android/Kotlin
1、Android各种Context的前世今生
2、Android DecorView 必知必会
3、Window/WindowManager 不可不知之事
4、View Measure/Layout/Draw 真明白了
5、Android事件分发全套服务
6、Android invalidate/postInvalidate/requestLayout 彻底厘清
7、Android Window 如何确定大小/onMeasure()多次执行原因
8、Android事件驱动Handler-Message-Looper解析
9、Android 键盘一招搞定
10、Android 各种坐标彻底明了
11、Android Activity/Window/View 的background
12、Android Activity创建到View的显示过
13、Android IPC 系列
14、Android 存储系列
15、Java 并发系列不再疑惑
16、Java 线程池系列
17、Android Jetpack 前置基础系列
18、Android Jetpack 易懂易学系列
19、Kotlin 轻松入门系列
20、Kotlin 协程系列全面解读
网友评论