Android Binder学习(四)之addService流程分析
来源：互联网 发布：unity编程语言 编辑：程序博客网 时间：2024/05/18 02:44
Android Binder学习(四)之addService流程分析
备注：本文基于Android5.1分析
该篇博文去年年底就基本整理完毕，年后几个月太忙，最近才有时间整理一下发表出来。博文是边看代码边整理的，本人能力有限，前后花了三个星期的苦逼夜晚整理。博文是按着代码的执行流程来分析的。以mediaServer添加camera服务为例来分析数据打包传递过程，中间穿插一些我自己理解画出来的图，如果你发现有问题，欢迎发表自己的看法，大家共同进步。
binder通信的过程，好比我们在淘宝下单至商品发货的过程。我们是客户端、淘宝相当于binder内核驱动、店家代表service_manager。就像下面说的（一开始可能不太理解，但大概先了解它的工作情形吧）。如果想粗线条的理解，也可以直接跳到博文最后总结性的流程分析。
- 1.服务请求：我们想买自己的商品，下单后，淘宝客户端会告诉我们，我们的商品已经订购成功，与此同时淘宝也会给店家发送一条消息(有人买你们的东西，且多了一个订单)
- 2.服务处理：店家收到订单后，会进行商品的分类打包，并贴上响应的邮寄地址。
- 3.服务反馈：店家打包完毕，发货后，会通过淘宝给我们发一条消息，说你的商品已经出库了。
上面的处理过程和binder进程间通信类型。在开始看的时候，最好能看看前面的一些数据结构介绍，这样在看的时候，一些概念才能更清楚。下面介绍addservice过程时，是根据camera服务来分析的。下一篇博文我们先介绍camera framwork代码，在进行后面的客户端请求camera服务分析。
一、Media_Server发送addService请求
1.CameraService::instantiate();
int main(){ sp<ProcessState> proc(ProcessState::self()); sp<IServiceManager> sm = defaultServiceManager(); ALOGI("ServiceManager: %p", sm.get()); AudioFlinger::instantiate(); MediaPlayerService::instantiate(); CameraService::instantiate(); //这个是我们重点关注对象 AudioPolicyService::instantiate(); SoundTriggerHwService::instantiate(); //以上是服务实例注册流程 ProcessState::self()->startThreadPool(); //启动线程池 IPCThreadState::self()->joinThreadPool(); //主线程加入到线程池中}在Android7.0以后，CameraService驻留在CameraServer，其它的android版本都是在mediaServer进程中。这里我分析的是Android5.1，所以CameraServie是在media_server进程中。上面的代码就是media_server进程的main函数。可以看到驻留在media_server进程中的服务有5个，这里我们只关注CameraService.首先我们来看看instantiate()方法。
template<typename SERVICE>class BinderService{public: static status_t publish(bool allowIsolated = false) { sp<IServiceManager> sm(defaultServiceManager()); //这里获取serviceManager代理对象。 return sm->addService( String16(SERVICE::getServiceName()), //找到服务对应的名字，这里是media.camera new SERVICE(), allowIsolated); //大家因该注意到前面那个new SERVICE(),看样子服务在这里注册，没错，服务就是在这里注册的。 } static void publishAndJoinThreadPool(bool allowIsolated = false) { publish(allowIsolated); joinThreadPool(); } static void instantiate() { publish(); } //可以看到instantiate后面有调用的publish()方法，请看上面对应的方法......}上面是一个模板类，调用那个service_manage代理对象addServic（）时大家看看,新创建服务对象其实就是模板参数。这里我们知道这里创建的是一个cameraService。详情请看下面代码追踪，CameraService类继承了BinderService,传进去的模板参数就是CameraService。
2.CameraService类
class CameraService : public BinderService<CameraService>, //这里模板传入的是CameraSrvice，那么在上面的new出来的就是CameraService对象了。 public BnCameraService, public IBinder::DeathRecipient, public camera_module_callbacks_t{ friend class BinderService<CameraService>;public: class Client; class BasicClient; // Implementation of BinderService<T> static char const* getServiceName() { return "media.camera"; } //可以看到服务名字是media.camera......}具体CameraService服务的接口实现，我们放在后面其它博客中详细叙述，这里主要介绍Binder。可以看到该类继承了BinderService类，模板参数正是CameraService。现在我们需要做的就是下面一件事情
- 1.这里在instantiate方法之后，会new出来一个CameraService对象。然后用sm代理对象，将服务对象添加到sm中了。下面看看它时如何添加的。
3.sm->addService()都干了什么
class BpServiceManager : public BpInterface<IServiceManager>{public:...... virtual status_t addService(const String16& name, const sp<IBinder>& service, bool allowIsolated) { Parcel data, reply; data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor()); //这里descriptor = “android.os.IServiceManager” data.writeString16(name); data.writeStrongBinder(service); data.writeInt32(allowIsolated ? 1 : 0); //由上面的publish方法定义的地方，可以看到这里allowIsolated变量为0. status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply); //调用代理对象，为什么叫remote，就因为是一个ServiceManager远端代理。 return err == NO_ERROR ? reply.readExceptionCode() : err; }......}IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager"); //代码中看是打包数据了，为了看清楚数据的包含关系，这里我画出打包数据的数据分布,方便大家一起跟踪一下。其中大家要住的是writeStrongBinder()方法了，该方法会将cameraService实例打包成一个flat_binder_object对象，具体如何打包的大家可以查看之前的博客。接下来看看serviceManager代理如何通信的。
4.remote()->transact()
status_t BpBinder::transact( uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags) //上面的flag默认为0，从上面一段代码看到，在调用时没有传入flag参数。{ // Once a binder has died, it will never come back to life. if (mAlive) { status_t status = IPCThreadState::self()->transact( mHandle, code, data, reply, flags);//注意这里的mHandle就是用来查找sm 进程的唯一标识。 if (status == DEAD_OBJECT) mAlive = 0; return status; } return DEAD_OBJECT;}这里看到remote()就是远房的亲戚(代理对象),代码逻辑简单，这里只是做了一层封装，我们还是去IPCThreadState::transact()看看吧。
5.IPCThreadState::transact()
status_t IPCThreadState::transact(int32_t handle, uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){ status_t err = data.errorCheck(); flags |= TF_ACCEPT_FDS; ...... if (err == NO_ERROR) { LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), getuid(), (flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY"); err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL); } if (err != NO_ERROR) { if (reply) reply->setError(err); return (mLastError = err); } if ((flags & TF_ONE_WAY) == 0) { //flag参数默认是0，这里只有前面设置为TF_ACCEPT_FDS，所以这里为true. if (reply) { err = waitForResponse(reply); //走这一路 } else { Parcel fakeReply; err = waitForResponse(&fakeReply); } //去除debug信息...... } else { err = waitForResponse(NULL, NULL); } return err;}上面就是线程的事务处理函数，主要就下面2件事情
- 1.写通信事务数据(由writeTransactionData()方法来完成)，后面我们会画出打包之后的数据存储分布。
- 2.读取事务数据(由waitForResponse()方法来完成),当service响应了这一请求，就会回一个消息。
6.IPCThreadState::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 */ tr.target.handle = handle;//这里handle是serviceManage唯一标识，而且放到target中，而我们的目标就是sm。 tr.code = code;//这里code就是ADD_SERVICE_TRANSACTION tr.flags = binderFlags; tr.cookie = 0; tr.sender_pid = 0; tr.sender_euid = 0; const status_t err = data.errorCheck(); if (err == NO_ERROR) { //下面是记录binder对象的信息了。 tr.data_size = data.ipcDataSize();//buffer大小 tr.data.ptr.buffer = data.ipcData();//buffer地址 tr.offsets_size = data.ipcObjectsCount()*sizeof(binder_size_t);//binder对象的个数。 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); } mOut.writeInt32(cmd); mOut.write(&tr, sizeof(tr)); return NO_ERROR;}该函数的一开始就是填充binder_transaction_data对象的数据，最后填充完毕后，重要数据的分布如图所示。
需要发送的binder_transaction_data数据填充好之后，在函数的最后会将所有数据，写入发送缓冲区中mOut中，最终mOut重要数据成员分布如下所示。
7.waitForResponse()-焦急的等待
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult){ int32_t cmd; int32_t err; while (1) { if ((err=talkWithDriver()) < NO_ERROR) break;//需要和kernel谈谈了，目的就是把上面打包的mOut数据给你^o^,我们先把目光移到下面的taklWithDriver(); err = mIn.errorCheck(); if (err < NO_ERROR) break; if (mIn.dataAvail() == 0) continue; cmd = mIn.readInt32(); IF_LOG_COMMANDS() { alog << "Processing waitForResponse Command: " << getReturnString(cmd) << endl; } switch (cmd) { case BR_TRANSACTION_COMPLETE： .... break; case BR_DEAD_REPLY: err = DEAD_OBJECT; goto finish; case BR_FAILED_REPLY: err = FAILED_TRANSACTION; goto finish; case BR_ACQUIRE_RESULT: .... goto finish; case BR_REPLY: ...... goto finish; default: err = executeCommand(cmd); if (err != NO_ERROR) goto finish; break; } }finish: ..... return err;}该函数是与serviceManager通信的主要函数，首先会调用talkWithDriver()方法，将之前的打包在mOut中的数据打包成struct binder_write_read 对象，并通过ioctrl发送给kernel。虽然之前的博文已经介绍了IPCThreadState::talkWithDriver()方法，这里为了分析连贯，再贴一次出来。
8.IPCThreadState::talkWithDriver
status_t IPCThreadState::talkWithDriver(bool doReceive){ if (mProcess->mDriverFD <= 0) { return -EBADF; } binder_write_read bwr; // Is the read buffer empty? const bool needRead = mIn.dataPosition() >= mIn.dataSize(); const size_t outAvail = (!doReceive || needRead) ? mOut.dataSize() : 0; //doReceive参数，默认是为true,上面我们看到没有传参数，那么doReceive = 1； bwr.write_size = outAvail; bwr.write_buffer = (uintptr_t)mOut.data(); //将mOut数据指针存放到这里,这就是我们上面打包的数据。 // This is what we'll read. if (doReceive && needRead) { bwr.read_size = mIn.dataCapacity(); //注意这里数据的大小，在我们new IPCThreadState对象时，已经初始化为256. bwr.read_buffer = (uintptr_t)mIn.data(); //mIn数据指针，放到这里 } else { bwr.read_size = 0; bwr.read_buffer = 0; } //...... bwr.write_consumed = 0; bwr.read_consumed = 0; status_t err; do {#if defined(HAVE_ANDROID_OS) if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0) //这里通过ioctl将数据写给kernel err = NO_ERROR; else err = -errno;#else err = INVALID_OPERATION;#endif ..... } while (err == -EINTR); IF_LOG_COMMANDS() { alog << "Our err: " << (void*)(intptr_t)err << ", write consumed: " << bwr.write_consumed << " (of " << mOut.dataSize() << "), read consumed: " << bwr.read_consumed << endl; } return err;}该函数的作用就是将之前打包的数据通过系统调用ioctl发送给kernel，最终发送给kernel的数据是struct binder_write_read对象。该对象已经被打包了3次，它们的包含关系如下所示。这里说明一下
- 1.在调用serviceManager代理对象时，打包在Parcel对象中的服务的描述符号、服务的名字、服务对象的地址(其实是一个打包了服务实例的struct flat_binder_object对象地址，其中真正的服务对象的地址保存在flat_binder_object对象的cookie域中）
- 2.这里会将上一步中打包的Parcel对象数据域的指针，保存到一个struct binder_transaction_data对象里面。说是打包进去，倒不如说是保存数据指针，并保存记录信息数据。最后在将数据直接吸入mOut对象中
- 3.将第二步打包好的Parcel对象数据域的指针，赋给一个struct binder_write_read对象的write_buffer域，同时将mIn对象的数据域指针赋给read_buffer域。紧接着就会将这个数据发送给kernel。
9.ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)
static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg){..... switch (cmd) { case BINDER_WRITE_READ: {..... if (bwr.write_size > 0) {//这里>0,往下看binder_thread_write()实现。 ret = binder_thread_write(proc, thread, bwr.write_buffer, bwr.write_size, &bwr.write_consumed); } if (bwr.read_size > 0) { ret = binder_thread_read(proc, thread, bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK); } ....... break; } //.....}------------------------------------------------------------------------int binder_thread_write(){ ..... case BC_TRANSACTION://我们上次传下来的就是这个命令：BC_TRANSACTION. case BC_REPLY: { struct binder_transaction_data tr; if (copy_from_user(&tr, ptr, sizeof(tr)))//取出事务数据 return -EFAULT; ptr += sizeof(tr);//数据游标指针移动 binder_transaction(proc, thread, &tr, cmd == BC_REPLY);//事务处理函数,请进入看看,如下 break; }.....}-------------------------------------------------------------------------------static void binder_transaction(){..... if (tr->target.handle) {//这里我们目的就是和serviceManage通信，handle = 0 走else分支；..... } else { target_node = binder_context_mgr_node;//直接拿到service_manage全局的binder_node对象。 if (target_node == NULL) { return_error = BR_DEAD_REPLY; goto err_no_context_mgr_node; } } e->to_node = target_node->debug_id; target_proc = target_node->proc; //注意这里target_proc就是Service_Manager进程的的binder_proc。..... t = kzalloc(sizeof(*t), GFP_KERNEL); //为该事务分配内存空间。 t->sender_euid = proc->tsk->cred->euid; //发送者就是media_server进程 t->to_proc = target_proc; //目的进程是Service_Manager进程，更详细可从源码中了解. t->to_thread = target_thread; //Service_Manager主线程 t->code = tr->code; //这里等于 ADD_SERVICE_TRANSACTION t->flags = tr->flags; //由上面的数据包可知是TF_ACCEPT_FDS t->priority = task_nice(current); t->buffer->allow_user_free = 0; t->buffer->debug_id = t->debug_id; t->buffer->transaction = t; //当前binder_buffer属于哪个事务。 t->buffer->target_node = target_node; //service_manager的binder_node对象 if (target_node) binder_inc_node(target_node, 1, 0, NULL);//引用计数+1 offp = (binder_size_t *)(t->buffer->data + ALIGN(tr->data_size, sizeof(void *))); if (copy_from_user(t->buffer->data, (const void __user *)(uintptr_t) //请查看上面最近的一个图，这里会将上图中的1过程打包的数据拷贝到刚刚申请的binder_buffer中。 tr->data.ptr.buffer, tr->data_size)) { binder_user_error("%d:%d got transaction with invalid data ptr\n", proc->pid, thread->pid); return_error = BR_FAILED_REPLY; goto err_copy_data_failed; } if (copy_from_user(offp, (const void __user *)(uintptr_t) tr->data.ptr.offsets, tr->offsets_size)) { //这里会拷贝记录指针，即记录事务数据中，binder对象的偏移地址，以及个数。 binder_user_error("%d:%d got transaction with invalid offsets ptr\n", proc->pid, thread->pid); return_error = BR_FAILED_REPLY; goto err_copy_data_failed; } for (; offp < off_end; offp++) { struct flat_binder_object *fp; ...... fp = (struct flat_binder_object *)(t->buffer->data + *offp); switch (fp->type) { case BINDER_TYPE_WEAK_BINDER: { struct binder_ref *ref; struct binder_node *node = binder_get_node(proc, fp->binder); //这里fp->binder指向的是cameraService服务对象的引用计数对象指针。 if (node == NULL) { //这里由于CameraService是第一次注册，所以是找不到这个binder_node的。 node = binder_new_node(proc, fp->binder, fp->cookie);//这里会创建一个新的binder_node对象，注意参数中fp->cookie是cameraService服务在media_server进程地址空间的地址,后面找到cameraService服务对象就靠它了。 if (node == NULL) { //这里创建的binder_node会添加到media_server进程的binder_proc结构中的，binder_proc->nodes return_error = BR_FAILED_REPLY; goto err_binder_new_node_failed; } node->min_priority = fp->flags & FLAT_BINDER_FLAG_PRIORITY_MASK; node->accept_fds = !!(fp->flags & FLAT_BINDER_FLAG_ACCEPTS_FDS); } if (fp->cookie != node->cookie) {//显然刚创建的binder对象，这里是一样的。 binder_user_error("%d:%d sending u%016llx node %d, cookie mismatch %016llx != %016llx\n", proc->pid, thread->pid, (u64)fp->binder, node->debug_id, (u64)fp->cookie, (u64)node->cookie); goto err_binder_get_ref_for_node_failed; } if (security_binder_transfer_binder(proc->tsk, target_proc->tsk)) { return_error = BR_FAILED_REPLY; goto err_binder_get_ref_for_node_failed; } ref = binder_get_ref_for_node(target_proc, node); //这里会在在service_manager的binder_proc->refs_by_node域查找该binder_node对象的binder_ref引用对象，如果没有就会新创建一个，并分别添加到refs_by_node和refs_by_desc域中。这里我们是第一次添加CameraService所以这里会重新创建。 if (ref == NULL) { return_error = BR_FAILED_REPLY; goto err_binder_get_ref_for_node_failed; } if (fp->type == BINDER_TYPE_BINDER)//在查找服务时，会走到这里，我们在getService那一章继续分析。 fp->type = BINDER_TYPE_HANDLE; else fp->type = BINDER_TYPE_WEAK_HANDLE; fp->handle = ref->desc; //这里是非常关键的一步了，将该binder引用对象的desc，保存在flat_binder_object->handle中，方便后面查找该引用对象。 binder_inc_ref(ref, fp->type == BINDER_TYPE_HANDLE, //增加引用计数 &thread->todo); trace_binder_transaction_node_to_ref(t, node, ref); binder_debug(BINDER_DEBUG_TRANSACTION, " node %d u%016llx -> ref %d desc %d\n", node->debug_id, (u64)node->ptr, ref->debug_id, ref->desc); } break; ...... } if (reply) { //这里为false BUG_ON(t->buffer->async_transaction != 0); binder_pop_transaction(target_thread, in_reply_to); } else if (!(t->flags & TF_ONE_WAY)) { //这里flags = TF_ACCEPT_FDS，显然这里为true。 BUG_ON(t->buffer->async_transaction != 0); t->need_reply = 1; //需要service_manager进程回复给media_server进程。 t->from_parent = thread->transaction_stack; //该事务依赖的前一个事务 thread->transaction_stack = t; } else { BUG_ON(target_node == NULL); BUG_ON(t->buffer->async_transaction != 1); if (target_node->has_async_transaction) { target_list = &target_node->async_todo; target_wait = NULL; } else target_node->has_async_transaction = 1; } t->work.type = BINDER_WORK_TRANSACTION; //注意这个工作项的类型。 list_add_tail(&t->work.entry, target_list); //将该事务加入到service_manager进程事务队列中。 tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE; list_add_tail(&tcomplete->entry, &thread->todo); if (target_wait) //如果service_manager进程在等待，下面就会唤醒service_manager对进程。 wake_up_interruptible(target_wait); return;}上面的代码很长，为了看起来精简一些，去掉了一些数据拷贝、错误检查的代码、以及一些其它的和今天议题暂时没有关系的代码。
- 1.由于tr->target.handle是0，所以这里由事务数据可以确定，这里数据是要发送给service_manager进程的。所以就有了target_node = binder_context_mgr_node,然后就定位到binder_proc对应的就是service_manager进程了。接着就会申请一个struct binder_transaction对象，并从service_manager buffer缓冲区中申请内存，并将对应的media_server进程的数据拷贝到binder_buffer中，最后将该binder_buffer对象保存binder_proc的buffers链表中，具体过程如下所示。
- 2.根据上层传下来的服务的引用计数指针，在当前binder_proc（meida_server）中查找该计数对象对应的binder_node对象，如果该bidner_node对象不存在，就会根据服务(这里是CameraService)的引用计数指针和服务对象的地址重新创建一个binder_node对象，紧接着会在service_manager 进程的binder_proc对象的refs_by_node上查找是否存在该binder_node的binder_ref对象，如果有会直接返回该binder_ref对象，反之就会创建一个该binder_node对应的binder_ref对象，并将该binder_ref对象插入到service_manager进程的binder_proc对象的refs_by_desc链表上。
小总结:之前没有看这一部分代码，老是认为binder_node都是链接到全局的binder_node对象 binder_context_mgr_node上的，现在发现是这样的。
- 1.各个server中注册的服务对应的binder_node对象都是链接在对应的server进程binder_proc对象上的。
- 2.所有binder_ref都是链接在service_manager进程的binder_proc对象中的。
10.事务数据读取(binder_thread_read)
service_manager进程从kernel醒来之后，就会读取自己是否有需要处理的事务，恰巧我们上面media_server发给它一条。
static int binder_thread_read(){...... ret = wait_event_freezable_exclusive(proc->wait, binder_has_proc_work(proc, thread)); //service_manager进程从这里唤醒...... while (1) { uint32_t cmd; struct binder_transaction_data tr; struct binder_work *w; struct binder_transaction *t = NULL; if (!list_empty(&thread->todo)) w = list_first_entry(&thread->todo, struct binder_work, entry); else if (!list_empty(&proc->todo) && wait_for_proc_work) w = list_first_entry(&proc->todo, struct binder_work, entry);...... switch (w->type) { case BINDER_WORK_TRANSACTION: { t = container_of(w, struct binder_transaction, work); } break;..... if (t->buffer->target_node) { struct binder_node *target_node = t->buffer->target_node; tr.target.ptr = target_node->ptr; tr.cookie = target_node->cookie; //...... cmd = BR_TRANSACTION; }...... tr.code = t->code; tr.flags = t->flags;...... tr.data_size = t->buffer->data_size; tr.offsets_size = t->buffer->offsets_size; tr.data.ptr.buffer = (binder_uintptr_t)( (uintptr_t)t->buffer->data + proc->user_buffer_offset); tr.data.ptr.offsets = tr.data.ptr.buffer + ALIGN(t->buffer->data_size, sizeof(void *)); if (put_user(cmd, (uint32_t __user *)ptr)) return -EFAULT; ptr += sizeof(uint32_t); if (copy_to_user(ptr, &tr, sizeof(tr))) return -EFAULT; ptr += sizeof(tr);}刚才添加cameraService的工作项是发送给service_manager进程的，而且service_manage进程在刚开机时，事情不是很多，一会就在kernel中睡眠了。所以我们接着它醒来的代码行分析。由于media_server发送过来的是一个类型为BINDER_WORK_TRANSACTION的工作项。这里先做个关于通信数据对象的转变过程分析。
上面的对象转来转去，最终会传到servie_manager进程中，传到service_manager进程中的也是一个binder_transaction_data，不过此时binder_transaction_data->buffer指向的是一个binder_buffer。而之前在media_server的binder_transaction_data->buffer指向的是一个Parcel对象。传到service_manager进程中的binder_transaction_data对象的分布如下（之前做了memcp）：
二、ServiceManager处理addService请求
1.binder_parse()
binder_parse(){ int r = 1; uintptr_t end = ptr + (uintptr_t) size; while (ptr < end) { uint32_t cmd = *(uint32_t *) ptr; //上面得知cmd = BR_TRANSACTION ptr += sizeof(uint32_t);...... switch(cmd) { case BR_TRANSACTION: { //media_server发送的就是这个消息。 struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr; if ((end - ptr) < sizeof(*txn)) { ALOGE("parse: txn too small!\n"); return -1; } binder_dump_txn(txn); if (func) { unsigned rdata[256/4]; //请看下面图片分析 struct binder_io msg; struct binder_io reply; //要发送给media_server的消息 int res; bio_init(&reply, rdata, sizeof(rdata), 4); //初始化reply数据，后面返回处理结果时，会通过reply对象的。 bio_init_from_txn(&msg, txn); //这里会将binder_transaction_data数据传递给一个struct binder_io类型的数据msg，后面解析事务数据就通过msg了。 res = func(bs, txn, &msg, &reply); //从上面传递的参数可以知道func = svcmgr_handler，请看下面源码 binder_send_reply(bs, &reply, txn->data.ptr.buffer, res); } ptr += sizeof(*txn); break; ...... }}我们知道ServiceManager进程在没有工作项的时候，会在kernel中睡眠等待。但是前面我们知道media_server进程已经唤醒了serviceManager进程，而且还给它发了一个事务工作项。这时候ServiceManager进程被唤醒之后，继续从kernel中读取消息来处理。此时的确有一条Media_Server进程发送给它的事务工作项。数据打包的数据如上图所示。
2.struct binder_io-结构分析
void bio_init(struct binder_io *bio, void *data, size_t maxdata, size_t maxoffs){ size_t n = maxoffs * sizeof(size_t); //maxoffs = 4，所以这里一般为16个字节 if (n > maxdata) { //16 > 256 ?显然不成立 bio->flags = BIO_F_OVERFLOW; bio->data_avail = 0; bio->offs_avail = 0; return; } bio->data = bio->data0 = (char *) data + n; //初始化数据其实位置，故意跳过前面binder对象偏移数组。 bio->offs = bio->offs0 = data; //binder对象偏移数组位置。 bio->data_avail = maxdata - n; //实际可用的buffer大小等于总的buffer大小减去偏移数组大小。 bio->offs_avail = maxoffs; //binder对象为4个，这个是固定的。 bio->flags = 0; //这个要留意了，后面在kernel中要用到，先留个心眼。}void bio_init_from_txn(struct binder_io *bio, struct binder_transaction_data *txn){ bio->data = bio->data0 = (char *)(intptr_t)txn->data.ptr.buffer; //可以看到这是记录了buffer的地址。 bio->offs = bio->offs0 = (binder_size_t *)(intptr_t)txn->data.ptr.offsets; //偏移数组的位置 bio->data_avail = txn->data_size; //可用数据的大小 bio->offs_avail = txn->offsets_size // sizeof(size_t); //binder对象个数 bio->flags = BIO_F_SHARED;}struct binder_io //下面的{ char *data; /* pointer to read/write from */ binder_size_t *offs; /* array of offsets */偏移数组 size_t data_avail; /* bytes available in data buffer */ size_t offs_avail; /* entries available in offsets array */ char *data0; /* start of data buffer */ binder_size_t *offs0; /* start of offsets buffer */ uint32_t flags; uint32_t unused;};下图只是在初始化rdata[256/4]数据时才有的分布，只是定义一个struct binder_io 对象来管理rdata数据缓冲区。
3.svcmgr_handler()-消息处理中心
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; //ALOGI("target=%x code=%d pid=%d uid=%d\n", // txn->target.handle, txn->code, txn->sender_pid, txn->sender_euid); if (txn->target.handle != svcmgr_handle) return -1; if (txn->code == PING_TRANSACTION) return 0; // Equivalent to Parcel::enforceInterface(), reading the RPC // header with the strict mode policy mask and the interface name. // Note that we ignore the strict_policy and don't propagate it // further (since we do no outbound RPCs anyway). strict_policy = bio_get_uint32(msg); s = bio_get_string16(msg, &len); if (s == NULL) { return -1; } if ((len != (sizeof(svcmgr_id) / 2)) || //全局变量svcmgr_id = “android.os.IServiceManager” memcmp(svcmgr_id, s, sizeof(svcmgr_id))) { //这里为了确定消息的准确性，会将发送给它数据的开始处的字符串数据对比。没有就直接返回错误。 fprintf(stderr,"invalid id %s\n", str8(s, len)); //上面我画的发送给service_manager user层的数据第一个就是“android.os.IServiceManager”，这里就不会进去了。 return -1; } //......selinux相关的 switch(txn->code) { case SVC_MGR_GET_SERVICE: case SVC_MGR_CHECK_SERVICE: s = bio_get_string16(msg, &len); if (s == NULL) { return -1; } handle = do_find_service(bs, s, len, txn->sender_euid, txn->sender_pid); if (!handle) break; bio_put_ref(reply, handle); return 0; case SVC_MGR_ADD_SERVICE: // 由上面返回给srviceManager进程的数据得知.code = ADD_SERVICE_TRANSACTION，就是这个case项 s = bio_get_string16(msg, &len); //这里获取到服务的名字“media.camera" if (s == NULL) { return -1; } handle = bio_get_ref(msg); //这里获取到media.camera binder_ref引用对象的desc成员数据，该数据标识了该服务对象。 allow_isolated = bio_get_uint32(msg) ? 1 : 0; if (do_add_service(bs, s, len, handle, txn->sender_euid, allow_isolated, txn->sender_pid)) return -1; break; case SVC_MGR_LIST_SERVICES: { uint32_t n = bio_get_uint32(msg); if (!svc_can_list(txn->sender_pid)) { ALOGE("list_service() uid=%d - PERMISSION DENIED\n", txn->sender_euid); return -1; } si = svclist; while ((n-- > 0) && si) si = si->next; if (si) { bio_put_string16(reply, si->name); return 0; } return -1; } default: ALOGE("unknown code %d\n", txn->code); return -1; } bio_put_uint32(reply, 0); return 0;}这个才是最核心的处理函数，这里又出现了一个新的结构体struct svcinfo，我们先来分析一下它的成员变量。
struct svcinfo{ struct svcinfo *next; //链表指针，可见每一个服务都是手拉手的。 uint32_t handle; //这个非常重要，读应该binder_ref引用对象中的desc数据，也就是通过这个来区分binder_ref引用对象了，以及后续的服务查找也是通过这个handle查找的。 struct binder_death death; //服务的死亡通知对象， int allow_isolated; size_t len; uint16_t name[0]; //服务的名字}; 上面就是一个服务注册到service_manager进程空间的存在形态，其中最最重要的要属handle成员变量了，该成员变量目前我理解是唯一标示一个服务。通过该handle就可以找到或者创建该服务在kernel中的binder_ref引用对象，接着就会把对应的binder_ref挂接到对应客户端进程的binder_ref 链表中了。
说完了上面的结构体，我们来分析一下svcmgr_handler()方法，该方法承载了service_manager的大部分工作。这里我们只关注了ADD_SERVICE的case项。该case项大概就做了下面几个动作。
1.首先通过bio_get_string16()方法，从数据包中解析出我们注册服务名字是”media.camera”.具体如何查找的细节，感兴趣的可以自己进去瞅瞅。
2.紧接着调用bio_get_ref()方法，找到该服务的binder_ref引用对象在kernel的一个handle(可以理解该handle唯一标示该引用对象)，后面创建服务代理对象时，拿到的就是这个handle。
3.然后调用do_add_service()方法将该服务打包成一个struct svcinfo 对象并插入到svclist全局链表中。当然这个添加过程还夹杂一些其它的处理，下面我们看看它的源代码。
4.do_add_service()核心工作
int do_add_service(struct binder_state *bs, const uint16_t *s, size_t len, uint32_t handle, uid_t uid, int allow_isolated, pid_t spid){ struct svcinfo *si; //ALOGI("add_service('%s',%x,%s) uid=%d\n", str8(s, len), handle, // allow_isolated ? "allow_isolated" : "!allow_isolated", uid); if (!handle || (len == 0) || (len > 127)) return -1; if (!svc_can_register(s, len, spid)) { ALOGE("add_service('%s',%x) uid=%d - PERMISSION DENIED\n", str8(s, len), handle, uid); return -1; } si = find_svc(s, len); //根据名字“media.camera"查找之前是否已经在serviceManager注册过了camera服务。如果存在说明服务挂掉了 if (si) { if (si->handle) { //如果第一次注册camera服务的话，这里肯定不为真，否则系统已经出问题了。 ALOGE("add_service('%s',%x) uid=%d - ALREADY REGISTERED, OVERRIDE\n", str8(s, len), handle, uid); svcinfo_death(bs, si); } si->handle = handle;//记录服务引用对象handle，很重要 } else { //首次注册 si = malloc(sizeof(*si) + (len + 1) * sizeof(uint16_t)); //申请struct svcinfo 对象 if (!si) { ALOGE("add_service('%s',%x) uid=%d - OUT OF MEMORY\n", str8(s, len), handle, uid); return -1; } si->handle = handle; //保存camera服务的binder_ref引用对象的desc成员，这个成员非常重要 si->len = len; //名字的长度 memcpy(si->name, s, (len + 1) * sizeof(uint16_t)); si->name[len] = '\0'; si->death.func = (void*) svcinfo_death; si->death.ptr = si; si->allow_isolated = allow_isolated; si->next = svclist; //这里采用头插发，插入该服务对应的struct svcinfo 对象数据。 svclist = si; //其中 svclist是一个全局变量。 } binder_acquire(bs, handle); //这里会增加该服务binder_ref引用对象的的引用计数，下面我们进kernel看看 binder_link_to_death(bs, handle, &si->death); //注册一个当服务出现异常时，处理函数。 return 0;}这里是addService()工作处理的狠心，看到这里可能大家都已经明白了，服务在serviceManage中存在形态，总的说来该函数就干了下面几件事。
- 1.根据要注册服务的名字，在服务链表中查找该服务是否已经注册过了。
- 2.根据前面检测结果，如果已经注册过了而且描述符号handle为0时，就更改该服务的描述符，反之就申请一个新struct svcinfo对象。
- 3.上面都成功执行后，通过binder_acquire()增加camera服务的引用计数(已经注册到service_manage中了,引用计数要+1)，请看下面源码。
- 4.注册死亡处理函数，当服务死亡时要回收一些东东。
5.binder_acquire()
void binder_acquire(struct binder_state *bs, uint32_t target){ uint32_t cmd[2]; cmd[0] = BC_ACQUIRE; //命令 cmd[1] = target; //该参数就是上面的handle，(即binder_ref->desc) binder_write(bs, cmd, sizeof(cmd)); //这个函数在之前我们就分析过了，它的作用只是向kernel写入命令和数据，不会读取消息，我们直接进到kernel分析。}上面就是打包了一下通信数据。即将包含了命令和处理对象的handle下发给kernle，下面我们直接看处理消息的地方。
6.binder_thread_write（）
int binder_thread_write(struct binder_proc *proc, struct binder_thread *thread, void __user *buffer, int size, signed long *consumed){ uint32_t cmd; void __user *ptr = buffer + *consumed; void __user *end = buffer + size; while (ptr < end && thread->return_error == BR_OK) { if (get_user(cmd, (uint32_t __user *)ptr)) //第一个获取的先是命令参数BC_ACQUIRE return -EFAULT; ptr += sizeof(uint32_t); trace_binder_command(cmd); if (_IOC_NR(cmd) < ARRAY_SIZE(binder_stats.bc)) { binder_stats.bc[_IOC_NR(cmd)]++; proc->stats.bc[_IOC_NR(cmd)]++; thread->stats.bc[_IOC_NR(cmd)]++; } switch (cmd) { case BC_INCREFS: case BC_ACQUIRE: //需处理的是这一条命令 case BC_RELEASE: case BC_DECREFS: { uint32_t target; struct binder_ref *ref; const char *debug_string; if (get_user(target, (uint32_t __user *)ptr)) //这是获取到handle参数(camera服务对象的handle)，而且是非0 return -EFAULT; ptr += sizeof(uint32_t); //buffer数据已经取出，位置指针移动 if (target == 0 && binder_context_mgr_node && //这里target肯定不是0，因为只有service_manager的binder_ref->desc才是0,所以这里是假 (cmd == BC_INCREFS || cmd == BC_ACQUIRE)) { ref = binder_get_ref_for_node(proc, binder_context_mgr_node); if (ref->desc != target) { binder_user_error("binder: %d:" "%d tried to acquire " "reference to desc 0, " "got %d instead\n", proc->pid, thread->pid, ref->desc); } } else ref = binder_get_ref(proc, target); //会执行这里，明显是在service_manager的binder_proc查找该handle对应的binder_ref对象 if (ref == NULL) { //之前已经创建该binder_ref对象而且已经插入到service_manager的binder_proc中，所以这里会找到相应的引用对象。 binder_user_error("binder: %d:%d refcou" "nt change on invalid ref %d\n", proc->pid, thread->pid, target); break; } switch (cmd) { case BC_INCREFS: debug_string = "IncRefs"; binder_inc_ref(ref, 0, NULL); break; case BC_ACQUIRE: //下面就要增加binder_ref的强引用计数了。 debug_string = "Acquire"; binder_inc_ref(ref, 1, NULL); //这里就是为了+1.请看下面是怎么+1的。 break;...}//---------------------增加强引用代码------------------------static int binder_inc_ref(struct binder_ref *ref, int strong, struct list_head *target_list){ int ret; if (strong) { //上面可以看到strong传进来的是1， if (ref->strong == 0) { //第一次，所以为0 ret = binder_inc_node(ref->node, 1, 1, target_list); //增加该binder_ref对应的binder_node强引用计数，这里就不贴代码了。感兴趣的自己查阅源码 if (ret) return ret; } ref->strong++; //这里增加强引用计数 } else { if (ref->weak == 0) { ret = binder_inc_node(ref->node, 0, 1, target_list); if (ret) return ret; } ref->weak++; //反之增加弱引用计数 } return 0;}上面的这条BC_ACQUIRE消息意义只有下面这两条处理过程。
- 1.根据handle增加挂在service_manger进程binder_proc对象下面响应binder_ref强引用计数。标示已经有人开始引用你了，确实我们已经在service_manager user空间引用了。
- 2.增加上一步binder_ref对应binder_node响应的引用计数。
7.binder_link_to_death()
void binder_link_to_death(struct binder_state *bs, uint32_t target, struct binder_death *death){ struct { uint32_t cmd; struct binder_handle_cookie payload; } __attribute__((packed)) data; data.cmd = BC_REQUEST_DEATH_NOTIFICATION; //注意这个命令 data.payload.handle = target; //唯一标示一个binder_ref对象的handle，(即binder_ref->desc) data.payload.cookie = (uintptr_t) death; //死亡通知对象 binder_write(bs, &data, sizeof(data));}注意上面的target参数就是camera服务的handle（binder_ref->desc,通过这个找到camera引用对象，进而找到camera服务）。此函数也是打包注册服务死亡处理函数。然后将命令发给kernel。具体请看下面操作。
int binder_thread_write(struct binder_proc *proc, struct binder_thread *thread, binder_uintptr_t binder_buffer, size_t size, binder_size_t *consumed){... case BC_REQUEST_DEATH_NOTIFICATION: case BC_CLEAR_DEATH_NOTIFICATION: {... ref = binder_get_ref(proc, target); //找到camera服务在service_manger中的binder_ref对象。 if (ref == NULL) {... break; } if (cmd == BC_REQUEST_DEATH_NOTIFICATION) { if (ref->death) {//第一次注册死亡通知函数，这里为NULL binder_user_error("%d:%d BC_REQUEST_DEATH_NOTIFICATION death notification already set\n", proc->pid, thread->pid); break; } death = kzalloc(sizeof(*death), GFP_KERNEL);//首先new一个死亡通知引用对象(struct binder_ref_death) if (death == NULL) { thread->return_error = BR_ERROR; binder_debug(BINDER_DEBUG_FAILED_TRANSACTION, "%d:%d BC_REQUEST_DEATH_NOTIFICATION failed\n", proc->pid, thread->pid); break; } binder_stats_created(BINDER_STAT_DEATH); INIT_LIST_HEAD(&death->work.entry); death->cookie = cookie;//将死亡处理函数，绑定对应的地方。 ref->death = death;//当前camera的binder_ref,绑定死亡处理函数。 if (ref->node->proc == NULL) {//......此处省略很多代码，都是再次确认一些参数是否是有效的，我们知道死亡通知注册过来就行了。 } break;当service注册一个服务之后，service_manager也会注册死亡通知对象，用于在camera出现异常时，给其它代理对象一个交代。希望通知是在new camera服务对象时，一起传过来的。
三、ServiceManager返回处理结果
1.binder_parse()后处理
int binder_parse(struct binder_state *bs, struct binder_io *bio, uintptr_t ptr, size_t size, binder_handler func){ ...... case BR_TRANSACTION: { struct binder_transaction_data *txn = (struct binder_transaction_data *) ptr; //注意kernel传过来的是binder_transaction_data类型的数据。 if ((end - ptr) < sizeof(*txn)) { ALOGE("parse: txn too small!\n"); return -1; } binder_dump_txn(txn); if (func) {...... res = func(bs, txn, &msg, &reply); //这里会往reply数据缓冲区中添数据。我们进去看看,func = svcmgr_handler binder_send_reply(bs, &reply, txn->data.ptr.buffer, res); //这个才是最后发送返回数据。res = 0 } ptr += sizeof(*txn); break; }......}-----------------------------------------------------------------//上面的func 函数指着就是下面的svcmgr_handler。int svcmgr_handler(struct binder_state *bs, struct binder_transaction_data *txn, struct binder_io *msg, struct binder_io *reply){...... switch(txn->code) { case SVC_MGR_ADD_SERVICE: s = bio_get_string16(msg, &len); if (s == NULL) { return -1; } handle = bio_get_ref(msg); allow_isolated = bio_get_uint32(msg) ? 1 : 0; if (do_add_service(bs, s, len, handle, txn->sender_euid, allow_isolated, txn->sender_pid)) return -1; break;......} bio_put_uint32(reply, 0); //在上面的addservice操作中，没有对reply对象操作。} 上面的代码上面已经介绍过，这里只是为了分析连贯性，再贴出一遍。add_service()操作处理完之后，就会将处理结果返回给media_server进程了。跳出switch case后，就是bio_put_uint32(reply, 0);
void bio_put_uint32(struct binder_io *bio, uint32_t n)//注意n = 0；{ uint32_t *ptr = bio_alloc(bio, sizeof(n)); //字面是数据申请，其实是数据记录指针偏移，这里申请4个字节。 if (ptr) *ptr = n; //这里将0保存到数据的开始位置，如下图所示。}static void *bio_alloc(struct binder_io *bio, size_t size)//紧接着上面的size = 4；{ size = (size + 3) & (~3); //size = 4 byte，而且4字节对齐。 if (size > bio->data_avail) { bio->flags |= BIO_F_OVERFLOW; return NULL; } else { void *ptr = bio->data; //得到可用数据其实地址 bio->data += size; //可用数据记录指针移动4个字节，即data+4 bio->data_avail -= size; //可用数据大小要减少4个字节 return ptr; //返回可用buffer首地址 }}上面的操作只是在缓冲区中添加了一个0，且相应的移动记录指针也移动+4了，目前还没有binder对象，偏移数组都是0。然后我们就回到binder_parse()函数中的binder_send_reply()
2.binder_send_reply()-回复数据打包
void binder_send_reply(struct binder_state *bs, struct binder_io *reply, binder_uintptr_t buffer_to_free, int status) //status 是上一次操作的返回值，这里=0；{ struct { uint32_t cmd_free; binder_uintptr_t buffer; uint32_t cmd_reply; struct binder_transaction_data txn; } __attribute__((packed)) data; //重新打包一个临时一个结构体 data.cmd_free = BC_FREE_BUFFER; //释放命令 data.buffer = buffer_to_free; //要释放的binder_buffer地址 data.cmd_reply = BC_REPLY; //回复命令，这里是media_Server data.txn.target.ptr = 0; //注意 ptr = 0 ，即sm data.txn.cookie = 0; //注意 cookie = 0 ，即sm data.txn.code = 0; if (status) { //由上面的调用结果可知，这里status = 0 data.txn.flags = TF_STATUS_CODE; data.txn.data_size = sizeof(int); data.txn.offsets_size = 0; data.txn.data.ptr.buffer = (uintptr_t)&status; data.txn.data.ptr.offsets = 0; } else { data.txn.flags = 0; data.txn.data_size = reply->data - reply->data0; //结合上面的图，这里数据大小是4，即之前存入的那个0 data.txn.offsets_size = ((char*) reply->offs) - ((char*) reply->offs0); //这里没有binder对象，所以binder对象数量= 0 data.txn.data.ptr.buffer = (uintptr_t)reply->data0; //buffer的起始位置 data.txn.data.ptr.offsets = (uintptr_t)reply->offs0;//偏移数组的起始位置 } binder_write(bs, &data, sizeof(data)); //又到了我们熟悉的写数据函数，}上面的打包的binder_transaction_data 数据内容很简单，这里我们就不罗列出数据结构图了。这里主要做的就是打包二个BC_FREE_BUFFER，BC_REPLY，以及记录当前发送数据的格式。我们可以不用态关心这里，只需要知道是那回事就好了。下面直接进kernel看看。
这里为了直观看得清晰，上面就列成表格的形式，来记录下数据的保存形式。
3.binder_thread_write()-释放binder_buffer和写回复数据
int binder_thread_write(struct binder_proc *proc, struct binder_thread *thread, binder_uintptr_t binder_buffer, size_t size, binder_size_t *consumed){......case BC_FREE_BUFFER: { binder_uintptr_t data_ptr; struct binder_buffer *buffer; if (get_user(data_ptr, (binder_uintptr_t __user *)ptr)) //获取上面打包的事务数据中要释放的binder_buffer用户空间地址 return -EFAULT; ptr += sizeof(binder_uintptr_t);//数据指针移动 buffer = binder_buffer_lookup(proc, data_ptr);//获取到binder_buffer地址 //这里根据binder_buffer用户空间地址，找到kernel对应的地址，紧接着就会释放当前binder_buffer. if (buffer == NULL) { binder_user_error("%d:%d BC_FREE_BUFFER u%016llx no match\n", proc->pid, thread->pid, (u64)data_ptr); break; } if (!buffer->allow_user_free) { //如果不允许用户空间释放的话，这里就直接就break。 binder_user_error("%d:%d BC_FREE_BUFFER u%016llx matched unreturned buffer\n", proc->pid, thread->pid, (u64)data_ptr); break; } binder_debug(BINDER_DEBUG_FREE_BUFFER, "%d:%d BC_FREE_BUFFER u%016llx found buffer %d for %s transaction\n", proc->pid, thread->pid, (u64)data_ptr, buffer->debug_id, buffer->transaction ? "active" : "finished"); if (buffer->transaction) { buffer->transaction->buffer = NULL; buffer->transaction = NULL; } if (buffer->async_transaction && buffer->target_node) { BUG_ON(!buffer->target_node->has_async_transaction); if (list_empty(&buffer->target_node->async_todo)) buffer->target_node->has_async_transaction = 0; else list_move_tail(buffer->target_node->async_todo.next, &thread->todo); } trace_binder_transaction_buffer_release(buffer); binder_transaction_buffer_release(proc, buffer, NULL); binder_free_buf(proc, buffer); break; } case BC_TRANSACTION: case BC_REPLY: {//第二次循环走到这里 struct binder_transaction_data tr; if (copy_from_user(&tr, ptr, sizeof(tr))) //拷贝出sm用户空间传下来的事务数据。 return -EFAULT; ptr += sizeof(tr); //移动记录指针 binder_transaction(proc, thread, &tr, cmd == BC_REPLY); //注意当前cmd = BC_REPLY，大家要注意了，此时此刻传进去的thread = service_Manager主线程。 break; }......}上面我们知道这里处理2个命令。
- 1.首先先处理的是BC_FREE_BUFFER，在释放binder_buffer时，因为传下来的是用户空间的地方，所以需要将地址转换成kernel空间的虚拟地址。由于前面我们已经说过，用户空间的地方和kernel空间的虚拟地址，相差一个固定的值，所以在
binder_buffer_lookup中直接根据地址减去一个固定值就得到了kernel空间的虚拟地址。 - 2.主要关注最后一组参数
binder_transaction(proc, thread, &tr, cmd == BC_REPLY);
这里上面就做了释放binder_buffer，和给media_server回复
4.binder_transaction()-回复事务数据处理
static void binder_transaction(struct binder_proc *proc, struct binder_thread *thread, struct binder_transaction_data *tr, int reply){......if (reply) { //replay = 1； in_reply_to = thread->transaction_stack; //大家一定要转变过来，此时的thread = service_manager主线程。还记得在上面的media_server发送给 //service_manager的事务吗，目前该事务仍在service_manager事务栈的顶端，所以根据这个事务， //service_manager主线程就可以找到发送事务的进程和线程，这样才能发送回复消息给它们。 if (in_reply_to == NULL) { binder_user_error("%d:%d got reply transaction with no transaction stack\n", proc->pid, thread->pid); return_error = BR_FAILED_REPLY; goto err_empty_call_stack; } binder_set_nice(in_reply_to->saved_priority); if (in_reply_to->to_thread != thread) { //显然上一个事务是发送给service_manager进程主线程，而thread 就是sm主线程，这里为假。 binder_user_error("%d:%d got reply transaction with bad transaction stack, transaction %d has target %d:%d\n", proc->pid, thread->pid, in_reply_to->debug_id, in_reply_to->to_proc ? in_reply_to->to_proc->pid : 0, in_reply_to->to_thread ? in_reply_to->to_thread->pid : 0); return_error = BR_FAILED_REPLY; in_reply_to = NULL; goto err_bad_call_stack; } thread->transaction_stack = in_reply_to->to_parent; //将之前sm主线程中记录的事务，重新安排到事务栈栈顶。 target_thread = in_reply_to->from; //这里由media_server发送给sm的事务，找到发送事务的源端是media_server主线程 if (target_thread == NULL) { return_error = BR_DEAD_REPLY; goto err_dead_binder; } if (target_thread->transaction_stack != in_reply_to) { //之前在media_server进程给sm进程发送事务时，事务也会保存到media_server事务栈栈顶，这里是一样的为假。 binder_user_error("%d:%d got reply transaction with bad target transaction stack %d, expected %d\n", proc->pid, thread->pid, target_thread->transaction_stack ? target_thread->transaction_stack->debug_id : 0, in_reply_to->debug_id); return_error = BR_FAILED_REPLY; in_reply_to = NULL; target_thread = NULL; goto err_dead_binder; } target_proc = target_thread->proc; //这里找到了media_server进程的binder_proc对象 } else {....... } if (target_thread) {//media_server进程肯定不为NULL e->to_thread = target_thread->pid; //media_server主线程pid target_list = &target_thread->todo; //media_server主线程任务队列 target_wait = &target_thread->wait; //media_server主线程等待队列 } else { target_list = &target_proc->todo; target_wait = &target_proc->wait; } /* TODO: reuse incoming transaction for reply */ t = kzalloc(sizeof(*t), GFP_KERNEL); //分配事务数据buffer tcomplete = kzalloc(sizeof(*tcomplete), GFP_KERNEL);...... t->sender_euid = proc->tsk->cred->euid; t->to_proc = target_proc; //记录media_server进程binder_proc对象 t->to_thread = target_thread; //记录media_server进程主线程对象 t->code = tr->code; //这里=0，组要要根据上面的表格对比。 t->flags = tr->flags; //这里= 0 t->priority = task_nice(current); t->buffer = binder_alloc_buf(target_proc, tr->data_size, //在media_server进程的buffer空间中申请binder_buffer,由此可见，事务是发给哪一个进程的，就在哪一个进程的buffer中申请binder_buffer. tr->offsets_size, !reply && (t->flags & TF_ONE_WAY)); if (t->buffer == NULL) { return_error = BR_FAILED_REPLY; goto err_binder_alloc_buf_failed; } t->buffer->allow_user_free = 0; //不允许用户空间释放buffer t->buffer->debug_id = t->debug_id; t->buffer->transaction = t; t->buffer->target_node = target_node; //回复消息时，target_node 始终为NULL. //......这里有一些查找binder对象的操作，由于从上面了sm发送下来的数据知道，目前我们没有binder对象，这里就省略了，同时也为了代码的简洁性。 if (reply) { //为真 BUG_ON(t->buffer->async_transaction != 0); binder_pop_transaction(target_thread, in_reply_to); //这里会根据in_reply_to 事务数据找到media_server主线程之前在栈顶的事务。 } else if (!(t->flags & TF_ONE_WAY)) { BUG_ON(t->buffer->async_transaction != 0); t->need_reply = 1; t->from_parent = thread->transaction_stack; thread->transaction_stack = t; } else { BUG_ON(target_node == NULL); BUG_ON(t->buffer->async_transaction != 1); if (target_node->has_async_transaction) { target_list = &target_node->async_todo; target_wait = NULL; } else target_node->has_async_transaction = 1; } t->work.type = BINDER_WORK_TRANSACTION; //事务工作项 list_add_tail(&t->work.entry, target_list);//将工作项添加到media_server进程的工作队列中 tcomplete->type = BINDER_WORK_TRANSACTION_COMPLETE; //返回给service_manager进程BINDER_WORK_TRANSACTION_COMPLETE消息。 list_add_tail(&tcomplete->entry, &thread->todo); //将该工作项BINDER_WORK_TRANSACTION_COMPLETE添加到service_manager进程的工作队列中。 if (target_wait) //media_server的等待队列不为空。 wake_up_interruptible(target_wait); //这里就唤醒了media_server进程了。 return;//上面的代码虽然我们之前也介绍过，但是这里的目的端已经切换成media_server进程了。static void binder_pop_transaction(struct binder_thread *target_thread, struct binder_transaction *t){ if (target_thread) { BUG_ON(target_thread->transaction_stack != t); BUG_ON(target_thread->transaction_stack->from != target_thread); target_thread->transaction_stack = target_thread->transaction_stack->from_parent; //这里根据事务t，找到media_server进程之前事务栈中的事务。因此我们可以对事务栈做个总结了。 t->from = NULL; } t->need_reply = 0; if (t->buffer) t->buffer->transaction = NULL; kfree(t); //释放该事务。 binder_stats_deleted(BINDER_STAT_TRANSACTION);}说到这里，不得不讲一下transaction_statck的用处。
我们知道事务处理是有先后顺序的，这里在事务的数据结构中加了一个from_parent和to_parent结构就是来记录这个先后顺序的。如下所示，有了下面两个域就可以在这个事务处理完毕之后，还原发送和接收端进程的事务堆栈，以让他们继续处理。
- 1.from_parent:记录来自发送事务消息的进程，事务堆栈中的事务消息(这里发送发送的事务就是in_reply_to)。
- 2.to_parent:记录来自事务接受端进程事务堆栈中的消息。
这里介绍一下上图中的流程信息(这里假设中间事务为A)。
- 1.在media_server 发送事务A给service_manager时，media_server的事务堆栈信息B，就会保存在事务A的from_parent域。
- 2.同时当media_server唤醒service_manager进程时，sm进程读取事务信息时，会将自己的transaction_stack中的数据保存在事务A的to_parent域。
- 3&4. media_server发送事务给service_manager进程时，media_server和service_manager进程的事务堆栈都会保存当前即将要处理的事务A
- 5&6. service_manager进程处理完add_service请求之后，将处理结果返回给media_server进程时，由sm之前处理的事务A中，找到media_server和service_manager事务堆栈中要处理的事务，并分别赋给他们的transaction_statck域。
(表达能力有限，不知道写明白了没)
5.binder_thread_read(来到media_server进程的waitForResponse())
static int binder_thread_read(struct binder_proc *proc, struct binder_thread *thread, void __user *buffer, int size, signed long *consumed, int non_block){ void __user *ptr = buffer + *consumed; void __user *end = buffer + size; int ret = 0; int wait_for_proc_work; if (*consumed == 0) { //media_server刚开始的时候*consumed = 0. if (put_user(BR_NOOP, (uint32_t __user *)ptr)) //所以这里会将BR_NOOP命令保存到缓冲区中 return -EFAULT; ptr += sizeof(uint32_t); } if (wait_for_proc_work) {...... if (non_block) { if (!binder_has_proc_work(proc, thread)) ret = -EAGAIN; } else ret = wait_event_freezable_exclusive(proc->wait, binder_has_proc_work(proc, thread)); //media_server就是这被睡眠了，与此同时醒来时也是在这里站起来的。 }...... while (1) { switch (w->type) { case BINDER_WORK_TRANSACTION: { //还记得上面唤醒media_server发的就是这个命令吧。 t = container_of(w, struct binder_transaction, work); //找到事务的数据 } break; ...... } if (!t) continue; BUG_ON(t->buffer == NULL); if (t->buffer->target_node) { //之前已经说过了，在反馈binder进程间通信时，target_node都是为NULL。 //....... } else { tr.target.ptr = NULL; tr.cookie = NULL; cmd = BR_REPLY; //返回回去的是BR_REPLY } tr.code = t->code; //这里为0 tr.flags = t->flags; //为0 tr.sender_euid = t->sender_euid; tr.data_size = t->buffer->data_size; //有效数据的大小 tr.offsets_size = t->buffer->offsets_size; //biner对象的个数，这里为0. tr.data.ptr.buffer = (void *)t->buffer->data + //这里buffer的初始地址，已经是用户空间的了。 proc->user_buffer_offset; tr.data.ptr.offsets = tr.data.ptr.buffer + //binder偏移数组的起始位置。 ALIGN(t->buffer->data_size, sizeof(void *)); if (put_user(cmd, (uint32_t __user *)ptr)) //将BR_REPLY命令保存到缓冲区中 return -EFAULT; ptr += sizeof(uint32_t); if (copy_to_user(ptr, &tr, sizeof(tr))) //将事务数据都打包到缓冲区中。 return -EFAULT; ptr += sizeof(tr); //缓冲区记录指针移动 list_del(&t->work.entry); //删除servie_manager发送给media_server的事务 t->buffer->allow_user_free = 1; //允许用户释放binder_buffer. if (cmd == BR_TRANSACTION && !(t->flags & TF_ONE_WAY)) { //cmd = BR_RELY t->to_parent = thread->transaction_stack; t->to_thread = thread; thread->transaction_stack = t; } else { t->buffer->transaction = NULL; kfree(t); //释放已经处理过的事务数据。 binder_stats_deleted(BINDER_STAT_TRANSACTION);//增加统计信息 }上面主要是数据的打包过程，这个时候返回给media_server进程用户空间的数据分布如下。
四、Media_Server梦开始的地方main()
在上面我们已经画出mediaServer即将要处理的消息内容了，但是为了查看方便，有些代码还是在贴一遍吧。这一小结主要分析mediaServer拿到通信数据后，做了什么。
1.MediaServer-main()
void main(){ sp<ProcessState> proc(ProcessState::self()); MediaLogService::instantiate(); ProcessState::self()->startThreadPool(); //启动线程池。..... CameraService::instantiate(); //注册camera服务..... ProcessState::self()->startThreadPool(); //启动线程池，前面已经启动过了，这里多此一举 IPCThreadState::self()->joinThreadPool();//当前主线程加入线程池}还记着开始的时候，CameraService::instantiate()就是调用的IPCThreadState::transact()方法，向service_manager进程注册camera服务的。我们接着这个函数，看看它如何处理service_manager进程反馈回来的消息。如果不明白为什么走这里，请看前面一开始ADD_SERVICE请求发出的地方。
status_t IPCThreadState::transact(int32_t handle, uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){........ if (err == NO_ERROR) { LOG_ONEWAY(">>>> SEND from pid %d uid %d %s", getpid(), getuid(), (flags & TF_ONE_WAY) == 0 ? "READ REPLY" : "ONE WAY"); err = writeTransactionData(BC_TRANSACTION, flags, handle, code, data, NULL); //这里是请求service_manager添加camera服务数据。 }...... if (reply) { err = waitForResponse(reply);//这里会等待service_manager反馈回来的数据。即这里是一个while(1)循环。 } else { Parcel fakeReply; err = waitForResponse(&fakeReply); }}后面注册服务都是走的上面的流程，先发出请求，然后等待service_manger进程反馈处理结果。
2.media_server的等待waitForResponse()
status_t IPCThreadState::waitForResponse(Parcel *reply, status_t *acquireResult){ int32_t cmd; int32_t err; while (1) { if ((err=talkWithDriver()) < NO_ERROR) break; //talkWithDriver()意义就是读写binder通信数据，这里是读取的操作。 err = mIn.errorCheck(); if (err < NO_ERROR) break; if (mIn.dataAvail() == 0) continue; cmd = mIn.readInt32();//根据之前我画的service_manager反馈过来的数据分布图，可以知道，这里第一个是BR_NOOP. switch (cmd) { case BR_REPLY: { binder_transaction_data tr; err = mIn.read(&tr, sizeof(tr)); //从min数据对象中读出事务数据。 ALOG_ASSERT(err == NO_ERROR, "Not enough command data for brREPLY"); if (err != NO_ERROR) goto finish; if (reply) { if ((tr.flags & TF_STATUS_CODE) == 0) { //还记着我们之前画的数据map吗，这里flags = 0，TF_STATUS_CODE = 0x08,所以这里为真，标示之前的请求已经成功处理掉了。 reply->ipcSetDataReference( //这个方法，就是把返回到用户空间的事务数据打包到reply对象中。 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, this); } else { //....... } } else { //....... } } goto finish; //最后会走到这里跳出while(1)循环。 default: err = executeCommand(cmd); //BR_NOOP命令就是在这里处理的。 if (err != NO_ERROR) goto finish; break; return err;}该方法就像它的名字那样，它会等待在那里，其实主线程在kernel中休眠了，不等也没办法了。它的处理简单就下面两步。
- 1.BR_NOOP:该消息走的default项，什么也没做直接返回的。(不信你可以进去看看)
- 2.BR_REPLY:这是真正的sm发送过来处理结果数据。如果tr.flags 不等于TF_STATUS_CODE说明请求成功了。
3.void Parcel::ipcSetDataReference（）
void Parcel::ipcSetDataReference(const uint8_t* data, size_t dataSize, const binder_size_t* objects, size_t objectsCount, release_func relFunc, void* relCookie){ binder_size_t minOffset = 0; freeDataNoInit(); mError = NO_ERROR; mData = const_cast<uint8_t*>(data); //这是有4个字节的buffer。且存放的数据是0 mDataSize = mDataCapacity = dataSize; //之前申请的大小就是4个字节。 //ALOGI("setDataReference Setting data size of %p to %lu (pid=%d)", this, mDataSize, getpid()); mDataPos = 0; ALOGV("setDataReference Setting data pos of %p to %zu", this, mDataPos); mObjects = const_cast<binder_size_t*>(objects); //binder对象其实地址 mObjectsSize = mObjectsCapacity = objectsCount; //binder对象的个数。 mNextObjectHint = 0; mOwner = relFunc; //释放内存的函数，后面我们就不进行了。 mOwnerCookie = relCookie; for (size_t i = 0; i < mObjectsSize; i++) { binder_size_t offset = mObjects[i]; if (offset < minOffset) { ALOGE("%s: bad object offset %"PRIu64" < %"PRIu64"\n", __func__, (uint64_t)offset, (uint64_t)minOffset); mObjectsSize = 0; break; } minOffset = offset + sizeof(flat_binder_object); } scanForFds();}上面做的工作只是将事务数据分别安放到当前Parcel对象的相应位置。其中scanForFds（）是为了查找返回来的数据中是否有binder对象，这个在获取代理对象时有用。下面我们回到刚开始addService（）函数中。
4.返回到addService()
virtual status_t addService(const String16& name, const sp<IBinder>& service, bool allowIsolated) { Parcel data, reply; data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor()); data.writeString16(name); data.writeStrongBinder(service); data.writeInt32(allowIsolated ? 1 : 0); status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);//这个处理过程就是在IPCThreadState.cpp中的transact方法中处理。 return err == NO_ERROR ? reply.readExceptionCode() : err;//返回NO_ERROR成功执行了。 }到这里我们addService总算分析完了，下面做个简要总结。
五、总结
下面以一个简单流程图，来结束本篇博文。博文中有些细节方面东西，如果不是做binder驱动的，只需要了解就行了，不要太深入研究。在实际开发中只要会用就行了。
阅读全文
0 0
- Android Binder学习(四)之addService流程分析
- Binder学习之addService
- Android Binder基本概念流程学习
- Binder学习笔记（六）—— binder服务端是如何组织addService数据的？
- Android Binder学习(三)之defaultServiceManager()的分析
- android之Binder设计分析
- Android之Binder设计分析
- android framwork 分析之binder
- addService实例分析
- Binder学习笔记（七）—— ServiceManager如何响应addService请求 ？
- Android内核学习之Binder
- Android Binder 通信机制学习（四）
- Binder通信流程分析
- Linux 路由 学习笔记 之四 路由删除流程分析
- Android Camera fw学习(四)-recording流程分析
- Android PackageManagerService流程详细分析（四）之权限
- Binder基本概念流程学习
- Binder基本概念流程学习
- 平凡的世界——杜梨树下的约定
- unity transform的position和localPosition属性的区别
- 17 容器深入研究
- 【涨姿势】关闭子窗口的同时刷新父窗口
- 【TCP/IP】(一)、网络基础知识
- Android Binder学习(四)之addService流程分析
- 最长回文子串长度
- windows 7环境python2.7安装paramiko模块
- TCP之Delay Ack和Nagle算法
- A*算法之旅之初识A*算法（一）
- VLC rtsp服务分割/打包HEVC(h265)
- C语言中的位运算
- tcp协议系列文章（1）：提纲挈领
- elasticsearch基础
