前面几篇文章,为我们学习Binder IPC通信机制提供了扎实的理论基础,接下来将正式进入Binder IPC通信架构及原理的解读。
Binder 是基于 C/S 架构的,由一系列的组件组成,包括 Client进程、Server进程、Service Manager进程、Binder 驱动。其中 Client进程、Server进程、Service Manager进程运行在用户空间,互相隔离,而Binder 驱动运行在内核空间。因此Client进程、Server进程、Service Manager 进程间的交互必须通过Binder驱动(系统调用 open、mmap 和 ioctl 函数来访问设备文件 /dev/binder,实现与 Binder 驱动的交互来间接的实现跨进程通信),而非直接交互的原因是,**因为Client进程、Server进程、Service Manager进程属于进程空间的用户空间,不可进行进程间交互,而Binder驱动属于进程空间的内核空间,可进行进程间(进程内)直接交互。**Binder IPC中的每一个Client、Server进程都各自独立维护着一个Binder线程池来处理IPC请求,因此Server、Client 进程都可以并发地发出IPC请求和响应IPC请求。
Server Manager进程与Binder驱动的交互也是通过Binder实现的。
由上图可知Binder IPC 主要参与角色有五种:
角色 | 说明 | 参与对象 |
---|---|---|
Client进程 | Binder服务的使用者 | Binder 代理对象 |
Server进程 | Binder服务的供应商 | Binder本地对象 |
Service Manager进程 | Binder服务的管理者,负责把Binder的名称到引用对象的转换,类似DNS的功能 | \ |
Binder驱动 | 实现各种Binder的底层交互和管理,类似路由器。 | Binder实体对象、Binder引用对象(实体的引用) |
Server 进程
启动时主动向Binder驱动
发起注册自己的Service组件IPC请求,然后Binder驱动
响应IPC请求并转发该请求给Service Manager进程
,再由Service Manager进程
注册管理该Service 组件,于是Service Manager进程拥有了对应Server进程的信息(即完成了服务注册)。当Client 进程
向Service Manager进程发起携带服务唯一标识的获取服务IPC请求时,再次由Binder驱动
响应并转发给Service Manager进程
,Service Manager
进程根据注册信息找到对应的服务对象,交由Binder驱动
返回给Client
。
Client进程和Server进程的一次IPC 流程可以从整体通信上分为五个步骤:
步骤 | 说明 |
---|---|
1 | Client 将通信数据封装为Parcel对象并传递到Binder驱动 |
2 | Client向Binder驱动发送BC_TRANSACTION_COMPLETE协议,Binder驱动根据协议内容找到目标Server进程后回复一个BR_TRANSACTION_COMPLETE告知Client其通信请求已被接受,Client接到BR_TRANSACTION_COMPLETE并处理后,会再次进入到Binder驱动程序中等待Server进程的响应结果 |
3 | Binder驱动在给Client回复一个BR_TRANSACTION_COMPLETE的同时,向目标Server进程发送一个BR_TRANSACTION返回协议,请求目标Server进程处理这个IPC请求 |
4 | Server进程接受BR_TRANSACTION并处理后,给驱动回复一个BC_REPLY协议,驱动根据协议内容找到目标Client进程后再次向Server进程发送一个BR_TRANSACTION_COMPLETE返回协议,告知Server已接到返回的相应结果,Server接到并处理了BR_TRANSACTION_COMPLETE协议后,一次IPC流程就结束了,接着会重新进入到驱动程序中等待下一次IPC请求 |
5 | Binder驱动在给Server进程发送BR_TRANSACTION_COMPLETE的同时,也会向目标Client进程发送一个BR_REPLY返回协议,代表Server进程已经处理完成IPC请求了并将结果返回给Client |
从具体对象来看,一次Binder IPC (即Binder库 与 Binder 驱动的交互)需要至少五种核心对象参与:BpBinder
、BBinder
、Binder实体对象
、Binder代理对象
、Binder驱动程序
。核心流程为BpBinder——>Binder引用对象——>Binder实体对象——>BBinder——>Binder 事务
步骤 | 说明 |
---|---|
1 | Client进程里的Binder代理对象 在向Binder驱动中的Binder引用对象 发起IPC请求,Binder驱动 根据Client进程传入过来的Binder 代理对象 的句柄值(BpBinder中的mHandle)找到目标Binder引用对象 。 |
2 | Binder驱动 再根据Binder引用对象 寻找对应的Binder实体对象 并创建一个Binder事务 ,封装此次IPC请求。 |
3 | Binder驱动 在根据Binder实体对象找到运行在Server进程的Binder本地对象 ,将Client进程发送的IPC请求携带的数据交给Binder本地对象 处理。 |
4 | Binder本地对象 在Server进程继续处理IPC请求,处理完成后将结果返回到Binder驱动 ,Binder驱动 把结果封装到步骤2创建的Binder事务 中。 |
5 | Binder 驱动 最后根据Binder事务 的相关属性,找到发出IPC请求的Client进程,并通知Client进程把结果返回给Binder代理对象 处理。 |
在浏览器输入一个域名地址http://www.xxx.com 按下回车后,因为不能直接通过域名找到目标服务器,接着访问 DNS 域名服务器(保存了域名和IP的映射)筛选出目标服务器,然后通过这个 ip 地址才能放到到 http://www.xxx.com 对应的服务器。
Server 进程运行于进程空间内的用户空间,作为Binder服务的供应商,Server组件启动时通过Binder驱动主动把自己注册到Server Manager进程之中(即主动建立binder服务名称和Binder引用对象的映射),方便Client随时通过Server Manager进程获取相应的Binder代理对象进而得到使用其服务提供的能力。
同一个Server进程可以同时运行多个Server组件(即提供Binder服务的代码模块),同一个Client进程也可以同时向多个Server 组件发起IPC 请求,每一个请求对应一个Client组件(或者成为Server代理),
Client进程是Binder服务的使用者,使用时通过Service Manager 进程通信获取Binder(本地对象的)代理对象,通过Binder代理对象经过Binder驱动去向Server进程发起IPC请求。
运行于用户空间的Service Manager守护进程是提供Binder服务的查询功能,根据注册时的Binder服务名称就能返回其对应的Binder引用对象,对于Binder服务通常是有一个唯一的字符串名称,主要想Servive Manager 注册了,应用就可以通过这个字符串名称来得到对应的Binder 引用对象,而Service Manager进程也是通过Binder IPC与其他进程进行通信的,至于实现细节后续再表,其作用就类似于DNS功能。
**Binder 驱动运行于内核空间,是整个Binder IPC的核心(由Android系统内核实现),Binder驱动实现open、mmap和ioctl系统调用,完成内核空间和用户空间缓存的映射以及对缓存和Server组件的管理。**包括不限于负责进程之间 Binder 通信的建立,Binder 在进程之间的传递,Binder对象生命周期管理(采用引用计数计数),数据包在进程之间的传递和交互等一系列底层支持,类似网络通信中路由器的功能。Server进程与Client进程的通信都需要依赖Binder驱动间接完成,Binder驱动抽象了一个虚拟设备文件dev/binder/并向用户空间暴露,使得应用程序进程可以通过它间接建立通信通道。
BC_XXX代表用户空间的进程发送给Binder驱动的命令,而BR_XXX是Binder驱动返回给用户空间进程的命令。
至此,我们大致能总结出 Binder 通信过程:
我们看到整个通信过程都需要 Binder 驱动的接入。下图能更加直观的展现整个通信过程(为了进一步抽象通信过程以及呈现上的方便,下图我们忽略了 Binder 实体及其引用的概念):
Binder驱动,通过虚拟出的物理设备(/dev/binder),连接Service进程、Client进程与Service Manager进程
Binder驱动、Service Manager进程属于Android基础架构是系统已经实现的,Client进程、Server 进程属于Android应用层需要开发者自己实现。跨进程通信时,开发者只需自定义Client、Server进程并显式使用上述3个步骤(注册服务,获取服务,使用服务),最终借助Android的基本架构功能就可完成进程间通信。
Binder机制在 Android中的实现主要依靠 Binder类,其实现了IBinder接口
用一个应用Binder的实例来介绍怎么显式使用注册服务,获取服务,使用服务完成进程间通讯
以 Client进程通过Server进程实现加法函数(两个整数相加) 为例
Server进程通过Binder驱动向ServiceManager进程注册服务
sp<ProcessState> proc(ProcessState::self());
sp<CalcService> service = new CalcService();
sp<IServiceManager> sm = defaultServiceManager();
sm->addService(“CalcService”, service);
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
Client进程使用某个service前(此处是CalcService),需通过Binder驱动向ServiceManager进程获取相应的Service信息
sp sm = defaultServiceManager();
sp binder = sm->getService(“CalcService”);
sp calcService = interface_cast (binder);
Client进程根据获取到的Service信息(Binder代理对象),通过Binder驱动建立与该Service所在Server进程通信的链路,并开始使用服务
status_t myAdd(int a, int b, String8& result)
{
Parcel data, reply;
data.writeInterfaceToken("CalcService");
data.writeInt(a);
data.writeInt(b);
remote()->transact(CALC_ADD, data, &reply);
//status_t ret = reply.readInt32();
//String8 tempResult = reply.readString8();
//result.setTo(tempResult);
//return ret;
}
目标参数与接口标识赋值,调用代理对象BpInterface的transact() 将上述数据发送到Binder驱动
transact(CALC_ADD, data, reply, 0)
// 参数说明:
// 1. CALC_ADD:目标方法的标识符(Client进程和Server进程自身约定,可为任意)
// 2. data :上述的Parcel对象
// 3. reply:返回结果
// 0:可不管
// 注:在发送数据后,Client进程的该线程会暂时被挂起,若Server进程执行的耗时操作,请不要使用主线程,以防止ANR
Binder驱动根据代理对象找到对应的真身Binder对象所在的Server 进程(系统自动执行),Binder驱动把数据发送到Server进程中,并通知Server 进程执行解包(系统自动执行)
收到Binder驱动通知后,Server 进程通过回调Binder对象onTransact()进行数据解包 & 调用目标方法
status_t BnCalcService::onTransact(int code, Parcel data, Parcel reply, int flags){
// code即在transact()中约定的目标方法的标识符
switch (code) {
case CALC_ADD: {
String8 tempResult;
//获得目标方法的参数
int arg0 = data.readInt();
int arg1 = data.readInt();
//调用服务端方法进行计算
status_t ret = myAdd(arg0, arg1, tempResult);
//将计算结果写入到reply返回
reply->writeInt32(ret);
reply->writeString8(tempResult);
return NO_ERROR;
}
}
}
将结算结果返回到Binder驱动
status_t ret = reply.readInt32();
String8 tempResult = reply.readString8();
result.setTo(tempResult);