Read The Fucking Source Code

引言

• Binder的实现十分复杂，但是用起来简单；
• 重要的实现在 Framework层 / Native层 / Kernal层，实现语言有Java / C / C++；
• 深入源码讲解的优秀博客有很多，在文章的末尾有链接，大家自行查阅；
• 本文以自顶向下的视角来解读，尽量不涉及底层代码细节。

Android选择Binder的理由

• 从性能的角度 数据拷贝次数： 一次（单向传递的拷贝）（仅低于共享内存）；
• C/S架构，稳定性高于共享内存（临界资源的并发同步问题）；
• 从安全的角度（Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行）；
• 从语言层面的角度（Java / C++ / c）；
• 从公司战略的角度(Linux是GPL协议，Android将GPL限定在Kernel层，上层使用Apache协议)。

Binder之拷贝一次的原因

 每次 单向通信 拷贝次数为 1，server用户空间和内核空间通过内存映射可以直接交互。

Binder对数据传输大小的限制

 内核4M 上层限制1m-8k（传输Bitmap过大，就会崩溃的原因，Activity之间传输BitMap）。

Binder通信模型

• Binder框架定义了四个角色：Server，Client，ServiceManager（以后简称SMgr）以及Binder驱动；
• Server，Client，SMgr运行于用户空间，驱动运行于内核空间；
• 这四个角色的关系和互联网类似：Server是服务器，Client是客户终端，SMgr是域名服务器（DNS），驱动是路由器。

Binder通信概述

• Client进程只不过是持有了Server端的代理；代理对象协助驱动完成了跨进程通信；
• 对于Server进程来说，Binder指的是Binder本地对象；
• 对于Client来说，Binder指的是Binder代理对象，它只是Binder本地对象的一个远程代理；对这个Binder代理对象的操作，会通过驱动最终转发到Binder本地对象上去完成；对于一个拥有Binder对象的使用者而言，它无须关心这是一个Binder代理对象还是Binder本地对象；对于代理对象的操作和对本地对象的操作对它来说没有区别；
• 对于传输过程而言，Binder是可以进行跨进程传递的对象；Binder驱动会对具有跨进程传递能力的对象做特殊处理：自动完成代理对象和本地对象的转换。

IBinder/IInterface/Binder/BinderProxy/Stub

• IBinder是一个接口，它代表了一种跨进程传输的能力；只要实现了这个接口，就能将这个对象进行跨进程传递；这是驱动底层支持的；在跨进程数据流经驱动的时候，驱动会识别IBinder类型的数据，从而自动完成不同进程Binder本地对象以及Binder代理对象的转换。
• IBinder负责数据传输，那么client与server端的调用契约（这里不用接口避免混淆）呢？这里的IInterface代表的就是远程server对象具有什么能力。具体来说，就是aidl里面的接口。
• Java层的Binder类，代表的其实就是Binder本地对象。BinderProxy类是Binder类的一个内部类，它代表远程进程的Binder对象的本地代理；这两个类都继承自IBinder, 因而都具有跨进程传输的能力；实际上，在跨越进程的时候，Binder驱动会自动完成这两个对象的转换。
• 在使用AIDL的时候，编译工具会给我们生成一个Stub的静态内部类；这个类继承了Binder, 说明它是一个Binder本地对象，它实现了IInterface接口，表明它具有远程Server承诺给Client的能力；Stub是一个抽象类，具体的IInterface的相关实现需要我们手动完成，这里使用了策略模式。

AIDL的过程分析

