Binder机制总结笔记

什么是Binder？

Binder的Android特有的IPC通信机制。Android的四大组件Activity、Service、Broadcast、ContentProvider，不同的App等都运行在不同的进程内，他们之间的通信都需要依靠Binder完成。因此Binder在整个Android系统都有着一个举足轻重的地位。
Binder的架构如下：

Binder采用的是C/S的架构方式。组成部分主要是client、server、Binder驱动、servicemanager。

framework层只是一层封装，为了上层方便调用native层的操作。主要的处理是有native层通过ioctl与内核进行通讯。
Binder机制

Binder机制主要是通过servicemanager进程代理，管理和注册服务。首先，服务器向servicemanager注册服务，这些服务最终会保存在内核中的binderproc列表中，同时servicemanager的servInfo中也会缓存一份。客户端需要和服务端进行通信时，首先通过sm获取服务端的引用，这些引用存储在servInfo中，拿到引用之后就可以将参数通过BinderProxy传到sm，然后通过系统调用copy_from_user传到内核中，此时客户端进入等待，内核将服务放到binderproc的TODO队列中，执行完之后通过copy_to_user拷贝到用户空间，然后BinderProxy会传给客户端。
binder驱动

Android是基于linux内核的。因此Android需要遵循linux内存访问的机制。用户空间和内核空间交互的唯一方式就是系统调用。Android使用一系列系统调用使得用户空间和内核空间进行交互。binder驱动提供了用户空间一个进程和另一个进程使用binder通信的基础，是负责binder通信内核的模块。
binder进程和线程

binder驱动中管理着一个全局的binderprocs链表，这个链表中的每一个binderproc结构都对应用户空间中的一个binder进程，每一个binder进程里面只有一个IProcessState对象，这是单例模式保证的。每个binder线程内部也只有一个IPCThreadState对象，也是单例保证的。binder驱动中也有与之相应的结构binder_thread，binderproc结构中的rb_root thread就记录所有binder进程中的binder_thread。

每一个binder的server进程注册之后，内部都会有一个binder线程池，先注册一个binder的线程，之后server进程也可以注册新的线程，或者binder驱动检测到当前没有空闲的线程的时候，那就会在线程池中新注册一个线程。biner线程池都是有一个最大的线程限制数目，默认是16个线程。
servicemanager启动

sm是读取init.rc配置文件启动的，通过调用binderOpen系统调用创建binderprocs链表，然后循环调用binderLooper不断处理共享内存中的数据。
servicemanager注册服务

某个service注册服务，调用addService函数。sm通过BC_TRANSACTION将ADD_SERVICE传到内核中，binder驱动将事务添加到TODO 列表中，此时注册服务的线程waitForResponse进入等待。Binder驱动收到命令之后，向servicemanager的事务队列中插入一条事务，这个事务就是创建一个binder_node并且插入到binderprocs中。执行完之后BR_TRANSACTION命令通知sm执行完成，sm将已注册的服务添加到servInfo中，通过BR_REPLY唤醒等待的线程。
sm获取服务

获取服务类似于注册服务的相反的过程。客户端通过getService函数获取服务，sm通过BC_TRANSACTION将CHECK_SERVICE的命令发给内核中，插入到sm的事务队列中，此时获取服务的队列进入等待。驱动收到的获取服务的命令之后，向sm发送BR_TRANSACTION查询已注册的服务，查到则返回，没有则再次查找。
完整的通信过程

首先通过sm获取服务端的BinderProxy，通过BinderProxy将函数的参数和标识传递到内核中，Binder驱动会插入一条TODO事务，等执行之后，再将结果返回到用户空间，之后唤醒线程的等待，通信结束。