上一篇 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 的服务。
现在可以串起来了吧。