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）相应的方法。