• asInterface 方法，我们在bind一个Service之后，在onServiceConnecttion的回调里面，就是通过这个方法拿到一个远程的service的。它会试着查找Binder本地对象，如果找到，说明Client和Server都在同一个进程，这个参数直接就是本地对象，直接强制类型转换然后返回，如果找不到，说明是远程对象（处于另外一个进程）那么就需要创建一个Binde代理对象，让这个Binder代理实现对于远程对象的访问。一般来说，如果是与一个远程Service对象进行通信，那么这里返回的一定是一个Binder代理对象，这个IBinder参数的实际上是BinderProxy。
• transact 方法，Proxy调用接口方法时，首先用Parcel把数据序列化了，然后调用了transact方法；这个Proxy类在asInterface方法里面被创建，前面提到过，如果是Binder代理那么说明驱动返回的IBinder实际是BinderProxy, 因此我们的Proxy类里面的mRemote实际类型是BinderProxy。
• onTransact 方法，transact方法，最终调入Native层，交给驱动来处理，Client端的线程挂起等待返回，驱动完成一些操作后，唤醒Server，调用Server进程本地对象的onTransact函数（由Server端的binder线程池完成）。我们再看Binder本地对象的onTransact方法（这里就是Stub类里面的此方法），在Server进程里面，onTransact根据调用号（每个AIDL函数都有一个编号，在跨进程的时候，不会传递函数，而是传递编号指明调用哪个函数）调用相关函数。这个方法将结果返回给驱动，驱动唤醒挂起的Client进程里面的线程并将结果返回。于是一次跨进程调用就完成了。
• 固定模式：一个需要跨进程传递的对象一定继承自IBinder，如果是Binder本地对象，那么一定继承Binder实现IInterface，如果是代理对象，那么就实现了IInterface并持有了IBinder引用；
• Proxy与Stub区别：虽然他们都既是Binder又是IInterface，不同的是Stub采用的是继承（is 关系），Proxy采用的是组合（has 关系）。他们均实现了所有的IInterface函数，不同的是，Stub又使用策略模式调用的是虚函数（待子类实现），而Proxy则使用组合模式。为什么Stub采用继承而Proxy采用组合？事实上，Stub本身is一个IBinder（Binder），它本身就是一个能跨越进程边界传输的对象，所以它得继承IBinder实现transact这个函数从而得到跨越进程的能力（这个能力由驱动赋予）。Proxy类使用组合，是因为他不关心自己是什么，它也不需要跨越进程传输，它只需要拥有这个能力即可，要拥有这个能力，只需要保留一个对IBinder的引用。

AIDL可以实现双向通信

• AIDL接口可以提供注册监听接口，参数可以用另一个AILD接口提供。
• 在service端可以通过RemoteCallbackList来处理多端的监听请求。

Android APP进程天生支持Binder通信的原理

• Android APP进程都是由Zygote进程孵化出来的。常见场景：点击桌面icon启动APP，或者startActivity启动一个新进程里面的Activity，最终都会由AMS去向Zygote进程发送请求，让Zygote去fork一个新进程并初始化Andriod APP运行需要的一些环境，而binder线程就是在这个时候新建启动的。Zygote在启动后，就不断的监听socket，等待请求来fork进程。
• 在fork出进程后，初始化运行环境时，会调用Native层AndroidRuntime.cpp中的nativeZygoteInit方法，接着调到app_main.cpp中的onZygoteInit。
• ProcessState::self()函数会调用open()打开/dev/binder设备，这个时候Client就能通过Binder进行远程通信；其次，proc->startThreadPool()负责新建一个binder线程，监听Binder设备，这样进程就具备了作为Binder服务端的资格。每个APP的进程都会通过onZygoteInit打开Binder，既能作为Client，也能作为Server，这就是Android进程天然支持Binder通信的原因。

Android APP有多少Binder线程，是固定的么？

