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

[java] view
plaincopyprint?

interface IMusicPlayerService

{

void start(String path);

void stop();

}

ImusicPlayerService.java文件

[java] view
plaincopyprint?

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方法代码贴出来：

[java] view
plaincopyprint?

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函数吧。同样为了方便，再次贴出：

[java] view
plaincopyprint?

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，那么我会这么做：

[java] view
plaincopyprint?

<pre name="code" class="java">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;

}

</pre><br><br>

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

[java] view
plaincopyprint?

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的同学已经晕了，没事多看几遍就很清晰的。

[java] view
plaincopyprint?

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函数屏蔽了。