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

成都创新互联公司-专业网站定制、快速模板网站建设、高性价比德城网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式德城网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖德城地区。费用合理售后完善，10多年实体公司更值得信赖。

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

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

那有些同学就会问了，这里说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 driver内核空间数据	描述
flat_binder_object	binder_node	binder service对象描述，每个添加到binder driver的service都会对应一个binder_node，包括service manager也是 。 flat_binder_object顾名思义就是压扁了的binder_object，为什么要压扁呢？是为了传输的需求，所以把binder对象从用户空间传输到binder driver内核空间的时候，就需要用到这个数据结构，比如addService的时候。
client,service进程	binder_proc	对应一个进程，当进程调用open方法打开binder driver的时候，binder driver会保存这个进程的相关信息，就是用binder_proc这个数据结构。 在上面我们说起过，一个进程中可能有多个service组件，比如service2进程，那在binder driver里面也是这种关系。 binder_proc和binder_node是一对多的关系。 binder_proc使用了红黑树的数据结构来描述了它里面binder_node。 红黑树的数据结构大家有不清楚可以百度下。
线程	binder_thread	binder_thread是线程在binder driver中的描述，所以binder_proc和binder_thread的对应关系也是1对多，也是用红黑树来组织的。
binder_transaction_data	binder_transaction	binder_transaction用来描述binder driver里面的一个事务。事务在数据库里面用的比较多，binder driver也借用了这个概念。 那binder_transaction_data就刚好是用来描述从用户空间到内核空间传输binder_transaction数据的。
-	binder_buffer	在前面描述过，binder driver会为每个进程分配一个不超过4MB的内存，用来传输数据。 那怎么来管理这块内存呢？ binder driver把这块内存划成一页一页来管理，那一个binder_buffer就表示一页。
-	binder_ref	binder driver里面的binder引用对象。 binder_ref主要的作用就是拥有一个句柄值，同时指向一个binder_node binder实体对象。 句柄值对应client里面的binder代理对象BpBinder里面的mHandle，所以client可以根据mHandle找到内核对应的binder_ref数据。 binder_ref关联的binder_node对象，这样，找到binder_ref后，就可以进一步找到binder_node。 binder_node上面讲过，关联了binder_proc，以及service进程里面的service组件，也就是binder本地对象。 所以，通过这一层层的关联，都连接起来了。
-	binder_ref_death	跟binder本地对象死亡通知有关。 我们知道binder机制是这样的引用的。 BpBinder(mHandle)->binder_ref->binder_node->BBinder binder本地对象。 那如果binder本地对象意外的挂了呢？比如service所在进程由于程序逻辑错误异常退出了，调用它的client怎么办呢？ 所以为了部分解决这个问题，binder因为死亡通知这个功能，当binder本地对象消亡之后，需要通知正在监听它的binder_ref client。
-	binder_work	binder driver的工作项描述，后面再具体描述。
binder_write_read	binder_write_read	ioctl指令BINDER_WRITE_READ的数据结构。

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

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

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

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

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

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

例子	binder
进入候车室	实现binder通信功能
火车票	实名binder对象
站台票	匿名binder对象
铁道部	service manager
检票口	binder driver

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指令

ioctl指令名称	含义	注释
BINDER_WRITE_READ	最重要的ioctl指令，后面可以执行很多binder命令操作。	独特的先写后读的设计，给予了用户空间程序更多的便利。
BINDER_SET_IDLE_TIMEOUT	暂未使用
BINDER_SET_MAX_THREADS	设置binder driver可以请求用户空间进程最大线程数。	不包括用户空间进程主动注册到binder driver的线程。
BINDER_SET_IDLE_PRIORITY	暂未使用
BINDER_SET_CONTEXT_MGR	通知binder driver，当前进程成为binder机制上下文，也就是service mangager	binder driver里面只能存在一个service manager，多次调用会出错。
BINDER_THREAD_EXIT	通知binder driver线程退出
BINDER_VERSION	返回当前binder driver版本号

七. 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

