Android: Binder: 彻底顿悟Android Binder

Binder机制可谓是Android 知识体系的重中之中，作为偏底层的基础组件，平时我们很少关注它，但是它却无处不在，这也是android面试考察点之一，本篇将从流程上将Binder通信过一遍。

 

文章目录

1：Binder作用

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

3：ServiceManager进程的作用

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

5：进程从ServiceManager获取服务的流程

6：Binder服务端数据接收

7：Binder通信全流程图

一：Binder作用 

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

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

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

基于这种方式衍生了几种 IPC（进程间通信）；

1：管道，消息队列，socket等。

而Android采用了新的机制：Binder ，这种方式只需要一次数据拷贝，并且Binder更加安全。

二：进程与 Binder驱动如何通信 

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

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

那么常见的系统调用函数接口如：

open/ read/ wirte/ioctl/ close/ mmap/ fork 等。 

用户进程与BInder通信步骤

1：打开Binder驱动： open("/dev/binder", O_RDWR| O_CLOEXEC);

2:  通过ioctl 与Binder驱动进行数据通信： ioctl(mDriverFD, BINDER_WRITE_READ,&bwr);

其中参数 bwr是读写数据结构。

三：ServiceManager进程的作用 。

先看下：Binder Client、Binder Server、ServiceManager之间关系

为了方便：ServiceManager简称为 SM。

Binder设计为C/S架构，C为Clinet(客户端)，S为Server（服务端），Server端提供接口给Client使用，而这个服务是以Binder引用的形式提供的。

我们知道，C和S是不同的进程，那么C如何拿到S的Binder引用了？

你可能会说，当然是SM了，S先将Binder引用存放在SM里，当C需要的时候向SM查询即可。

这样似乎可以讲通，但是SM也是一个单独的进程，那么S,C如何与SM通信了？这个实际上就陷入了 先有鸡还是先有蛋的问题。

其实面对这样的问题，一般就是系统给初始化。什么意思？

系统先将 SM作为特殊的 Binder（handle = 0）提前放入Binder驱动，当C,S想要获取SM的Binder引用，只需要获取 handle = 0的Binder即可。

3.1 SeerviceManager注册进 Binder驱动 

 SM注册进Binder驱动后就会 等待Binder驱动的消息，这里列举两个常见的处理消息的场景

1：其他进程添加服务到 SM这里。

2：其他进程向SM插叙服务。

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

 它主要记录 name和 handle字段。

1：当SM收到添加服务的指令后，从Binder驱动里取出 handle和name ,并构造结构体插入到 链表。

2：当SM收到查询服务的指令后，从 Binder驱动里取出 name, 并找到链表里对应name的 handle， 然后写入 Binder驱动，Binder驱动最后转发给 查询进程。

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

4.1：其它进程找到 SM

我们以振动服务作为切入点来分析

tranceBeginAndSlog("StartVibratorService")
vibrator = new VibratoeService(context);
ServiceManager.addService("vibrator", vibrator);
tranceEnd();

在system_server 进程里构造振动服务（VibratorService继承自Binder）,并添加到SM里

system_server /  addService

 源码可以看到，主要分为两步：

1：先找到 ServiceManager

2:  往ServiceManager里添加服务 

getIserviceManager()

 

 

其中 BInderINternal.getContextObject()是 native方法。我们重点看下 Native层。

serviceManager对应的 BpBinder对象，没有找到的话，创建新的并存取缓存里，方便下次直接获取。

1：ProcessState里维护了一个单例，每个进程只有一个ProcessState对象，创建ProcessState时候就会打开Binder驱动，同时会设置Binder线程池里线程个数等其他参数。

2：Native层构造BpBinder（handle = 0） 表示该BpBinder是ServiceManager在客户端的引用，同时在构造 BinderProxyNativeData持有BpBinder。

3： 构造BinderProxy对象并持有BinderProxyNativeData, 也就是间接持有BpBinder

4： 最后构造ServiceManagerProxy对象，它实现了 IServiceManager接口，它的成员变量mRemote指向了 BinderProxy。

可以看出，获取ServiceManager的过程并不是真正去获取ServiceManager的Binder对象，而是获取它再当前进程的代理： BpBinder

