3. Android binder设计篇

一. 引言--女娲造人的故事

在天地混沌之际，上神女娲因为觉得自己太孤单，没人跟它一起嗨，决定按照自己的模样添加一些生物；于是呢，捏泥为人，并赋予了人生育的能力，所以女娲被称为了人类的母亲；

神话故事很美好，解释了人类的来源，但是这个逻辑中其实有个缺陷，就是女娲从哪里来的？

那有些同学就会问了，这里说Binder设计，为什么要提到女娲造人的故事呢？这是因为二者在源头这个问题的处理上有异曲同工之妙，嗯，后面会再做说明。

二. Android Binder简介

Andoid Binder从Open Binder发展而来，提供了跨进程通信机制；其实linux已经提供很多的跨进程机制，比如管道，共享内存等等，那为什么google要使用binder呢？

其实，大家也可以思考下，针对于移动设备这种低配置的设备(相对于服务器)，新的进程间通信机制需要具备什么新的优点呢？

1. 内存节省，因为移动设备的低配置，所以需要新的通信机制尽可能的节省资源，binder在跨进程数据拷贝时只进行一次；

2. 高效性，比如对于手机这种东西，大家肯定希望它反应迅速，界面流畅；

3. 安全性，手机涉及了大量的用户隐私，比如支付宝账号，电话本联系人号码，短信记录，通话记录等等；

在linux系统中对于权限安全性管理，UID是一个很重要的东西，所以对于安全性，binder就在binder driver里面负责填写调用进程的UID和PID；相比一些在应用程序填写UID和PID的进程间通信机制，安全性得到了极大提高。

总体来说，Binder肯定是一个不错的进程间通信机制，否则android经过这么多年的发展，如果Binder不是足够优秀的话，以google的技术实力，早就被google替换了吧！

三.Binder通信关系总图

Binder作为Android里面进程间通信机制，主要有4个模块参与这个过程，分别是

client

service

ServiceManager

Binder Driver

client和service作为通信的模块很容易理解，因为client需要和service通信，所以它们两个必然会成为通信的一部分。

那service manager和Binder driver起的作用是什么呢？

service manager提供service的注册，查询等服务，那说的再明白一点，就是service Binder本地对象把自己和一个名字添加到service manager注册；

这样，client就可以向service manager通过指定的名字去查询之前注册的service，从而找到对应的Binder实体对象，再继而生成属于自己进程的Binder 引用对象。

最后把这个属于自己进程的Binder引用对象和自己进程内的一个Binder代理对象对应起来；这样client就间接的拥有了service Binder本地对象的引用，进而可以和service通信。

那Binder driver是做什么用的呢？

Binder driver提供的是桥梁的作用，比如从service注册是service manager,抑或从client到service mangager查询service，以及从client到service的通信，都需要通过Binder driver。

所以Binder driver提供了一个桥梁，同时在通信的过程中记录了一些数据。

为了更好的说明，先上一张整体Binder的关系图。

这张图已经基本包括了binder通信过程中的所有对象，我们可以用言语来简略的描述下这个过程和各个对象的含义，至于更详细的我们后面再讲。

过程简短描述：

1. 首先这张图有两个空间，用户空间和内核空间；client, service,service manager运行在用户空间；而binder driver运行在内核空间。

2. service manager首先注册为binder driver的服务管理者，注册的过程中，service manager会调用open和mmap方法来通知binder driver为它分配一块最大不超过4MB的内存，当然这个大小可以由service manager来指定，service manager指定的是128KB。这块内存同时被两个虚拟地址应用，一个binder driver的一个是service manager的。

换句话就是说binder driver为service manager分配了一块同时被内核空间和用户空间映射的内存。

这也是binder驱动的精华，通过这种虚拟内存双重映射，减少了binder driver和service manager之间的数据拷贝。

3. 这样，binder driver就记录下了与service manager 对应的binder实体对象(也就是图中的sm binder实体)。

并且强制规定sm binder实体对象对应的是句柄值是0。也就是其他进程来访问service，只要它传到binder driver的句柄值是0，那就意味着目标service就是service manager。

然后service manager进程进入等待状态，等待别的进程来唤醒。比如别的进程要注册service或者查询service。

