关于Binder线程池

1、Binder线程池的枚举状态：

enum{

  BINDER_LOOPER_STATE_REGISTERD=0x01

  BINDER_LOOPER_STATE_ENTERED=0x02

  BINDER_LOOPER_STATE_EXITED=0x04

  BINDER_LOOPER_STATE_INVALID=0x08

  BINDER_LOOPER_STATE_WATTING=0x10

  BINDER_LOOPER_STATE_NEED_RETURN=0x20

};

    根据字面意思可以理解为六种状态：注册、进入线程池、退出、非法、等待、需要返回。

    所有线程的初始状态都是NEED_RETURN，并且不管有没有work（所谓work就是线程监听到了消息），第一次read后都会返回。几乎所有的线程第一次ioctl都是write命令BC_REGISTER_LOOPER，把自己加入到线程池后返回，进而让应用程序知道线程是否成功进入线程池。

    有一个例外的线程，就是用于open驱动的那个线程，一般是进程的主线程，第一次调用ioctl会阻塞在ENTER_LOOPER状态。

2、进程

    每个使用Binder的进程都会在使用前打开binder驱动，驱动在open的时候会创建结构体binder_proc，并将它的指针记录到文件结构体private_data中，以后的驱动操作就能通过文件结构体来获取该进程的信息。

    驱动里都是以binder_proc为单元来分配和记录资源的，驱动会给每个使用binder的进程创建一个/proc/binder/proc/pid文件，用来展示进程相关的binder信息。

    /proc/binder/stats和/proc/binder/proc/pid能查看到相关信息

3、线程

    主要结构体binder_thread

    驱动会为每一个与binder有一腿的线程创建该结构体，并记录到进程的threads中

4、线程池

    ioctl(BINDER_WRITE_READ)有两步，第一步是write，会传给驱动一些以BC_开头的命令，让驱动去执行，一次可以传多个命令。第二步是read，会从驱动获取一些以BR_开头的回复，也可能是多个，read这一步有可能阻塞当前线程，直到驱动给它回复并唤醒它。

    任何一个线程在read阶段返回时，会检查进程的ready_threads，这个变量表示当前进程有多少个线程正在等待进程work，这类线程必然处于WATTING状态，如果当前没有线程等待进程work，驱动在read的返回BR队列最前面加上一个BR_SPAWN_LOOPER通知该线程，线程池已经没有可用于处理进程work的线程了，你得赶紧给我产生一个新的，线程在read返回之后便会根据该BR创建一个新的线程，并让它以BC_REGISTER_LOOPER加入线程池并待命，然后自己才去处理这些read到的真正的work。

    通过read返回这种方式创建的线程数不能超过进程的max_threads，此数通过ioctl(BINDER_SET_MAX_THREADS)设置，binder库中默认为15。但是，这个MAX并不约束进程的线程数，也不约束线程池中的线程数，仅仅约束在驱动要求下生成的线程数，即通过BC_REGISTER_LOOPER加入线程池中的线程数。

    work分为两种，进程work和线程work，分别记录在binder_proc和binder_thread的to-do队列中。线程池中可能有多个线程在同时等待，但一个work只需唤醒一个线程来做即可。