开篇

本篇以aosp分支android-11.0.0_r25作为基础解析

我们在之前的文章中，从驱动层面分析了Binder是怎样工作的，但Binder驱动只涉及传输部分，待传输对象是怎么产生的呢，这就是framework层的工作了。我们要彻底了解Binder的工作原理，不仅要去看驱动层，还得去看framework层以及应用层（AIDL）

ServiceManager

getIServiceManager

我们还是以第一次见到Binder的地方ServiceManager开始分析，我们选取getService方法来分析（这个方法既有入参也有返回），抛除掉它缓存和log的部分，最核心的代码就一句getIServiceManager().getService(name)

private static IServiceManager getIServiceManager() {if (sServiceManager != null) {return sServiceManager;}// Find the service managersServiceManager = ServiceManagerNative.asInterface(Binder.allowBlocking(BinderInternal.getContextObject()));return sServiceManager;
}

BinderInternal.getContextObject

我们从BinderInternal.getContextObject()开始看起，这个函数是一个native函数，他被实现在frameworks/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);
}

ProcessState

我们在这里可以发现一个比较关键的类ProcessState，它是一个负责打开binder驱动并进行mmap映射的单例对象，这从它的self函数就可以看出来，每个进程只存在一个ProcessState实例

位置：frameworks/native/libs/binder/ProcessState.cpp

sp<ProcessState> ProcessState::self()
{Mutex::Autolock _l(gProcessMutex);if (gProcess != nullptr) {return gProcess;}gProcess = new ProcessState(kDefaultDriver);return gProcess;
}

我们来看看它的构造函数

ProcessState::ProcessState(const char *driver): mDriverName(String8(driver)), mDriverFD(open_driver(driver))    //打开binder驱动, mVMStart(MAP_FAILED), mThreadCountLock(PTHREAD_MUTEX_INITIALIZER), mThreadCountDecrement(PTHREAD_COND_INITIALIZER), mExecutingThreadsCount(0), mMaxThreads(DEFAULT_MAX_BINDER_THREADS), mStarvationStartTimeMs(0), mBinderContextCheckFunc(nullptr), mBinderContextUserData(nullptr), mThreadPoolStarted(false), mThreadPoolSeq(1), mCallRestriction(CallRestriction::NONE)
{if (mDriverFD >= 0) {// mmap the binder, providing a chunk of virtual address space to receive transactions.mVMStart = mmap(nullptr, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);...}
}

这里的:后是c++构造函数初始化赋值的一种语法，可以看到其中调用了open_driver函数打开binder驱动

static int open_driver(const char *driver)
{//打开binder驱动int fd = open(driver, O_RDWR | O_CLOEXEC);int vers = 0;//验证binder版本status_t result = ioctl(fd, BINDER_VERSION, &vers);if (result != 0 || vers != BINDER_CURRENT_PROTOCOL_VERSION) {...}//设置binder最大线程数size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);return fd;
}

这里做了三件事，打开binder驱动、验证binder版本、设置binder最大线程数，接着构造函数调用mmap建立binder映射，这里面的实现我们已经在Android源码分析 - Binder驱动（上）、（中）、（下）中分析过了，感兴趣的同学可以回过头去看一看

ProcessState::self函数执行完后，当前进程的binder初始化工作已经执行完毕，接下来我们回过头来看它的getContextObject函数

sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /*caller*/)
{sp<IBinder> context = getStrongProxyForHandle(0);if (context == nullptr) {ALOGW("Not able to get context object on %s.", mDriverName.c_str());}// The root object is special since we get it directly from the driver, it is never// written by Parcell::writeStrongBinder.internal::Stability::tryMarkCompilationUnit(context.get());return context;
}

我们在binder驱动篇就提到了，handle句柄0代表的就是ServiceManager，所以这里调用getStrongProxyForHandle函数的参数为0

sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{sp<IBinder> result;AutoMutex _l(mLock);//查找或建立handle对应的handle_entryhandle_entry* e = lookupHandleLocked(handle);if (e != nullptr) {IBinder* b = e->binder;if (b == nullptr || !e->refs->attemptIncWeak(this)) {if (handle == 0) {//当handle为ServiceManager的特殊情况//需要确保在创建Binder引用之前，context manager已经被binder注册Parcel data;status_t status = IPCThreadState::self()->transact(0, IBinder::PING_TRANSACTION, data, nullptr, 0);if (status == DEAD_OBJECT)return nullptr;}//创建BpBinder并保存下来以便后面再次查找b = BpBinder::create(handle);e->binder = b;if (b) e->refs = b->getWeakRefs();result = b;} else {result.force_set(b);e->refs->decWeak(this);}}return result;
}
ProcessState::handle_entry* ProcessState::lookupHandleLocked(int32_t handle)
{const size_t N=mHandleToObject.size();//新建一个handle_entry并插入到vector中if (N <= (size_t)handle) {handle_entry e;e.binder = nullptr;e.refs = nullptr;status_t err = mHandleToObject.insertAt(e, N, handle+1-N);if (err < NO_ERROR) return nullptr;}return &mHandleToObject.editItemAt(handle);
}

