Binder机制作为android系统IPC（Inter-Process Communication，进程间通信）的主要方式，理解Binder机制至关重要。首先简要介绍IPC的个人理解。IPC的概念是随进程产生而产生的，在操作系统相关知识中，进程代表资源管理单位，每个进程享有独立的内存空间，两个不同的进程之间不能直接互相访问内存，这是因为不同的进程可能来自不同的开发者，为了提高系统安全性而做出的“隔离”。但是某些特定情况下，仍然需要进行进程之间的数据交换，比如Android系统中，普通应用程序利用Intent可以跳转到拨打电话应用程序，而电话号码则需要从当前应用程序传输到拨打电话应用程序，为了适应类似情况，诞生了各种IPC方式，从而实现进程间的数据交换。常见的IPC通讯方式有管道(pipe)、共享内存、内存映射、信号量（semaphore）、套接字（Socket）等，而Binder同样属于一种IPC形式。
Binder机制贯穿Android系统各个层面，逻辑相对复杂。首先简要介绍Binder机制中的各个角色，为了便于理解，类比“淘宝购物”流程各个角色。

- ServiceManager(SM): 服务提供者的管理者，即XXXManagerService的管理者。可以理解为“淘宝网站”。
- Binder驱动：ServiceManager、XXXManaagerService的中转站。可以理解为“淘宝网站”的“服务器”
- XXXManagerService: 服务提供者。可以理解解为“淘宝卖家”
- client： 应用程序，或者其他需要使用服务的组件。可以理解为“买家”。

  场景再现：每一个“服务提供者”（淘宝卖家）为了给Client(买家)提供服务，都会先去找“ServiceManager”(淘宝网站)进行注册，然后等待Client(买家)的访问,Client(买家)请求服务（买东西），都会先找“ServiceManager”(淘宝网站)查找想要的“XXXManagerService”（淘宝卖家），找到以后，在Binder驱动(“淘宝网站”的“服务器”)中进行申请服务(下单、付款)，而后“XXXManagerService”（淘宝卖家）实现申请的服务（发货）。
Binder机制中的各个角色相对复杂，如果仍不能理解的话，只需对各个角色有印象即可，随着文章对各个角色代码执行流程的分析，相信能对Binder机制有深刻的理解。
本文将首先介绍第一角色“ServiceManager”，如果类比“淘宝网站”，ServiceManager应该在Android系统开机时就要开始工作，并且一直处于运行状态。那ServiceManager是如何启动的呢？下面将从ServiceManager进程main函数开始，直到ServiceManager处于正常运行状态，进行代码执行流程分析。

  注意：此处使用android-4.0.1_r1系统源码，不同版本系统源码结构大同小异

step1

int main(int argc, char **argv)
{//binder状态结构体struct binder_state *bs;//值为0的宏定义void *svcmgr = BINDER_SERVICE_MANAGER;//打开binder驱动bs = binder_open(128*1024);//将当前进程注册为"大管家"if (binder_become_context_manager(bs)) {LOGE("cannot become context manager (%s)\n", strerror(errno));return -1;}svcmgr_handle = svcmgr;//进入循环binder_loop(bs, svcmgr_handler);return 0;
}

位置：frameworks/base/cmds/servicemanager/service_manager.c
servicemanager作为标准的c语言程序，android系统开机时启动，此时执行main函数，servicemanager开始启动。
主函数主要做了三件事:1.打开binder驱动；2.将当前进程注册为“大管家”；3.进入循环，等待其他进程访问。
接下来将进入相应函数继续分析代码。

step2

struct binder_state *binder_open(unsigned mapsize)
{struct binder_state *bs;bs = malloc(sizeof(*bs));//检查错误if (!bs) {errno = ENOMEM;return 0;}//打开binder驱动bs->fd = open("/dev/binder", O_RDWR);if (bs->fd < 0) {fprintf(stderr,"binder: cannot open device (%s)\n",strerror(errno));goto fail_open;}//内存映射大小bs->mapsize = mapsize;//映射内存bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);//检查错误if (bs->mapped == MAP_FAILED) {fprintf(stderr,"binder: cannot map device (%s)\n",strerror(errno));goto fail_map;}/* TODO: check version */return bs;//映射内存错误处理
fail_map:close(bs->fd);//打开驱动错误处理
fail_open:free(bs);return 0;
}

