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