整条链路下来还是比较清晰的，最终获得了一个BpBinder对象，这是native中的类型，需要将它转换成java中的类型，这里调用了javaObjectForIBinder函数，位于frameworks/base/core/jni/android_util_Binder.cpp中

javaObjectForIBinder

// If the argument is a JavaBBinder, return the Java object that was used to create it.
// Otherwise return a BinderProxy for the IBinder. If a previous call was passed the
// same IBinder, and the original BinderProxy is still alive, return the same BinderProxy.
jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{if (val == NULL) return NULL;//JavaBBinder返回true，其他类均返回flaseif (val->checkSubclass(&gBinderOffsets)) {// It's a JavaBBinder created by ibinderForJavaObject. Already has Java object.jobject object = static_cast<JavaBBinder*>(val.get())->object();return object;}BinderProxyNativeData* nativeData = new BinderProxyNativeData();nativeData->mOrgue = new DeathRecipientList;nativeData->mObject = val;jobject object = env->CallStaticObjectMethod(gBinderProxyOffsets.mClass,gBinderProxyOffsets.mGetInstance, (jlong) nativeData, (jlong) val.get());if (env->ExceptionCheck()) {// In the exception case, getInstance still took ownership of nativeData.return NULL;}BinderProxyNativeData* actualNativeData = getBPNativeData(env, object);//如果object是刚刚新建出来的BinderProxyif (actualNativeData == nativeData) {//处理proxy计数...} else {delete nativeData;}return object;
}

我们先看一看这个gBinderProxyOffsets是什么

static struct binderproxy_offsets_t
{// Class state.jclass mClass;jmethodID mGetInstance;jmethodID mSendDeathNotice;// Object state.//指向BinderProxyNativeData的指针jfieldID mNativeData;  // Field holds native pointer to BinderProxyNativeData.
} gBinderProxyOffsets;const char* const kBinderProxyPathName = "android/os/BinderProxy";static int int_register_android_os_BinderProxy(JNIEnv* env)
{...jclass clazz = FindClassOrDie(env, kBinderProxyPathName);gBinderProxyOffsets.mClass = MakeGlobalRefOrDie(env, clazz);gBinderProxyOffsets.mGetInstance = GetStaticMethodIDOrDie(env, clazz, "getInstance","(JJ)Landroid/os/BinderProxy;");gBinderProxyOffsets.mSendDeathNotice =GetStaticMethodIDOrDie(env, clazz, "sendDeathNotice","(Landroid/os/IBinder$DeathRecipient;Landroid/os/IBinder;)V");gBinderProxyOffsets.mNativeData = GetFieldIDOrDie(env, clazz, "mNativeData", "J");...
}

可以看到，gBinderProxyOffsets实际上是一个用来记录一些java中对应类、方法以及字段的结构体，用于从native层调用java层代码

接下来我们看javaObjectForIBinder函数的具体内容

jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{if (val == NULL) return NULL;//JavaBBinder返回true，其他类均返回flaseif (val->checkSubclass(&gBinderOffsets)) {// It's a JavaBBinder created by ibinderForJavaObject. Already has Java object.jobject object = static_cast<JavaBBinder*>(val.get())->object();return object;}...
}

首先有一个IBinder类型检查的判断，我看了一圈发现目前只有当IBinder的实际类型为JavaBBinder的时候会返回true，其他子类均返回false。JavaBBinder类继承自BBinder，里面保存了对java层Binder对象的引用，所以在这种情况下，直接返回里面的object就好了。

从这里可以看出，native层的javaBBinder与java层的Binder是对应关系

我们这里传进来的是BpBinder，会接着往下走

jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{...BinderProxyNativeData* nativeData = new BinderProxyNativeData();nativeData->mOrgue = new DeathRecipientList;nativeData->mObject = val;jobject object = env->CallStaticObjectMethod(gBinderProxyOffsets.mClass,gBinderProxyOffsets.mGetInstance, (jlong) nativeData, (jlong) val.get());...
}

接着实例化一个BinderProxyNativeData，将Binder死亡回调DeathRecipientList和Binder对象（这里为BpBinder）赋值给它，然后调用java层方法。gBinderProxyOffsets之前说过了，类为android.os.BinderProxy，方法为getInstance，所以这里调用的即为android.os.BinderProxy.getInstance(nativeData, iBinder)，BinderProxy的路径为frameworks/base/core/java/android/os/BinderProxy.java

