引言

我们都知道Binder IPC可以支持并发访问和响应，但是你知道是为什么么？

一、Binder线程池的启动

Binder线程池的启动主要就是依赖以下两个函数。一个进程通过调用其内部的ProcessState对象的成员startThreadPool函数来启动线程池，通过IPCThreadState对象的成员函数joinThreadPool，将启动的线程加入到Binder线程池并注册成为一个Binder线程。当线程启动之后，会不断与binder驱动进行通信，读取本线程和本进程中待处理的事务，如果接受到Binder驱动的请求，则处理之。而当进程繁忙时， Binder驱动会向目标进程发送一个BR_SPAWN_LOOPER命令，申请一个新的进程。

 ProcessState::self()->startThreadPool();IPCThreadState::self()->joinThreadPool();

当Binder驱动接到Server发来的IPC请求时，就会回复一个BR_SPAWN_LOOPER通知创建Binder线程用于处理这个请求，当threadLoop函数返回false时则会被回收相应的对象。

1、ProcessState#startThreadPool函数来启动线程池

ProcessState在同一进程内是唯一的，主要用于初始化Binder设备，而IPCThreadState 用于与Binder驱动通信。

通常Service组件注册完毕之后对应的进程就会自动开启一个Binder线程池来处理Client进程发送过来的IPC请求。通常进程是通过调用其内部的ProcessState对象的startThreadPool函数来启动的。

\frameworks\native\libs\binder\ProcessState.cpp

