文章目录
- 前言
- 一、跨进程通讯的过程
- 1. AIDL客户端代码
- 2. AIDL服务端代码
- 3. 通信过程
- a. 发送请求时序图
- b. 接收请求时序图
- 二、Binder一次拷贝
- 1. 发送给Binder驱动的数据
- 2. 一次拷贝示意图
- 三、Binder驱动源码
- 1. 相关数据结构
- 2. 阅读Binder驱动源码
- 参考
前言
最近在学习Binder,之前都是跳过相关细节,通过阅读文章对Binder有了一些认识,但是并没有真正理解Binder。如果要深入理解Framework的代码,就必须要真正理解Binder。
我学习Binder的方法:
一边阅读Gityuan的Binder系列文章,一边调试阅读Binder相关代码来验证自己的理解。对于AOSP 非内核层的代码调试,网上已经有很多文章说明。但是Binder核心是在Binder驱动,就不好直接调试了。不过Binder提供详尽的调试日志开关,通过控制这些开关我们就可以让Binder打印调试日志,从而可以观察Binder驱动的运行。具体如何使用Binder驱动的调试开关,可以阅读Gityuran的Binder子系统之调试分析系列文章。我这里分析阅读的是Android 11的Binder代码,与Gityuan中的Android 6.0代码还是有出入的,但是总体流程是没有差别。
一定要配合源码边调试边阅读,除了Binder驱动层,能直接调试的尽量直接调试。 由于已经有了Gityuan大神的系列文章了,所以我对这篇文章的定位主要是补充和更新的作用。如果对驱动层代码感兴趣可以Clone我下面分享的带注释的Binder驱动源码来阅读理解。
一、跨进程通讯的过程
这里用AIDL跨进程通讯进行举例。让大家对Binder跨进程有个整体的认识,然后再根据时序图研究具体的实现代码
1. AIDL客户端代码
com.kevin.lab.IPersonManager.Stub.Proxy#getPersonListSize
@Override public int getPersonListSize(int arg) throws android.os.RemoteException
{
//用来存放要发送的数据
android.os.Parcel _data = android.os.Parcel.obtain();
//用来存放要接收的数据
android.os.Parcel _reply = android.os.Parcel.obtain();
int _result;
try {
//写入要发送的请求数据
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeInt(arg);
boolean _status = mRemote.transact(Stub.TRANSACTION_getPersonListSize, _data, _reply, 0);
if (!_status && getDefaultImpl() != null) {
return getDefaultImpl().getPersonListSize(arg);
}
//读取接收到的回复数据
_reply.readException();
_result = _reply.readInt();
}
finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
2. AIDL服务端代码
com.kevin.lab.IPersonManager.Stub#onTransact
@Override public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException
{
java.lang.String descriptor = DESCRIPTOR;
switch (code)
{
case INTERFACE_TRANSACTION:
{
reply.writeString(descriptor);
return true;
}
case TRANSACTION_getPersonListSize:
{
//读取接收的请求数据
data.enforceInterface(descriptor);
int _arg0;
_arg0 = data.readInt();
int _result = this.getPersonListSize(_arg0);
//写入要发送的回复数据
reply.writeNoException();
reply.writeInt(_result);
return true;
}
default:
{
return super.onTransact(code, data, reply, flags);
}
}
}
3. 通信过程
a. 发送请求时序图
b. 接收请求时序图
当服务端处理完请求后,就会将结果写入到Parcel reply中,然后通过Binder发送给客户端。这个过程类似客户端发送请求的过程,只是这里发送的不是请求,而是响应结果
二、Binder一次拷贝
对于Binder,很多文章都会介绍它的优点:一次拷贝,但是这个一次拷贝具体是拷贝哪部分,解释得不是很清楚。我这里将我阅读源码得到的答案总结出来。
首先我们要知道一次拷贝发生的地方是在Binder驱动里面,所以具体实现要去看驱动源码。在说明解释具体的驱动源码之前,我们先通过图表了解这个拷贝过程具体拷贝哪部分数据。
1. 发送给Binder驱动的数据
首先我们要知道发送给Binder驱动的数据是什么类型,以及如何构成的。
Binder驱动接收到的是binder_write_read对象,而在生成的AIDL方法中发送和接收请求使用的是Parcel data和Parcel reply。这里再贴一次AIDL客户端发送代码,便于与下面的图对照理解
@Override public int getPersonListSize(int arg) throws android.os.RemoteException
{
//用来存放要发送的数据,对应下图中的Parcel data
android.os.Parcel _data = android.os.Parcel.obtain();
//用来存放要接收的数据,对应下图中的Parcel reply
android.os.Parcel _reply = android.os.Parcel.obtain();
int _result;
try {
//写入要发送的请求数据
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeInt(arg);
boolean _status = mRemote.transact(Stub.TRANSACTION_getPersonListSize, _data, _reply, 0);
if (!_status && getDefaultImpl() != null) {
return getDefaultImpl().getPersonListSize(arg);
}
//读取接收到的回复数据
_reply.readException();
_result = _reply.readInt();
}
finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
上面这幅图描述的是发送的(Parcel data)、接收的(Parcel reply)与传递给Binder驱动的(binder_write_read)数据之间联系。
首先将Parcel data封装成binder_transaction_data,然后将binder_transaction_data写入到IPCThreadState的mOut中,接着将mOut和mIn封装成binder_write_read。然后通过ioctl系统调用传递给Binder驱动,最后再由Binder驱动发送给接收方(接收方接收的是经过处理后的binder_transcation_data)。
当从ioctl返回后(接收方发送响应数据回来),mIn中就有了响应数据,但是此时还没有赋值给Parcel reply,这个时候需要从mIn中读取binder_transaction_data,然后将binder_transaction_data中的buffer,offsets等赋值给Parcel reply。注意这里的mData和mObjects都是指针,也就是说实际进行的是浅拷贝,而mData和mObjects指向的内存区域里面的数据在Binder驱动里面就已经准备好,更进一步说其实是发送方(客户端)通过ioctl调用Binder驱动时,Binder驱动就将这部分数据拷贝到了接收方的内存空间中。在赋值给Parcel reply时,只执行了浅拷贝(给指针赋值)。由此可见,接收到的binder_transaction_data中的buffer,offsets指针所指向的内存区域没有被二次拷贝,该区域的数据只进行了一次拷贝
。
2. 一次拷贝示意图
这里将驱动中实现一次拷贝的示意图绘制出来,可以对比上面来进一步理解
从图中可以看出,内核虚拟地址空间与接收方通过mmap分配的虚拟地址空间都共同指向了相同的物理内存。当Binder驱动收到发送方的请求时候,将发送方中buffer,offsets指针指向的内存区域数据(这里抽象描述为data)拷贝到共同映射的物理内存。
三、Binder驱动源码
1. 相关数据结构
要理解Binder驱动源码,首先要了解各个数据结构的作用以及这些数据结构的之间的关系。下面我将核心数据结构的关系绘制出来,然后解释每个数据结构的作用
序号 | 结构体 | 名称 | 解释 |
---|---|---|---|
1 | binder_proc | binder进程 | 每个进程调用open()打开binder驱动都会创建该结构体,用于管理IPC所需的各种信息 |
2 | binder_context | binder上下文 | binder驱动中用来记录ServiceManager信息 |
2 | binder_thread | binder线程 | 对应于上层的binder线程 |
3 | binder_node | binder实体 | 对应于BBinder对象,记录BBinder的进程、指针、引用计数等 |
4 | binder_ref | binder引用 | 对应于BpBinder对象,记录BpBinder的引用计数、死亡通知、BBinder指针等 |
5 | binder_ref_death | binder死亡引用 | 记录binder死亡的引用信息 |
6 | binder_write_read | binder读写 | 记录buffer中读和写的数据信息 |
7 | binder_transaction_data | binder事务数据 | 记录传输数据内容,比如发送方pid/uid,RPC数据 |
8 | flat_binder_object | binder扁平对象 | Binder对象在两个进程间传递的扁平结构 |
9 | binder_buffer | binder内存 | Binder用来传输数据的缓存区(也就是一次拷贝关键地方) |
10 | binder_transaction | binder事务 | 记录传输事务的发送方和接收方线程、进程等 |
11 | binder_work | binder工作 | 记录binder工作类型 |
12 | binder_state | binder状态 |
2. 阅读Binder驱动源码
由于Binder驱动源码较多,如果一段一段放到博客,阅读起来体验非常糟糕。因此,我决定将添加了注释的Binder驱动源码放到了下面的Github仓库中,请Clone下来用VSCode打开然后根据时序图描述的执行过程阅读。
仓库地址:带注释的Binder驱动源码
有了对Binder驱动数据结构的初步印象,接着只要编写一个类似的AIDL测试程序,配合带注释的Binder驱动源码和前面的AIDL时序图,边阅读边理解。最后再通过开启相应的Binder驱动调试开关验证自己的理解,这样就可以深入理解Binder驱动的实现原理。
参考
- Gityuan Binder系列