从驱动层分析android的Binder机制-android学习之旅（83）

前言及知识准备

Binder驱动程序

Service组件的注册和启动

Clinet应用获取服务

本次主要介绍Android平台下Binder进程间机制。从机制的组成出发，将按照Binder驱动程序、Binder服务的注册和启动、Client应用获取服务三个方面来讲述。最后针对该模块提出了自己的问题以及思考

首先介绍Binder机制的组成。

第一部分就是Binder驱动程序，它存在于内核层，是服务提供者和服务使用者用来交互的“桥梁”第二部分是server，顾名思义，是用来提供服务的第三部分是Client，就是使用服务的应用第四部分就是Service Manager。比较特殊，后面详述。

Client、Server、Service Manager都是在用户空间的。如下图：

Service Manager是Binder机制中的关键组成部分，是Service的管理者。当一个应用想要提供服务时，首先要向Service Manager注册，然后再启动；而Client想要获取服务时，也需要向Service Manager进行查询，获取服务。但是Service Manager实际上也是一种server，只不过功能较为特殊。

一个完整的Binder机制通信过程如下：

1、Binder设备进行初始化2、实例化Service Manager对象，并且打开Binder设备3、为打开的Binder设备分配内存4、将Service Manager向binder驱动程序注册，成为Binder的上下文管理者5、Service组件向Service Manager注册服务，循环等待client进程请求6、启动Binder服务线程，并且加入线程池中7、Client应用从Service Manager获取相关服务的代理对象即指针，并且向其传递服务命令8、Service组件完成服务返回信息给client9、Client停止使用服务，当Service组件无应用使用时，终止服务。**重点内容**

介绍驱动层的结构体

结构体binder_buffer这个结构体是用来描述内核缓冲区，即缓冲区的分配信息。在为Binder设备分配内存时，便会维护这样一个结构体列表。部分结构体如下：Entry保存的是缓冲区列表的节点；rb_node是空闲/正在使用缓冲区的节点，其他变量我们不关心。

后半部结构体如下，其中transaction变量，用于描述此缓冲区交给了哪个事务。target_node描述此缓冲区交给了哪个Binder对象使用data指向了一块数据缓冲区，data_size为其大小。Offset_size用于寻找数据data中的Binder对象。

binder_transaction_data结构体用来描述进程间通信过程中所使用的数据的。联合体target描述的是一个目标Binder对象Cookie是一个附加数据，code是通信双方约定好的通信代码

Pid与euid是发送端的进程和线程ID号data_size与offset_size和前面用法一样。联合体data指向数据缓冲区。Offsets变量记录着缓冲区中Binder结构体的位置

flat_binder_object结构体描述一个Binder对象的结构体，通常存在于通信数据缓冲区中。Type说明此Binder对象类型Flag为通信时所需的各种标志，如优先级、文件描述等。   

Binder与handle组成的联合体。当此结构体指向一个Binder实体对象时，使用Binder表示；如果指向的是一个Binder引用对象，则使用Handle表示。

Client进程和server进程的一次进程间通信分为如下五步：

1.client进程将通信数据封装，以便传递给Binder驱动程序将如下信息封装入parcel类型的结构体中：①Strict Mode Policy也就是通信双方约定的协议，比如进制磁盘操作等等；②服务接口描述符，用于server判断是否为自己需要处理的服务请求；③service组件的名称，用于Binder驱动程序识别组件并且传递消息④ flat_binder_object结构体。将目标service组件封装成次结构体即可。⑤通信双方约定好的通信指令。将以上数据写入封装好之后，就交给Binder驱动程序来处理。2.client进程向Binder驱动发送一个请求服务(BC_TRANSACTION)的命令，Binder驱动首先将传递进来的parcel类型数据封装成binder_transaction_data结构体，并且根据协议内容，将数据写入内核缓冲区，并且找到相关server进程之后，返回一个请求完成消息(BR_TRANSACTION_COMPLETE)给client进程，表示已经接受3.Binder驱动程序将client进程发来的通信数据复制到新的binder_transaction_data结构体中，传递给server进程，之后Binder驱动将待处理事务加入到server进程的事务序列中，并且并且向serve进程发送服务请求BR_TRANSACTION，唤醒server进程，请求目标server进完成通信请求。4.server进程收到协议并进行处理之后，将处理结果、服务执行情况、需要返回的目标client进程封装成一个结构体，发送给Binder驱动，并且发送一个回应消息BC_REPLAY，Binder驱动收到后向server发送一个通信完成消息，表示通信结果已经收到，并且将通信结果拷贝到Client进程的缓冲区中，释放server进程内核缓冲区，此时server进程认为通信结束，准备下一次通信。5.Binder驱动把通信结果返回给client进程，向client进程发送服务完毕消息，表示通信请求完成，client用户将内核缓冲区中的通信结果拷贝出来，并且进行相应处理。处理完成后，Binder驱动清理client进程申请的内核缓冲区。

至此完成全部的通信步骤，Binder驱动程序再次充当了一个传递者的角色。

Binder对象知识：

Binder本地对象(BBinder)：用户空间创建，运行在server进程中。Binder实体对象(binder_node)：创建在Binder驱动程序中，是在内核层，被Binder本地对象所引用。Binder引用对象(binder_ref)：由Binder驱动创建，被用户空间中的client进程创建的代理对象所引用。Binder代理对象(BpBinder)：存在于用户空间中，被client进程所使用。会被其他client进程引用，也引用了Binder驱动程序中的Binder引用对象。

依赖关系如下图：

Binder代理对象依赖Binder引用对象，饮用对象依赖于实体对象，实体对象依赖于本地对象 。

一个Service组件想要注册服务，必须先启动Service Manager

1.打开Binder设备，方法如前面所述，2.向Binder驱动注册，成为Binder上下文管理者。3.注册成功之后，便进入循环等待相关进程访问。

如果server进程突然崩溃怎么办？ ##、

答：当一个进程发现服务不可用时，可想Binder驱动程序递交死亡通知，驱动程序将该通知发送到各个使用服务的程序中。

Binder机制如何知道哪些进程使用了服务？

答：Binder机制在服务注册时为每个server继承维护了一个用于记录哪些client进程使用了这个服务的二叉树。

结构体binder_transaction_data以及binder_buffer,这些和内存相关的结构体，用户进程可以操作吗？可以的话，怎么操作？不可以的话，用户进程怎么对binder的内存缓冲区进行操作？

答：这两个数据结构都是定义在内核空间的。用户进程不允许直接操作这两个数据结构。在client进程发送给Binder驱动时，驱动接收数据会首先进行数据转型，使用的是内核中的函数IPCThreadState类里的writeTransactionData函数进行数据转型，由此完成了binder_transaction_data的写入。当用户申请通信时，便会由驱动程序来完成写入该结构体的操作。binder_buffer则是由Binder驱动程序来进行维护的，描述了一个内核缓冲区的使用情况，操作函数有Binder驱动程序控制。