Android Binder Java

在阅读本文章前，如果读者还没有阅读过《android Binder Native》，强烈建议先去阅读这篇文章，否则你可能有的地方会不明白。

如果你已经读过了上篇文章，那么对于BpBinder、BBinder应该有了一定了解，在Java层的Binder也是一个C/S架构，而且在命名上尽可能的保持与Native层一致，所以大家可以认为，Java Binder 是Native Binder的一个镜像版本。下面先来看下Java Binder 中的相关类。

• Binder代表了Bn端（相当于服务端）
• BinderProxy 代表了Bp端（相当于客户端）
• BinderInternal只是一个仅供Binder使用的类，内部定义了一个GCWatcher用来处理Binder相关的回收

了解了Java Binder 的大致关系后，我们要想一下，Java层代码 是如何与Native层关联的？ 有的人会问，为啥要关联？？ MMP, Android是Linux系统，肯定是要借助Native层的 C 代码来操作底层硬件了…. 下面分析Java Binder和Native Binder是如何建立起联系的

以下Native代码使用在线阅读网站:http://androidxref.com/进行阅读,且代码版本为 7.1.1_r6 ， Java代码版本 API23

Java Binder的初始化

在Android系统中，在Java创建初期的时，系统会提前注册一些JNI（Java 和 Native 通信的桥梁，不懂的同学自行查阅～）函数，其中就有一个函数是用来专门负责搭建 Java Binder 和Native Binder关系的。它在Binder.cpp 的register_android_os_binder内

int register_android_os_Binder(JNIEnv* env)
{   //初始化java binder 和 native层关系
    if (int_register_android_os_Binder(env) < 0)
        return -1;
    //初始化 java binder internal 和native 层关系
    if (int_register_android_os_BinderInternal(env) < )
        return -1;
    //初始化 java binderproxy 和native层关系
    if (int_register_android_os_BinderProxy(env) < 0)
        return -1;
        ....

        return 0;
}

上面代码完成了3个操作

• 关联 Java Binder 和Native
• 关联 Java BinderInternal 和Native
• 关联 Java BinderProxy 和Native

下面一一分析。

static int int_register_android_os_Binder(JNIEnv* env)
{   //kBinderPathName 为 "android/os/Binder"
    jclass clazz = FindClassOrDie(env, kBinderPathName);
    //静态类对象，专门保存Binder类在JNI层的一些信息
    gBinderOffsets.mClass = MakeGlobalRefOrDie(env, clazz);
    gBinderOffsets.mExecTransact = GetMethodIDOrDie(env, clazz, "execTransact", "(IJJI)Z");
    gBinderOffsets.mObject = GetFieldIDOrDie(env, clazz, "mObject", "J");
    //注册
    return RegisterMethodsOrDie(
        env, kBinderPathName,
        gBinderMethods, NELEM(gBinderMethods));
}

看上面代码我们需要知道

• gBinderOffset 是一个静态类对象，它专门保存Binder在JNI层的一些使用信息
• 获取信息 并赋值给 gBinderOffsets.mExecTransact 和 mObject 这些都是JNI 对Java层 Binder进行操作时 所需要的

static int int_register_android_os_BinderInternal(JNIEnv* env)
{   // PathName com/android/internal/os/BinderInternal
    jclass clazz = FindClassOrDie(env, kBinderInternalPathName);

    gBinderInternalOffsets.mClass = MakeGlobalRefOrDie(env, clazz);
    gBinderInternalOffsets.mForceGc = GetStaticMethodIDOrDie(env, clazz, "forceBinderGc", "()V");

    return RegisterMethodsOrDie(
        env, kBinderInternalPathName,
        gBinderInternalMethods, NELEM(gBinderInternalMethods));
}

看代码可以知道跟 Binder 的代码基本类似。

