Java层Binder机制详解

本文是我阅读《Android内核剖析》一书的笔记，在此写下来是希望能够加深理解，也希望朋友们能够指出其中的不足。

Binder是一种基于C/S的架构，主要包括四个部分：服务端(Server)，客户端(Client)，Binder驱动，ServiceManager。Binder是Android系统中非常重要的一种IPC机制，如果你想研究Frameworks，必须先对Binder机制诱有一定的认识，否则是无法看懂Frameworks源码的。上述四个部分分别在不同的进程中，他们之间的交互都是通过Binder实现，现在站在宏观的角度来分析Server,Client,ServiceManager之间的关系，如下图：

                   

分析上图：

(1)    当一个服务进程启动后，需要将其中的Service注册到ServiceManager中，此时底层会有两个变化：①后台启动一个监听线程，监听Binder驱动发过来的消息 ② 在Binder驱动中生存一个Service的Binder引用

(2)    Client想和某一个Service交互，需要向ServiceManager申请获得该Service在Binder中的引用，并存放在自身的mRemote变量中，之后通过mRemote调用。

上图展示了客户端如何和服务端交互：

 客户端获取服务端在Binder驱动中的应用，这个引用改写了transact方法(这个方法来自于IBinder)，这个方法通过调用onTransact方法实现如下功能：首先向服务端发送一个消息调用，并挂起当前线程，然后等待服务端执行完毕返回，最后继续执行客户端线程。

下面使用AIDL工具生成一个简单的服务端和客户端吧。在一个包中新建一个ImusicPlayerService.aidl文件，这时在R.java目录下回自动生成一个ImusicPlayerService.java文件。

ImuiscPlayerService.aidl

interface IMusicPlayerService{void start(String path);void stop();}

ImusicPlayerService.java文件

public interface IMusicPlayerService extends android.os.IInterface{/** Local-side IPC implementation stub class. */public static abstract class Stub extends android.os.Binder implements com.binder.demo.IMusicPlayerService{private static final java.lang.String DESCRIPTOR = "com.binder.demo.IMusicPlayerService";/** Construct the stub at attach it to the interface. */public Stub(){this.attachInterface(this, DESCRIPTOR);}/** * Cast an IBinder object into an com.binder.demo.IMusicPlayerService interface, * generating a proxy if needed. */public static com.binder.demo.IMusicPlayerService asInterface(android.os.IBinder obj){if ((obj==null)) {return null;}android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);if (((iin!=null)&&(iin instanceof com.binder.demo.IMusicPlayerService))) {return ((com.binder.demo.IMusicPlayerService)iin);}return new com.binder.demo.IMusicPlayerService.Stub.Proxy(obj);}@Override public android.os.IBinder asBinder(){return this;}@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_start:{data.enforceInterface(DESCRIPTOR);java.lang.String _arg0;_arg0 = data.readString();boolean _result = this.start(_arg0);reply.writeNoException();reply.writeInt(((_result)?(1):(0)));return true;}case TRANSACTION_stop:{data.enforceInterface(DESCRIPTOR);this.stop();reply.writeNoException();return true;}}return super.onTransact(code, data, reply, flags);}private static class Proxy implements com.binder.demo.IMusicPlayerService{private android.os.IBinder mRemote;Proxy(android.os.IBinder remote){mRemote = remote;}@Override public android.os.IBinder asBinder(){return mRemote;}public java.lang.String getInterfaceDescriptor(){return DESCRIPTOR;}@Override public boolean start(java.lang.String filePath) throws android.os.RemoteException{android.os.Parcel _data = android.os.Parcel.obtain();android.os.Parcel _reply = android.os.Parcel.obtain();boolean _result;try {_data.writeInterfaceToken(DESCRIPTOR);_data.writeString(filePath);mRemote.transact(Stub.TRANSACTION_start, _data, _reply, 0);_reply.readException();_result = (0!=_reply.readInt());}finally {_reply.recycle();_data.recycle();}return _result;}@Override public void stop() throws android.os.RemoteException{android.os.Parcel _data = android.os.Parcel.obtain();android.os.Parcel _reply = android.os.Parcel.obtain();try {_data.writeInterfaceToken(DESCRIPTOR);mRemote.transact(Stub.TRANSACTION_stop, _data, _reply, 0);_reply.readException();}finally {_reply.recycle();_data.recycle();}}}static final int TRANSACTION_start = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);static final int TRANSACTION_stop = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);}public boolean start(java.lang.String filePath) throws android.os.RemoteException;public void stop() throws android.os.RemoteException;}

我们来重点分析一下两个重要的类：

class Stub extends android.os.Binderimplements com.binder.demo.ImusicPlayerService

private static class Proxy implementscom.binder.demo.ImusicPlayerService

对照上面一个图很容易知道Stub这个类对应的是Server端，而Proxy对应的是客户端，那么首先从客户端分析：

在客户端中，我们看到一个私有变量mRemote，它存放的就是服务端在Binder驱动中的一个引用。接下来分析start方法：为了查看方便，我再次将start方法代码贴出来：