• Android APP进程在Zygote fork之初就为它新建了一个Binder主线程，使得APP端也可以作为Binder的服务端，这个时候Binder线程的数量就只有一个。
• Android APP上层应用的进程一般是开启一个Binder线程，而对于SystemServer或者media服务等使用频率高，服务复杂的进程，一般都是开启两个或者更多。
• Binder线程数目不固定，驱动会根据目标进程中是否存在足够多的Binder线程来告诉进程是不是要新建Binder线程。
• 采用动态新建Binder线程的意义有两点，第一：如果没有Client请求服务，就保持线程数不变，减少资源浪费，需要的时候再分配新线程。第二：有请求的情况下，保证至少有一个空闲线程是给Client端，以提高Server端响应速度。

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的优先级nice，这样T2会使用和T1类似的时间完成任务。很多资料会用‘线程迁移’来形容这种现象，容易让人产生误解。一来线程根本不可能在进程之间跳来跳去，二来T2除了和T1优先级一样，其它没有相同之处，包括身份，打开文件，栈大小，信号处理，私有数据等。
• 关于工作线程的启动，Binder驱动还做了一点小小的优化。当进程P1的线程T1向进程P2发送请求时，驱动会先查看一下线程T1是否也正在处理来自P2某个线程请求但尚未完成（没有发送回复）。这种情况通常发生在两个进程都有Binder实体并互相对发时请求时。假如驱动在进程P2中发现了这样的线程，比如说T2，就会要求T2来处理T1的这次请求。因为T2既然向T1发送了请求尚未得到返回包，说明T2肯定（或将会）阻塞在读取返回包的状态。这时候可以让T2顺便做点事情，总比等在那里闲着好。而且如果T2不是线程池中的线程还可以为线程池分担部分工作，减少线程池使用率。
• Binder线程是执行Binder服务的载体，只对于服务端才有意义，对请求端来说，是不需要考虑Binder线程的。
• Binder线程就是执行Binder实体业务的线程，一个普通线程如何才能成为Binder线程呢？很简单，只要开启一个监听Binder字符设备的Loop线程即可。通过ioctl来进行监听。
• Binder线程与Binder主线程的区别是：线程是否可以终止Loop，不过目前启动的Binder线程都是无法退出的，其实可以全部看做是Binder主线程，其实现原理是，在SystemServer主线程执行到最后的时候，Loop监听Binder设备，变身死循环线程。
• Binder线程池：每个Server进程在启动时会创建一个binder线程池，并向其中注册一个Binder线程；之后Server进程也可以向binder线程池注册新的线程，或者Binder驱动在探测到没有空闲binder线程时会主动向Server进程注册新的的binder线程。对于一个Server进程有一个最大Binder线程数限制，默认为16个binder线程，例如Android的system_server进程就存在16个线程。对于所有Client端进程的binder请求都是交由Server端进程的binder线程来处理的。

Binder数据包接收队列（线程）等待队列管理

• 通常数据传输的接收端有两个队列：数据包接收队列和（线程）等待队列，用以缓解供需矛盾。当超市里的进货（数据包）太多，货物会堆积在仓库里；购物的人（线程）太多，会排队等待在收银台，道理是一样的。在驱动中，每个进程有一个全局的接收队列，也叫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端的处理能力或耗尽线程池里的线程，进而阻塞同步交互。

Binder的同步和异步的区别

• 很多人都会说，Binder是对Client端同步，而对Service端异步，其实并不完全正确，在单次Binder数据传递的过程中，其实都是同步的。只不过，Client在请求Server端服务的过程中，是需要返回结果的，即使是你看不到返回数据，其实还是会有个成功与失败的处理结果返回给Client，这就是所说的Client端是同步的。至于说服务端是异步的，可以这么理解：在服务端在被唤醒后，就去处理请求，处理结束后，服务端就将结果返回给正在等待的Client线程，将结果写入到Client的内核空间后，服务端就会直接返回了，不会再等待Client端的确认，这就是所说的服务端是异步的。
• 不过这里有一点要注意，对于同一个线程的请求，如果是阻塞的，那么没什么问题，肯定是等待上一个请求结束才能处理下一个，但是对于oneway方式的binder请求呢，这里就会存在这么一个场景，对于oneway的请求，如果上一个还没处理完，同一个线程的新的oneway请求会被塞到同一个目标线程等待执行，而不会触发创建新的Binder线程，因为这并不会妨碍另一端的处理，因为它压根无需等待，但是这可能会造成服务端单个线程任务繁重，而其他线程保持空闲，不过在一定程度上实现了同一种任务的顺序执行，可能也有一定的好处吧。

Binder权限控制

• A线程通过Binder远程调用线程B，线程B的IPCThreadState中的mCallingUid和mCallingPid保存的就是线程A的UID和PID，线程B可以通过UID和PID进行权限比对，判断线程A是否有权限调用线程B的某个方法。
• 线程B通过Binder调用当前线程的某个组件时，需要将UID和PID进行还原，当调用结束后，需要将其恢复为调用线程（线程A）的UID和PID。

