Android Binder图文详解和驱动源码分析

心中要有一片海

已于 2023-04-21 16:59:51 修改

阅读量971

点赞数

分类专栏： AOSP 文章标签： android binder aosp

于 2023-04-18 23:12:12 首次发布

本文链接：https://blog.csdn.net/lylwo317/article/details/130230090

版权

AOSP 专栏收录该内容

1 篇文章 1 订阅

订阅专栏

文章目录

前言

最近在学习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状态