static int int_register_android_os_BinderProxy(JNIEnv* env)
{   // Error类
    jclass clazz = FindClassOrDie(env, "java/lang/Error");
    gErrorOffsets.mClass = MakeGlobalRefOrDie(env, clazz);
    // Proxy
    clazz = FindClassOrDie(env, kBinderProxyPathName);
    gBinderProxyOffsets.mClass = MakeGlobalRefOrDie(env, clazz);
    gBinderProxyOffsets.mConstructor = GetMethodIDOrDie(env, clazz, "<init>", "()V");
    //应该是用于 Binder 内的 DeathRecipient通知.
    gBinderProxyOffsets.mSendDeathNotice = GetStaticMethodIDOrDie(env, clazz, "sendDeathNotice",
"(Landroid/os/IBinder$DeathRecipient;)V");
    gBinderProxyOffsets.mObject = GetFieldIDOrDie(env, clazz, "mObject", "J");
    // 弱引用 赋值mSelf
    gBinderProxyOffsets.mSelf = GetFieldIDOrDie(env, clazz, "mSelf","Ljava/lang/ref/WeakReference;");
    gBinderProxyOffsets.mOrgue = GetFieldIDOrDie(env, clazz, "mOrgue", "J");

    clazz = FindClassOrDie(env, "java/lang/Class");
    gClassOffsets.mGetName = GetMethodIDOrDie(env, clazz, "getName", "()Ljava/lang/String;");

    return RegisterMethodsOrDie(
        env, kBinderProxyPathName,
        gBinderProxyMethods, NELEM(gBinderProxyMethods));
}

相比与Binder 与BinderInternal，BinderProxy的初始化关联代码可能稍微复杂一点，它主要做了如下操作

• 找到Error类
• 找到根据pathName找到BinderProxy 赋值给gBinderProxyOffsets.mClass
• 使用弱引用 并赋值给 mSelf

由上面这些代码可以看出来，3部主要定义了几个全局的静态变量，分别是gBinderOffsets、gBinderInternalOffsets、gBinderProxyOffsets,并获取了一些JNI使用Java Binder的一些函数,如: MethID、fieldID等，最后通过RegisterMethodsOrDie 来真正的搭建 Native 与Java的通信。

初始化完成了，我们接下来分析 它的工作流程(通过ActivityManagerService，简称AMS)。

如果大家看了上一篇文章《android Binder Native》的话，那么就应该知道，Binder消息最终会由ServiceManager来管理，如果要接受 那么就需要将自己注册到ServiceManager内，所以接下来我们要研究的内容如下

• AMS如何将自己注册进ServiceManager
• AMS如何响应客户端的Binder调用请求

我们从AMS的setSystemProcess为起点来看

 public void setSystemProcess() {
     try {       ServiceManager.addService(Context.ACTIVITY_SERVICE,this,true);
   .....     
    }

很清晰，没毛病。第一行代码就直接把自己加入到了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);
        }
    }

可以看到，这里调用了getIServiceManager()的addService, 它又是个啥东东?

    private static IServiceManager getIServiceManager() {
        if (sServiceManager != null) {
            return sServiceManager;
        }

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

竟然调用了ServiceManagerNative.asInterface() 和 BinderInternal.getContectObject()，如果大家阅读过前一篇，那么就应该会很熟悉了。我们来看getContextObject()

public static final native IBinder getContextObject();

在BinderInternal内，它是一个native方法，我们直接转到在Binder.cpp 的android_os_BinderInternal_getContextObject()内

static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
    sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
    //创建一个Java Binder对象
    return javaObjectForIBinder(env, b);
}

上面代码首先是调用了 ProcessState的getContextObject(NULL)方法，该方法返回的实际是一个BpBinder,如果有不熟悉的同学，由于篇幅较多，这里就不在叙述，请大家转移至上一篇文章／
接下来我们看 javaOBjectForIBinder(),该函数在Native创建了一个Java Binder对象。

jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{
    .....
    AutoMutex _l(mProxyLock);


    jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
    if (object != NULL) {
        ....
        android_atomic_dec(&gNumProxyRefs);
        val->detachObject(&gBinderProxyOffsets);
        env->DeleteGlobalRef(object);
    }
    object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
    if (object != NULL) {
        env->SetLongField(object, gBinderProxyOffsets.mObject, (jlong)val.get());
        val->incStrong((void*)javaObjectForIBinder);

        jobject refObject = env->NewGlobalRef(
                env->GetObjectField(object, gBinderProxyOffsets.mSelf));
        //将新建的BinderProxy注册到BpBinder的ObjecrtManager中
        //并注册回调函 proxy_cleanup,以便在BinderProcy(detach)时回收资源
        val->attachObject(&gBinderProxyOffsets, refObject,
                jnienv_to_javavm(env), proxy_cleanup);
        //用户死亡通知的list
        sp<DeathRecipientList> drl = new DeathRecipientList;
        drl->incStrong((void*)javaObjectForIBinder);
        //将死亡通知的list 和BinderProxy联系起来
        env->SetLongField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jlong>(drl.get()));
        //增加proxy对象引用计数
        android_atomic_inc(&gNumProxyRefs);
        //用于垃圾回收。创建的Proxy对象超过200个，则调用BinderInternal内的GCWatcher进行响应回收。
        incRefsCreated(env);
    }
    return object;
}

