文《Android系统的Binder机制之二——服务代理对象（1）》咱们学习了进程的C/C++层面的服务代理对象BpBinder，和Binder底层处理方式。本文咱们将深刻分析一下在进程的Java层面服务代理对象的建立和使用。html
Android中程序大部分都是java开发，底层经过JNI调用C/C++的代码。这样一个程序就分为了两个层面C/C++层面和Java层面。运行状态下，咱们说它们都在一个进程之中，拥有相同的进程属性（UID，GID等等）。java
Binder客户程序的C/C++层面的对象和原理咱们在上文《Android系统的Binder机制之二——服务代理对象（1）》已经学习。下面咱们将介绍客户程序怎样在Java层面经过JNI调用底层C/C++代码的建立服务代理。android
我在《Android系统的Binder机制之一——Service Manager》中介绍过，客户端要想得到服务代理，首先要向ServiceManager查询Service。在Java层面也是这样，因此咱们首先分析Java层面ServiceManager类。cookie
咱们经过查看ServiceManager的源码咱们发现，ServiceManager类型也是一个Singleton类型。全部的方法都是静态方法，全部静态方法都是访问它的IServiceManager类型的静态变量sServiceManager，定义以下：网络
1: private static IServiceManager sServiceManager;
因此能够理解ServiceManager就是IServiceManager对象的一个代理。为建立和访问这个变量都是经过ServiceManager的getIServiceManager方法，定义以下：app
1: private static IServiceManager getIServiceManager() {
2: if (sServiceManager != null) {
3: return sServiceManager;
4: }
5:
6: // Find the service manager
7: sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
8: return sServiceManager;
9: }
经过上面的代码，很是清晰的告诉咱们ServiceManager类型是一个Singleton类型。如今咱们主要研究sServiceManager对象怎样建立的。以下代码建立IServiceManager对象：框架
1: sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
咱们首先查看BinderInternal类的getContextObject方法的代码，发现是Native代码（哈哈！有终于到达C/C++层面了，咱们已经熟悉了），对应的代码为android_util_binder.cpp中的android_os_BinderInternal_getContextObject函数，代码以下：函数
1: static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
2: {
3: sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
4: return javaObjectForIBinder(env, b);
5: }
终于看到咱们上文《Android系统的Binder机制之二——服务代理对象（1）》介绍过的ProcessState对象了，咱们再去查看ProcessState对象的getContextObject方法，代码以下：学习
1: sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
2: {
3: if (supportsProcesses()) {
4: return getStrongProxyForHandle(0);
5: } else {
6: return getContextObject(String16("default"), caller);
7: }
8: }
咱们看到在当前进程的ProcessState对象实际上是调用getStrongProxyForHandle方法来建立binder句柄为0的服务代理对象——BpBinder对象，咱们在《Android系统的Binder机制之一——Service Manager》提到过ServiceManager的binder句柄是一个闻名句柄0。上文《Android系统的Binder机制之二——服务代理对象（1）》已经介绍过ProcessState对象的getStrongProxyForHandle方法，这里就很少说了。this
咱们能够看出Java调用C/C++，建立一个服务代理对象BpBinder，在查看BpBinder的定义咱们发现继承自IBinder接口，而后在android_util_binder.cpp中的方法android_os_BinderInternal_getContextObject中，把C/C++层面的IBinder对象封装成Java层面的IBinder对象。具体实现能够查看上文的android_os_BinderInternal_getContextObject方法。
至此咱们已经清楚BinderInternal.getContextObject()，返回的是ServiceManager的服务代理对象——BpBinder对象。那么ServiceManagerNative类的静态方法asInterface作什么用呢？咱们仍是经过代码来分析，在ServiceManagerNative.java中，asInterface的代码以下：
1: static public IServiceManager asInterface(IBinder obj)
2: {
3: if (obj == null) {
4: return null;
5: }
6: IServiceManager in =
7: (IServiceManager)obj.queryLocalInterface(descriptor);
8: if (in != null) {
9: return in;
10: }
11:
12: return new ServiceManagerProxy(obj);
13: }
将会用IBinder对象建立一个ServiceManagerProxy对象，ServiceManagerProxy类型继承了IServiceManager接口，因此asInterface方法最终目的是用一个IBinder对象建立一个IServiceManager对象。
为何要用IBinder对象建立一个IServiceManager对象呢？经过ServiceManager的代理对象——IBinder对象（BpBinder对象）应该能够直接请求ServiceManager中的服务了啊？咱们在前文《Android系统的Binder机制之二——服务代理对象（1）》简单介绍了一下IBinder类型，客户端经过transact方法向Service发送请求，客户端的onTransact被调用处理客户端的请求，请求经过请求代码来区分。具体请参考Android手册。若是客户端直接用调用ServiceManager的代理对象的IBinder接口，那么客户端必需要记住全部请求的请求代码，对客户端来讲不太友好。因此在ServiceManagerNative类中就把ServiceManager的代理对象——IBinder对象（BpBinder对象）封装成ServiceManagerProxy对象，暴露给客户程序一个IServiceManager接口，这样IServiceManager对象将会代理客户程序发往ServiceManager的代理对象的请求。而且是调用IServiceManager对象的方法来给ServiceManager发送请求，这样对客户程序来说和本地的函数调用是一致的，接口很是友好。好比咱们客户程序须要调用IServiceManager的getService方法来查询一个Service，ServiceManagerProxy实现代码以下：
1: public IBinder getService(String name) throws RemoteException {
2: Parcel data = Parcel.obtain();
3: Parcel reply = Parcel.obtain();
4: data.writeInterfaceToken(IServiceManager.descriptor);
5: data.writeString(name);
6: mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
7: IBinder binder = reply.readStrongBinder();
8: reply.recycle();
9: data.recycle();
10: return binder;
11: }
咱们能够很是清晰的看到ServiceManagerProxy对象将客户程序的请求转换成对ServiceManager代理对象——IBinder对象（BpBinder对象）的调用。后文咱们将会详细介绍怎样经过IServiceManager查询和得到一个系统Service代理对象。
到这里咱们已经分析完了，ServiceManager的Singleton对象——sServiceManager的建立。若是有不清楚的地方请查看代码。
客户程序经过调用ServiceManager类型的静态方法asInterface得到了IServiceManager对象，可是最终目的通常都是要查询和得到其余的Service，通常都是要调用IServiceManager的getService方法，向ServiceManager得到其余的Service。好比：
1: IBinder b = ServiceManager.getService(Context.NETWORKMANAGEMENT_SERVICE);
上面的代码中就是调用ServiceManager的静态方法得到网络管理服务代理对象。咱们顺藤摸瓜，看看系统是怎样生成这个Service代理对象的。这里只是简单说明一下调用顺序，详细过程请查看源码。
一、调用ServiceManager.java中的ServiceManager静态方法getService。
二、调用ServiceManagerNative.java中的ServiceManagerProxy方法getService。代码以下：
1: public IBinder getService(String name) throws RemoteException {
2: Parcel data = Parcel.obtain();
3: Parcel reply = Parcel.obtain();
4: data.writeInterfaceToken(IServiceManager.descriptor);
5: data.writeString(name);
6: mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
7: IBinder binder = reply.readStrongBinder();
8: reply.recycle();
9: data.recycle();
10: return binder;
11: }
请注意IBinder的transact方法是同步方法（本例中ServiceManager处理完成请求以后才会返回），咱们能够看出调用transact以后，调用reply.readStrongBinder()来读取IBinder对象。
三、查看Parcel.java中的readStrongBinder方法，发现是Native方法，将会调用到C/C++的代码。
四、查看android_util_binder.cpp中的android_os_Parcel_readStrongBinder函数。代码以下：
1: static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jobject clazz)
2: {
3: Parcel* parcel = parcelForJavaObject(env, clazz);
4: if (parcel != NULL) {
5: return javaObjectForIBinder(env, parcel->readStrongBinder());
6: }
7: return NULL;
8: }
parcel->readStrongBinder()将会产生一个IBinder对象。
五、查看Parcel.cpp中，Parcel的方法readStrongBinder。代码以下：
1: sp<IBinder> Parcel::readStrongBinder() const
2: {
3: sp<IBinder> val;
4: unflatten_binder(ProcessState::self(), *this, &val);
5: return val;
6: }
六、查看Parcel.cpp中，Parcel的方法unflatten_binder。代码以下：
1: status_t unflatten_binder(const sp<ProcessState>& proc,
2: const Parcel& in, sp<IBinder>* out)
3: {
4: const flat_binder_object* flat = in.readObject(false);
5:
6: if (flat) {
7: switch (flat->type) {
8: case BINDER_TYPE_BINDER:
9: *out = static_cast<IBinder*>(flat->cookie);
10: return finish_unflatten_binder(NULL, *flat, in);
11: case BINDER_TYPE_HANDLE:
12: *out = proc->getStrongProxyForHandle(flat->handle);
13: return finish_unflatten_binder(
14: static_cast<BpBinder*>(out->get()), *flat, in);
15: }
16: }
17: return BAD_TYPE;
18: }
终于看到调用咱们的老朋友ProcessState对象的getStrongProxyForHandle方法了，这样将会建立一个BpBinder对象，而后该BpBinder对象将会被转换成IBinder对象返回给Java层。
七、Java层为了用使用Service方便，能够把Service代理对象——BpBinder对象（IBinder对象）封装成一个对客户程序友好的代理对象，就如前面ServiceManagerProxy所示那样。
八、用户程序就能够经过该代理对象访问相应Service了。
经过所述，咱们了解了Service代理对象在Java层的建立和使用。Android系统的Binder机制博大精深，我在本文中不少方面都是走马观花，若是想深刻学习请参阅Android的源码。
参考资料：