4. service进程启动后，同样会通过open和mmap方法通知binder driver为service进程分配一块不超过4MB的内存，一般应用程序的是1MB左右(1mb - 8kb)。

同第2点一样，这块内存也被binder driver内核空间和service进程用户空间的虚拟地址同时映射。

然后向service manager注册service；正如第2点所言，binder driver强制规定了0号句柄对应的是service manager实体对象，所以service进程只要传入0号句柄，然后把想注册的service一起传入过来就可以了。

5. binder driver接到service的ioctl调用后，找到第2点描述的sm binder实体，然后通过这个sm binder实体找到service manager对应的进程。

此时，service manager的进程正在睡眠等待状态，于是binder driver把要处理的工作封装成一个binder_transaction丢给service manager进程，也就是把数据拷贝到binder driver为service manager分配的那块内存(也就是第2步binder driver为service manager分配的那块内存)，这也是binder数据传输的唯一一次数据拷贝，然后唤醒它。

6. 此时，service进程会返回service进程用户空间，然后会再次进入binder driver，并且进入等待状态；它需要等待service manager注册service的返回结果。

7. service manager进程被唤醒后，回到service manager用户空间，同时把binder driver拷贝过来的数据读取出来，把名称和从binder driver传入的句柄值保存起来，再次执行结果通过ioctl指令通知binder driver。

8. service manager进程回到binder driver之后，通过之前第5步产生的binder_transaction找到之前调用的binder driver的service进程和线程，把第7点从service manager返回的结果读出来，然后拷贝到binder driver为service分配的内存，再唤醒service线程。

9. service manager在binder driver完成之后，会再次进程等待状态。

10. service进程被service manager进程唤醒之后，会回到service进程的用户空间，然后把第8步binder driver拷贝service进程内存的数据读取出来(这块内存在binder driver中，被service进程和binder driver同时映射)，再完成最后的逻辑。

11. client进程启动后，也会像service和service manager一样通过open和mmap方法请求binder driver为client进程分配一块内存用户进程间通信。

12. client进程向service manager发起查询service请求，同时传入要查询service的名称，传入的binder句柄值是0，也就是对应着service manager。

13. binder driver接受到client的查询请求后，根据句柄值0找到service manager的binder实体对象(sm binder实体)，然后通过sm binder实体对象找到service manager进程。此时，service manager进程正处于等待状态。

14. binder driver把从client传入的数据拷贝到为service manager分配的那块内存，生成一个binder_transaction，然后唤醒service manager进程。

15. client进程经过一些处理后进入等待状态，等待service manager来唤醒。

16. service manager被唤醒后，把binder driver拷贝给它的数据读取出来，当然最重要的是从client进程传入的service 名称。通过查找，找到名称对应的句柄值。也就是第7点那个名称和句柄值。然后通过ioctl再次回到binder driver。

17. binder driver通过binder_transaction找到第15点的client进程和线程，通过从service manager返回的句柄值找到binder driver里面对应的service 实体对象。然后唤醒client线程。

18. 在binder driver里面,client线程根据service 实体对象，生成属于client进程的binder引用对象，也就是一个句柄值，再返回client进程用户空间。

19. 在client进程用户空间，把句柄值拷贝出来，封装成一个BpBinder对象，BpBinder对象里面mHandle值就保存了这个句柄值。

20. client和service通信，client使用第19步获取到的mHandle句柄值，发送给binder driver。

21. binder driver根据mHandle句柄值找到client进程内对应的binder引用对象，再根据binder引用对象找到它对应的binder实体对象，再根据binder实体对象找到其所在的binder进程。然后把数据拷贝到binder driver为service进程分配的那块内存，再唤醒service进程。

22. client进程的调用线程进入等待状态。

23. 由于binder实体对象有个cookie值指向用户空间service进程的的service地址，所以service在被唤醒后，它可以找到是由哪个service组件来响应此次服务(service进程内可能不止一个service组件)。

24. service完成自己的逻辑后，再次通过binder_ioctl通知binder driver，告诉binder driver处理结果，然后再唤醒client进程。这个过程就和service manager通知service是一样的了。

这样，整个通信过程就基本结束了。

ps:

1. 这里说的service和android应用里面说的4大组件service并不是一个概念，这里的service指的是提供Binder服务的Binder本地对象。

