Android Binder 设计思想

mwq30123
1,158 阅读15分钟

Android Binder 设计思想

来自此处《Android Bander设计与实现 - 设计篇》的笔记

1引言

1.1 传统IPC有何弊端？为何要新建Binder？

1.1.1传输性能

  • socket作为通用接口，传输效率低，开销大，主要用于在跨网络的进程间通信和本机低速网络通信，两次拷贝过程
  • 消息队列和管道采用存储-转发方式，发送方到内核缓存区，内核缓存区到接收方缓存区，至少两次拷贝过程
  • 共享内存无需拷贝，但控制复杂，难以使用

1.1.2安全性考虑

  • 传统IPC无法获取发送方可靠的UID/PID, binder可以在内核中添加可靠的身份表示
  • 传统IPC访问接入点是开发的，无法建议私有通道，例如socket的ip地址都是开放的，无法阻止恶意程序猜测接收方地址，从而获取连接

1.2 Binder是什么？

  • 基于Client-Sever通信模式的IPC机制
  • 传输过程只需1次拷贝
  • 为发送方添加UID/PID身份，同时支持实名Binder和匿名Binder，安全性高

2 面向对象的 Binder IPC

2.1 Client-Server通信模型

必要条件

  • server必须要有确定的访问接入点(或者说地址)来接受Client的请求，并且Client可以通过某种途径获知Server地址
  • 指定Command-Reply协议来传输数据

网络通信

  • Server接入点就是Server主机IP+端口号
  • 传输协议为TCP协议

binder

  • 对于Server而言，binder是Server提供的某个特定服务的访问接入点，Clitent通过这个“地址”向Server发送请求来使用该服务
  • 对于Client而言，binder是通向Server的管道入口，想要和某个Server通信，必须建立这个管道并获取管道入口

2.2 Binder 面向对象思想

  • Binder实体是位于Server进程中的对象，该对象提供了一套方法用以实现对服务的请求，就像类的成员函数。
  • 遍布于client进程中的入口，可以看成是Binder实体的“指针”，“引用”，“代理”或者说是“句柄。Client通过binder引用访问Server。
  • 面向对象的思想将进程间通信转化为“使用binder引用来访问binder实体对象的方法”。binder实体是一个可以跨进程引用的对象。binder实体位于某个进程中，而binder引用遍布于系统的各个进程中。
  • 形形色色的binder对象以及星罗棋布的应用仿佛粘连各个应用程序的胶水，这也是Binder的英文原意。

2.3 Binder驱动

	Binder驱动和内核其他模块一样，使用C语言实现，为面向对象的进程间通信提供底层支持。

3 Binder通信模型

3.0 Binder框架四个角色--类比互联网：

  • 运行于用户空间：Server(服务器)、Client(客户端)、ServerManager(DNS)
  • 运行于内核空间：Binder驱动(路由器)

3.1 Binder驱动

  • 通信核心，工作于内核态，提供open(),mmap(),ioctl()等标准文件操作
  • 非硬件设备，只是实现方式与设备驱动程序一样，以字符驱动设备中的misc设备注册在dev下，通过/dev/binder访问
  • 负责进程间Binder通信的建立，binder在进程中的传递，binder引用计数管理，数据包在进程间的传递与交互等一系列底层支持。
  • 驱动与应用程序之间定义了一套接口协议，主要功能由ioctl()接口实现
  • 驱动代码位于linux目录的drivers/misc/binder.c中

3.2 ServiceManager与实名Binder(注册)

  • SM的作用是将字符形式的Binder名称转化成Client中对该Binder的引用。
  • 注册了名字的Binder叫实名Binder，就像网站有ip，也有地址。
  • Server创建Binder实体，并取一个字符名称。将Binder连同名称以数据包的形式通过Binder驱动发送给SM
  • Binder驱动为此Binder创建位于内核中的实体节点和SM对实体的引用。SM收到数据包后，从中取出名字和引用填入一张查找表中，即注册过程。
  • SM是Server端，有自己的Binder实体。特殊的是没有名字，无需注册。一个进程使用BINDER_SET_CONTEXT_MGR命令时，那此进程就会将自身注册成SM，同时驱动会自动为其创建Binder实体。此Binder的引用在所有Client中都固定为0。类似网络通信，0号引用好比域名服务器地址，必须预先配置好。

3.3 Client获取实名Binder引用(查找)

  • 通过前一阶段的注册，Client可以直接通过名字获取Binder引用。但我们通常通过0号引用即SM，来获取某个binder引用，此获取过程同样需要binder名称。
  • SM中始终留有一个Binder引用，每个Client通过查找都会得到一个新的binder引用。如同java对象引用，同时也都是强引用。

3.4匿名Binder

并不是所有进程中的binder都需要注册给SM广而告之。例如某个client进程可以通过已经建立的Binder连接，将自己的binder实体引用发送给Server进程。Server进程使用该引用请求Client进程，此过程进程双方的角色就发生了互换。例如应用启动过程中的ApplicationThread

4 Binder协议

4.0概述

基本格式：命令+数据。使用ioctl(fd,cmd,arg)交互。

4.1 BINDER_WRITE_READ之写操作

  数据格式同样为：命令+数据。均存放在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_DONEBinder实体处理引用计数后，给Binder驱动的反馈
BC_REGISTER_LOOPER通知binder驱动，Server端创建了一个线程Server端线程池管理
BC_ENTER_LOOPER通知binder驱动，Server端某个线程进入主循环，可以接收数据
BC_EXIT_LOOPER通知binder驱动，Server端某个线程退出主循环，不再接收数据
BC_REQUEST_DEATH_NOTIFICATIONclient要求binder驱动在Binder实体销毁时，client能得到通知参数1：uint32 *ptr; 需要得到死亡通知的Binder引用 参数2：void * *cookie: 与死亡通知相关的信息，驱动会在发出死亡通知时返回给发出请求的进程。
BC_DEAD_BINDER_DONEclient收到实体死亡通知，删除引用，并告知驱动

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驱动职责：
    • 驱动为接收方分担了最为繁琐的任务：分配/释放大小不等，难以预测的有效负荷缓存区。接收方只需存放大小固定，空间可预测的消息头即可。通过映射，省略了在内核中暂存。

7 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队列

9 总结

性能：单次拷贝<br />	安全性：PID/UID可控<br />	易用性：面向对象设计
avatar
文章
阅读
粉丝