看代码我们知道 首先调用了 val->findObject(), 然而val就是BpBinder, BpBinder的findObject 主要功能是 查找gBinderProxyOffsets 是否存在ObjectManager中，如果存在就返回。 这里又突然蹦出来个ObjectManager，这是啥东西？？ 它实际存在于 BpBinder中，负责管理在Native层中创建的 Java BinderProxy对象。
接下来又创建了一个新的BinderProxy，然后调用attachObject.于BpBinder关联，BpBinder的目的段又是ServiceManager。所以该准备的也都准备就绪了。 以上代码主要做了如下事件:

• 创建一个Java层的BinderProxy
• 通过attachObject 将Java层 BinderProxy与 BpBinder进行关联
• 返回BinderProxy

接下来看ServiceManagerNative.asInterface

    static public IServiceManager asInterface(IBinder obj)
    {
        if (obj == null) {
            return null;
        }
        IServiceManager in =(IServiceManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
            return in;
        }

        return new ServiceManagerProxy(obj);
    }

可以看到，最终以BpProxy对象为 参数，构造了一个ServiceManagerProxy(BpProxy), 这种结构和Interface.h 里面定义的宏是一个套路,以BpProxy为参数构造一个和业务相关的Proxy对象。我们来看ServiceManagerProxy 的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实际上是BinderProxy对象，调用它的transact将封装好的请求发送出去。
        mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
        reply.recycle();
        data.recycle();
    }

我们先来看data.writeStrongBinder 它是一个特别的函数，为了让大家能够知道具体是怎么特别，我们先来看以下知识点。

AMS从ActivityManagerNative派生，并且ActivityManagerNative 从Binder派生,我们直接看Binder的构造期就好了。

 public Binder() {
        init();
        ....
    }

调用了init方法，该方法是native的

static void android_os_Binder_init(JNIEnv* env, jobject obj)
{   //创建一个JavaBBinderHolder
    JavaBBinderHolder* jbh = new JavaBBinderHolder();
    if (jbh == NULL) {
        jniThrowException(env,"java/lang/OutOfMemoryError", NULL);
        return;
    }

    jbh->incStrong((void*)android_os_Binder_init);
    //将这个JavaBBinderHolder 保存到 Java Binder对象的mObject中
    env->SetLongField(obj, gBinderOffsets.mObject,(jlong)jbh);
}

上面创建了一个Native的 JavaBBinderHolder对象，并且将它与Java Binder对象进行了关联。

class JavaBBinderHolder : public RefBase
{
public:
    sp<JavaBBinder> get(JNIEnv* env, jobject obj)
    {
        ....
        sp<JavaBBinder> b = mBinder.promote();
        if (b == NULL) {
            b = new JavaBBinder(env, obj);
            mBinder = b;
            ....
        }
        return b;
    }

可以看到JavaBBinderHolder派生RefBase，并不在 Binder的家族链，但是get函数里面新建了一个 JavaBBinder(env,Java中的Binder对象),而JavaBBinder从BBinder派生。那么问题来了，get函数是哪里调用的??? 不要着急，我来告诉你，它就在data.writeStrongBinder中…
Parcel.cpp

static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)
{
    Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
    if (parcel != NULL){
    //实际是一ibinderForJavaObject 的返回作为参数
      const status_t err = parcel- >writeStrongBinder(ibinderForJavaObject(env, object));
        if (err != NO_ERROR) {
            signalExceptionForError(env, clazz, err);
        }
    }
}

可以看到这里实际以ibinderForJavaObject返回做参数
Binder.cpp ibinderForJavaObject()

sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)
{
    if (obj == NULL) return NULL;

    if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) {
        JavaBBinderHolder* jbh = (JavaBBinderHolder*)
            env->GetLongField(obj, gBinderOffsets.mObject);
        return jbh != NULL ? jbh->get(env, obj) : NULL;
    }

    if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {
        return (IBinder*)
            env->GetLongField(obj, gBinderProxyOffsets.mObject);
    }

   return NULL;
}

