Binder机制，从Java到C （3. ServiceManager in Java）

上一篇 Binder机制，从Java到C （2. IPC in System Service ：AMS）  中提到 Application是通过ServiceManager找到了AMS 的service代理对象。那在这个之前当然是要先找到ServiceManager的代理对象，才能调用ServiceManager的服务嘛。下面就看看怎么来获得这个代理对象的吧：

还记得上一篇调用的ServiceManager的方法吧：IBinder b = ServiceManager.getService("activity");

那下面就來看一下ServiceManager.getService()是怎样的:
/frameworks/base/core/java/android/os/ServiceManager.java

public final class ServiceManager {
    ...
    private static IServiceManager getIServiceManager() {
        if (sServiceManager != null) {
            return sServiceManager;
        }

        // Find the service manager
        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());  （1）
        return sServiceManager;
    }

    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;
    }

 说明：

（1） ：根据前两篇的分析，我们可以推測是在BinderInternal.getContextObject()中，找到了ServiceManager的BinderProxy，似乎和前面有些不同。接着看。

那就接着看BinderInternal.getContextObject()有什麼不同：
/framework/base/core/java/com/android/internal/os/BinderInternal.java

public class BinderInternal {
    ….
    public static final native IBinder getContextObject();
    ….
}

 会getContextObject()是个JNI方法, ServiceManager难道运行在native环境？答案是Yes! ServiceManager确实运行在Native环境。

继续看，在/framework/base/core/jni/android_util_Binder.cpp找到了对应的方法：

static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
 {
     sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
     return javaObjectForIBinder(env, b); //按照字面意思来看，就是把一个Native层的Binder代理对象转化成Java层的Binder代理对象
 }

这个方法只有两句代码，第一句看着就是找一个IBinder对象啦，然后第二句，就是把一个Native里面的Binder代理对象转化成Java层的Binder代理对象，然后好返回给Java层。

来看一下第一句代码，在/frameworks/native/libs/binder/ProcessState.cpp里：

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
{
    return getStrongProxyForHandle(0);
}

 里面的这一句代码就暂时先不展开了，不然没完没了了，這里按字面意思也可以看出，是根据一个handle來获得一个Native层的Binder代理对象。而0是一個default值。代表servicemanager的binder handle值。所以这里你给个0，就返回给你servicemanager的Binder代理对象。

那到这里，我們就认为通过BinderInternal.getContextObject()，获得了Native的一個binder 代理对象后，javaObjectForIBinder()会创建一个BinderProxy对象返回到Java层去。
经过上面的分析，我们可以知道：ServiceManager的Stub端在Native层。ServiceManager的Proxy端在Java层。

结合前面两篇总结一下：
1. Application通过AMS的static 方法，先得到ServiceManager的BinderProxy。
2. 然后从ServiceManager获得AMS的BinderProxy，从而可以使用AMS的远程服务方法。
3. Application通过AMS的远程服务方法，如bindservice(), 將Application Remote Service的BinderProxy提供给Activity，从而Activity可以远程调用这些remote service 的服务。

现在可以串起来了吧。