Binder是android系统进程间通信（IPC）方式之一。Linux已经拥有管道，system V IPC，socket等IPC手段，却还要依赖Binder来实现进程间通信，说明Binder具有无可比拟的优势。深入了解Binder并将之与传统IPC作对比有助于我们深入领会进程间通信的实现和性能优化。本文将对Binder的设计细节做一个全面阐述，首先通过介绍Binder通信模型和Binder通信协议了解Binder的设计需求；然后分别阐述Binder在系统不同部分的表述方式和起的作用。最后还会解释Binder在数据接收端的设计考虑，包括线程池管理，内存映射和等待队列管理等。通过本文对Binder的详细介绍以及其他IPC通信方式的对比，读者将对Binder的优势和使用Binder作为Android主要IPC方式的原因有深入了解。
背景知识
进程隔离
进程隔离是为保护操作系统中进程互不干扰而设计的一组不同硬件和软件的技术。这个技术为了避免进程A写入进程B的情况发生。进程的隔离实现，使用了虚拟地址空间。进程A的虚拟地址和进程B的虚拟地址不同，这样就防止进程A将数据信息写入进程B。
用户空间/内核空间
Linux Kernel是操作系统的核心，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。
对于Kernel这么一个高安全级别的东西，显然是不容许其他的应用程序随便调用或访问的，所以需要对Kernel提供一定的保护机制，这个保护机制用来告诉那些应用程序，你只可以访问某些许可的资源，不许可的资源是拒绝访问的，于是就把Kernel和上层的应用程序抽象的隔离开，分别称之为Kernel Space 和User Space。
系统调用/内核态/用户态
用户空间访问内核空间的唯一方式是系统调用；通过这个统一入口接口，所有的资源访问都是在内核的控制下执行，以免导致对用户程序对系统资源的越权访问，从而保障了系统的安全和稳定。
当一个任务（进程）执行系统调用而陷入内核代码中执行的时候，我们就称进程处于内核运行态（内核态），此时处理器处于特权级最高（0级）的内核代码中执行，当进程在执行用户自己的代码时，则称其处于用户运行态（用户态）。即此时处理器在特权级最低的（3级）用户代码中运行。处理器在特权等级高的时候才能执行那些特权CPU指令。
内核模块/驱动
通过系统调用，用户空间可以访问内核空间，那么如果一个用户空间想与另外的一个用户空间进行通信怎么办？很自然想到的是让操作系统内核添加支持；传统的Linux通信机制，比如Socket，管道等都是内核支持的；但是Binder并不是Linux内核的一部分，它是怎么做到访问内核空间的呢？Linux的动态可加载内核模块（Loadable Kernel Module，LKM）机制解决了这个问题；模块是具有独立功能的程序，它可以被单独编译，但不能独立运行。它在运行时被链接到内核作为内核的一部分在内核空间运行。这样，android系统可以通过添加一个内核模块运行在内核空间，用户进程之间通过这个模块作为桥梁，就可以完成通信了。
在android系统中，这个运行在内核空间的，负责各个用户进程通过Binder通信的内核模块叫做Binder驱动。
为什么使用Binder
基于Client-Server的通信方式广泛应用于从互联网和数据库访问到嵌入式手持设备内部通信等各个领域。智能手机平台特别是android系统中，为了向应用开发者提供丰富多样的功能，这种通信方式更是无处不在，诸如媒体播放，视音频捕获，到这种让手机更智能的传感器（加速度，方位）都由不同的server负责管理，应用程序只需要为Client与这些server建立连接便可以使用这些服务，花很少时间和精力就能开发出令人炫目的功能。Client-Server方式的广泛采用对进程间通信（IPC）机制是一个挑战。目前linux支持的IPC包括传统的管道，System V IPC，即消息队列/共享内存/信号量，以及socket中只有socket支持Client-server的通信方式。当然也可以在这些底层机制上架设一套协议来实现Client-server通信，但这样增加了系统的复杂性，在手机这种条件复杂，资源稀缺的环境下可靠性也难以保证。
另一方面是传输性能。socket作为一款通用的接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。消息队列和管道采用存储-转发模式。即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方的缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但是控制复杂，难以使用。
还有一点是出于安全性考虑。Android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据，连接无线网络，长期操作底层的设备导致电池很快耗尽。传统的IPC没有任何安全措施，完全依赖上层的协议来确保。首先传统iPC的接收方式无法获得对方进程可靠的UID/PID(用户ID/进程ID），从而无法鉴别对方身份。android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID，但这样不可靠。容易被恶意程序利用。可靠的身份标识只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。比如命名管道的名称，System V
的键值。socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法阻止恶意程序通过猜测接收方地址获得连接。
基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。Binder基于Client-server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。
面向对象的Binder IPC
Binder使用Client-Server通信方式，一个进程作为Server提供诸如视频/音频解码，视频捕获，地址本查询，网络连接等服务；多个进程作为Client像Server发起服务请求，获得所需要的服务。要想实现Client-Server必须实现以下两点：一是server必须有确定的访问接入点或者说地址来接收Client请求，并且Client可以通过某种途径货值Server的地址。二是制定Command-Reply协议来传输数据。例如网络通信中，Server的访问接入点就是Server主机的IP地址和端口号，传输协议为TCP协议。对于Server而言，Binder可以看成Server提供的实现某个特定服务的访问接入点。Client通过这个‘地址’向Server发送请求来使用该服务；对Client而言，Binder可以看成通向Server的管道入口，要想和某个Server通信首先必须建立这个管道并获得管道入口。
与其他IPC不同，Binder使用了面向对象的思想来描述作为访问接入点的Binder及其在Client中的入口，Binder是一个实体位于Server 中的对象，该对象提供了一套方法用以实现对服务的请求，就像类的成员函数。遍布于Client中的入口可以看成指向这个Binder对象的‘指针’，一旦获得这个‘指针’，就可以调用该对象的方法来访问server，在Client看来，通过Binder‘指针’调用其提供的方法和通过指针调用其它任何本地方法并无区别，尽管前者的实体位于远程Server端，而后者的实体位于本地内存中。‘指针’是c++的术语，而更通常的说法是引用，即Client端通过Binder引用访问Server。而软件领域另一个术语‘句柄’也可以用来表达Binder在Client中存在的方式。从通信角度看，Client中的Binder也可以是看做Server Binder的‘代理’，在本地代表远端Server为Client提供服务。本文会使用‘引用’或‘句柄’这两个广泛使用的术语。
面向对象思想的引入将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而他的引用却遍布于系统的各个进程之中。最诱人的是，这个引用和java里面引用一样既可以是强类型，也可以是弱类型，而且可以从一个进程传给其他进程，让大家都能访问同一Server，就像将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。形形色色的Binder对象以及星罗棋布的引用仿佛粘结各个应用的胶水，这也是Binder在英文里的原意。
Binder 通信模型
Binder框架定义了四个角色，Server，Client，ServiceManager，以及Binder驱动。其中Server，Client，SMgr运行于用户空间，Binder驱动运行于内核空间。这四个角色的关系和互联网类似：Server是服务器，Client是客户终端，SMgr是域名服务器（DNS），驱动是路由器。
Binder驱动
和路由器一样，Binder驱动虽然默默无闻，却是通信的核心，尽管名叫‘驱动’，实际上和硬件没有任何关系，只是实现方式和设备驱动程序是一样的：它工作处于内核态，提供open(),mmap() poll() ioctl()等标准文件操作，以字符驱动设备中的misc设备注册在设备目录/dev下，用户通过/dev/binder访问它。驱动负责进程之间Binder通信的建立，Binder在进程之间传递，Binder引用计数管理，数据包在进程之间的传递和交互等一系列底层支持。驱动和应用程序之间定义了一套接口协议，主要功能由ioctl（）接口实现，不提供read() write()接口，因为iocTL()灵活方便，且能够一次调用实现先写后续以满足同步交互，而不必分布调用write() read()。Binder驱动的代码位于Linux目录的drivers/misc/binder.c中。
serviceManager与实名Binder
和DNS类似，SMgr的作用是将字符形式Binder名字转化成Client中对该Binder的引用，使Client能够通过Binder名字获得对Server中Binder实体的引用。注册了名字的Binder叫实名Binder，就像每个网站除了有IP地址外还有自己的网址。Server创建了Binder实体，为其取一个字符形式，可读易记的名字，将这个Binder连同名字以数据包的形式通过Binder驱动发送给SMgr，通知SMgr注册一个名叫张三的Binder，它位于某个Server中。驱动为这个穿过进程边界的Binder创建位于内核实体节点以及SMgr对实体的引用，将名字及新建的引用打包传递给SMgr。SMgr接收数据包后，从中取出名字和引用填入一张查找表中。
细心的读者可能会发现一个蹊跷：SMgr是一个进程，Server是另一个进程，Server向SMgr注册Binder必然会涉及进程间通信。当前实现的是进程间通信却又要用到进程间通信，这就好像蛋可以孵化出鸡前提却是要找鸡来孵蛋。Binder的实现比较巧妙：预先创造一只鸡来孵蛋：SMgr和其他进程同样采用BInder通信。SMgr是Server端，有自己的Binder对象（实体），其他进程都是Client端，需要通过这个Binder的引用来实现Binder的注册，查询和获取。SMgr提供的Binder比较特殊，他没有名字也不需要注册，当一个进程使用BINDER_SET_CONTEXT_MGR命令将自己注册成SMgr时，BInder驱动会自动为他创建Binder实体（这就是预先造好的鸡）。其次这个Binder的引用在所有Client中都固定为0，而无需通过其他手段获得。也就是说，一个Server若要想SMgr注册自己Binder就必须通过0这个应用号和SMgr的Binder通信。类比网络通信，0号引用就好比域名服务器的地址，你必须预先手工或动态配置好。要注意这里说的Client是相对SMgr而言的，一个应用程序可能是提供服务的Server，但对SMgr来说他仍然是个Client。
Client获得实名Binder的引用
Server向SMgr注册了Binder实体及其名字之后，Client就可以通过名字获得该Binder的引用了。Client也利用保留的0号引用向SMgr请求访问某个Binder：我申请获得名字叫张三的Binder的引用。SMgr收到这个连接请求，从请求数据包里获得Binder的名字，在查找表里找到该名字对应的条目，从条目中取出Binder的引用，将该引用作为回复发送给发起请求的Client。从面向对象的角度，这个Binder对象现在有了两个引用：一个位于SMgr中，一个位于发起请求的Client中。如果接下来有更多的Client请求该Binder，系统中就会有更多的引用指向该Binder，就像java里面一共对象存在多个引用一样。而且类似的这些执行Binder的引用是强类型，从而确保只要有引用Binder实体就不会被释放掉。通过以上过程就可以看出，SMgr像个火车票代售点，收集了所有火车的车票，可以通过它购买到乘坐各趟火车的票—-得到某个Binder的引用。
匿名Binder
并不是所有的Binder都需要注册给SMgr广而告之的。Server端可以通过已经建立的BInder连接将创建的Binder实体传给Client，当然这条已经建立的BInder连接必须是通过实名Binder实现。由于这个Binder没有向SMgr注册名字，所以是个匿名Binder。Client将会收到这个匿名Binder的引用，通过这个引用向位于Server中的实体发送请求。匿名Binder为通信双方建立一条私密通道，只要Server没有把匿名Binder发给别的进程，别的进程就无法通过穷举或猜测等任何方式获得该Binder的引用，向该Binder发送请求。
Binder表述
考察一次Binder通信的全过程会发现：Binder存在于系统以下几个部分中：
应用程序进程：分别位于Server进程和Client进程中
Binder驱动：分别管理为Server端的Binder实体和Client端的引用
传输数据： 由于Binder可以跨进程传递，需要再传输数据中予以表述。
在系统不同部分，Binder实现的功能不同，表现形式也不一样。
Binder在应用程序中的表述
Binder本质上只是一种底层通信方式，和具体服务没有关系。为了提供具体服务，Server必须提供一套接口函数以便Client通过远程访问使用各种服务。这时通常采用Proxy设计模式：将接口函数定义在一个抽象类中，Server和Client都会以该抽象类为基类实现所有的接口函数，所不同的是，Server端是真正的功能的实现，而Client端是对这些函数远程过程调用请求的包装。如何将Binder和Proxy设计模式结合起来是应用程序实现面向对象的Binder通信的根本问题。
通常意义下，Binder指的是一种通信机制，我们说AIDL使用Binder进行通信，指的就是Binder这种IPC机制。
对于Server进程来说，Binder指的是Binder本地对象
对于Client来说，Binder指的是Binder代理对象，它只是Binder本地对象的一个远程代理；对这个Binder代理对象的操作，会通过驱动最终转发到Binder本地对象上去完成。对于一个拥有Binder对象的使用者而言，它无须关心这是一个Binder代理对象还是Binder本地对象；对于代理对象的操作和对本地队形的操作对它来说没有区别。
对于传输过程而言，Binder是可以进行跨进程传递的对象；Binder驱动会对具有跨进程传递能力的对象做特殊处理：自动完成代理对象和本地对象的转换。
驱动里面的Binder
我们现在知道，Server进程里面的Binder对象指的是Binder本地对象，Client里面的对象指的是Binder代理对象；在Binder对象进行跨进程传递的时候，Binder驱动会自动完成这两种类型的转换；因此Binder驱动必然保存了每一个跨越进程的Binder对象的相关信息；在驱动中，Binder本地对象的代表是一个叫做binder_node的数据结构，Binder代理对象是用binder_ref代表的；有的地方把Binder本地对象直接称作Binder实体，把Binder代理对象直接称作Binder引用（句柄），其实指的是Binder对象在驱动里面的表现形式。
Binder内存映射和接收缓存区管理
暂且撇开Binder，考虑一下传统的IPC方式中，数据是怎样从发送端到达接收端的呢？通常的做法是，发送方将准备好的数据存放在缓存区中，调用API通过系统调用进入内核中。内核服务程序在内核空间分配内存，将数据从发送方的缓存区复制到内核缓存区中，接收方读数据时也要提供一块缓存区，内核将数据从内核缓存区拷贝到接收方提供的缓存区中并唤醒接收线程，完成一次数据发送。这种存储—转发机制有两个缺陷：首先是效率低下，需要两次拷贝，用户空间->内核空间->用户空间。Linux使用copy_from_user()和copy_to_user()实现这两个跨空间拷贝，在此过程中如果使用了高端内存（high memory），这种拷贝需要临时建立/取消页面映射，造成性能损失。其次是接收数据的缓存要由接收方提供，可接收方不知道要多大内存才够用，只能开辟尽量大的空间或先调用API接收消息头获得消息体大小，再开辟适当的空间接收消息体。这两种做法都有不足，不是浪费空间就是浪费时间。
Binder采用一种全新的策略：由Binder驱动负责管理数据接收缓存。我们注意到Binder驱动实现了mmap（）系统调用，这对字符设备是比较特殊的，因为mmap（）通常用在有物理存储介质的文件系统上，而像Binder这样没有物理介质，村崔用来通信的字符设备没必要支持mmap()。Binder驱动当然不是为了在物理介质和用户空间做映射，而是用来创建数据接收的缓存空间。先看mmap()是如何使用的：
这样Binder的接收方就有了一片大小为MAP_SIZE的接收缓存区。mmap()的返回值是内存映射在用户空间的地址，不过这段空间是由驱动管理，用户不必也不能直接访问（映射类型为PROT_READ,只读映射）
接收缓存区映射好后就可以作为缓存池接收和存放数据了，前面说过，接收数据包的结构为binder_transaction_data,但这只是消息头，真正的有效负荷位于data.buffer所指向的内存中。这片内存不需要接收方提供，恰恰是来自mmap()映射的这片缓存池。在数据从发送方向接收方拷贝的时候，驱动会根据发送数据包的大小，使用最佳匹配算法从缓存池中找到一块大小合适的空间，将数据从发送缓存区复制过来。要注意的是，存放的binder_transaction_data结构本身以及表4中所有消息的内存空间还是得由接收者提供，但这些数据大小固定，数量也不多，不会给接收方造成不便。映射的缓存池要足够大，因为接收方的线程池可能会同时处理多条并发的交互，每条交互都需要从缓存池中获取目的存储区，一旦缓存池耗竭将产生无法预期的后果。
有分配必然有释放。接收方在处理完数据包后，就要通知驱动释放data.buffer所指向的内存区。在介绍Binder协议时已经提到，这是由命令BC_FREE_BUFFER完成的。
通过上面介绍可以看到，驱动为接收方分担了最为繁琐的任务：分配/释放大小不等，难以预测的有效负荷缓存区，而接收方只需要提供缓存来存放大小固定，最大空间可以预测的消息头即可。在效率上，由于mmap()分配的内存是应设在接收方用户空间里的，所有总体效果就相当于对有效符合数据做了一次从发送发用户空间到接收方用户空间的直接数据拷贝，省去了内核中暂存这个步骤，提升了一倍的性能。顺便再提一点，Linux内核实际上没有一个用户空间到另一个用户空间的直接拷贝的函数，需要先用copy_from_user()拷贝到内核空间，再用copy_to_user拷贝到另一个用户空间。为了实现用户空间到用户空间的拷贝，mmap()分配的内存除了映射进了接收方的进程里，还映射进了内核空间。所以调用copy_from_user（）将数据拷贝进内核空间也相当于拷贝进了接收方的用户空间，这就是Binder只需一次拷贝的“秘密”。
Binder接收线程管理
Binder通信实际上是位于不同进程中的线程之间的通信。假如进程S是Server端，提供Binder实体，线程T1从Client进程C1中通过Binder的引用向进程S发送请求，S为了处理这个请求需要启动线程T2，而此时线程T1处于接收返回数据的等待状态。T2处理完请求就会将处理结果返回给T1，T1被唤醒得到处理结果。在这过程中，T2仿佛T1在进程S中的代理，代表T1执行远程任务，而给T1的感觉就像是穿越到S中执行一段代码又返回到了C1。为了使这种穿越更加真实，驱动会将T1的一些属性赋给T2，特别是T1的优先级。这样T2会使用和T1类似的时间完成任务。
对于Server进程S，可能会有许多Client同时发起请求，为了提高效率往往开辟线程池并发处理收到的请求。怎么使用线程池实现并发处理呢？这和具体的IPC机制有关。拿socket举例，Server端的socket设置为侦听模式，有一个专门的线程使用该socket侦听来自Client的连接请求，即阻塞在accept（）上、这个socket就像一只会生蛋的鸡，一旦收到来自Client的请求就会生一个蛋—-创建新的socket并从accept（）返回。侦听线程从线程池中启动一个工作线程并将生下的蛋交给该线程。后序业务处理就由该线程完成并通过这个与Client实现交互。
可是对于Binder来说，既没有侦听模式也不会下蛋，怎么管理线程池呢？一种简单的做法是，不管三七二十一，先创建一堆线程，每个线程都用BINDER_WRITE_READ命令读Binder。这些线程会阻塞在驱动为该Binder设置的等待队列上。一旦有来自Client的数据驱动会从队列中唤醒一个线程来处理。这样做简单直观，省去了线程池，但一开始创建一堆线程有点浪费资源。于是Binder协议引入了专门命令或消息帮助用户管理线程池，包括：
首先要管理线程池就要知道池子有多大，应用程序通过INDER_SET_MAX_THREADS告诉驱动最多可以创建几个线程。以后每个线程在创建，进入主循环，退出主循环时都要分别使用BC_REGISTER_LOOP，BC_ENTER_LOOP，BC_EXIT_LOOP告知驱动，以便于驱动收集和记录当前线程池的状态。每当驱动接收完数据包返回读Binder的线程时，都要检查一下是不是已经没有闲置线程了。如果是，而且线程总数不会超出线程池的最大线程数，就会在当前读出的数据包后面再追加一条BR_SPAWN_LOOP消息，告诉用户线程即将不够用了，请再启动一些，否则下一个请求可能不能及时响应。新线程一启动又会通过BC_xxx_LOOP告知驱动更新状态。这样只要线程没有耗尽，总是有空闲线程在等待队列中随时待命，及时处理请求。
关于工作线程的启动，Binder驱动还做了一点小小的优化。当进程P1的线程T1像P2发送请求时，驱动会先查看一下线程T1是否也正在处理来自P2某个线程请求但尚未完成（没有发送回复）。这种情况情况发生在两个进程都有Binder实体并互相对发请求时。假如驱动在进程P2中发现了这样的线程，比如说T2，就会要求T2来处理T1的这次请求。因为T2既然想T1发送了请求尚未得到的返回包，说明T2肯定（或将）会阻塞在读取返回包的状态。这时候可以让T2顺便做点事情，总比等在那里闲着好。而且如果T2不是线程池中的线程还可以为线程池分担部分工作，减少线程池的使用率。
数据包接收队列与（线程）等待队列
通常数据传输的接收端有两个队列：数据包接收队列和（线程）等待队列，用以缓解供需矛盾。当超市里的进货（数据包）太多，货物会堆积在仓库里；购物的人（线程）太多，会排队等待在收银台，道理是一样的。在驱动中，每个进程有一个全局的接收队列，也叫to-do队列，存放不是发往特定线程的数据包；相应的有一个全局等待队列，所有等待从全局接收队列里收数据的线程在该队列里排队。每个线程有自己私有的to-do队列，存放发送给该线程的数据包；相应的每个线程都有各自私有等待队列，专门用于本线程等待接收自己to-do队列里的数据。虽然名叫队列，其实线程私有等待队列中最多只有一个线程，即他自己。
由于发送时没有特别标记，驱动怎么判断哪些数据包该放入全局to—do队列，哪些数据包该送入特定线程的to–do队列呢？这里有两条规则。规则1：Client发给Server的请求数据包都提交到Server进程的全局to-do队列。不过有个特例，就是上节谈到的Binder对工作线程启动的优化。经过优化，来自T1的请求不是提交给P2的全局to—do队列，而是送入了T2的私有to–do队列。规则2：对同步请求的返回数据包（由BC_REPLY发送的包）都发送到发起请求的线程的私有to—do队列中。如上面的例子，如果进程P1的线程T1发给进程P2的线程T2的是同步请求，那么T2返回的数据包将送进T1的私有to–do队列而不会提交到P1的全局to—do队列。
数据包进入接收队列的潜规则也就决定了线程进入等待队列的潜规则，即一个线程只要不接收返回数据包则应该在全局等待队列中等待新任务，否则就应该在其私有等待队列中等待Server的返回数据。还是上面的例子，T1在向T2发送同步请求后就必须等待在它私有等待队列中，而不是在P1的全局等待队列中排队，否则将得不到T2的返回的数据包。
这些潜规则是驱动对Binder通信双方施加的限制条件，体现在应用程序上就是同步请求交互过程中的线程一致性：1) Client端，等待返回包的线程必须是发送请求的线程，而不能由一个线程发送请求包，另一个线程等待接收包，否则将收不到返回包；2) Server端，发送对应返回数据包的线程必须是收到请求数据包的线程，否则返回的数据包将无法送交发送请求的线程。这是因为返回数据包的目的Binder不是用户指定的，而是驱动记录在收到请求数据包的线程里，如果发送返回包的线程不是收到请求包的线程驱动将无从知晓返回包将送往何处。
接下来探讨一下Binder驱动是如何递交同步交互和异步交互的。我们知道，同步交互和异步交互的区别是同步交互的请求端（client）在发出请求数据包后须要等待应答端（Server）的返回数据包，而异步交互的发送端发出请求数据包后交互即结束。对于这两种交互的请求数据包，驱动可以不管三七二十一，统统丢到接收端的to-do队列中一个个处理。但驱动并没有这样做，而是对异步交互做了限流，令其为同步交互让路，具体做法是：对于某个Binder实体，只要有一个异步交互没有处理完毕，例如正在被某个线程处理或还在任意一条to-do队列中排队，那么接下来发给该实体的异步交互包将不再投递到to-do队列中，而是阻塞在驱动为该实体开辟的异步交互接收队列（Binder节点的async_todo域）中，但这期间同步交互依旧不受限制直接进入to-do队列获得处理。一直到该异步交互处理完毕下一个异步交互方可以脱离异步交互队列进入to-do队列中。之所以要这么做是因为同步交互的请求端需要等待返回包，必须迅速处理完毕以免影响请求端的响应速度，而异步交互属于‘发射后不管’，稍微延时一点不会阻塞其它线程。所以用专门队列将过多的异步交互暂存起来，以免突发大量异步交互挤占Server端的处理能力或耗尽线程池里的线程，进而阻塞同步交互。