从上面代码可以看到，如果obj属于Binder那么把 gBinderOffsets.mObject对象取出来，该对象实际就是JavaBBinderHolder，然后调用该对象的get函数 ,其内部会创建一个JavaBBinder对象，并赋值给JavaBBinderHolder的mBinder。 如果属于BinderProxy,那么则取出gBinderProxyOffsets.mObject对象，实际是BpBinder，然后返回。

所以由上面代码可知，ServiceManager.addService实际加入的不是ActivityManagerService，而是一个JavaBBinder对象。我们需要知道

• Java的Binder通过mObject指向Native层的JavaBBinderHolder对象
• JavaBBinderHolder 的mBinder 指向一个Native的 JavaBBinder
• Native 的JavaBBinder又通过mObject变量指向一个Java层的Binder对象。

data.writeStrongBinder解析完了，那么接下来看 transact

static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,jint code, jobject dataObj, jobject replyObj, jint flags)
{
    ....
        Parcel* data = parcelForJavaObject(env, dataObj);
    if (data == NULL) {
        return JNI_FALSE;
    }
    Parcel* reply = parcelForJavaObject(env, replyObj);
    if (reply == NULL && replyObj != NULL) {
        return JNI_FALSE;
    }
    ....
    IBinder* target = (IBinder*)
        env->GetLongField(obj, gBinderProxyOffsets.mObject);
    ....

    status_t err = target->transact(code, *data, reply, flags);
      signalExceptionForError(env, obj, err, true,data->dataSize());
    return JNI_FALSE;
    }

上面代码主要做了如下几件事

• Parcel data = parcelForJavaObject 从Java的 Parcel对象中得到 Native的Parcel对象
• Parcel* reply = parcelForJavaObject 用于得到一个用于回复的Parcel对象
• 从BpProxy中获取之前创建好的BpBinder
• 调用BpBinder的transact,最后会发送给ServiceManager

关于ActivityManagerService如何将自己注册到ServiceManager的已经分析完，下面我们接着分析ActivityManagerService是如何响应请求的。

从Native的 JavaBBinder 的onTransact开始…

    virtual status_t onTransact(
        uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0)
    {
        JNIEnv* env = javavm_to_jnienv(mVM);

        IPCThreadState* thread_state = IPCThreadState::self();
        const int32_t strict_policy_before = thread_state->getStrictModePolicy();
        //这里调用Java Binder层的 execTransact函数
        //mObject就是 AMS
        jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,code, reinterpret_cast<jlong>(&data), reinterpret_cast<jlong>(reply), flags);
 ....
 return res != JNI_FALSE ? NO_ERROR : UNKNOWN_TRANSACTION;;
}

从上面代码可以看到，调用了 ActivityManagerSerivce 的exectransact方法(gBinderOffsets.mExecTransact),为什么会调用？ 请迅速的向上翻，并找到Java Binder 和Native关联时所调用的GetMethodIDOrDie方法。
exectransact在Binder类中定义，我们来看代码。

 private boolean execTransact(int code, long dataObj, long replyObj,int flags) {
        Parcel data = Parcel.obtain(dataObj);
        Parcel reply = Parcel.obtain(replyObj);

        try {
            res = onTransact(code, data, reply, flags);
        }  ....
           ....
           ....
        return res;
    }

这里Binder的子类 可以覆盖onTransact方法，来完成业务功能需求。按ActivityManagerService来说的话，它重新实现来onTransact,它会先进行一些处理，然后调用super.onTransact 也就是ActivityManagerNative的onTransact,在其内 会进行各种case 来处理相应的情况。

现在 有关AMS如何注册到ServiceManager内 和AMS如何响应已经解析完了，根据分析我们大体得知

• 对于客户端的BinderProxy来说，Java层的BinderProxy 对应一个 Native层的BpBinder。从Java层发送的请求 都是从BinderProxy到 BpBinder 然后由BpBinder发送请求到Binder驱动
• 对于服务端的Service来说，Java层的Binder对应一个Native层的JavaBBinder。JavaBBinder起到中转作用，把客户端的请求从Native层传到Java层。

相信到这里，大家对于Binder已经不陌生了。