[置顶] Android源码代理模式---Binder

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中的应用分析

代理模式在这里使用的基本上是天衣无缝了，我觉得这是代理模式的经典使用。我们在客户端无法直接访问服务端（因为跨进程，地址空间都不一致），通过代理模式，能够让我们在客户端感觉像是直接访问服务端一样。

如果错过了太阳时你流了眼泪，那你也要错过群星了