位置：frameworks/base/cmds/servicemanager/binder.c
首先分析servicemanager主函数第一步:打开binder驱动。对应binder_open函数。
binder_open函数主要做了两件事:1.向内核请求打开binder驱动；2.给当前进程映射内存
open函数打开binder驱动，该函数是内核中binder驱动提供的函数，接下里将进入内核中的binder驱动分析open函数的调用。

step3

static int binder_open(struct inode *nodp, struct file *filp)
{   //创建binder_proc结构体struct binder_proc *proc;binder_debug(BINDER_DEBUG_OPEN_CLOSE, "binder_open: %d:%d\n",current->group_leader->pid, current->pid);//创建结构体proc = kzalloc(sizeof(*proc), GFP_KERNEL);if (proc == NULL)return -ENOMEM;//初始化binder_proc结构体get_task_struct(current);proc->tsk = current;INIT_LIST_HEAD(&proc->todo);init_waitqueue_head(&proc->wait);proc->default_priority = task_nice(current);//加锁mutex_lock(&binder_lock);binder_stats_created(BINDER_STAT_PROC);hlist_add_head(&proc->proc_node, &binder_procs);proc->pid = current->group_leader->pid;INIT_LIST_HEAD(&proc->delivered_death);//将binder_proc结构体保存在filp的private_data中，以便以后使用filp->private_data = proc;mutex_unlock(&binder_lock);if (binder_debugfs_dir_entry_proc) {char strbuf[11];snprintf(strbuf, sizeof(strbuf), "%u", proc->pid);proc->debugfs_entry = debugfs_create_file(strbuf, S_IRUGO,binder_debugfs_dir_entry_proc, proc, &binder_proc_fops);}return 0;
}

位置：drivers/staging/android/binder.c
首先创建了一个binder_proc结构体，并将结构体中的变量进行了一系列的初始化。最后将该结构体保存在文件filp中。此处文件filp可以理解为当前进程的PCB(进程控制块PCB)，它将进程的信息存储到文件中。下面将解释结构体binder_proc的部分变量，以便后续代码分析。

struct binder_proc {struct hlist_node proc_node;struct rb_root threads;struct rb_root nodes;struct rb_root refs_by_desc;struct rb_root refs_by_node;int pid;struct vm_area_struct *vma;struct task_struct *tsk;struct files_struct *files;struct hlist_node deferred_work_node;int deferred_work;void *buffer;ptrdiff_t user_buffer_offset;struct list_head buffers;struct rb_root free_buffers;struct rb_root allocated_buffers;size_t free_async_space;struct page **pages;size_t buffer_size;uint32_t buffer_free;struct list_head todo;wait_queue_head_t wait;struct binder_stats stats;struct list_head delivered_death;int max_threads;int requested_threads;int requested_threads_started;int ready_threads;long default_priority;struct dentry *debugfs_entry;
};

位置：drivers/staging/android/binder.c
该结构体变量较多，其中threads;nodes;refs_by_desc;refs_by_node;在后续分析中经常出现。threads变量是树结构，存储当前进程中用于处理用户请求的线程信息，此处可以理解为线程控制块(Thread Control Block,TCB)的集合；nodes、refs_by_desc，分别用来保存当前进程中的binder实体集合、引用其他进程中的binder实体集合；refs_by_node也是树结构，和refs_by_desc一样用来保存引用其他进程中的binder实体集合，但是refs_by_desc是句柄值为key，而refs_by_node以binder实体的地址值为key。此处应当注意refs_by_desc中的句柄值尤其重要。

step4