2. 上面说的Binder代理对象，Binder引用对象，Binder实体对象，Binder本地对象是按照从client到service的顺序的，可以按个解释下这几个对象的含义。

a. Binder代理对象，运行在client用户空间，对应的类是BpBinder，实现的关键在于它有个句柄mHandle变量，通过这个变量可以在Binder driver内核空间里面找到对应的Binder引用对象。

b. Binder引用对象，运行在Binder driver内核空间，对应的数据是binder_ref结构体。

c. Binder实体对象，运行在Binder driver内核空间，对应的数据是binder_node结构体。

d. Binder本地对象，运行在service用户空间，对应的数据是BBinder，其实就是一个提供服务的Binder service。

3. 可能大家看到看到对于service manager在binder driver中， client和并没有binder引用对象，而其他service在client进程中却有binder 引用对象，这是为什么呢？

这个问题就回到文章开始的第一点，里面在描述女娲造人关于源头这个问题上的时候，我们说神话故事里面假设女娲是事先存在的，从而弥补了这个故事里面的漏洞。

那在binder机制里面，也有这个问题：就是client通过service manager拿到service的binder句柄值，那么service怎么拿到service manager的句柄值呢？

就好比说人是女娲造的，那女娲又是哪里来的呢？

好吧，跟神话故事一样，我们也是假设service manager是事先存在的，并且规定它的句柄值就是0。

那么client和service只要传入句柄0就可以找到service manager在binder driver中的binder实体对象，自然也不需要binder 引用对象了。

而且service manager进程也不会像其他service进程一样，可能存在多个service服务。

4. service manager请求binder driver为它分配的内存是128kb，一般应用程序(client, service)请求binder driver为它分配的内存是1MB - 8KB。

这是我们要求使用binder时不能传输大于1MB数据的原因，比如通过intent传输图片，很有可能会超过binder传输上限。当然这个我们在后面分析代码的时候会看到。

详见：

android_proj/framework/base/libs/binder/ProcessState.cpp

#define BINDER_VM_SIZE ((1*1024*1024) - (4096 *2))

5. 在上图中大家看到有些service进程中可能存在多个service组件，比如service2进程。它们都通过binder driver注册到了service manager，但是它们有不同的名称对应以及不同的service组件地址，这两个区别分别会被service manager和binder driver(通过binder_node结构体的cookie数据)所记住。

所以可以区分。

6. binder线程池，用户空间的程序有个线程池来响应binder driver，但是有个上限，一般是15个线程，详见

android_proj/framework/base/libs/binder/ProcessState.cpp

open_driver(){

   ...

   size_t maxThreads = 15;  

   result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);

   ...

}

但是需要说明的是这15个线程指的是binder driver请求用户空间程序创建的最大线程数(当应用程序线程数不足以响应binder请求时，binder driver会请求应用程序分配线程)，并不包括用户空间程序主动注册到binder driver的。

四. binder机制中的数据结构

在初步了解binder机制的通信过程后，我们需要更深一步的了解binder通信，所以需要简单讲解下binder通信过程中的数据结构。

五. 实名binder对象和匿名binder对象

所谓的实名和匿名是针对service manager而言的，就是service manager知不知道这个binder对象的存在，并且给它一个名字相对应。

正如第一步里面所描述的女娲造人的故事，女娲可以造人，但是人也可以造人。如果把女娲比喻成service manager，那么第一代人就是实名binder对象，第一代人以及后面的人造的人就是匿名binder对象；

因为它对于女娲这个service manager而言，女娲并不知道它们的存在和名字。

这个比喻如果难以理解的话，那再举个更加现实的栗子：

如果一个人想进入火车候车室，那么他需要火车票或者站台票，那我们现在来做如下比喻:

1. 假如把进入候车室这个功能比喻成实现binder通信这个功能，那么：

2. 火车票和站台票都可以进入候车室，也就是说实名binder和匿名binder都可以完成进程间通信功能，这点并没有什么区别。

3. 由于火车票是实名制的，所以铁道部能知道卖出的票和购买人的***一一对应；但是对于站台票，铁道部并不能知道这种对应关系；

那对于service manager和实名binder，匿名binder也是这种关系 -- service mangager清楚的知道所有实名binder的名称，binder服务所在的进程等等信息，但是对于匿名binder却一无所知，它甚至不知道匿名binder的存在。

