Binder是Android的进程间通信核心，如果看过Android源码，你会发现源码中Android的各种核心服务都是通过Binder机制进行相互通信的。在Binder的client部分就是通过代理模式来访问Server端的。这里想通过代理模式来详细介绍Java层Binder。文中会简单介绍代理模式，详细介绍Binder机制。(源码基于6.0.1)
代理模式
意图
对其他对象提供一种代理以控制对这个对象的访问。
UML图
代码示例
abstract class Subject{
public abstract void operate();
}
class RealSubject{
public void operate(){
System.out.println("real operate");
}
}
class Proxy{
private Subject realSubject;
Proxy(Subject subject){
realSubject = subject;
}
public void operate(){
realSubject.operate();
}
}
public static void main(String[] args){
RealSubject real = new RealSubject();
Proxy proxy = new Proxy(real);
proxy.operate(); //实际上交给了realsubject去操作了。
}关于代理模式
上面的代码跟UML图只是一个例子，并不能完全描述代理模式的。代理模式强调的是一种代理，上面的例子中其实直接用RealSubject就可以了，完全没必要用Proxy。另外代理与被代理对象并不要求有共同的父类/接口。代理模式有几种常见的情况：
- 远程代理(Remote Proxy): 如果某个对象无法实例化，不在同一个地址空间，需要通过编码来进行通信。比如需要访问网络服务器上面的一个对象操作。比如我们接下来需要介绍的Binder。
- 虚代理(Virtual Proxy): 在需要的时候创建大对象，比如超大图片，我们可以使用一个虚代理代理图像，在真正需要的时候再去将图像完全加载出来，在这之前只需要在代理里面保存图像的大小，让它有个占位就好了。
- 保护代理(Protect Proxy): 需要对对象的某些操作进行隐藏，那么就可以使用代理对它的接口进行隐藏。
- 智能指引(Smart Reference): 当需要对对象的引用进行计数的时候，可以使用智能指引的代理模式。
Binder
Binder是一个接口形式的IPC。在这里以我们在应用程序开发过程中使用的.aidl文件声明生成的接口为例。使用aidl需要说明的是Android官方文档上面强调过:
使用aidl的必要条件是你的Service想要被其他客户端从不同的应用程序为了IPC而调用，并且想要在你的Service中处理多线程。如果你不需要并行来自不同的应用程序的IPC,那么你只需要使用实现Binder就好了，如果你不需要处理多线程的并行，那么你使用Messenger就好了。
这里只是为了说明Binder，名称为ITestService.aidl:
package com.houzhi.testproject;
interface ITestService{
String getContent();
}在编译运行前，Android ide(eclipse/android studio) 会自动生成相关的类，ITestService.Stub, ITestService.Proxy, 而我们通过调用bindService就可以得到Binder的代理。
Intent service; //只是为了表明类型
ServiceConnection connection = new ServiceConnection(){
public void onServiceConnected(ComponetName name, IBinder service){
ITestService testService = ITestService.stub.asInterface(service);
//testService就是我们得到的代理
}
public void onServiceDisConnected(ComponentName name){
}
}
context.bindService(service,connection);
整个自动生成的类以及Binder, IInterface的UML图如下：
ITestService.stub.asInterface(service)的内部就是创建了一个Proxy对象，其实现代码如下：
public static com.houzhi.testproject.IMyAidlInterface asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof com.houzhi.testproject.IMyAidlInterface))) {
return ((com.houzhi.testproject.IMyAidlInterface) iin);
}
return new com.houzhi.testproject.IMyAidlInterface.Stub.Proxy(obj);
}上面的代码需要说明的是obj的queryLocalInterface会返回null, 因为obj其实是一个BinderProxy类型，而BinderProxy类中，并没有给DESCRIPTOR添加对应的IInterface。在源码中具体的实现在native层，native通过jni的方式利用mObject（相当于对应的对象id,BinderProxy的成员变量）创建了一个BinderProxy。将这个BinderProxy返回给客户端。
从UML图就已经看出Binder是一个非常典型的代理模式，是一种远程代理，实际上Proxy代理的是另外一个进程中的Stub对象。内部是将接口函数标记为对应的ID，然后根据这个ID来标识目前调用的是哪一个函数。由DESCRIPTOR来作为Token分隔不同的接口调用，另外通过Parcel来写入函数参数和接受函数返回值（Stub端对应接受参数和写入结果）。aidl可接受的类型也是普通类型(int,double…),以及Map,List,String,
CharSequence,Parcel,和Binder类型。对应的处理也是不一样的，不过终归可以使用基本的方式搞定。
下面是Stub与Proxy关于接口函数实现的具体代码:
public static abstract class Stub extends android.os.Binder implements com.houzhi.testproject.ITestService {
private static final java.lang.String DESCRIPTOR = "com.houzhi.testproject.ITestService";
//省略了部分代码
@Override
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
switch (code) {
case INTERFACE_TRANSACTION: {
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_getContent: {
data.enforceInterface(DESCRIPTOR);
java.lang.String _result = this.getContent();
reply.writeNoException();
reply.writeString(_result);
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements com.houzhi.testproject.ITestService {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
mRemote = remote;
}
//省略了部分代码
@Override
public java.lang.String getContent() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.lang.String _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getContent, _data, _reply, 0);
_reply.readException();
_result = _reply.readString();
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
}
static final int TRANSACTION_getContent = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
}Binder底层实现简述
看完上一节其实就能想到怎么去实现Binder了，将接口调用请求转换成数据流的形式，通过int类型的id标识具体是哪一个函数，用token来划分每一次函数调用请求，按照函数参数顺序和类型一个一个地写入和读取参数。而在底层通过一个进程通信（Pipe，共享内存）把这些消息发到服务端/客户端，这样就可以大致实现了。实际上最底层使用的是Binder驱动，服务端通过IPCThreadState开启一个线程(IPCThreadState::self()->startThreadPool())，并且将线程放入到线程池中（IPCThreadState::self()->joinThreadPool()），等待接收来自客户端的请求(talkWithDriver())。而客户端通过BinderProxy(内部保存了本地BpBinder的指针）的transact,最后访问Binder(talkWithDriver())。内部使用访问驱动函数都是ioctl。
ServiceManager
上面大致介绍了服务端，客户端与Binder驱动通信流程。但是大家有没有想过，在客户端需要请求服务端的时候，我怎么知道我究竟想要请求哪一个服务端呢？ServiceManager。ServiceManager是保存了所有的Service的fd(驱动文件号)。通过请求ServiceManager的getService(String name)就可以获取对应的服务。而ServiceManager也是一个服务，它的fd是0,是服务中心管理器。客户端指定name，通过Binder请求ServiceManager，然后得到客户端想要的服务BinderProxy，然后就可以请求服务端了。当然创建服务的时候，首先需要通过ServiceManager.addService将服务添加到ServiceManager中。
Binder连接的几大模块
Android中应用层常用的几个重要的模块都是由Binder联系起来的，ActivityManagerService，WindowManagerService，InputManagerService。下面是他们之间的关系图：
另外还有很多服务，比如说Wifi，NetworkPolicy，Power等等。他们都是在SystemServiceRegistry中注册的，这个注册本来在ContextImpl中，现在移到了一个单独的类SystemServiceRegistry。
代理模式在Binder中的应用分析
代理模式在这里使用的基本上是天衣无缝了，我觉得这是代理模式的经典使用。我们在客户端无法直接访问服务端（因为跨进程，地址空间都不一致），通过代理模式，能够让我们在客户端感觉像是直接访问服务端一样。
如果错过了太阳时你流了眼泪，那你也要错过群星了