在上一篇文章《Binder客户端和驱动端通信流程实例分析----以acquireWakeLock()函数为例（一）》中，我们介绍了亮屏锁WakeLock类的acquire()函数如何将Binder请求从app上层一步步向下传递到frameworknative层的IPCThreadState类的transact()函数。
IPCThreadState类的transact()函数主要做的事情如下：
1. 调用IPCThreadState::writeTransactionData()函数把包含Binder请求信息的parcel内容拆解重组到一个binder_transaction_data结构体的变量中，再把命令码cmd和binder_transaction_data写入到mOut变量，mOut变量在后续的处理中将被包含在一个binder_write_read结构体变量中，通过ioctl()传给Binder驱动；
2. 调用IPCThreadState::waitForResponse()进入一个与Binder驱动进行沟通的while循环，该循环主要代码如下（因篇幅所限，进行了缩略）：
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();
switch (cmd) {
case BR_TRANSACTION_COMPLETE:
if (!reply && !acquireResult) goto finish;
break;
case BR_DEAD_REPLY:
err = DEAD_OBJECT;
goto finish;
case BR_FAILED_REPLY:
err = FAILED_TRANSACTION;
goto finish;
case BR_ACQUIRE_RESULT:
…
If (…) continue;
goto finish;
case BR_REPLY:
…
default:
err = executeCommand(cmd);
if (err != NO_ERROR) goto finish;
break;
}
}
该段循环代码调用talkWithDriver()函数与Binder驱动进行通信，然后根据返回的cmd命令码，执行不同的操作，如果判断该次事务已经完成，则退出while循环，否则继续调用talkWithDriver()与Binder驱动进行通信。通过在该循环中添加打印，可以发现在一次Binder事务中一般会调用五六次talkWithDriver()，当服务端完全处理好该次事务，并把处理结果通过Binder驱动返回后，就可成功退出循环。
现在我们看一下talkWithDriver()函数。talkWithDriver()是framework native层和设备文件驱动层的过渡函数，再往下就是设备文件驱动层了。talkWithDriver()在函数开头声明了一个binder_write_read结构体变量，然后把mIn和mOut的内存地址写入该变量。mIn是接收返回数据的载体，mOut则是Binder请求信息的载体。现在，关键的数据载体都打包在binder_write_read结构体中。数据打包完成后，talkWithDriver()执行以下代码，将binder_write_read结构体向下传递给设备文件：
if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
其中，bwr是binder_write_read结构体变量，BINDER_WRITE_READ是请求类型。mProcess是一个ProcessState实例，在Android Framework中属于单例实现（即一个进程只有一个mProcess），其成员mDriverFD是一个设备文件描述符，当mProcess实例被创建时，会调用open_driver()函数打开路径为"/dev/binder"的Binder驱动设备，返回的文件描述符就被保存在mDriverFD。通过这样的机制，当程序需要和Binder驱动通信时，只需要调用ioctl，把mDriverFD作为设备文件描述符，就可以把请求类型和请求数据准确无误地传递给Binder驱动。
现在，我们已经到了framework native层的边界，再往下走就会通过ioctl()进入linux kernel的领域。如果我们在安卓源代码中搜索ioctl()的定义，会搜出来至少几十个结果，很难判断哪个是talkWithDriver()里面调用的ioctl()。
这时候不要慌，静下心来思考。既然它是一个操作设备驱动文件的函数，那么不妨到内核文件系统路径，也就是kernel-3.18/fs/目录下搜索。我们发现，kernel-3.18/fs/ioctl.c这个文件里面实现了ioctl()函数，但是它的定义方式比较特殊，是通过宏SYSCALL_DEFINE3进行定义的，如下所示：
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
int error;
struct fd f = fdget(fd);
if (!f.file)
return -EBADF;
error = security_file_ioctl(f.file, cmd, arg);
if (!error)
error = do_vfs_ioctl(f.file, fd, cmd, arg);
fdput(f);
return error;
}
如果我们在这个函数里面添加打印，就会发现，talkWithDriver()调用的ioctl()，正好就是kernel-3.18/fs/ioctl.c文件里面的ioctl()。
现在我们已经进入linux kernel层。
在ioctl()的实现代码中，最终会通过如下调用顺序到达Binder驱动：
ioctl()→do_vfs_ioctl()→vfs_ioctl()→f_op->unlocked_ioctl()
现在观察f_op->unlocked_ioctl()。在kernel-3.18/fs/ioctl.c的ioctl()中，有以下代码：
struct fd f_op = fdget(fd);
可见f_op就是指向Binder设备文件"/dev/binder"的一个文件描述结构体，在上述调用顺序中，最后一个环节是调用该文件描述结构体的unlocked_ioctl()函数。
这时候如果我们打开Binder驱动的实现文件kernel-3.18/drivers/staging/android/binder.c，就可以看到unlocked_ioctl()其实是一个函数映射：
static const struct file_operations binder_fops = {
.owner = THIS_MODULE,
.poll = binder_poll,
.unlocked_ioctl = binder_ioctl,
.compat_ioctl = binder_ioctl,
.mmap = binder_mmap,
.open = binder_open,
.flush = binder_flush,
.release = binder_release,
};
可以看到，它是binder_ioctl()的映射。
在binder_ioctl()中，由于前面传递的请求类型是BINDER_WRITE_READ，故会执行以下命令分支：
case BINDER_WRITE_READ:
ret = binder_ioctl_write_read(filp, cmd, arg, thread);
if (ret)
goto err;
break;
在这个分支中，主要的动作是调用binder_ioctl_write_read()。
在binder_ioctl_write_read()的实现代码中，首先调用binder_thread_write()对请求数据包进行解包，逐个执行包中的命令，其中最主要的命令是BC_TRANSACTION，会触发执行binder_transaction()。
在binder_transaction()函数中，最主要的动作是遍历红黑树，找到服务端的工作队伍，将Binder请求插入该队伍，相当于加入一个新的工作任务。
插入完成后，线程就会返回到binder_ioctl_write_read()函数体中，执行binder_thread_read()。
binder_thread_read()会执行一个while循环，在不需要等待服务端返回数据的情况下，该循环立刻退出，如果需要等待，则当服务端返回数据时才退出。退出循环后，线程回退到talkWithDriver()的while循环。
当返回的结果符合条件时，线程退出talkWithDriver()的while循环，逐层向上返回，直到退出WakeLock的acquire()函数。
至此，我们完成了基于acquireWakeLock()函数的Binder客户端和驱动端的通信流程分析。由于Binder机制具有全局通用性，其它api的Binder请求都可以通过类似的方法和流程进行分析。