private static BinderProxy getInstance(long nativeData, long iBinder) {BinderProxy result;synchronized (sProxyMap) {try {result = sProxyMap.get(iBinder);if (result != null) {return result;}result = new BinderProxy(nativeData);} catch (Throwable e) {// We're throwing an exception (probably OOME); don't drop nativeData.NativeAllocationRegistry.applyFreeFunction(NoImagePreloadHolder.sNativeFinalizer,nativeData);throw e;}NoImagePreloadHolder.sRegistry.registerNativeAllocation(result, nativeData);// The registry now owns nativeData, even if registration threw an exception.sProxyMap.set(iBinder, result);}return result;
}

这里的逻辑比较简单，以iBinder为 key 尝试从sProxyMap取出BinderProxy，如果取到值了就直接将它返回出去，如果没取到，用之前传进来的BinderProxyNativeData指针为参数实例化一个BinderProxy，并将其设置到sProxyMap中

从这里可以看出每一个服务的BinderProxy都是以单例形式存在的，并且native层的BinderProxyNativeData与java层的BinderProxy是对应关系

BinderProxyNativeData* getBPNativeData(JNIEnv* env, jobject obj) {return (BinderProxyNativeData *) env->GetLongField(obj, gBinderProxyOffsets.mNativeData);
}jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{...BinderProxyNativeData* actualNativeData = getBPNativeData(env, object);//如果object是刚刚新建出来的BinderProxyif (actualNativeData == nativeData) {//处理proxy计数...} else {delete nativeData;}return object;
}

接下来判断我们通过BinderProxy.getInstance方法获得的BinderProxy是不是刚刚创建出来的，如果是新建的则需要处理一下proxy计数，这里是通过对比BinderProxy中的mNativeData和我们新建出来的nativeData地址判断的

ServiceManagerNative.asInterface

我们将目光放回getIServiceManager方法，现在我们知道BinderInternal.getContextObject()方法返回了ServiceManager对应的BinderProxy，接着会调用Binder.allowBlocking方法，这个方法只是改变了BinderProxy中的一个参数，使其允许阻塞调用，这样的话getIServiceManager就可以被简化成如下代码

private static IServiceManager getIServiceManager() {if (sServiceManager != null) {return sServiceManager;}// Find the service managersServiceManager = ServiceManagerNative.asInterface(/* BinderProxy */);return sServiceManager;
}

我们看到asInterface方法实际上是直接实例化了一个ServiceManagerProxy对象

public static IServiceManager asInterface(IBinder obj) {if (obj == null) {return null;}// ServiceManager is never localreturn new ServiceManagerProxy(obj);
}

ServiceManagerProxy

从名字就能听出来，ServiceManagerProxy其实是一个代理类，它其实是IServiceManager.Stub.Proxy的代理，实际上是没有什么必要的，可以发现作者也在注释中标注了This class should be deleted and replaced with IServiceManager.Stub whenever mRemote is no longer used，我们看一下它的构造方法

public ServiceManagerProxy(IBinder remote) {mRemote = remote;mServiceManager = IServiceManager.Stub.asInterface(remote);
}

ServiceManagerProxy实现了IServiceManager接口，但这个方法的实现都是直接调用mServiceManager，以addService举例

public void addService(String name, IBinder service, boolean allowIsolated, int dumpPriority)throws RemoteException {mServiceManager.addService(name, service, allowIsolated, dumpPriority);
}

这与直接使用IServiceManager.Stub.asInterface(remote)得到IServiceManager并没有什么区别

IServiceManager

我们将重点转到IServiceManager上，我们在源码中搜索不到IServiceManager.java文件，因为实际上这个文件是通过aidl生成的

关于aidl我们到后面再详细分析，现在我们只需要知道它其实是辅助我们进行binder通信的一种工具，aidl文件会在编译过程中生成出与之对应的java文件

IServiceManager`的`aidl`文件路径为`frameworks/native/libs/binder/aidl/android/os/IServiceManager.aidl

我们来看一下它生成出的IServiceManager.Stub.asInterface方法

public static android.os.IServiceManager asInterface(android.os.IBinder obj)
{if ((obj == null)) {return null;}android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);if (((iin != null) && (iin instanceof android.os.IServiceManager))) {return ((android.os.IServiceManager) iin);}return new android.os.IServiceManager.Stub.Proxy(obj);
}

这里我们传入的IBinder是BinderProxy，它的queryLocalInterface永远返回null，所以这里返回的是IServiceManager.Stub.Proxy对象，我们接着看之前调用的getService方法

@Override public android.os.IBinder getService(java.lang.String name) throws android.os.RemoteException
{android.os.Parcel _data = android.os.Parcel.obtain();android.os.Parcel _reply = android.os.Parcel.obtain();android.os.IBinder _result;try {_data.writeInterfaceToken(DESCRIPTOR);_data.writeString(name);boolean _status = mRemote.transact(Stub.TRANSACTION_getService, _data, _reply, 0);_reply.readException();_result = _reply.readStrongBinder();}finally {_reply.recycle();_data.recycle();}return _result;
}

Parcel

Parcel是一个存放读取数据的容器，它的基本功能和使用相信进阶Android开发应该都懂，我们在这里只介绍一些关键性函数的含义，其他就不多赘述了，有机会的话以后单独开一章分析它

函数	作用
obtain	获取一个新的Parcel对象
ipcData、data	数据区首地址
ipcDataSize、dataSize	数据大小
ipcObjects	偏移数组首地址
ipcObjectsCount	IPC对象数量
dataPosition	数据指针当前的位置
dataCapacity	数据区的总容量（始终 >= dataSize）

这里获取了两个Parcel，一个_data用来传递参数数据，一个_reply用来接收回应。接着，_data首先调用writeInterfaceToken方法，这里的token是客户端与服务端的一个协定，服务端会校验我们写入的这个token，然后按照顺序将参数依次写入到_data中（序列化），然后通过binder调用远程服务真正的方法，然后检查异常。

对于无返回值的方法来说，到这一步已经结束了，但我们这个方法是有返回值的，所以我们需要一个_result，从_reply中读取出数据（反序列化），赋给_result，然后返回出去

BinderProxy.transact

我们重点看transact这一部分，通过我们之前的分析，我们知道mRemote是一个BinderProxy类型的对象，我们来看他的transact方法

public boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {//检查Parcel大小Binder.checkParcel(this, code, data, "Unreasonably large binder buffer");...//trace...//Binder事务处理回调...//AppOpsManager信息记录...try {final boolean result = transactNative(code, data, reply, flags);if (reply != null && !warnOnBlocking) {reply.addFlags(Parcel.FLAG_IS_REPLY_FROM_BLOCKING_ALLOWED_OBJECT);}return result;} finally {...}
}

我这里简化了一下代码，可以看到，首先就是对Parcel大小的检查

static void checkParcel(IBinder obj, int code, Parcel parcel, String msg) {if (CHECK_PARCEL_SIZE && parcel.dataSize() >= 800*1024) {// Trying to send > 800k, this is way too much.StringBuilder sb = new StringBuilder();sb.append(msg);sb.append(": on ");sb.append(obj);sb.append(" calling ");sb.append(code);sb.append(" size ");sb.append(parcel.dataSize());sb.append(" (data: ");parcel.setDataPosition(0);sb.append(parcel.readInt());sb.append(", ");sb.append(parcel.readInt());sb.append(", ");sb.append(parcel.readInt());sb.append(")");Slog.wtfStack(TAG, sb.toString());}
}

Android默认设置了Parcel数据传输不能超过800k，当然，各个厂商是可以随意改动这里的代码的，如果超过了的话，便会调用Slog.wtfStack打印日志，需要注意的是，在当前进程不是系统进程并且系统也不是工程版本的情况下，这个方法是会结束进程的，所以在应用开发的时候，我们需要注意跨进程数据传输的大小，避免因此引发crash

省去中间的一些log、回调，接下来便是调用transactNative方法，这是一个native方法，实现在frameworks/base/core/jni/android_util_Binder.cpp中

static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,jint code, jobject dataObj, jobject replyObj, jint flags) // throws RemoteException
{if (dataObj == NULL) {jniThrowNullPointerException(env, NULL);return JNI_FALSE;}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 = getBPNativeData(env, obj)->mObject.get();if (target == NULL) {jniThrowException(env, "java/lang/IllegalStateException", "Binder has been finalized!");return JNI_FALSE;}//log...status_t err = target->transact(code, *data, reply, flags);//log...if (err == NO_ERROR) {return JNI_TRUE;} else if (err == UNKNOWN_TRANSACTION) {return JNI_FALSE;}signalExceptionForError(env, obj, err, true /*canThrowRemoteException*/, data->dataSize());return JNI_FALSE;
}

这里首先是获得native层对应的Parcel并执行判断，Parcel实际上功能是在native中实现的，java中的Parcel类使用mNativePtr成员变量保存了其对应native中的Parcel的指针

然后调用getBPNativeData函数获得BinderProxy在native中对应的BinderProxyNativeData，再通过里面的mObject域成员变量得到其对应的BpBinder，这个函数在之前分析javaObjectForIBinder的时候已经出现过了

BpBinder.transact

之后便是调用BpBinder的transact函数了

status_t BpBinder::transact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{// Once a binder has died, it will never come back to life.//判断binder服务是否存活if (mAlive) {...status_t status = IPCThreadState::self()->transact(mHandle, code, data, reply, flags);if (status == DEAD_OBJECT) mAlive = 0;return status;}return DEAD_OBJECT;
}

这里有一个Alive判断，可以避免对一个已经死亡的binder服务再发起事务，浪费资源，除此之外便是调用IPCThreadState的transact函数了

IPCThreadState

路径：frameworks/native/libs/binder/IPCThreadState.cpp

还记得我们之前提到的ProcessState吗？IPCThreadState和它很像，ProcessState负责打开binder驱动并进行mmap映射，而IPCThreadState则是负责与binder驱动进行具体的交互

IPCThreadState也有一个self函数，与ProcessState的self不同的是，ProcessState是进程单例，而IPCThreadState是线程单例，我们来看看它是怎么实现的

IPCThreadState* IPCThreadState::self()
{//不是初次调用的情况if (gHaveTLS.load(std::memory_order_acquire)) {restart://初次调用，生成线程私有变量key后const pthread_key_t k = gTLS;//先从线程本地储存空间中尝试获取值IPCThreadState* st = (IPCThreadState*)pthread_getspecific(k);if (st) return st;//没有的话就实例化一个return new IPCThreadState;}//IPCThreadState shutdown后不能再获取if (gShutdown.load(std::memory_order_relaxed)) {ALOGW("Calling IPCThreadState::self() during shutdown is dangerous, expect a crash.\n");return nullptr;}//首次获取时gHaveTLS为false，会先走这里pthread_mutex_lock(&gTLSMutex);if (!gHaveTLS.load(std::memory_order_relaxed)) {//创建一个key，作为存放线程本地变量的keyint key_create_value = pthread_key_create(&gTLS, threadDestructor);if (key_create_value != 0) {pthread_mutex_unlock(&gTLSMutex);ALOGW("IPCThreadState::self() unable to create TLS key, expect a crash: %s\n",strerror(key_create_value));return nullptr;}//创建完毕，gHaveTLS置为truegHaveTLS.store(true, std::memory_order_release);}pthread_mutex_unlock(&gTLSMutex);//回到gHaveTLS为true的casegoto restart;
}

gHaveTLS是一个原子类型的bool值，它在存取过程中需要指定内存序std::memory_order_xxx，在这里我们直接忽略掉，把它当成一个纯粹的bool值就好了

在这里，TLS的全称为Thread Local Storage，表示线程本地储存空间，和java中的ThreadLocal其实是一个作用

当一个线程初次获取IPCThreadState的时候，会先走到gHaveTLS为false的case，此时程序会创建一个key，作为存放线程本地变量的key，创建成功后将gHaveTLS置为true，然后goto到gHaveTLS为true的case，此时线程本地储存空间中暂时还是没有数据的，所以会new一个IPCThreadState出来，在IPCThreadState的构造函数中，会将自己保存到线程本地储存空间中，这样，当线程第二次再获取IPCThreadState的时候，便会直接走到pthread_getspecific这里获取并返回

IPCThreadState::IPCThreadState(): mProcess(ProcessState::self()),mServingStackPointer(nullptr),mServingStackPointerGuard(nullptr),mWorkSource(kUnsetWorkSource),mPropagateWorkSource(false),mIsLooper(false),mIsFlushing(false),mStrictModePolicy(0),mLastTransactionBinderFlags(0),mCallRestriction(mProcess->mCallRestriction) {pthread_setspecific(gTLS, this);clearCaller();mIn.setDataCapacity(256);mOut.setDataCapacity(256);
}

我们通过构造函数可以发现，它调用了pthread_setspecific函数将自身保存在了线程本地储存空间中

IPCThreadState`中，成员变量`mIn`用于接收来自`binder`设备的数据，`mOut`用于储存发往`binder`设备的数据，他们的默认容量都为`256字节

transact

我们接着看它的transact函数

status_t IPCThreadState::transact(int32_t handle,uint32_t code, const Parcel& data,Parcel* reply, uint32_t flags)
{LOG_ALWAYS_FATAL_IF(data.isForRpc(), "Parcel constructed for RPC, but being used with binder.");status_t err;flags |= TF_ACCEPT_FDS;//log...err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, nullptr);if (err != NO_ERROR) {if (reply) reply->setError(err);return (mLastError = err);}if ((flags & TF_ONE_WAY) == 0) {    //binder事务不为TF_ONE_WAY//当线程限制binder事务不为TF_ONE_WAY时if (UNLIKELY(mCallRestriction != ProcessState::CallRestriction::NONE)) {if (mCallRestriction == ProcessState::CallRestriction::ERROR_IF_NOT_ONEWAY) {//这个限制只是log记录ALOGE("Process making non-oneway call (code: %u) but is restricted.", code);CallStack::logStack("non-oneway call", CallStack::getCurrent(10).get(),ANDROID_LOG_ERROR);} else /* FATAL_IF_NOT_ONEWAY */ {//这个限制会终止线程LOG_ALWAYS_FATAL("Process may not make non-oneway calls (code: %u).", code);}}if (reply) {err = waitForResponse(reply);} else {Parcel fakeReply;err = waitForResponse(&fakeReply);}//log...} else {err = waitForResponse(nullptr, nullptr);}return err;
}

这个函数的重点在于writeTransactionData和waitForResponse，我们依次分析

writeTransactionData

status_t IPCThreadState::writeTransactionData(int32_t cmd, uint32_t binderFlags,int32_t handle, uint32_t code, const Parcel& data, status_t* statusBuffer)
{binder_transaction_data tr;tr.target.ptr = 0; /* Don't pass uninitialized stack data to a remote process *///目标binder句柄值，ServiceManager为0tr.target.handle = handle;tr.code = code;tr.flags = binderFlags;tr.cookie = 0;tr.sender_pid = 0;tr.sender_euid = 0;const status_t err = data.errorCheck();if (err == NO_ERROR) {//数据大小tr.data_size = data.ipcDataSize();//数据区起始地址tr.data.ptr.buffer = data.ipcData();//传递的偏移数组大小tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);//偏移数组的起始地址tr.data.ptr.offsets = data.ipcObjects();} else if (statusBuffer) {tr.flags |= TF_STATUS_CODE;*statusBuffer = err;tr.data_size = sizeof(status_t);tr.data.ptr.buffer = reinterpret_cast<uintptr_t>(statusBuffer);tr.offsets_size = 0;tr.data.ptr.offsets = 0;} else {return (mLastError = err);}//这里为BC_TRANSACTIONmOut.writeInt32(cmd);mOut.write(&tr, sizeof(tr));return NO_ERROR;
}

在分析这个函数之前，我们需要先回忆一下在前面binder驱动章节我们所学习的binder结构和通信过程：Android源码分析 - Binder驱动（中）

binder_tansaction首先会读取一个请求码cmd，当binder请求码为BC_TRANSACTION/BC_REPLY的时候，binder驱动所接收的参数为binder_transaction_data结构体，所以在这个函数中，我们将binder请求码（这里为BC_TRANSACTION）和binder_transaction_data结构体依次写入到mOut中，为之后binder_tansaction做准备

waitForResponse

数据准备好后，接着便来到了waitForResponse函数

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{uint32_t cmd;int32_t err;while (1) {if ((err=talkWithDriver()) < NO_ERROR) break;err = mIn.errorCheck();if (err < NO_ERROR) break;if (mIn.dataAvail() == 0) continue;cmd = (uint32_t)mIn.readInt32();IF_LOG_COMMANDS() {alog << "Processing waitForResponse Command: "<< getReturnString(cmd) << endl;}switch (cmd) {case BR_ONEWAY_SPAM_SUSPECT:...case BR_TRANSACTION_COMPLETE://当TF_ONE_WAY模式下收到BR_TRANSACTION_COMPLETE直接返回，本次binder通信结束if (!reply && !acquireResult) goto finish;break;case BR_DEAD_REPLY:...case BR_FAILED_REPLY:...case BR_FROZEN_REPLY:...case BR_ACQUIRE_RESULT:...case BR_REPLY:{binder_transaction_data tr;err = mIn.read(&tr, sizeof(tr));ALOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY");//失败直接返回if (err != NO_ERROR) goto finish;if (reply) {    //客户端需要接收replayif ((tr.flags & TF_STATUS_CODE) == 0) {    //正常reply内容reply->ipcSetDataReference(reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),tr.data_size,reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),tr.offsets_size/sizeof(binder_size_t),freeBuffer /*释放缓冲区*/);} else {    //内容只是一个32位的状态码//接收状态码err = *reinterpret_cast<const status_t*>(tr.data.ptr.buffer);//释放缓冲区freeBuffer(nullptr,reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),tr.data_size,reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),tr.offsets_size/sizeof(binder_size_t));}} else {    //客户端不需要接收replay//释放缓冲区freeBuffer(nullptr,reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),tr.data_size,reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),tr.offsets_size/sizeof(binder_size_t));continue;}}goto finish;default://这里是binder服务端部分的处理，现在不需要关注err = executeCommand(cmd);if (err != NO_ERROR) goto finish;break;}}finish:if (err != NO_ERROR) {if (acquireResult) *acquireResult = err;if (reply) reply->setError(err);mLastError = err;logExtendedError();}return err;
}

这里有一个循环，正如函数名所描述，会一直等待到一整条binder事务链结束返回后才会退出这个循环，在这个循环的开头，便是talkWithDriver方法

talkWithDriver

status_t IPCThreadState::talkWithDriver(bool doReceive)
{//检查打开的binder设备的fdif (mProcess->mDriverFD < 0) {return -EBADF;}binder_write_read bwr;// Is the read buffer empty?//dataPosition >= dataSize说明上一次读取到的数据已经消费完const bool needRead = mIn.dataPosition() >= mIn.dataSize();// We don't want to write anything if we are still reading// from data left in the input buffer and the caller// has requested to read the next data.//需要写的数据大小，这里的doReceive默认为true，如果上一次的数据还没读完，则不会写入任何内容const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0;bwr.write_size = outAvail;bwr.write_buffer = (uintptr_t)mOut.data();// This is what we'll read.if (doReceive && needRead) {//将read_size设置为读缓存可用容量bwr.read_size = mIn.dataCapacity();//设置读缓存起始地址bwr.read_buffer = (uintptr_t)mIn.data();} else {bwr.read_size = 0;bwr.read_buffer = 0;}// Return immediately if there is nothing to do.//没有要读写的数据就直接返回if ((bwr.write_size == 0) && (bwr.read_size == 0)) return NO_ERROR;bwr.write_consumed = 0;bwr.read_consumed = 0;status_t err;do {//调用binder驱动的ioctlif (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)err = NO_ERROR;elseerr = -errno;if (mProcess->mDriverFD < 0) {err = -EBADF;}} while (err == -EINTR);if (err >= NO_ERROR) {//写数据被消费了if (bwr.write_consumed > 0) {//写数据没有被消费完if (bwr.write_consumed < mOut.dataSize())LOG_ALWAYS_FATAL("Driver did not consume write buffer. ""err: %s consumed: %zu of %zu",statusToString(err).c_str(),(size_t)bwr.write_consumed,mOut.dataSize());else {//写数据消费完了，将数据大小设置为0，这样下次就不会再写数据了mOut.setDataSize(0);processPostWriteDerefs();}}//读到了数据if (bwr.read_consumed > 0) {//设置数据大小及数据指针偏移，这样后面就可以从中读取出来数据了mIn.setDataSize(bwr.read_consumed);mIn.setDataPosition(0);}return NO_ERROR;}return err;
}

这里的binder_write_read也是一个我们熟悉的结构，我们在之前的文章Android源码分析 - Binder驱动（中）中了解过，关于binder通信的代码，我们需要结合着binder驱动一起看才能理解

在binder驱动层中，binder_ioctl_write_read函数会从用户空间读取一个binder_write_read结构，这个结构体主要描述了数据传输的大小和位置以及消费情况（已读/写数据大小），这么看来，talkWithDriver函数的结构就很清晰了：

创建出binder_write_read结构，根据之前的读取情况，决定是否读写数据，设置写数据内容和大小，设置读数据的空间和容量
调用binder驱动的ioctl
重置写缓存，根据ioctl的结果设置读缓存

这之后，waitForResponse函数就可以从读缓存mIn中读到数据了，我们回到这个函数中，发现它首先从读缓存中读取了一个binder响应码，然后根据这个响应码再处理接下来的工作

处理Reply

在此之前，我们先回顾一下一次binder_tansaction的整个过程，根据事务类型，分为两种情况：

TF_ONE_WAY

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zKdizSIy-1656337918435)(https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/df0ca935bc2646c7a5edc1ae16f284dc~tplv-k3u1fbpfcp-zoom-in-crop-mark:3024:0:0:0.awebp?)]

非 TF_ONE_WAY

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pux8PfWF-1656337918437)(https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5768ee7438c0419099d8513db644c8fe~tplv-k3u1fbpfcp-zoom-in-crop-mark:3024:0:0:0.awebp?)]