ServiceManager简述

• ServiceManager的内核空间是128k，主要面向系统服务提供注册和查询服务：
  • 注册服务：记录服务名和handle信息，保存到svclist列表；
  • 查询服务：根据服务名查询相应的的handle信息。
• ServiceManager需要查询吗？
  • ServiceManager是比较特殊的服务，所有应用都能直接使用，因为ServiceManager对于Client端来说Handle句柄是固定的，都是0，所以ServiceManager服务并不需要查询，可以直接使用。

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。
• 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

• 在ServiceManager中注册过的Binder都叫实名Binder。当Client与Server通过实名Binder建立好Binder连接后，Server还可以通过这个连接将新的Binder实体封装进数据包传递给Client，这个被传递的就叫做匿名Binder，匿名Binder依然会在Binder Driver中生成实体节点，但不会在ServiceManager中注册。
• service不是必须去service manager中注册后才能去使用。
• 匿名binder必须是建立在一个实名binder之上的，实名binder就是在service manager中注册过的。首先client和server通过实名binder建立联系，然后把匿名binder通过这个实名通道“传递过去”，对方也可以正确获取service的代理对象Bpxxx。
• 平常开发过程中，通过aidl和binderService方式获取的Binder是不会注册到SM中的，这种Binder就是匿名Binder，匿名Binder要依赖于实名Binder进行传递，比如Service中的onBind方法返回的Binder对象是需要通过AMS来传递给客户端的。

系统服务与bindService等启动的服务的区别

• 也就是上面说的实名Binder和匿名Binder的区别。
• 服务可分为系统服务与普通服务，系统服务一般是在系统启动的时候，由SystemServer进程创建并注册到ServiceManager中的。而普通服务一般是通过ActivityManagerService启动的服务，或者说通过四大组件中的Service组件启动的服务。这两种服务在实现跟使用上是有不同的，主要从以下几个方面：
  • 服务的启动方式：
    • 系统服务一般都是SystemServer进程负责启动，比如AMS，WMS，PKMS，电源管理等，这些服务本身其实实现了Binder接口，作为Binder实体注册到ServiceManager中，被ServiceManager管理，而SystemServer进程里面会启动一些Binder线程，主要用于监听Client的请求，并分发给响应的服务实体类，可以看出，这些系统服务是位于SystemServer进程中。
    • bindService类型的服务，这类服务一般是通过Activity的startService或者其他context的startService启动的，这里的Service组件只是个封装，主要的是里面Binder服务实体类，这个启动过程不是ServcieManager管理的，而是通过ActivityManagerService进行管理的，同Activity管理类似（Binder实体保存在ServiceRecord中）。
  • 服务的注册与管理：
    • 系统服务一般都是通过ServiceManager的addService进行注册的，这些服务一般都是需要拥有特定的权限才能注册到ServiceManager。
    • bindService启动的服务可以算是注册到ActivityManagerService，只不过ActivityManagerService管理服务的方式同ServiceManager不一样，而是采用了Activity的管理模型。
  • 服务的请求使用方式：
    • 系统服务一般都是通过ServiceManager的getService得到服务的句柄，这个过程其实就是去ServiceManager中查询注册系统服务。
    • bindService启动的服务，主要是去ActivityManagerService中去查找相应的Service组件，最终会将Service内部Binder的句柄传给Client。

总结

• 从 应用开发工程师 的角度来看，这是一篇不涉及底层代码的文章（喜忧参半）。
• 从 系统工程师 的角度来看，这是一篇不太重要的文言文（全是悲伤）。

 

小编的扩展链接

《Android 基础组件 全家桶》
 

优秀博客链接

进程间通信IPC
为什么 Android 要采用 Binder 作为 IPC 机制？
Android-Binder机制
Android Bander设计与实现 - 设计篇
Android跨进程通信：图文详解 Binder机制 原理
听说你Binder机制学的不错，来面试下这几个问题（一）
Binder学习指南
Android中的Binder机制二(匿名Binder)