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代理对象。而是一個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 的服务。

现在可以串起来了吧。