Android系统的Binder机制之三——服务代理对象（2）

转自：http://my.unix-center.net/~Simon_fu/?p=942 

上文《Android系统的Binder机制之二——服务代理对象（1）》我们学习了进程的C/C++层面的服务代理对象BpBinder，和Binder底层处理方式。本文我们将深入分析一下在进程的Java层面服务代理对象的创建和使用。

Android进程的C/C++层面和Java层

    Android中程序大部分都是java开发，底层通过JNI调用C/C++的代码。这样一个程序就分为了两个层面C/C++层面和Java层面。运行状态下，我们说它们都在一个进程之中，拥有相同的进程属性（UID，GID等等）。

    Binder客户程序的C/C++层面的对象和原理我们在上文《Android系统的Binder机制之二——服务代理对象（1）》已经学习。下面我们将介绍客户程序怎样在Java层面通过JNI调用底层C/C++代码的创建服务代理。

ServiceManager类型和对象

    我在《Android系统的Binder机制之一——Service Manager》中介绍过，客户端要想获得服务代理，首先要向ServiceManager查询Service。在Java层面也是这样，所以我们首先分析Java层面ServiceManager类。

    我们通过查看ServiceManager的源码我们发现，ServiceManager类型也是一个Singleton类型。所有的方法都是静态方法，所有静态方法都是访问它的IServiceManager类型的静态变量sServiceManager，定义如下：

1: private static IServiceManager sServiceManager;

所以可以理解ServiceManager就是IServiceManager对象的一个代理。为创建和访问这个变量都是通过ServiceManager的getIServiceManager方法，定义如下：

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方法，这里就不多说了。

    我们可以看出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的创建。如果有不清楚的地方请查看代码。

查询和获得Service代理对象

    客户程序通过调用ServiceManager类型的静态方法asInterface获得了IServiceManager对象，但是最终目的一般都是要查询和获得其他的Service，一般都是要调用IServiceManager的getService方法，向ServiceManager获得其他的Service。比如：

1: IBinder b = ServiceManager.getService(Context.NETWORKMANAGEMENT_SERVICE);

    上面的代码中就是调用ServiceManager的静态方法获得网络管理服务代理对象。我们顺藤摸瓜，看看系统是怎样生成这个Service代理对象的。这里只是简单说明一下调用顺序，详细过程请查看源码。

1、调用ServiceManager.java中的ServiceManager静态方法getService。

2、调用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对象。

3、查看Parcel.java中的readStrongBinder方法，发现是Native方法，将会调用到C/C++的代码。

4、查看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对象。

5、查看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: }

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层。

7、Java层为了用使用Service方便，可以把Service代理对象——BpBinder对象（IBinder对象）封装成一个对客户程序友好的代理对象，就如前面ServiceManagerProxy所示那样。

8、用户程序就可以通过该代理对象访问相应Service了。

    通过所述，我们了解了Service代理对象在Java层的创建和使用。Android系统的Binder机制博大精深，我在本文中很多方面都是蜻蜓点水，如果想深入学习请参阅Android的源码。

 

参考资料：

IPC框架分析 Binder，Service，Service manager