4. 购买站台票不是想买就可以买的，需要持有火车票吃可以购买站台票；

那对于实名binder和匿名binder也是如此，匿名binder不是想创建就能创建的，首先需要得到一个实名binder，通过实名binder得到匿名binder，具体例子可以参考bindService得到一个匿名binder的实现。

5. 对于检票口，不管是火车票还是站台票都会从检票口通过，所以检票口可以记录一些信息；同样，对于binder driver，不管是实名binder还是匿名binder都会通过binder driver，binder driver也会记录它们的信息。

六. binder ioctl指令

七. binder命令

binder命令按照命令的流向性分为两大类：

1. BC_XXX

2. BR_XXX

从用户空间流向binder driver的命令被称为BC_XXX，也就是binder command的简称；相应的从binder driver流向用户空间进程的称为BR_XXX，也就是binder return的简称。如下图：

对于所有的binder 命令，可以用下面两张表来描述：

具体可以参考./working_directory/kernel/goldfish/driver/staging/android/binder.h

enum BinderDriverCommandProtocol {

  ...

}

enum BinderDriverReturnProtocol {

  ...

}

3. BC_XXX

4. BR_XXX

八. 引用计数

在第七点的表中，我们提到了所有的Binder协议命令，其中包括类似BC_INCREFS，BC_ACQUIRE，BC_RELEASE，BC_DECREFS之类的命令，表中解释是维护binder对象的引用计数；那为什么要进行这样的设计呢？

那我们可以来做这样一种假设：

client进程引用service进程的一个binder本地对象正在通信，如果这个时候service进程把这个binder本地对象回收了怎么办？

为了解决这个问题，binder机制使用了引用的概念：

在Java里面，我们知道维护一个对象的生命周期可以通过强引用，软引用，弱引用和虚引用来实现(具体的区别大家可以百度，里面一些区别和技巧还是很有用的，特别是软引用用来实现图片的缓存)，只要一个对象被从垃圾回收的根节点强引用所关联，那么它是不会被回收的。

所以，类似的，binder机制里面也采用这个概念。

那，binder driver为什么不直接引用binder 本地对象呢？

这是因为binder driver是在内核空间，binder本地对象在service进程的用户空间，不能直接引用。

所以，binder 机制才通过这种通过命令调用的方式，通知service进程为指定的binder本地对象增加/减少引用，从而达到维护用户空间service进程binder本地对象生命周期的目的。

九. 死亡通知机制

通过上面几点介绍，一到七点保证了binder间进程通信，第八点保证了生命周期管理，一切看起来都那么完美。

但是，还是有意外情况发生，那就是：

提供服务的service进程死亡了怎么办？

对应这个问题,client和binder driver都爱莫能助，因为它们也无法控制service进程的生命周期。又回到了第八点阐述的那个问题：

client进程引用service进程的一个binder本地对象正在通信，如果service进程的binder本地对象不存在了怎么办？

对于service进程死亡，一般可以分为两种情况：

1. 正常死亡，比如程序自己退出

2. 异常退出，比如因为程序里面的一个逻辑错误导致进程退出

如果是第1种情形，程序会自己主动close掉自己进程打开的binder driver；从而调用到binder driver的binder_release函数。

如果是第2种情形，操作系统会帮我们close，从而也可以调用binder driver的binder_release函数。

所以，上面两种可能都可以在binder driver的binder_release函数中去解决。

binder 机制死亡通知的过程是这样的：

a. client进程拿到指向service进程binder本地对象的引用后，它可以向这个service进程binder本地对象请求注册一个死亡通知(其实就是BpBinder，因为它实现了死亡通知的接口)。

b. binder driver记录下了这层对应关系。

c. 当binder driver检测到目标service进程已经死亡时，它找到这个进程所有binder本地对象在binder driver里面对应的binder实体对象。

d. 然后根据binder实体对象找到所有引用它的binder引用对象，如果发现binder引用对象有注册死亡通知，那么就封装一个binder_work项给binder引用对象所在的进程，然后唤醒它；让那个进程去完成自己的逻辑。

至此，binder设计篇内容全部提供完毕，下面会写一些binder实现篇的东西，也就是从代码的角度来分析这些内容。