admin 管理员组

文章数量: 1184232


2024年3月13日发(作者:oracle19c安装界面卡住)

Android Binder设计与实现 – 设计篇

摘要

Binder是Android系统进程间通信(IPC)方式之一。Linux已经拥有管道、

system V IPC、socket等IPC手段,却还要倚赖Binder来实现进程间通信,说

明Binder具有无可比拟的优势。深入了解Binder并将之与传统 IPC做对比有

助于我们深入领会进程间通信的实现和性能优化。

本文将对Binder的设计细节做一个全面的阐述,首先通过介绍Binder通信

模型和Binder通信协议了解Binder的设计需求;然后分别阐述Binder在系统

不同部分的表述方式和起的作用;最后还会解释Binder在数据接收端的设计考

虑,包括线程池管理,内存映射和等待队列管理等。通过本文对Binder的详细

介绍以及与其它IPC通信方式的对比,读者将对Binder的优势和使用Binder

作为Android主要IPC方式的原因有深入了解。

1.引言

基于Client-Server的通信方式广泛应用于从互联网和数据库访问到嵌入

式手持设备内部通信等各个领域。智能手机平台特别是Android 系统中,为了

向应用开发者提供丰富多样的功能,这种通信方式更是无处不在,诸如媒体播放,

视音频捕获,到各种让手机更智能的传感器(加速度、方位、温度、光亮度等)

都由不同的Server负责管理,应用程序只需作为Client与这些Server建立连

接便可以使用这些服务,花很少的时间和精力就能开发出令人眩目的功能。

Client-Server方式的广泛采用对进程间通信(IPC)机制是一个挑战。目前linux

支持的IPC包括传统的管道、System V IPC、即消息队列/共享内存/信号量,以

及socket中只有socket支持Client-Server的通信方式。当然也可以在这些底

层机制上架设一套协议来实现Client-Server通信,但这样增加了系统的复杂

性,在手机这种条件复杂,资源稀缺的环境下可靠性也难以保证。

另一方面是传输性能。socket作为一款通用接口,其传输效率低,开销大,

主要用在跨网络的进程间通信和本机上进程间的低速通信。消息队列和管道采用

存储-转发方式,即数据先从发送方缓存区拷贝到内核开辟的缓存区中,然后再

从内核缓存区拷贝到接收方缓存区,至少有两次拷贝过程。共享内存虽然无需拷

贝,但控制复杂,难以使用。

表 1 各种IPC方式数据拷贝次数

IPC

共享内存

Binder

Socket/管道/消息队列

还有一点是出于安全性考虑。Android作为一个开放式,拥有众多开发者的

平台,应用程序的来源广泛,确保智能终端的安全是非常重要的。终端用户不希

望从网上下载的程序在不知情的情况下偷窥隐私数据,连接无线网络,长期操作

底层设备导致电池很快耗尽等等。传统IPC没有任何安全措施,完全依赖上层协

议来确保。首先传统IPC的接收方无法获得对方进程可靠的UID/PID(用户ID/

进程ID),从而无法鉴别对方身份。Android为每个安装好的应用程序分配了自

己的UID,故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户

在数据包里填入UID/PID,但这样不可靠,容易被恶意程序利用。可靠的身份标

记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的,无法

建立私有通道。比如命名管道的名称、system V的键值、socket的ip地址或文

件名都是开放的,只要知道这些接入点的程序都可以和对端建立连接,不管怎样

都无法阻止恶意程序通过猜测接收方地址获得连接。

基于以上原因,Android需要建立一套新的IPC机制来满足系统对通信方式,

传输性能和安全性的要求,这就是Binder。Binder基于 Client-Server通信模

式,传输过程只需一次拷贝,为发送发添加UID/PID身份,既支持实名Binder

也支持匿名Binder,安全性高。

2.面向对象的 Binder IPC

Binder使用Client-Server通信方式:一个进程作为Server提供诸如视频

/音频解码,视频捕获,地址本查询,网络连接等服务;多个进程作为Client

向Server发起服务请求,获得所需要的服务。要想实现Client-Server通信必

须实现以下两点:一是server 必须有确定的访问接入点或者说地址来接受

Client的请求,并且Client可以通过某种途径获知Server的地址;二是制定

数据拷贝次数

0

1

2


本文标签: 进程 方式 传统