4.2:  添加服务扫ServiceManager 

既然刚刚我们找到了SM的Binder代理，接下来看看我们应该如何使用它给 SM添加服务。

#ServiceManagerNative.ServiceManagerProxy
public void addService(string name,  IBinder service,boolean allowIsolated,int dumpPriority)
{

    // 构造Parcel
    Parcel data = Parcle.obtain();
    Parcel reply = Parcle.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驱动上。

此时Binder驱动收到的消息包括但不限于：

1：服务的名字

2：ServiceManager的handle

3:  BBinder对象指针

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

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

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

 BBinder作用

java层传递的是Binder对象，那么如何与 Native的 BBinder关联起来了？

重点就在：下面这行代码。

Parcel.writeStrongBinder(Binder)

 

 也就是说，Server端的 java Binder对象在 Native层的代表是BBinder。

Binder驱动记录了BBinder的地址，当有消息过来时通过找到BBinder对象进而找到java层的 Binder对象，最终调用 Binder.onTransact()。

5： 进程从ServiceManager获取服务流程 

5.1：其他进程找到SM

振动服务添加完成后，某些进程想要获取振动服务，比如微信收到消息后需要振动用以提示用户。

我们看看，应该如何获取振动服务。

private void vibrate(){
    
    // 获取振动服务
    Vibrator vib = (Vibraator) getSystemService(Context.VIBRATOR_SERVICE);
    // 开始振动
    vib.virate(1000);
}

与添加服务类似，我们首先找到 SM，找到SM过程 和4.1是一样的，这里不必赘述。

5.2 从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驱动。

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

1：服务的名字

2： ServiceManager的 handle 

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

对比添加服务和获取服务的流程，两者前半部分都是相似的，都是先拿到SM的BpBinder引用，然后写入驱动，最后由SM进程处理，只是对于获取服务来说，还需要将查询的结果handle写入驱动返回给调用方。 

5.3：handle转换成Binder对象

问： 我们知道SM维护的链表中 handle是整形的，但是调用者接收的是Binder对象，这两个是怎么结合起来的了？

答：  handle表示的是Binder服务端在客户端的索引句柄，只要客户端拿到了 handle,它就能通过Binder驱动调用到服务端。

（SM将查询到结果后将 handle写入驱动，然后从驱动将结果存入 reply字段，最后通过 reply拿到 Binder引用，重点方法是： reply.readStrongBinder()）。

 

 

 通过驱动返回的handle构造 BpBinder ,最终封装为  java层的 BinderProxy。

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

6：Binder服务端数据接收 

在微信进程拿到振动服务（在system_server进程里）的Binder（BinderProxy）后，就可以调用振动方法了，然后指令发送给驱动，驱动通过振动服务的handle找到对应的服务 BBinder指针，从而调用服务的接收方法。

下面来看下system_server进程是如何接收并处理指令的。

system_server进程启动的时候，就会开启Binder线程池，并等待驱动数据到来。

当sytem_server进程添加振动服务到SM时，会将 java层的 Binder转为 Native层的BBinder,并将 BBinder对象指针写入Binder驱动。

当微信进程调用 system_server接口时：

1：微信进程调用BpBinder.transact()  将handle和数据写入Binder驱动

2： Binder驱动根据handle找到 system_server进程

3：system_server进程从驱动拿到数据，并取出BBinder指针，最终调用 到 system_server进程java层的  Binder.onTransact()；

如此一来：微信程序成功调用了振动服务，也就是所一次 Client和 Service端的通信就完成了。

7：Binder通信全流程图 

 整个设计中，核心是 handle，现在我们简单的总结一下

1：通过handle构造 Client端的BpBinder(Native层)，与此对应的是java层的 BinderProxy

2：通过handle驱动找到server端进程，进而调用BBinder(Native层)，与此对应的是java层的Binder。

3：通过handle的一系列中转，Client,transact() 成功调用了 Server。onTransact() 一次Binder通信过程就完成了。

以上：就是整个Binder机制的梳理过程，此间省略了Binder驱动里的映射逻辑，可以将BInder驱动当做一个黑盒，更重要的是  Binder客户端和服务端是如何进行映射的。