命令名称	含义	注释
BC_TRANSACTION	意思是进行一次transaction，比如addService，getService，或者client跨进程调用service方法等等。	最重要的binder命令之一，一般通过ioctl--BINDER_WRITE_READ来和binder driver交互。
BC_REPLY	回复binder driver	比如addService的时候，service manager在处理完自己的逻辑后会发送此命令到binder driver，告诉binder driver自己处理结果。
BC_ACQUIRE_RESULT	暂不支持
BC_FREE_BUFFER	通知binder driver去释放一个binder_buff的内存，参数int表示此binder_buff在用户空间进程的虚拟映射地址。	一般是在处理完一个事务之后，通知binder driver释放先关内存。
BC_INCREFS	通知binder driver增加目标service 弱引用, 参数int表示目标service的handle值，
BC_ACQUIRE	通知binder driver增加目标service 强引用,参数int表示目标service的handle值.
BC_RELEASE	通知binder driver减少目标service强引用,参数int表示目标service的handle值.
BC_DECREFS	通知binder driver减少目标service弱引用,参数int表示目标service的handle值.
BC_INCREFS_DONE	通知binder driver BR_INCREFS命令执行完毕，一般由service进程在处理完binder driver的BR_INCREFS命令后向binder driver发出。
BC_ACQUIRE_DONE	通知binder driver BR_ACQUIRE命令执行完毕，一般由service进程在处理完binder driver的BR_ACQUIRE命令后向binder driver发出。	因为binder driver在请求service进程增加一个service组件的强引用之后，它需要等待service组件增加强引用计数的结果，它需要根据这个结果修改自己的一些状态。
BC_ATTEMPT_ACQUIRE	暂不支持
BC_REGISTER_LOOPER	通知binder driver此进程进入BINDER_LOOPER_STATE_REGISTERED状态，再经过一些处理就会进入就绪状态，可以处理进程的事务。 此命令是binder driver通知用户空间进程创建线程后，用户空间进程创建线程后会调用此命令，通知binder driver此线程已经准备好。
BC_ENTER_LOOPER	用户空间进程主动请求binder driver通知此线程可以处理进程间binder 通信请求，一般如果没有事情做的话，会进入等待状态。	此命令和BC_REGISTER_LOOPER的区别就是 BC_ENTER_LOOPER是用户空间进程主动通知binder driver的， BC_REGISTER_LOOPER是binder driver发现此用户空间进程的线程池无法响应binder通信，需要创建新线程；然后向目标用户空间进程发出请求创建线程命令 用户空间进程创建线程完毕后，会调用BC_REGISTER_LOOPER通知binder driver。
BC_EXIT_LOOPER	通知binder driver此线程退出
BC_REQUEST_DEATH_NOTIFICATION	client请求binder driver注册目标service组件的死亡通知	以便在目标serive组件死亡的时候得到通知，然后client可以处理自己的逻辑。
BC_CLEAR_DEATH_NOTIFICATION	client通知binder driver取消注册对某个service binder本地对象的死亡通知监听
BC_DEAD_BINDER_DONE	client通知binder driver对某个service进程的binder本地对象死亡通知处理完毕。

4.BR_XXX

命令名称	含义	注释
BR_ERROR	通知用户空间进程，binder driver处理出现异常
BR_OK	通知用户空间进程，binder driver处理成功
BR_TRANSACTION	binder driver请求用户空间进程处理一个事务，事务的数据方法binder_transaction_data结构体中，	比如addService的时候，binder driver请求service manager去注册一个service。
BR_REPLY	binder driver通知用户空间进程处理完毕	比如用户空间进程发起的BC_TRANSACTION 处理完毕后，binder driver就会反馈BR_REPLY
BR_ACQUIRE_RESULT	暂不支持
BR_DEAD_REPLY	binder driver反馈目标binder对象已经死亡，返回错误。
BR_TRANSACTION_COMPLETE	binder driver反馈事务处理完成
BR_INCREFS	binder driver请求用户空间进程增加指定binder本地对象的弱引用
BR_ACQUIRE	binder driver请求用户空间进程增加指定binder本地对象的强引用
BR_RELEASE	binder driver请求用户空间进程减少指定binder本地对象的强引用
BR_DECREFS	binder driver请求用户空间进程减少指定binder本地对象的弱引用
BR_ATTEMPT_ACQUIRE	暂不支持
BR_NOOP	没有什么操作
BR_SPAWN_LOOPER	binder driver请求用户空间进程分配一个线程；这种情况一般是在用户空间进程线程池无法处理binder driver间通信请求的情况下。
BR_FINISHED	暂不支持
BR_DEAD_BINDER	通知用户空间进程所监听的binder本地对象已经销毁
BR_CLEAR_DEATH_NOTIFICATION_DONE	在用户空间进程请求BC_CLEAR_DEATH_NOTIFICATION命令后，binder driver返回这个命令通知用户空间进程
BR_FAILED_REPLY	binder driver返回失败

八. 引用计数

在第七点的表中，我们提到了所有的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实现篇的东西，也就是从代码的角度来分析这些内容。

网站名称：3.Androidbinder设计篇
转载源于：http://chengdu.cdxwcx.cn/article/ipjdho.html