我们先对照着看TF_ONE_WAY的情况

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{switch (cmd) {...case BR_TRANSACTION_COMPLETE://当TF_ONE_WAY模式下收到BR_TRANSACTION_COMPLETE直接返回，本次binder通信结束if (!reply && !acquireResult) goto finish;break;...}}
}

对于TF_ONE_WAY模式来说，客户端在收到BR_TRANSACTION_COMPLETE响应码后则返回，不会再等待BR_REPLY

而对于非TF_ONE_WAY模式来说，客户端不仅会收到BR_TRANSACTION_COMPLETE响应码，之后还会阻塞等待binder驱动给它发来BR_REPLY响应码，这之后一次binder_transaction才算完成

status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult)
{switch (cmd) {...case BR_REPLY:{binder_transaction_data tr;err = mIn.read(&tr, sizeof(tr));ALOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY");//失败直接返回if (err != NO_ERROR) goto finish;if (reply) {    //客户端需要接收replayif ((tr.flags & TF_STATUS_CODE) == 0) {    //正常reply内容reply->ipcSetDataReference(reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),tr.data_size,reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),tr.offsets_size/sizeof(binder_size_t),freeBuffer /*释放缓冲区*/);} else {    //内容只是一个32位的状态码//接收状态码err = *reinterpret_cast<const status_t*>(tr.data.ptr.buffer);//释放缓冲区freeBuffer(nullptr,reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),tr.data_size,reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),tr.offsets_size/sizeof(binder_size_t));}} else {    //客户端不需要接收replay//释放缓冲区freeBuffer(nullptr,reinterpret_cast<const uint8_t*>(tr.data.ptr.buffer),tr.data_size,reinterpret_cast<const binder_size_t*>(tr.data.ptr.offsets),tr.offsets_size/sizeof(binder_size_t));continue;}}goto finish;...}}
}

一般来说，非TF_ONE_WAY模式肯定是需要一个reply来接收的，即reply != null，此时我们来看看接收正常reply的过程（接收32位状态码没什么好说的，直接从读缓冲区中强制类型转换出一个32位的code就完事了）

这里我们就需要看一下Parcel的ipcSetDataReference函数了

void Parcel::ipcSetDataReference(const uint8_t* data, size_t dataSize, const binder_size_t* objects,size_t objectsCount, release_func relFunc) {// this code uses 'mOwner == nullptr' to understand whether it owns memoryLOG_ALWAYS_FATAL_IF(relFunc == nullptr, "must provide cleanup function");//先清理重置一下数据和状态freeData();auto* kernelFields = maybeKernelFields();LOG_ALWAYS_FATAL_IF(kernelFields == nullptr); // guaranteed by freeData.mData = const_cast<uint8_t*>(data);mDataSize = mDataCapacity = dataSize;kernelFields->mObjects = const_cast<binder_size_t*>(objects);kernelFields->mObjectsSize = kernelFields->mObjectsCapacity = objectsCount;mOwner = relFunc;//检查数据binder_size_t minOffset = 0;for (size_t i = 0; i < kernelFields->mObjectsSize; i++) {binder_size_t offset = kernelFields->mObjects[i];if (offset < minOffset) {ALOGE("%s: bad object offset %" PRIu64 " < %" PRIu64 "\n",__func__, (uint64_t)offset, (uint64_t)minOffset);kernelFields->mObjectsSize = 0;break;}const flat_binder_object* flat= reinterpret_cast<const flat_binder_object*>(mData + offset);uint32_t type = flat->hdr.type;//binder类型出现异常if (!(type == BINDER_TYPE_BINDER || type == BINDER_TYPE_HANDLE ||type == BINDER_TYPE_FD)) {...kernelFields->mObjectsSize = 0;break;}minOffset = offset + sizeof(flat_binder_object);}scanForFds();
}

其实这个函数也不复杂，我们知道binder_mmap做到了一次拷贝，将数据拷贝到了内核物理内存中，然后将其与用户空间虚拟内存做了映射，所以这个函数此时只需要将数据的地址，大小等等无脑赋值进去，客户端后续便可以用Parcel提供的函数方便的从中读取数据了

freeBuffer

最后我们再来看一下freeBuffer这个释放缓冲区的方法，

void IPCThreadState::freeBuffer(Parcel* parcel, const uint8_t* data,size_t /*dataSize*/,const binder_size_t* /*objects*/,size_t /*objectsSize*/)
{...if (parcel != nullptr) parcel->closeFileDescriptors();IPCThreadState* state = self();state->mOut.writeInt32(BC_FREE_BUFFER);state->mOut.writePointer((uintptr_t)data);state->flushIfNeeded();
}

可以看到，这里向binder驱动发送了一个BC_FREE_BUFFER请求，然后binder驱动会负责回收这块缓冲区内存

我们在Parcel::ipcSetDataReference函数中可以发现，它将freeBuffer函数指针赋值给了mOwner，等到什么时候不需要这个Parcel了，便会调用这个函数进行缓冲区内存回收

Android源码分析 - Framework层的Binder（客户端篇）相关推荐

Android 源码分析
查看源码版本号: build\core\version_defaults.mk //搜索该文件中的 PLATFORM_VERSION值 frameworks 目录 (核心框架--java及C++语言) ...
Android源码分析 - Zygote进程
开篇本篇以android-11.0.0_r25作为基础解析上一篇文章Android源码分析 - init进程,我们分析了Android第一个用户进程init进程的启动过程和之后的守护服务 init ...
Android源码分析（三）-----系统框架设计思想
一 : 术在内而道在外 Android系统的精髓在源码之外,而不在源码之内,代码只是一种实现人类思想的工具,仅此而已...... 近来发现很多关于Android文章都是以源码的方向入手分析Androi ...
Android源码分析--MediaServer源码分析（二）
在上一篇博客中Android源码分析–MediaServer源码分析(一),我们知道了ProcessState和defaultServiceManager,在分析源码的过程中,我们被Android的B ...
Android源码分析（十一）-----Android源码中如何引用aar文件
一:aar文件如何引用系统Settings中引用bidehelper-1.1.12.aar 文件为例源码地址:packages/apps/Settings/Android.mk LOCAL_PAT ...
Android源码分析工具及方法
转载自:http://bbs.pediy.com/showthread.php?t=183278 标题: [原创]Android源码分析工具及方法作者: MindMac 时间: 2014-01 ...
Android 源码分析工具
2019独角兽企业重金招聘Python工程师标准>>> 标题: [原创]Android源码分析工具及方法作者: MindMac 时间: 2014-01-02,09:32:35 ...
Android源码分析—属性动画的工作原理
转载请注明出处: http://blog.csdn.net/singwhatiwanna/article/details/17853275 前言本文为Android动画系列的最后一篇文章,通过对源码 ...
Android源码分析-全面理解Context
前言 Context在android中的作用不言而喻,当我们访问当前应用的资源,启动一个新的activity的时候都需要提供Context,而这个Context到底是什么呢,这个问题好像很好回答又好像 ...

Android源码分析 - Framework层的Binder（客户端篇）

开篇