void ProcessState::startThreadPool()
{AutoMutex _l(mLock);if (!mThreadPoolStarted) {//防止重复启动线程池mThreadPoolStarted = true;spawnPooledThread(true);}
}

从上面我们可以得知一个进程中有且只有一个Binder线程池且只启动一次，接着是真正通过ProcessState#spawnPooledThread来启动线程池的。

isMain为true表示是线程是进程主动创建并加入到它Binder线程池的，对应的是BC_ENTER_LOOPER协议，而Binder驱动请求进程创建的线程则isMain为false，对应的是BC_REGISTER_LOOPER。

void ProcessState::spawnPooledThread(bool isMain)
{if (mThreadPoolStarted) {String8 name = makeBinderThreadName();//Binder线程的名称sp<Thread> t = new PoolThread(isMain);t->run(name.string());}
}String8 ProcessState::makeBinderThreadName() {int32_t s = android_atomic_add(1, &mThreadPoolSeq);pid_t pid = getpid();String8 name;name.appendFormat("Binder:%d_%X", pid, s);return name;
} 

主要就是创建PoolThread对象并调用其run函数启动一个新线程，而PoolThread 继承Thread并重写了线程入口函数threadLoop

class PoolThread : public Thread
{
public:PoolThread(bool isMain): mIsMain(isMain){}protected:virtual bool threadLoop(){IPCThreadState::self()->joinThreadPool(mIsMain);return false;}const bool mIsMain;
};

接着IPCThreadState#joinThreadPool 将当前线程进入到线程池中去等待和处理IPC请求。

Binder驱动接到IPC 请求的时候就会发一个 BR_SPAWN_LOOPE ，然后Server 端就创建一个线程来处理，但是一个fd 最多绑定15线程。

2、IPCThreadState#joinThreadPool 将当前线程进入到线程池中去等待和处理IPC请求

IPCThreadState#joinThreadPool 函数将当前线程注册到Binder驱动中，成为一个Binder线程，以便Binder驱动可以分发IPC请求给它处理，在进入Binder驱动前talkWithDriver会自动检测IPCThreadState内部的协议输出缓冲区是否还有协议，有则发给BInder驱动处理，处理完成返回后Binder驱动回复返回协议保存至IPCThreadState内部的协议输入缓冲区中，函数getAndExecuteCommand将会去处理。

void IPCThreadState::joinThreadPool(bool isMain)
{//将协议写入到IPCThreadState的输出缓冲区mOut.writeInt32(isMain ? BC_ENTER_LOOPER : BC_REGISTER_LOOPER);set_sched_policy(mMyThreadId, SP_FOREGROUND);status_t result;do {processPendingDerefs();// now get the next command to be processed, waiting if necessaryresult = getAndExecuteCommand();if (result < NO_ERROR && result != TIMED_OUT && result != -ECONNREFUSED && result != -EBADF) {abort();}if(result == TIMED_OUT && !isMain) {break;}} while (result != -ECONNREFUSED && result != -EBADF);LOG_THREADPOOL("**** THREAD %p (PID %d) IS LEAVING THE THREAD POOL err=%p\n",(void*)pthread_self(), getpid(), (void*)result);mOut.writeInt32(BC_EXIT_LOOPER);talkWithDriver(false);
}

若talkWithDriver函数长期没有等到IPC请求或者getAndExecuteCommand函数执行超时，且isMain为false时就跳出循环，并向Binder驱动发送BC_EXIT_LOOPER协议告知Binder驱动，前面创建的这个线程它要退出Binder线程池了。

二、Service 代理对象的获取

Server进程和Client进程的通信要依靠Binder驱动来进行。

Service组件在启动时，会将自己注册到ServiceManager组件中，以便Client组件通过ServiceManager来找到这个Service组件。

在Binder IPC机制中Client要与Server通信，Client组件必须要先获取Service组件的代理对象，使用的时候很方便直接通过Service Manager代理对象的getService接口就可以获取，前面分析了ServiceManager 自身代理对象的获取，普通Service 组件代理对象获取的流程也大同小异，虽然说要与Binder驱动沟通，但是对于我们开发者来说这一部分的工作被Service Manager 帮忙承担了。

sp<IServiceManager> sm = defaultServiceManager();
sp<IBinder> binder = sm->getService(String16(DETECT_SERVICE_NAME));
sp<IDetectService> bpDetectService = interface_cast <IDetectService>(binder);

总结起来在Client进程（本例中名称为DetectClient）获取一个普通Service 代理对象三部曲为：

1、获取Service Manager 代理对象BpServiceManager

主要就是通过IServiceManager#defaultServiceManager函数获取，预知详情参见前文。

2、调用BpServiceManager#getService

BpServiceManager继承自BpInterface，而BpInterface是一个继承BpRefsBase的模板类，在getService函数中最多会尝试100次来尝试获取名称对应的Service组件代理对象

class BpServiceManager : public BpInterface<IServiceManager>
{
public:BpServiceManager(const sp<IBinder>& impl): BpInterface<IServiceManager>(impl){}virtual sp<IBinder> getService(const String16& name) const{unsigned n;for (n = 0; n < 100; n++){if (n > 0) {ALOGI("Waiting for service %s...", String8(name).string());usleep(50000);}sp<IBinder> svc = checkService(name);if (svc != NULL) return svc;}return NULL;}...
};

在checkService函数来真正去尝试获取Service组件代理对象，对比前文addService的核心流程大同小异（通过Service Manager代理对象请求Service Manager进程执行ADD_SERVICE_TRANSACTION），把协议换为CHECK_SERVICE_TRANSACTION协议即可。

    virtual sp<IBinder> checkService( const String16& name) const{Parcel data, reply;//执行writeInterfaceToken函数，拼装Binder协议头data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());data.writeString16(name);//remote()即0号引用remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);return reply.readStrongBinder();}

换言之，getService 的实现就一个标准的Binder IPC 五部曲：

步骤	说明
1	DetectClient将DetectService代理对象对应的名称封装为Parcel对象并传递到Binder驱动。
2	DetectClient向Binder驱动发送BC_TRANSACTION_COMPLETE协议，Binder驱动根据协议内容找到目标Service Manager进程后回复一个BR_TRANSACTION_COMPLETE告知DetectClient其通信请求已被接受，Client接到BR_TRANSACTION_COMPLETE并处理后，会再次进入到Binder驱动程序中等待Server Manager进程的返回它想要的代理对象的句柄。
3	Binder驱动在给DetectClient回复一个BR_TRANSACTION_COMPLETE的同时，向Service Manager进程发送一个BR_TRANSACTION返回协议，请求目标Server Manager 进程执行CHECK_SERVICE_TRANSACTION指令。
4	Service Manager进程接收BR_TRANSACTION并处理CHECK_SERVICE_TRANSACTION后，给驱动回复一个BC_REPLY协议（包含了DetectClient申请Service组件的信息），驱动根据协议内容为DetectClient进程创建一个对应的Binder引用对象，给Service Manager进程发送一个BR_TRANSACTION_COMPLETE返回协议，告知Service Manager它返回的目标Service 组件信息已经收到了，已接到返回的相应结果，Service Manager接到并处理了BR_TRANSACTION_COMPLETE协议后，一次IPC流程就结束了，接着会重新进入到驱动程序中等待下一次IPC请求。
5	Binder驱动在给Service Manager进程发送BR_TRANSACTION_COMPLETE的同时，也会向DetectClient进程发送一个BR_REPLY返回协议（内容包含了前面所创建的Binder引用对象的举止值），DetectClient进程就可以拿着这个句柄来创建一个目标Binder代理对象，同时也代表Service Manager进程已经处理完成IPC请求了并将结果返回给Client

通过这样子就可以拿到了Service 代理对象，简而言之，Client进程通过Service Manager进程拿到目标Service代理对象的引用对象的句柄值，再根据这个句柄值创建对应的Service 代理对象。

2.1、Service Manager 处理CHECK_SERVICE_TRANSACTION

前面说过Service Manager是在svcmgr_handle函数中统一处理Client进程的IPC请求。

\frameworks\native\cmds\servicemanager\service_manager.c

int svcmgr_handler(struct binder_state *bs,struct binder_transaction_data *txn,struct binder_io *msg,struct binder_io *reply)
{struct svcinfo *si;uint16_t *s;size_t len;uint32_t handle;uint32_t strict_policy;int allow_isolated;...switch(txn->code) {case SVC_MGR_GET_SERVICE:case SVC_MGR_CHECK_SERVICE://从binder_io结构体中的msg数据缓冲区得到代理对象的名称s = bio_get_string16(msg, &len);if (s == NULL) {return -1;}//获取目标Binder引用对象的句柄handle = do_find_service(s, len, txn->sender_euid, txn->sender_pid);if (!handle)break;//传入目标引用对象的句柄到Binder驱动,并封装为一个对应的binder_object结构体并下入reply中，Binder驱动拿到的返回值就是replybio_put_ref(reply, handle);return 0;case SVC_MGR_ADD_SERVICE:...break;case SVC_MGR_LIST_SERVICES: {...}bio_put_uint32(reply, 0);return 0;
}

从binder_io结构体中的msg数据缓冲区还原出代理对象的名称后，通过do_find_service函数从已注册的Service组件列表svclist中查找与之对应的一个svcinfo结构体，并返回Service 组件的句柄。

在Service Manager中每一个被注册了的Service组件对应一个svcinfo 结构并保存在一个全局队列svclist中，其中svcinfo的成员next指向下一个svcinfo结构体、prt是一个Service组件Binder引用对象的句柄值、name是Service组件名称，death指向一个用于描述死亡接收通知的结构体binder_death。

uint32_t do_find_service(const uint16_t *s, size_t len, uid_t uid, pid_t spid)
{// 查找与字符串s对应一个svcinfo结构体struct svcinfo *si = find_svc(s, len);...if (!svc_can_find(s, len, spid, uid)) {return 0;}return si->handle;
}

2.2、Binder 驱动为Client进程创建对应的Service组件的Binder引用对象

找到Service组件结构体后就得到了其他Binder引用对象的句柄，返回到svcmgr_handler函数中，Service Manager接着通过bio_put_ref函数把句柄传给Binder驱动，Binder驱动就根据它找到对应的Binder引用对象，进而找到该引用对象所指向（引用）的Binder实体对象，最后Binder驱动就在请求该Service组件的代理对象时创建另一个Binder引用对象了。

\frameworks\native\cmds\servicemanager\binder.c

void bio_put_ref(struct binder_io *bio, uint32_t handle)
{struct flat_binder_object *obj;if (handle)//非0位trueobj = bio_alloc_obj(bio);elseobj = bio_alloc(bio, sizeof(*obj));if (!obj)return;obj->flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;obj->type = BINDER_TYPE_HANDLE;obj->handle = handle;obj->cookie = 0;
}

bio_alloc函数在binder_io结构体的数据缓冲区分配一个未初始化的binder_object结构体并赋值给obj，保存了位置后返回到bio_put_ref函数，继续对创建的结构体进行初始化后

static struct flat_binder_object *bio_alloc_obj(struct binder_io *bio)
{struct flat_binder_object *obj;obj = bio_alloc(bio, sizeof(*obj));//在binder_io结构体的数据缓冲区分配一个未初始化的binder_object结构体//在binder_io的bio偏移数组中分配一个元素来保存binder_object结构体在数据缓冲区的位置，方便Binder驱动获知Service Manager给它返回的IPC结果中包含了一个Binder对象if (obj && bio->offs_avail) {bio->offs_avail--;*bio->offs++ = ((char*) obj) - ((char*) bio->data0);return obj;}bio->flags |= BIO_F_OVERFLOW;return NULL;
}

再回到svcmgr_handler函数中将Binder驱动IPC结果保存到binder_io类型结构体reply中了，接着回到binder_parse中最后调用binder_send_reply函数将reply的内容返回给Binder驱动（即向Binder驱动发送BC_REPLY协议）。

Binder驱动是在binder_transaction函数中处理Service Manager 发来的协议

Service Manager进程返回给Binder驱动的IPC结果中包含了BINDER_TYPE_WEAK_HANDLE类型的binder_object结构体（即flat_binder_object 结构体），Binder驱动就对这个结构体进行解包并从其中找到Binder引用对象ref（即指向的是运行在Server进程中的DetectService组件），然后查找是否存在对应的Binder引用对象，存在则直接返回给调用者，不存在则为Client进程创建一个新的Binder引用对象再返回，再经过Binder驱动一系列的处理之后

static void binder_transaction(struct binder_proc *proc,struct binder_thread *thread,struct binder_transaction_data *tr, int reply,binder_size_t extra_buffers_size)
{int ret;struct binder_transaction *t;struct binder_work *tcomplete;struct binder_proc *target_proc = NULL;struct binder_thread *target_thread = NULL;struct binder_node *target_node = NULL;struct binder_transaction *in_reply_to = NULL;struct binder_buffer_object *last_fixup_obj = NULL;struct binder_context *context = proc->context;.../* TODO: reuse incoming transaction for reply */t = kzalloc(sizeof(*t), GFP_KERNEL);binder_stats_created(BINDER_STAT_TRANSACTION_COMPLETE);...for (; offp < off_end; offp++) {struct binder_object_header *hdr;switch (hdr->type) {case BINDER_TYPE_BINDER:case BINDER_TYPE_WEAK_BINDER: {...}break;case BINDER_TYPE_HANDLE:case BINDER_TYPE_WEAK_HANDLE: {struct flat_binder_object *fp;...} break;}
}

2.3、Binder库为Client进程创建Binder代理对象

最终目标线程target_thread返回到用户空间之后，再次进去到IPCThreadState#waitForResponse函数处理从Binder驱动读取回来的BR_REPLY协议，将Binder 驱动IPC结果封装为Parcel的对象reply中，再次返回到Service Manager代理对象的成员函数checkService中，最后通过Parcel的readStrongBinder函数得到Binder的代理对象。

status_t Parcel::readStrongBinder(sp<IBinder>* val) const
{return unflatten_binder(ProcessState::self(), *this, val);
}status_t unflatten_binder(const sp<ProcessState>& proc,const Parcel& in, sp<IBinder>* out)
{const flat_binder_object* flat = in.readObject(false);if (flat) {switch (flat->type) {case BINDER_TYPE_BINDER:*out = reinterpret_cast<IBinder*>(flat->cookie);return finish_unflatten_binder(NULL, *flat, in);case BINDER_TYPE_HANDLE:*out = proc->getStrongProxyForHandle(flat->handle);return finish_unflatten_binder(static_cast<BpBinder*>(out->get()), *flat, in);}}return BAD_TYPE;
}

本质上还是通过ProcessState#getStrongProxyForHandle函数从其内部的Binder代理对象列表中查找是否存在一个与flat_binder_object结构体句柄值handle对应的Binder代理对象，存在则返回，不存在则根据handle创建相应的BInder代理对象再返回，而且flat_binder_object的handle同时是指向了Service组件引用对象，因此ProcessState#getStrongProxyForHandle函数返回的Binder代理对象也指向了Service组件的引用对象。

3、asInterface “转换”

当BpServiceManager#checkService 函数执行完成之后，就将一个Binder代理对象的IBinder接口返回到DetectClient进程的入口函数main，接着最差最后一步——"转换"为具体的Binder代理对象。

interface_cast并不是指针转换，而是利用BpBinder指针，构建出一个新的BpServiceManager对象。宏函数实现的。

android::sp<IDetectService> IDetectService::asInterface(               const android::sp<android::IBinder>& obj)                  {                                                                  android::sp<IDetectService> intr;                                if (obj != NULL) {                                             intr = static_cast<IDetectService*>(                         obj->queryLocalInterface(IDetectService::descriptor).get());              if (intr == NULL) {                                        intr = new BpIDetectService(obj);                         }                                                          }                                                              return intr;                                                   }