Android Binder 通信原理图文详解

前言

Binder机制可谓是Android 知识体系里的重中之重，作为偏底层的基础组件，平时我们很少关注它，而它却是无处不在，也是Android 面试易考察的点之一。网上很多文章，要么知识点比较陈旧，要么源码贴一堆，要么没有成体系地分析，导致读者一知半解，似是而非。
本篇将从流程上将Binder通信过一遍，尽量多用图展示。
通过本篇文章，你将了解到：

Binder的作用

进程与Binder驱动如何通信

ServiceManager进程的作用

进程添加服务到ServiceManager的流程

进程从ServiceManager获取服务的流程

Binder服务端数据接收

Binder 通信全流程图

1. Binder的作用

先看Linux下进程地址映射关系：

我们知道，对象调用本身就是地址空间的访问。

如上，进程之间各自访问各自的内存地址，它们之间无法直接访问对方的地址，也就是说微信不能直接调用支付宝提供的接口。而内核具有访问其它进程地址空间的权限，因此微信可以将消息发送给内核，让内核帮忙转发给支付宝，这种方式叫做：存储/转发方式。

由此衍生的几种IPC(进程间通信)如：管道、消息队列、socket等，而Android 上采用了新的机制：

Binder，相比传统的方式，Binder只需要一次数据拷贝，并且Binder更安全。

Binder机制是Android 里用来做IPC的主要方式。

2. 进程与Binder驱动如何通信

既然得要内核进行消息中转，那么Binder驱动得运行在内核空间，而事实上也确实如此，Binder驱动加载后在内核空间运行，进程只需要和Binder驱动取得联系，通过Binder驱动联系另一个进程，那么一次消息的传送过程就可以实现了。

内核提供提供一系列的系统调用接口给用户进程使用，当用户进程想要访问内核时，只需要调用对应的接口，此时代码就会从用户空间切换到内核空间执行。

常见的系统调用函数如：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

SM 注册进Binder驱动后就会等待来自Binder驱动的消息，这里列出了两个最常见的处理消息的Case：

其它进程添加服务到SM里

其它进程向SM查询服务

SM里维护着一个链表，链表的元素是结构体：

主要记录的是name和handle字段。
当SM收到添加服务的指令后，从Binder驱动里取出handle和name，并构造结构体插入到链表。
当SM收到查询服务的指令后，从Binder驱动里取出name，并找到链表里相同的name，找到后取出handle，最后写入到Binder驱动。

4. 进程添加服务到ServiceManager的流程

其它进程找到SM

现在SM已经翘首以盼其它进程的请求了，接着来看看如何添加一个服务到SM里。
以Java层添加服务为例，我们选择振动服务作为切入点分析。

在system_server 进程里构造振动服务(VibratorService继承自Binder)，并添加到SM里。

可以看出，分两步：

先找到ServiceManager

往ServiceManager里添加服务

getIServiceManager()继续往下：

BinderInternal.getContextObject() 是native方法，后续流程较多，我们用图表示。

寻找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();
    }

其中IPCThreadState与线程相关，不同的线程会维护一个单例。

由此可见，最终还是通过BpBinder发送消息，进而发送到Binder驱动。

此时驱动收到的信息包括不限于：

服务的名字

ServiceManager的handle

BBinder对象指针

驱动建立服务handle和BBinder对象指针的映射关系，并将服务的名字和服务的handle传递给ServiceManager(通过ServiceManager handle查找)。

ServiceManager拿到消息后建立映射关系，等待其它进程的请求。

至此，进程添加服务到ServiceManager过程已经分析完毕，用图表示如下：

BBinder作用

Java层传递的是Binder对象，如何与Native的BBinder关联起来呢？
重点在：

Parcel.writeStrongBinder(Binder)

也即是说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;
    }

由此可见，最终还是通过BpBinder发送消息，进而发送到Binder驱动。
此时驱动收到的信息包括不限于：

服务的名字

ServiceManager的handle

Binder驱动收到消息后，找到SM，并将服务的名字传给SM，SM从自己维护的链表里找到服务名相同的节点，最终取出该服务的handle，发送给Binder驱动。

用图表示如下：

对比添加服务流程和获取服务流程，两者前半部分都很相似，都是先拿到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()方法。
直接看图：

如上，通过驱动返回的handle构造BpBinder，最终封装为Java层的BinderProxy。

至此，获取服务流程就结束了，用图展示简化的流程

6. Binder服务端数据接收

微信进程拿到振动服务(在system_server进程里)的Binder(BinderProxy)后，就可以调用振动方法了，而后指令发送给驱动，驱动通过振动服务的handle找到对应的服务BBinder指针，从而调用服务的接收方法。
微信进程发送指令给Binder驱动前面已经分析过，重点来看看system_server进程是如何接收并处理指令的。

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机制的全过程：

以上就是整个Binder机制的梳理过程，此间省略了Binder驱动里的映射逻辑，可以将Binder驱动当做一个黑盒，而更重要的是Binder客户端和服务端是如何进行映射的。
Binder流程比较绕，尤其是IPCThreadStsate作为客户端的发送和服务端的数据接收的实体，需要区分不同的场景。
当然，jni基础知识必不可少。

本文基于Android 10

以上就是Android Binder 通信原理图文详解的详细内容，更多关于Android Binder 通信原理的资料请关注脚本之家其它相关文章！