数据格式同样为：命令+数据。均存放在write_buffer域指向的内存空间，多条命令可连续存放。数据紧跟着命令后面，数据格式会有所不同.
| Binder写操作命令字 | | arg |
|---|
| BC_TRANSACTION | 最常用命令之一，Client通过驱动向Server发送请求数据, | struct binder_transaction_data 利用binder_transaction_data中的flag域区分同步异步。flag域中的TF_ONE_WAY为1，则为异步，Client无需等待BC_REPLY数据包。否则需要等到数据包接收，才算完成一次交互。 |
| BC_REPLY | 最常用命令之二Server通过驱动向Client发送应答数据 | |
| BC_ACQUIRE_RESULT | |
| BC_ATTEMPT_ACQUIRE | | |
| BC_FREE_BUFFER | 释放一块映射的内存 | |
| BC_INCREFS BC_ACQUIRE BC_RELEASE BC_DECREFS | 管理Binder引用计数 | 32位Binder引用号 |
| BC_INCREFS_DONE BC_ACQUIRE_DONE | Binder实体处理引用计数后，给Binder驱动的反馈 | |
| BC_REGISTER_LOOPER | 通知binder驱动，Server端创建了一个线程 | Server端线程池管理 |
| BC_ENTER_LOOPER | 通知binder驱动，Server端某个线程进入主循环，可以接收数据 | |
| BC_EXIT_LOOPER | 通知binder驱动，Server端某个线程退出主循环，不再接收数据 | |
| BC_REQUEST_DEATH_NOTIFICATION | client要求binder驱动在Binder实体销毁时，client能得到通知 | 参数1：uint32 *ptr; 需要得到死亡通知的Binder引用 参数2：void * *cookie: 与死亡通知相关的信息，驱动会在发出死亡通知时返回给发出请求的进程。 |
| BC_DEAD_BINDER_DONE | client收到实体死亡通知，删除引用，并告知驱动 | |
4.2 BINDER_WRITE_READ 从Binder中读出数据
格式与写操作一致，同样能连续存放。
| Binder读操作命令字 | |
|---|
| BR_ERROR | 内部错误？ |
BR_OK
BR_NOOP | 操作成功，与BR_TRANSACTION_COMPLETE区别在哪？ |
| BR_SPAWN_LOOPER | 驱动发现接收方线程不够用，要求接收方创建线程 |
BR_TRANSACTION
BR_REPLY | |
BR_ACQUIRE_RESULT
BR_ATTEMPT_ACQUIRE | |
| BRFINISHED | |
| BR_DEAD_REPLAY | 交互过程中如果发现对方进程或线程已经死亡则返回该消息 |
| BR_TRANSACTION_COMPLETE | 驱动告知发送方“发送成功”，与接收方是否返回请求数据无关 |
BR_INCREFS
BR_ACQUIRE
BR_RELEASE
BR_DECREFS | 引用与计数管理 |
BR_DEAD_BINDER
BR_CLEAR_DEATH_NOTIFICATION_DONE | 告知Client进程，Binder实体死亡通知处理相关 |
| BR_FAILED_REPLY | 发送非法引用号，则返回此 |
4.3 struct binder_transaction_data 收发数据包结构
| 成员定义 | |
|---|
union {
size_t handle;
void *ptr；
} target; | 对于发送方 target指向目的地。target.handle(即句柄)存放binder引用
当数据包到达接收方时，target已被驱动赋予了binder实体对象内存的指针，存放在target.ptr |
| void *cookie； | 发送方忽略该成员，binder实体创建时，接收方自定义的任意数值，与binder指针相关的额外信息，驱动也基本不关心该成员 |
| unsigned int code； | Server端定义的公共接口函数编号(业务码？) |
| unsigned int flags; | 交互相关标志位，其中最重要的是TF_ONE_WAY位 |
| pid_t sender_pid; | 发送方进程ID和用户ID，由驱动负责填入 |
| uid_t sender_euid; | |
| size_t data_size; | Server定义的公共接口函数关心的数据相关,传输中的Binder，以flat_binder_object的形式包含在buffer中.
buffer指向部分会copy到映射区 |
| size_t offsets_size; | |
union{
struct { *buffer;*offsets} ptr;
uint8_t buf[8];
}data; | |
5 Binder的表述
Binder存在于系统的这些部分：
应用程序进程：Server进程和Client进程
Binder驱动：分别管理为Server端Binder实体和Client端引用
传输数据：Binder可以跨进程传递，需要在传输数据中予以表述
在不同的部分，Binder实现的功能不同，表现形式也不一样。我们需要关心其扮演的角色和使用的数据结构。
5.1 Binder在应用程序中的表述
Binder本质是底层通信的方式，与具体服务无关。Server必须提供一套接口函数，以便Client远程访问。
这时通常采用Proxy设计模式，将接口函数定义在一个抽象类中
Server端，实现所有接口函数，是正在的功能实现
Client端同样实现所有接口函数，但却是对这些函数远程调用请求的包装
如何将Binder和Proxy设计模式结合是应用程序实现面向对象Binder通信的根本问题
5.1.1 在server端表述--Binder实体
Binder实体类实现两个类的所有虚函数：
公共接口函数类，具体服务实现
BBinder:IBinder抽象类，提供onTransact()，用于跨进程调用。输入就是binder_tansaction_data结构上的数据包，case-by-case解析data中的code值和函数参数，分发给具体接口函数的实现。
5.1.2在client端表述--Binder引用
Client中会有代理类实现这两个类：
公共接口函数类，函数调用封装为binder_transaction_data数据包
BpBinder:IBinder抽象类，提供transact(),用于跨进程调用.
5.2 Binder 在传输数据中的表述
Binder传输结构为flat_binder_object
5.2.1 flat_binder_object结构
| 属性 | 含义 |
|---|
| unsigned long type; | binder类型:
BINDER_TYPE_BINDER
表示传递的是Binder实体，并且指向该实体的都是强引用;
BINDER_TYPE_WEAK_BINDER
表示传递的是Binder实体，并且指向该实体的都是弱引用;
BINDER_TYPE_HANDLE
表示传递的是Binder强引用;
BINDER_TYPE_WEAK_HANDLE
表示传递的是Binder弱引用;
BINDER_TYPE_FD
表示传递的是文件形式Binder; |
| unsigned long flags | 只对第一次传递Binder实体时有效，因为是用于驱动在内核中创建Binder实体节点，
内容暂不关心了就。 |
union{
void * binder;
signed long handle;
};
| void * binder;
指向Binder实体在Server进程中的内存地址，传递Binder实体时使用。
signed long handle;
存放Binder在进程中的引用号，传递Binder引用时使用。 |
| void * cookie； | 只对Binder实体有效，存放Binder相关附加信息 |
5.2.2 驱动对flat_binder_object的操作
无论是Binder实体还是引用都从属某个进程，所以不能透明的在进程间传递，必须经过驱动“翻译”。
| binder类型 | 在发送方的操作 | 在接收方的操作 |
|---|
| BINDER_TYPE_BINDER BINDER_TYPE_WEAK_BINDER | 只有实体所在的进程才能发送该类型的Binder。第一次发送时，驱动为其在内核中创建节点，并保存binder，cookie，flag域 | 如果是第一次接收该Binder则创建实体在内核中的引用；将handle域替换为新建的引用号；将type域替换为INDER_TYPE_(WEAK_)HANDLE |
| BINDER_TYPE_HANDLE BINDER_TYPE_WEAK_HANDLE | 驱动根据handle域提供的引用号查找binder在内核中的引用。如果找不到，则不合法。 | 1.如果收到的binder实体位于接收进程：将ptr域替换为保存在节点中的binder值，cookie值替换，type替换为BINDER_TYPE_(WEAK_)BINDER
2.如果收到的Binder实体不在接收进程中：如果第一次接收则创建实体在内核中的引用；将handle域替换为新建的引用号 |
| BINDER_TYPE_FD |
| 略 |
5.3 Binder 在驱动中的表述
驱动是Binder通信的核心：
所有Binder实体及其在各个进程中的引用都登记在驱动中
驱动记录Binder引用与实体间多对一的关系
为引用找到对应实体，为实体创建或者查找对应引用
记录Binder的归属进程
管理Binder引用，创建or销毁Binder实体
5.3.1 Binder实体在驱动中的表述
Binder实体在驱动中，称为“节点”，由binder_node 结构表示。根据传输数据中的flat_binder_object,构建binder_node节点。
binder_node结构
| 属性 | 含义 |
|---|
| int debug_id; | 用于调试 |
| struct binder_work work; | ？ |
union{
struct rb_node rb_node;
struct hlist_node dead_node;
};
| 内核为每个进程维护一颗红黑树，存放此进程的所有binder实体的用户空间指针(ptr).rb_node即为binder_node在红黑树中的形式。
待销毁节点，待切断所有引用后，彻底销毁。 |
| struct binder_proc *proc； | 该节点所属进程 |
| struct hlist_head refs; | 该节点所有引用队列 |
| int internal_strong_refs; | 强指针计数器 |
| int local_strong_refs; | 驱动为传输中的Binder设置的强引用计数 |
| int local_weak_refs; | 驱动为传输中的Binder设置的弱引用计数 |
| void __user * ptr; | 指向用户空间内存地址，来自flat_binder_object的binder成员 |
| void __user *cookie; | |
unsigned pending_strong_ref;
unsigned has_strong_ref;
unsigned has_weak_ref;
unsigned pending_weak_ref; | 引用计数相关 |
| unsigned has_async_transaction; | 表面该节点在to-do队列中有异步交互尚未完成。to-do队列是驱动为接收进程或线程开辟的，用于暂存发往接收端的数据包。
如果to-do中有尚未完成的异步交互，则将新到的异步交互，存放在async队列中。为同步交互让路，避免长时间阻塞发送端 |
| struct list_head aysnc_todo; | 异步交互等待队列；分流发往本节点的异步交互包 |
| unsigned accept_fds; | 文件binder相关，略 |
| int min_priority; | 设置处理请求的线程的最低优先级，值来自于flat_binder_object中的flags成员
区别在哪？ |
5.3.2 Binder引用在驱动中的表述
表述为binder_ref，根据传输数据中的flat_binder_object构建。
binder_ref结构
| 属性 | 含义 |
|---|
| int debug_id; | 调试用 |
| struct rb_node rb_node_desc; | 每个进程有一棵红黑树，进程所有引用以引用号（即本结构的desc域）为索引添入该树中。本成员用做链接到该树的一个节点。 |
| struct rb_node rb_node_node; | 每个进程又有一棵红黑树，进程所有引用以节点实体在驱动中的内存地址（即本结构的node域）为所引添入该树中。本成员用做链接到该树的一个节点。 |
| struct hlist_node node_entry; | 该域将本引用做为节点链入所指向的Binder实体结构binder_node中的refs队列 |
| struct binder_proc *proc; | 本引用所属的进程 |
| struct binder_node *node; | 本引用所指向的节点（Binder实体） |
| uint32_t desc; | 本结构的引用号 |
| int strong; | 强引用计数 |
| int weak; | 弱引用计数 |
| struct binder_ref_death *death; | 应用程序向驱动发送BC_REQUEST_DEATH_NOTIFICATION或BC_CLEAR_DEATH_NOTIFICATION命令从而当Binder实体销毁时能够收到来自驱动的提醒。该域不为空表明用户订阅了对应实体销毁的‘噩耗’。 |
5.3.3 小结：
Binder实体会有很多引用，这些引用分布在不同的进程中。
每个进程使用红黑树存放实体
每个进程使用红黑树存放引用
Binder引用可以通过两个键值索引：
实体在内核中的地址:
驱动创建于内核中的binder_node结构地址，非实体在用户进程中的内存地址。内核地址是唯一的，而用户进程地址可能会重合
驱动为引用分配的32位标识，Binder引用在用户进程中的句柄，单个进程内是唯一的。通过引用号在红黑树中找到binder_ref,通过ref的node域找到Binder实体相关信息。
6. Binder内存映射和接收缓存区管理
传统IPC数据拷贝:用户空间-->内核空间-->用户空间
Binder数据拷贝:Client用户空间--> 内核空间:Server用户空间
Binder内存映射mmap()方法：
接收方开辟缓存区，mmap(),返回内存映射在用户空间地址
映射类型为只读，用户不能直接访问缓存区，缓存区由驱动管理
唯有binder_transaction_data.data.buffer会进入缓存区。其余部分(理解为消息头)依然需要接收方提供。
Binder驱动职责：
驱动为接收方分担了最为繁琐的任务：分配/释放大小不等，难以预测的有效负荷缓存区。接收方只需存放大小固定，空间可预测的消息头即可。通过映射，省略了在内核中暂存。
Binder会预先创建一堆线程，这些线程会阻塞在等待队列上。一旦有数据请求，驱动会从队列中唤醒一个线程来处理。
Binder如何管理线程：
应用程序通过BINDER_SET_MAX_THREADS,告诉驱动最大线程数
以后每个线程创建，进入/退出循环都会告知驱动，以便驱动记录当前线程池状态(BC_REGISTER_LOOP，BC_ENTER_LOOP，BC_EXIT_LOOP)
其他线程利用率优化
8 数据包接收队列与等待队列管理
1.队列用以缓解请求与处理的“供需矛盾”：
接收队列,也叫to-do队列,存放数据包，分为：进程全局队列& 线程私有接收队列
等待队列，等待to-do处理后的数据，分为：进程全局等待队列 & 线程私有等待队列
2.数据包进入进程or线程to-do队列规则：
规则1：Client发送给Server的请求数据包进入全局to-do队列。(除非发送线程T1与Server的线程T2有交互，且T1正等待读取返回包)
规则2：同步请求的返回数据包，送入发送请求的线程的私有to-do队列
3.驱动递交同步交互和异步交互规则：
为了减少异步交互对同步发送端的阻塞。异步要为同步让步。即一旦to-do队列中有异步在处理，新提交的异步只能特制的async_todo队列。而新提交的同步，依然可以进入to-do队列
性能：单次拷贝<br /> 安全性：PID/UID可控<br /> 易用性：面向对象设计
mwq30123
Android工程师
92.2k
粉丝
