Binder in Java
Android在Native层实现了进程间的Binder通信，但是上层应用程序的开发及Framework的实现都是Java，用Java层再实现一次肯定是不合理的，Java可以通过JNI调用Native Code，所以通过JNI复用Binder在Native层的实现就是一个顺理成章的事情。
注册Service
在Init进程的init2阶段，系统启动了ServerThread，在ServerThread中会启动很多用Java实现的系统服务，比如说PowerService：
power = new PowerManagerService(); ServiceManager.addService(Context.POWER_SERVICE, power);
新建Server端实体，然后向ServiceManager注册，从代码表面看是和Native层Binder一样的。PowerManagerService继承自Java层的Binder类：
public final class PowerManagerService extends IPowerManager.Stub public interface IPowerManager extends android.os.IInterface { public static abstract class Stub extends android.os.Binder implements android.os.IPowerManager {
在以在new PowerManagerService时会调用Binder的构造函数，Binder的构造函数中调用了init()，init是native方法，执行JNI的android_os_Binder_init:
static void android_os_Binder_init(JNIEnv* env, jobject obj) { JavaBBinderHolder* jbh = new JavaBBinderHolder(); if (jbh == NULL) { jniThrowException(env, "java/lang/OutOfMemoryError", NULL); return; } ALOGV("Java Binder %p: acquiring first ref on holder %p", obj, jbh); jbh->incStrong((void*)android_os_Binder_init); env->SetIntField(obj, gBinderOffsets.mObject, (int)jbh); }
在android_os_Binder_init，新建了一个JavaBBinderHolder对角，并将其指针保存在了obj即Binder的gBinderOffsets.mObject域中，而gBinderOffsets.mObject又是个什么东西？看一下它的定义：
static struct bindernative_offsets_t { jclass mClass; jmethodID mExecTransact; jfieldID mObject; } gBinderOffsets;
在AndroidRuntine::startReg中会调用register_android_os_Binder，register_android_os_Binder会调用int_register_android_os_Binder等函数建立Java层Binder、BinderProxy、BinderInternal、Log等与Native层的映射关系。比如在int_register_android_os_Binder中会通过JNI标准的方法GetMethodID等初始化gBinderOffsets：
static int int_register_android_os_Binder(JNIEnv* env) { jclass clazz; clazz = env->FindClass(kBinderPathName); LOG_FATAL_IF(clazz == NULL, "Unable to find class android.os.Binder"); gBinderOffsets.mClass = (jclass) env->NewGlobalRef(clazz); gBinderOffsets.mExecTransact = env->GetMethodID(clazz, "execTransact", "(IIII)Z"); assert(gBinderOffsets.mExecTransact); gBinderOffsets.mObject = env->GetFieldID(clazz, "mObject", "I"); assert(gBinderOffsets.mObject); return AndroidRuntime::registerNativeMethods( env, kBinderPathName, gBinderMethods, NELEM(gBinderMethods)); }
在android_os_Binder_init中new了一个JavaBBinderHolder，JavaBBinderHolder new了一个JavaBBinder保存到了自己的成员wp<JavaBBinder> mBinder中。
JavaBBinder继承自Native层的BBinder，并且将Java层的Binder对象（此处即PowerManagerService）保存到了成员mObject中，并通过object()方法返回。
现在我们发现，JavaBinder，BinderBBinderHolder，JavaBBinder存在相互引用关系：
PowerManagerService.mObject->JavaBBinderHolder
JavaBBinderHolder.mBinder->JavaBBinder
JavaBBinder.mObject->PowerManagerService
Binder是一种Client-Server类型的IPC，PowerManagerService属于Server端，从Native Binder中我们知道，Client通过BpBinder经由Binder Driver、BBinder与Serverr通信，PowerManagerService通过JavaBBinderHolder引用JavaBBinder，而JavaBBinder继承自BBinder，符合了Server的条件，Server实体有了，接下来就要向ServiceManager注册，通过以下方法：
ServiceManager.addService(Context.POWER_SERVICE,power);
// In ServiceManager public static void addService(String name, IBinder service) { try { getIServiceManager().addService(name, service, false); } catch (RemoteException e) { Log.e(TAG, "error in addService", e); } } private static IServiceManager getIServiceManager() { if (sServiceManager != null) { return sServiceManager; } sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject()); return sServiceManager; }
BinderInternal.getContextObject是一个Native方法，调用JNIandroid_os_BinderInternal_getContextObject：
static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz) { sp<IBinder> b = ProcessState::self()->getContextObject(NULL); return javaObjectForIBinder(env, b); }
ProcessState::self()->getContextObject就很熟悉了，在Binder in Native中可以知道，这个调用返回new BpBinder(0)。
javaObjectForIBinder的作用就是，新建一个Java层的BinderProxy对象,将Native层的BpBinder保存到BinderProxy.mObject，并将BinderProxy的弱引用通过attachObject保存到Native层的BpBinder(成员mObjects中)，这样Java层的BinderProxy与Native层的BpBinder就可以相互引用了。Java层的BinderProxy及其在Native层的表示间的映射关系同Binder类一样也是在register_android_os_Binder中建立的。
上面红色的部分就等效于：
gServiceManager = ServiceManagerNative.asInterface(new BinderProxy());
ServiceManagerNative继承自IServiceManager与Java层的Binder类，BinderProxy可以引用BpBinder。asInterface就像Native Binder中的interface_cast的，asInterface实现可以简化为：
return new ServiceManagerProxy(obj);
obj是BinderProxy对象。ServiceManagerProxy直接将这个BinderProxy对象保存在了成员mRemote中，并通过asBinder返回。
ServiceManagerProxy同时实现了IServiceManager，而且由其名字可知，ServiceManagerProxy是作为ServiceManager在Client端的代理的，看下它的addService的实现：
public void addService(String name, IBinder service, boolean allowIsolated) throws RemoteException { Parcel data = Parcel.obtain(); Parcel reply = Parcel.obtain(); data.writeInterfaceToken(IServiceManager.descriptor); data.writeString(name); data.writeStrongBinder(service); data.writeInt(allowIsolated ? 1 : 0); mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0); reply.recycle(); data.recycle(); }
writeStrongBinder是Native方法，调用android_os_Parcel_writeStrongBinder，在android_os_Parcel_writeStrongBinder将Java Parcel转换成Native Parcel（Native Parcel的指针保存在Java Parcel的成员变量中），然后调用以下语句：
const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));
sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)根据obj返回JavaBBinder或Native BpBinder，在这里传入的obj 是PowerManagerService，返回JavaBBinder。接下来调用了mRemote.transact，mRemote是BinderProxy的对象。
BinderProxy的transact是Native方法，调用JNIandroid_os_BinderProxy_transact，在android_os_BinderProxy_transact中通过：
IBinder* target = (IBinder*) env->GetIntField(obj, gBinderProxyOffsets.mObject);
...
status_t err = target->transact(code, *data, reply, flags);
获取到BinderProxy中保存的BpBinder，然后调用BpBinder的transact，到这里就和Native Binder的调用流程一样了，Native ServiceManager会注册我们的Service，在这里是PowerManagerService。
获得注册的Service
Service已经向ServiceManager注册了，那么我们怎么获得所注册的Service，或者更准确地说，怎么获得所注册的Service的代理呢？
回想下我们在APK中是怎么获取系统服务的：
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
看一下getSystemService的实现，位于ContextImpl中：
@Override public Object getSystemService(String name) { ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); return fetcher == null ? null : fetcher.getService(this); } registerService(POWER_SERVICE, new ServiceFetcher() { public Object createService(ContextImpl ctx) { IBinder b = ServiceManager.getService(POWER_SERVICE); IPowerManager service = IPowerManager.Stub.asInterface(b); return new PowerManager(ctx.getOuterContext(), service, ctx.mMainThread.getHandler()); }});
1. ServiceManager.getService获得IBinder对象
同ServiceManager.addService一样，ServiceManager.getService首先获得一个ServiceManagerProxy的对象，然后调用它的getService方法：
public IBinder getService(String name) throws RemoteException { ... mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0); IBinder binder = reply.readStrongBinder(); ... return binder; }
mRemote是BinderProxy对象，内部引用了BpBinder，调用BinderProxy的Native方法transact与Binder通信，然后通过readStrongBinder()读取返回的数据，一个IBinder对象。
readStrongBinder中通过javaObjectForIBinder返回了BinderProxy对象，前面已经说过。
2. 通过asInterface将获得的IBinder对象转换成IPowerManager对象
IPowerManager.Stub.asInterface可以简化为：
return new android.os.IPowerManager.Stub.Proxy(obj);
Proxy只是将传入的参数（BinderProxy）保存到了成员mRemote中并通过asBinder返回。
Proxy与Stub都是IPowerManager.aidl编译后生成的类，都位于IPowerManager.java中。关于aidl网上有很多资料。
3. IPowerManager对象是不向外暴露的，构造一个PowerManager封装IPowerManager返回。
PowerManager只是将IPowerManager保存在了成员变量中，PowerManager中保存了BinderProxy，BinderProxy中引用了Native BpBinder，就可以与Server进行通信了。
Server端响应Client请求
Server端接收到Client的请求后会调用BBinder的transact处理请求，transact会调用虚函数onTransact，JavaBBinder继承自BBinder，所以会调用JavaBBinder::onTransact，在JavaBBinder::onTransact中有以下一句：
jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact, code, (int32_t)&data, (int32_t)reply, flags);
通过JNI反向调用了Java类的方法。前面我们知道了，Java实现的Service中，Service对象，JavaBBinderHolder，JavaBBinder存在相互引用关系，JavaBBinder的成员mObject引用了Java中的Service对象，比如此处的PowerManagerService，而且在int_register_android_os_Binder中通过
gBinderOffsets.mExecTransact = env->GetMethodID(clazz, "execTransact", "(IIII)Z");
将Service的execTransact方法（其实是Binder的方法）保存在了gBinderOffsets.mExecTransact中，所在以JavaBBinder::onTransact中会调用Binder.execTransact。在Binder.execTransact中调用了onTransact，执行子类即Stub类的onTransact方法，在onTransact中根据code值执行相应的方法，最终是调用Service类（继承自Stub）中相应的方法。
总结
Java层通过JNI利用了Native层的Binder，在JNI函数注册时会建立Java层Binder，BinderProxy，BinderProxy等类与Native层的映射关系。Java层Service实体继承自Java层的Binder类，在Binder类初始化时会创建一个JavaBBinderHolder作为JavaBBinder的容器，JavaBBinder继承自BBinder，Java层Binder类引用JavaBBinderHolder，JavaBBinderHolder引用JavaBBinder，JavaBBinder继承自BBinder并引用Java层的Binder类，这三者互相引用，这样Java层的Service实体就可以通过BBinder与驱动进行通信了。
进程向Java层的ServiceManager代理发送GET_SERVICE请求，然后通过JNI向Native层的ServiceManager请求服务，Native层的ServiceManager返回请求的服务的代理对你BpBinder，通过javaObjectForIBinder函数将Native的BbBinder转化为Java层对应的BinderProxy，然后通过aidl生成的Stub类asInterface方法将BinderProxy封闭到请求的服务的代理对象中，这个代理对象引用了BinderProxy，BinderProxy内部保存了Native层的BpBinder，这样就可以与驱动进行通信了。
当Server端接收到Client的请求时会通过BBinder的transact调用Server的服务，BBinder的transact调用虚函数onTransact，这样就会调到BBinder的子类JavaBBinder的onTransact，而JavaBinder::onTransact会通过JNI反向调用到Java层Binder类的execTransact，Binder.execTransact调用onTransact即子类Stub的onTransact，然后根据code值调用Service实体类（继承自Stub）相应的方法。