static int binder_mmap(struct file *filp, struct vm_area_struct *vma)
{...struct binder_buffer *buffer;...proc->buffer = area->addr;proc->user_buffer_offset = vma->vm_start - (uintptr_t)proc->buffer;...
}

位置：drivers/staging/android/binder.c
step2中调用的mmap函数同样对应内核中的binder驱动中的binder_mmap函数。此函数主要用于将当前进程中的虚拟内存和内核中的虚拟内存映射在同一块物理内存上，如果此处不理解虚拟内存和物理内存定义，可查阅操作系统相关知识。并且将开辟的共用物理内存分成块纪录struct binder_buffer*中。并且将内核中映射的虚拟内存地址保存在的当前进程binder_proc结构体中的buffer变量；将当前进程中映射的虚拟内存地址相对于buffer变量地址偏移量保存binder_proc中的bufferuser_buffer_offset，这样要用户进程中的虚拟内存地址就等于buffer＋user_buffer_offset。

由于代码较为复杂，不作过多解释，以图示1.1帮助理解。

图示1.1 binder_mmap内存映射示意图

step5

int binder_become_context_manager(struct binder_state *bs)
{return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

位置：frameworks/base/cmds/servicemanager/binder.c
直接调用ioctl函数,ioct函数是内核中binder驱动提供的函数，接下里将进入内核中的binder驱动分析ioctl函数的调用。

代码较长，分段分析

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{int ret;//获取当前进程的binder_procstruct binder_proc *proc = filp->private_data;//定义binder_threadstruct binder_thread *thread;//命令大小unsigned int size = _IOC_SIZE(cmd);//将穿入参数转换为用户空间地址void __user *ubuf = (void __user *)arg;

位置：drivers/staging/android/binder.c
首先获得当前进程的binder_proc，然后定义binder_thread，获得cmd命令大小，并将arg参数转换为用户空间地址指针变量。注意:__user标识表示该指针指向用户空间地址，不能直接拷贝，只能通过copy_from_user，copy_to_user函数拷贝。

    //如果条件满足挂起进程ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);if (ret)return ret;//加锁mutex_lock(&binder_lock);//获取当前线程的binder_thread，如果获取不到就新建一个thread = binder_get_thread(proc);if (thread == NULL) {ret = -ENOMEM;goto err;}

位置：drivers/staging/android/binder.c
wait_event_interruptible函数的作用是检查binder_stop_on_user_error < 2是否是真，如果为真挂起当前进程，否则不挂起。此处明显binder_stop_on_user_error < 2为假，不挂起进程。binder_get_thread函数的作用是获取当前进程的binder_thread，若binder_proc的binder_thread树上没有当前线程则新建一个binder_thread添加到树中并返回，若有则获取并返回。

    switch (cmd) {...case BINDER_SET_CONTEXT_MGR://若binder_context_mgr_node不是空，错误跳转if (binder_context_mgr_node != NULL) {printk(KERN_ERR "binder: BINDER_SET_CONTEXT_MGR already set\n");ret = -EBUSY;goto err;}//若binder_context_mgr_uid不是-1，错误跳转if (binder_context_mgr_uid != -1) {if (binder_context_mgr_uid != current->cred->euid) {printk(KERN_ERR "binder: BINDER_SET_""CONTEXT_MGR bad uid %d != %d\n",current->cred->euid,binder_context_mgr_uid);ret = -EPERM;goto err;}} else//存储当前进程的euidbinder_context_mgr_uid = current->cred->euid;//创建binder_node节点binder_context_mgr_node = binder_new_node(proc, NULL, NULL);//错误检查if (binder_context_mgr_node == NULL) {ret = -ENOMEM;goto err;}//弱引用增加binder_context_mgr_node->local_weak_refs++;//强引用增加binder_context_mgr_node->local_strong_refs++;//标识有强引用binder_context_mgr_node->has_strong_ref = 1;//标识有弱引用binder_context_mgr_node->has_weak_ref = 1;break;

位置：drivers/staging/android/binder.c
此处cmd传入的是BINDER_SET_CONTEXT_MGR，因此只看相关内容。首先检查binder_context_mgr_node和binder_context_mgr_uid有没有设置过，因为“大管家”只能有一个，所以若设置过则做错误处理。此处未设置，执行else内容，将当前进程的euid存储下来。binder_new_node为进程创建一个binder_node，并挂在binder_proc对应的树上。查错后对引用信息进行处理，此处对代码逻辑分析无影响，无做过多解释。

至此binder_become_context_manager函数算是执行完成了，接下来将返回到step1中的main函数分析第三步:进入循环，等待其他进程访问，即binder_loop的执行。

分段阅读

step6

void binder_loop(struct binder_state *bs, binder_handler func)
{int res;//定义binder_write_read结构体struct binder_write_read bwr;unsigned readbuf[32];//初始化binder_write_read结构体bwr.write_size = 0;bwr.write_consumed = 0;bwr.write_buffer = 0;//赋值readbuf[0]为BC_ENTER_LOOPER命令readbuf[0] = BC_ENTER_LOOPER;//写进binderbinder_write(bs, readbuf, sizeof(unsigned));

位置：frameworks/base/cmds/servicemanager/binder.c
首先定义了binder_write_read结构体并初始化，从名字可以看出它是一个负责记录向binder驱动读写内容的结构体，后续将详细介绍它的各个变量的作用。然后用readbuf[0]纪录命令BC_ENTER_LOOPER，并调用函数binder_write，从名字可以猜测，该函数应该是负责向binder驱动中写入内容的。注意此函数并没有用到binder_write_read结构体，只是传入了BC_ENTER_LOOPER命令。下面将进入binder_write函数继续分析。

int binder_write(struct binder_state *bs, void *data, unsigned len)
{//定义binder_write_readstruct binder_write_read bwr;int res;//要写入binder驱动的数据长度,复制为lenbwr.write_size = len;//定义写入的内容已经被消耗了多少bwr.write_consumed = 0;//赋值写入数据bwr.write_buffer = (unsigned) data;//初始化读入信息bwr.read_size = 0;bwr.read_consumed = 0;bwr.read_buffer = 0;//向binder驱动交互res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);if (res < 0) {fprintf(stderr,"binder_write: ioctl failed (%s)\n",strerror(errno));}return res;
}

位置：frameworks/base/cmds/servicemanager/binder.c
进入该函数后，创建了一个binder_write_read：write_size变量代表向binder驱动写入数据的大小，此处为len;write_consumed变量表示写入的数据被消耗了多少，此处当然为0；write_buffer表示要写入的数据；read_size、read_consumed、read_buffer类似,只是它们用来存储读取相关信息。定义好binder_write_read各个变量后同样是进入内核的binder驱动中调用binder_ioctl函数。

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{...switch (cmd) {//若cmd是BINDER_WRITE_READcase BINDER_WRITE_READ: {struct binder_write_read bwr;//检查长度if (size != sizeof(struct binder_write_read)) {ret = -EINVAL;goto err;}//从用户空间拷贝binder_write_read并赋值给bwrif (copy_from_user(&bwr, ubuf, sizeof(bwr))) {ret = -EFAULT;goto err;}binder_debug(BINDER_DEBUG_READ_WRITE,"binder: %d:%d write %ld at %08lx, read %ld at %08lx\n",proc->pid, thread->pid, bwr.write_size, bwr.write_buffer,bwr.read_size, bwr.read_buffer);//若bwr.write_size > 0if (bwr.write_size > 0) {//执行binder_thread_writeret = binder_thread_write(proc, thread, (void __user *)bwr.write_buffer, bwr.write_size, &bwr.write_consumed);

位置：drivers/staging/android/binder.c
此次调用switch语句前内容和step5一致，只有case语句执行内容不同，因此着重看switch语句内容。因ioctl函数传入BINDER_WRITE_READ，因此执行case BINDER_WRITE_READ内容。首先将ubuf中传入的binder_write_read通过copy_from_user函数从用户空间复制到内核空间中并存在binder_write_read bwr中。然后检查是否bwr.write_size > 0，此处为真，因此执行binder_thread_write函数。下面将进入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) {//读取ptr指向数据，赋值给cmdif (get_user(cmd, (uint32_t __user *)ptr))return -EFAULT;//指针后移ptr += sizeof(uint32_t);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_ENTER_LOOPER:binder_debug(BINDER_DEBUG_THREADS,"binder: %d:%d BC_ENTER_LOOPER\n",proc->pid, thread->pid);if (thread->looper & BINDER_LOOPER_STATE_REGISTERED) {thread->looper |= BINDER_LOOPER_STATE_INVALID;binder_user_error("binder: %d:%d ERROR:"" BC_ENTER_LOOPER called after ""BC_REGISTER_LOOPER\n",proc->pid, thread->pid);}thread->looper |= BINDER_LOOPER_STATE_ENTERED;break;}...}return 0;
}

位置：drivers/staging/android/binder.c
首先获取要写入数据的起始地址，起始地址是用bwr.write_buffer减去bwr.write_consumed，因为此处bwr.write_buffer代表binder_loop函数中赋值的BC_ENTER_LOOPER，bwr.write_consumed为0，因此ptr其实指向的是BC_ENTER_LOOPER代表的int值。end即为数据结束地址。接下来进入一个较长的while循环，这个while循环的作用是读取ptr中的数据，然后根据读取的数据进行进一步操作。进入while循环后先读取ptr指向的int值命令并赋值给cmd，此处cmd就是BC_ENTER_LOOPER，然后进行指针后移，以便下一次读取命令。最后一步是进入一个switch语句，它是用来处理写入数据的地方。只看case BC_ENTER_LOOPER部分。首先检查当前线程的binder_thread的looper位有没有设置BINDER_LOOPER_STATE_REGISTERED，BINDER_LOOPER_STATE_REGISTERED表示当前线程有没有注册循环，显然没有注册，因此不会进行错误处理。然后将binder_thread的looper位添加BINDER_LOOPER_STATE_ENTERED，表示当前线程已经进入循环状态。

binder_thread_write函数执行完毕，继续binder_ioctl函数执行。

//若bwr.read_size > 0if (bwr.read_size > 0) {...}binder_debug(BINDER_DEBUG_READ_WRITE,"binder: %d:%d wrote %ld of %ld, read return %ld of %ld\n",proc->pid, thread->pid, bwr.write_consumed, bwr.write_size,bwr.read_consumed, bwr.read_size);if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {ret = -EFAULT;goto err;}break;}

位置：drivers/staging/android/binder.c
因为binder_loop函数中赋值read_size为0，不执行if语句内容。最后将bwr复制回ubuf中，也就是用户空间中。

至此一次binder驱动的写入操作就完成了，现在返回到binder_looper函数中继续分析。因为接下来又将再次进入binder驱动中，所以进入step7。

step7

void binder_loop(struct binder_state *bs, binder_handler func)
{...for (;;) {//初始化读取信息bwr.read_size = sizeof(readbuf);bwr.read_consumed = 0;bwr.read_buffer = (unsigned) readbuf;//读取res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr);...}
}

位置：frameworks/base/cmds/servicemanager/binder.c
step6中提到bwr变量并没有使用，因为它是用来进行向binder驱动读取数据的，与BC_ENTER_LOOPER命令的执行无关。文章开头解释service_manager作为“服务提供者的管理者”，它要管理众多的XXXManagerService，就像淘宝网站要管理淘宝卖家一样，一旦淘宝卖家要上架商品，或者下架商品，淘宝网站必须进行处理，因此service_manager必要有一个循环来不停的接收众多XXXManagerService发送的命令，类似淘宝卖家向淘宝网站发送上架下架命令，而这个提到的循环就是该for循环。for循环中先初始化了bwr读取部分的信息。最后向内核bidner驱动发送BINDER_WRITE_READ用来读取数据。此处可以先想象以下，由于service_manager开机时就启动，并且肯定在任何一个XXXManagerService启动之前启动，所以此时它向binder驱动读取数据肯定是读取不到东西的。下面进入binder_ioctl代码分析。

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{...switch (cmd) {struct binder_write_read bwr;//检查长度if (size != sizeof(struct binder_write_read)) {ret = -EINVAL;goto err;}//从用户空间拷贝binder_write_read并赋值给bwrif (copy_from_user(&bwr, ubuf, sizeof(bwr))) {ret = -EFAULT;goto err;}binder_debug(BINDER_DEBUG_READ_WRITE,"binder: %d:%d write %ld at %08lx, read %ld at %08lx\n",proc->pid, thread->pid, bwr.write_size, bwr.write_buffer,bwr.read_size, bwr.read_buffer);//若bwr.write_size > 0if (bwr.write_size > 0) {...}//若bwr.read_size > 0if (bwr.read_size > 0) {//binder_thread_readret = binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK);if (!list_empty(&proc->todo))wake_up_interruptible(&proc->wait);if (ret < 0) {if (copy_to_user(ubuf, &bwr, sizeof(bwr)))ret = -EFAULT;goto err;}}binder_debug(BINDER_DEBUG_READ_WRITE,"binder: %d:%d wrote %ld of %ld, read return %ld of %ld\n",proc->pid, thread->pid, bwr.write_consumed, bwr.write_size,bwr.read_consumed, bwr.read_size);if (copy_to_user(ubuf, &bwr, sizeof(bwr))) {ret = -EFAULT;goto err;}break;}

位置：drivers/staging/android/binder.c
在step6中已经进入binder_ioctl函数一次，它的作用是告诉binder驱动，service_manager要进入循环状态了，是写操作。而这次进入binder_ioctl函数的作用是用来读取众多XXXManagerService发送的命令，尽管现在读取不到任何内容。
swich语句前step6中已经分析过，不再解释，进入switch后一样是先把用户空间的binder_write_read复制过来到内核的binder_write_read bwr中。此时bwr.write_size > 0为假，不执行。而bwr.read_size > 0为真，执行binder_thread_read函数，step6中进行写操作时执行了binder_thread_write用来将当前线程注册为循环状态，而此处的binder_thread_read可以猜测应该是使用当前线程进行数据读取的操作了。下面进入binder_thread_read函数分析。

分段阅读

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;//验证是否consumed == 0if (*consumed == 0) {//向数据起始地址写入BR_NOOP命令if (put_user(BR_NOOP, (uint32_t __user *)ptr))return -EFAULT;//指针后移ptr += sizeof(uint32_t);}

位置：drivers/staging/android/binder.c
这部分代码类似binder_thread_write函数，先获取数据起始和结尾地址。然后验证consumed是否是0，此处因为binder_looper函数中设置为0，因此执行if语句中内容。if语句先向数据起始地址写入了BR_NOOP命令，然后指针后移，这里BR_NOOP的作用暂时不解释，后续文章回用到，暂且有个印象吧。

retry://检查当前线程的transaction_stack变量是否为空，和todo列表是否为空wait_for_proc_work = thread->transaction_stack == NULL &&list_empty(&thread->todo);//检查return_error及ptrif (thread->return_error != BR_OK && ptr < end) {if (thread->return_error2 != BR_OK) {if (put_user(thread->return_error2, (uint32_t __user *)ptr))return -EFAULT;ptr += sizeof(uint32_t);if (ptr == end)goto done;thread->return_error2 = BR_OK;}if (put_user(thread->return_error, (uint32_t __user *)ptr))return -EFAULT;ptr += sizeof(uint32_t);thread->return_error = BR_OK;goto done;}//thread进入BINDER_LOOPER_STATE_WAITING状态thread->looper |= BINDER_LOOPER_STATE_WAITING;//若为真，当前进程的binder_proc的ready_threads变量加1if (wait_for_proc_work)proc->ready_threads++;//加锁mutex_unlock(&binder_lock);//若为真if (wait_for_proc_work) {//若当前线程的looper不是BINDER_LOOPER_STATE_REGISTERED 或 BINDER_LOOPER_STATE_ENTERED状态，出错处理if (!(thread->looper & (BINDER_LOOPER_STATE_REGISTERED |BINDER_LOOPER_STATE_ENTERED))) {binder_user_error("binder: %d:%d ERROR: Thread waiting ""for process work before calling BC_REGISTER_""LOOPER or BC_ENTER_LOOPER (state %x)\n",proc->pid, thread->pid, thread->looper);wait_event_interruptible(binder_user_error_wait,binder_stop_on_user_error < 2);}//将线程优先级设置为进程优先级binder_set_nice(proc->default_priority);//是否阻塞if (non_block) {if (!binder_has_proc_work(proc, thread))ret = -EAGAIN;} else//若binder_has_proc_work返回为假，则挂起进程ret = wait_event_interruptible_exclusive(proc->wait, binder_has_proc_work(proc, thread));} else {if (non_block) {if (!binder_has_thread_work(thread))ret = -EAGAIN;} elseret = wait_event_interruptible(thread->wait, binder_has_thread_work(thread));}

位置：drivers/staging/android/binder.c
这部分代码较长了些，但是其实有用的操作不多。首先检查当前线程的binder_thread的transaction_stack和todo是否为空，变量transaction_stack是什么呢？从名字看应该是存储事务的，这里先不做解释，后续文章会用到它，再做介绍。同样todo是什么呢，从drivers/staging/android/binder.c 中对binder_thread的定义来看它是一个struct list_head类型的变量，那肯定是个列表喽。从当前线程的binder_thread创建开始，一直未使用过transaction_stack和todo，并且创建函数binder_get_thread也没有处理transaction_stack和todo，那transaction_stack肯定是NULL，todo列表肯定是空。因此wait_for_proc_work为1，wait_for_proc_work变量表示是否要向binder_proc中查找有没有事务要完成，这里为1，表示线程中没有事务，要到进程中找事务处理了。然后检查return_error及ptr，因为binder_get_thread创建binder_thread时设置了thread->return_error = BR_OK，因此if语句内容不执行。然后将binder_thread设置为BINDER_LOOPER_STATE_WAITING状态。接下来判断wait_for_proc_work是否为真，此处是proc->ready_threads++，然后加锁，再次判断wait_for_proc_work是否为真，为真，进入if语句。if语句中先判断当前线程的looper变量是不是BINDER_LOOPER_STATE_REGISTERED 和 BINDER_LOOPER_STATE_ENTERED状态，若不是，则做出错处理。step6中已经将looper设置为BINDER_LOOPER_STATE_ENTERED，因此不执行出错处理。然后将线程优先级设置为进程优先级，再判断non_block是否为真，因为binder_thread_read传进来的是O_NONBLOCK，因此non_block为假，函数wait_event_interruptible_exclusive将servicemanager进程挂起。执行到此大管家servicemanager启动就算完成了，接下来众多XXXManagerService向servicemanager发送命令时就会唤醒servicemanager进程，这将会在后续文章进行介绍。

总结：
- servicemanager首先打开binder驱动，然后映射内存。
- servicemanager首次进入binder_ioctl函数，通过BINDER_SET_CONTEXT_MGR命令将自己注册为“大管家”。
- servicemanager在binder_looper函数中第二次进入binder_ioctl函数，通过BINDER_WRITE_READ命令，写入BC_ENTER_LOOPER命令，告诉binder驱动，servicemanager进入循环。
- servicemanager在binder_looper函数中第三次进入binder_ioctl函数，也是通过通过BINDER_WRITE_READ命令，读取众多XXXManagerService向servicemanager发送的命令，但是此时没有命令，因此servicemanager进程被挂起等待命令到来。