java和c++直接如何进行ipc通信的？

ServiceManager.java里面有个getIServiceManager。

        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());

BinderInternal.getContextObject()实际调用到了android_os_BinderInternal_getContextObject，android_utils_binder.cpp这个文件里面。

sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
       return javaObjectForIBinder(env, b);

这里的b是一个BpBinder,c++层的。

这个javaObjectForIBinder这个很重要。从名字上看是从ibinder创建一个javaobject。

重要的代码如下：

gBinderProxyOffsets.mClass是int_register_android_os_BinderProxy里面定义的，对应的java层的类是android/os/BinderProxy，

BinderProxy这个类定义在Binder.java文件里面

    object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);

这个object 对象是一个BinderProxy的对象。
    if (object != NULL) {
        LOGDEATH("objectForBinder %p: created new proxy %p !\n", val.get(), object);
        // The proxy holds a reference to the native object.
        env->SetIntField(object, gBinderProxyOffsets.mObject, (int)val.get());

给BinderProxy的成员变量object赋值val.get(),是个int值，这个地方val.get()没查到这个函数。val是刚才创建的BpBinder对象。

翻译是，代理端有个本地对象的引用。

        
        val->incStrong(object);

        // The native object needs to hold a weak reference back to the
        // proxy, so we can retrieve the same proxy if it is still active.

本地对象需要对代理端有个弱引用
        jobject refObject = env->NewGlobalRef(
                env->GetObjectField(object, gBinderProxyOffsets.mSelf));
        val->attachObject(&gBinderProxyOffsets, refObject,
                jnienv_to_javavm(env), proxy_cleanup);


        // Also remember the death recipients registered on this proxy
        sp<DeathRecipientList> drl = new DeathRecipientList;
        drl->incStrong((void*)javaObjectForIBinder);
        env->SetIntField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jint>(drl.get()));


        // Note that a new object reference has been created.
        android_atomic_inc(&gNumProxyRefs);
        incRefsCreated(env);
    }


    return object;这里返回的对象就是BinderProxy

android_os_BinderInternal_getContextObject返回的就是BinderProxy端的一个对象。

ServiceManagerNative.asInterface又对这个BinderProxy进行了转换，创建了ServiceManagerProxy这个对象，这个过程和底层c++层类似。

getIServiceManager返回的就是ServiceManagerProxy对象。

那这个ServiceManagerProxy是如何和底层通信的。

以getService获取服务为例。

从ServiceManager.java里面的getService开始。

return getIServiceManager().getService(name);，这里getService调用的就是ServiceManagerProxy这个里面的。

mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);使用了mRemote对象，这个对象就是BinderProxy对象。这个transact对应的就是BinderProxy里面的transact，对应到jni层android_os_BinderProxy_transact，

parcelForJavaObject，这个函数从字义上看就是将java层面的parcel对象转换成本地的parcel对象。

里面有个gParcelOffsets变量，初始化在int_register_android_os_Parcel里面

类对应的就是android/os/Parcel，获取这个对象的mObject对应的parcel，这个地方mObject应该赋值过。

android_os_Parcel_init地方，创建了一个本地parcel对象，并把这个对象给第二个参数的mObject对象进行了赋值。

这个init是在Parcel构造函数里面调用的。找到头了。

parcelForJavaObject这个函数获得的对象实际上就是parcel.cpp的一个对象了。

下面又涉及到gBinderProxyOffsets，这个地方是不是和parcel类似呢？我们找找给对象的gBinderProxyOffsets.mObject这个变量赋值的地方

int_register_android_os_BinderProxy这里面调用了gBinderProxyOffsets.mClass这个对应的类是android/os/BinderProxy

这里构造了一个BinderProxy的对象。javaObjectForIBinder我们一开始分析了这个函数。这个里面创建了一个BinderProxy对象，

javaObjectForIBinder这个函数第二个参数传人的是c++层BpBinder对象。

在javaObjectForIBinder里面，将BpBinder对象赋值给了BinderProxy对象的mObject对象。

    IBinder* target = (IBinder*)
        env->GetIntField(obj, gBinderProxyOffsets.mObject);

这里获得的这个Binder就是BpBinder对象了。

所以这个transact也就是BpBinder的transact了。

但是怎么和ServiceManager联系上呢？这个不用操心了。在底层通过读取parcel里面的描述符得到。不对，底层可以知道，但是这个地方BpBinder如何BpServiceManager联系起来呢？我们漏掉了什么吗？

查看底层，有个BpBinder.cpp文件实现了BpBinder。

忘了在哪里看到过，BpBinder对应的就是BpSercieManager,这个需要确认一下。

IPCThreadState executeCommand里面

sp<BBinder> b((BBinder*)tr.cookie);

这里的b代表的就是一个BB端的对象，这个对象就是根据handle确认的，这里就是BnServiceManager。见书《深入理解android I》p160