public boolean start(java.lang.String filePath) throws android.os.RemoteException{android.os.Parcel _data = android.os.Parcel.obtain();android.os.Parcel _reply = android.os.Parcel.obtain();boolean _result;try {_data.writeInterfaceToken(DESCRIPTOR);_data.writeString(filePath);mRemote.transact(Stub.TRANSACTION_start, _data, _reply, 0);_reply.readException();_result = (0!=_reply.readInt());}finally {_reply.recycle();_data.recycle();}return _result;}

发现start里面其实就是调用的mRemote中的transact方法，这不就是一种典型的代理模式吗？我想这里之所以使用代理模式，是为了在将参数打包发送到服务端去之前，固定各个参数在包中的顺序，方便服务端去除数据。至于其中的Stub.TRANSACTION_start是在Stub类中定义的一个变量，用来标示函数的。

static final int TRANSACTION_start =(android.os.IBinder.FIRST_CALL_TRANSACTION + 0);

 

transact函数经改写后，本质就是调用了Stub中的onTransact函数，那么我们来分析一下服务端的onTransact函数吧。同样为了方便，再次贴出：

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_start:{data.enforceInterface(DESCRIPTOR);java.lang.String _arg0;_arg0 = data.readString();boolean _result = this.start(_arg0);reply.writeNoException();reply.writeInt(((_result)?(1):(0)));return true;}

由于传入的code是TRANSACTION_start,所以服务端首先从包中按照客户端的写入顺序读出数据，然后调用自己的start方法，也就是说我们已经完成在客户端调用服务端的方法了，然后将返回数据写入到reply包中，Binder驱动接到这个通知后，就会继续执行客户端线程从这个包中去除数据。

 

细心的朋友可能会发现一个问题，还有一个非常关键的问题没有解决，客户端是如何拿到服务端的Binder应用的，下面就来分析一下这个问题

 

在写程序的时候，经常会使用getSystemService这个函数来获取一个XXXManager,例如我需要获得一个InputMethodManager，那么我会这么做：

InputMethodManagerwm=(InputMethodManager)context.getSystemService(“input_method”);getSystemService这个函数是在ContextImpl中实现的，部分源码如下：} else if (INPUT_METHOD_SERVICE.equals(name)) {            return InputMethodManager.getInstance(this);进入到getInstance（this）看看源码：static public InputMethodManager getInstance(Looper mainLooper) {        synchronized (mInstanceSync) {            if (mInstance != null) {                return mInstance;            }            IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);            IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);            mInstance = new InputMethodManager(service, mainLooper);        }        return mInstance;}

代码中通过使用ServiceManager中的getService方法获取到一个Binder对象，然后通过这个Binder对象new 一个InputMethodManager出来并返回，这里我们不得不猜想这个Binder对象就是一个服务端的引用，为了验证猜想，继续进入到getService看看

public static IBinder getService(String name) {        try {            IBinder service = sCache.get(name);            if (service != null) {                return service;            } else {                return getIServiceManager().getService(name);            }        } catch (RemoteException e) {            Log.e(TAG, "error in getService", e);        }        return null;    }

还挺复杂的，我们进入getIServiceManager中看看吧，估计第一次学习Binder的同学已经晕了，没事多看几遍就很清晰的。

private static IServiceManager getIServiceManager() {        if (sServiceManager != null) {            return sServiceManager;        }        // Find the service manager        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());        return sServiceManager;}

到了这里就涉及到几点知识点了，容我慢慢道来：

(1)    ServiceManager本身就是一个Service,那么我们的客户端再和它交互之前也必须获取到它在Binder中的引用，说道这里可能有些朋友就会想，我们不是要通过ServiceManager获取Binder应用吗，那么他自己的Binder应用怎么获取呢，呵呵，这个问题解决起来很简单，Android中提供了BinderInternal.getContextObject（）函数返回ServiceManger的引用，说白了就是这个意思：ServiceManager的Binder引用通过上面这个函数获得，而其他Service的Binder引用需要通过ServiceManager获得。

(2)    这里有一个asInterfaec函数，它的代码大家可以查看Stub类中的asInterface，在这里我只说明一下它的作用。前面已经说过，一个Service说到底就是一个Binder对象，一个Binder对象创建后，就会在Binder驱动中形成一个引用，客户端就是通过这个引用和服务端交互，但是如果在这个Service进程内部调用这个Service，那么就没有必要使用IPC，直接可以使用这个Service对象(Binder对象)，也就是说这个函数就是对外界提供了统一的接口，不管是远程调用还是本地调用，使用的都是同样的代码，

 

到这里我们会发现，在XXXManager里面有一个IXXX类型的变量，如果是远程调用，那么就是Proxy累，如果是本地调用，存放的就是Stub类

总结：

（1）      Server所在进程启动后，需要将其中的Servic注册到ServiceManager,这样Client就可以通过ServiceManager找到对应的Binder引用，而ServiceManager自身的Binder引用时通过BinterInternal.getContextObject()函数获得

（2）      我们在写程序时，通过getSystemService获得XXXManager,在XXXManager中保存了一个IXXX变量，这个变量可能是Proxy类型，也可能是Stub类型，这个过程被asInterface函数屏蔽了。