社区编辑申请
注册/登录
源码分析----openHarmony IPC数据传输情景分析
系统 OpenHarmony
这篇文章关注驱动自身的数据传输,做一次完整的数据分析。由于IPC通信流程比较复杂,我们先开启上帝视角,将一些数据结构和数据流向直接阐述出来,然后再结合源码调用流查看是否具体是这样的。

​想了解更多内容,请访问:​

​51CTO和华为官方合作共建的鸿蒙技术社区​

​https://ost.51cto.com​

1、前情概览

我们在前片博客中讲述了 proxy - stub 架构的一般编程范式,这篇文章关注驱动自身的数据传输,做一次完整的数据分析。由于IPC通信流程比较复杂,我们先开启上帝视角,将一些数据结构和数据流向直接阐述出来,然后再结合源码调用流查看是否具体是这样的。

2、数据结构简述

(1)messageParcel

messageParcel 用户态数据,可以写入一般类型,也可以写入iremoteObject。为什么要区分这两种类型,这里先卖一个关子。

class MessageParcel : public Parcel {
public:
MessageParcel();
~MessageParcel();
explicit MessageParcel(Allocator *allocator);
bool WriteRemoteObject(const sptr<IRemoteObject> &object);
sptr<IRemoteObject> ReadRemoteObject();
bool WriteFileDescriptor(int fd);
int ReadFileDescriptor();
bool ContainFileDescriptors() const;
bool WriteInterfaceToken(std::u16string name);
std::u16string ReadInterfaceToken();
bool WriteRawData(const void *data, size_t size);
const void *ReadRawData(size_t size);
bool RestoreRawData(std::shared_ptr<char> rawData, size_t size);
const void *GetRawData() const;
size_t GetRawDataSize() const;
size_t GetRawDataCapacity() const;
void WriteNoException();
int32_t ReadException();
bool WriteAshmem(sptr<Ashmem> ashmem);
sptr<Ashmem> ReadAshmem();
void ClearFileDescriptor();
void SetClearFdFlag()
{
needCloseFd_ = true;
};
private:
#ifndef CONFIG_IPC_SINGLE
bool WriteDBinderProxy(const sptr<IRemoteObject> &object, uint32_t handle, uint64_t stubIndex);
#endif
static constexpr size_t MAX_RAWDATA_SIZE = 128 * 1024 * 1024; // 128M
static constexpr size_t MIN_RAWDATA_SIZE = 32 * 1024; // 32k
bool needCloseFd_ = false;
std::vector<sptr<Parcelable>> holders_;
int writeRawDataFd_;
int readRawDataFd_;
void *kernelMappedWrite_;
void *kernelMappedRead_;
std::shared_ptr<char> rawData_;
size_t rawDataSize_;
};

(2) flat_binder_object

这是内核描述iremoteObject对象信息的结构体。当调用 object->Marshalling(*this)的时候会将messageParcel 转化为flat_binder_object。同理还有一个UnMarshalling方法。

struct flat_binder_object {
unsigned long type; // binder类型:可以为BINDER_TYPE_BINDER或BINDER_TYPE_HANDLE等类型
unsigned long flags; // 标记
union {
void *binder; // 当type=BINDER_TYPE_BINDER时,它指向Binder对象位于C++层的本地Binder对象的弱引用。
signed long handle; // 当type=BINDER_TYPE_HANDLE时,它等于Binder对象在Binder驱动中对应的Binder实体的Binder引用的描述。
};
void *cookie; // 当type=BINDER_TYPE_BINDER时才有效,它指向Binder对象位于C++层的本地Binder对象。
};

(3)  binder_transaction_data

这个数据不仅包含了flat_binder_object中的纯数据,也包含的cmdID以及发送者的其他信息。

struct binder_transaction_data {
union {
size_t handle; // 当binder_transaction_data是由用户空间的进程发送给Binder驱动时,
// handle是该事务的发送目标在Binder驱动中的信息,即该事务会交给handle来处理;
// handle的值是目标在Binder驱动中的Binder引用。
void *ptr; // 当binder_transaction_data是有Binder驱动反馈给用户空间进程时,
// ptr是该事务的发送目标在用户空间中的信息,即该事务会交给ptr对应的服务来处理;
// ptr是处理该事务的服务的服务在用户空间的本地Binder对象。
} target; // 该事务的目标对象(即,该事务数据包是给该target来处理的)
void *cookie; // 只有当事务是由Binder驱动传递给用户空间时,cookie才有意思,它的值是处理该事务的Server位于C++层的本地Binder对象
unsigned int code; // 事务编码。如果是请求,则以BC_开头;如果是回复,则以BR_开头。
unsigned int flags;
pid_t sender_pid;
uid_t sender_euid;
size_t data_size; // 数据大小
size_t offsets_size; // 数据中包含的对象的个数
union {
struct {
const void *buffer;
const void *offsets;
} ptr;
uint8_t buf[8];
} data; // 数据
};

(4)  binder_write_read

驱动真正读写的数据,也就是binder_transaction_data 会转化为binder_write_read交给驱动真正的读写。

struct binder_write_read {
signed long write_size;
signed long write_consumed;
unsigned long write_buffer;
signed long read_size;
signed long read_consumed;
unsigned long read_buffer;
};

(5)  binder_ref

binder_ref是描述Binder引用的结构体。

struct binder_ref {
int debug_id;
struct rb_node rb_node_desc; // 关联到binder_proc->refs_by_desc红黑树中
struct rb_node rb_node_node; // 关联到binder_proc->refs_by_node红黑树中
struct hlist_node node_entry; // 关联到binder_node->refs哈希表中
struct binder_proc *proc; // 该Binder引用所属的Binder进程
struct binder_node *node; // 该Binder引用对应的Binder实体
uint32_t desc; // 描述
int strong;
int weak;
struct binder_ref_death *death;
};

(6) binder_proc

struct binder_proc {
struct hlist_node proc_node; // 根据proc_node,可以获取该进程在"全局哈希表binder_procs(统计了所有的binder proc进程)"中的位置
struct rb_root threads; // binder_proc进程内用于处理用户请求的线程组成的红黑树(关联binder_thread->rb_node)
struct rb_root nodes; // binder_proc进程内的binder实体组成的红黑树(关联binder_node->rb_node)
struct rb_root refs_by_desc; // binder_proc进程内的binder引用组成的红黑树,该引用以句柄来排序(关联binder_ref->rb_node_desc)
struct rb_root refs_by_node; // binder_proc进程内的binder引用组成的红黑树,该引用以它对应的binder实体的地址来排序(关联binder_ref->rb_node)
int pid; // 进程id
struct vm_area_struct *vma; // 进程的内核虚拟内存
struct mm_struct *vma_vm_mm;
struct task_struct *tsk; // 进程控制结构体(每一个进程都由task_struct 数据结构来定义)。
struct files_struct *files; // 保存了进程打开的所有文件表数据
struct hlist_node deferred_work_node;
int deferred_work;
void *buffer; // 该进程映射的物理内存在内核空间中的起始位置
ptrdiff_t user_buffer_offset; // 内核虚拟地址与进程虚拟地址之间的差值
// 内存管理的相关变量
struct list_head buffers; // 和binder_buffer->entry关联到同一链表,从而对Binder内存进行管理
struct rb_root free_buffers; // 空闲内存,和binder_buffer->rb_node关联。
struct rb_root allocated_buffers; // 已分配内存,和binder_buffer->rb_node关联。
size_t free_async_space;
struct page **pages; // 映射内存的page页数组,page是描述物理内存的结构体
size_t buffer_size; // 映射内存的大小
uint32_t buffer_free;
struct list_head todo; // 该进程的待处理事件队列。
wait_queue_head_t wait; // 等待队列。
struct binder_stats stats;
struct list_head delivered_death;
int max_threads; // 最大线程数。定义threads中可包含的最大进程数。
int requested_threads;
int requested_threads_started;
int ready_threads;
long default_priority; // 默认优先级。
struct dentry *debugfs_entry;
};

(7) binder_node

binder_node是描述Binder实体的结构体。

struct binder_node {
int debug_id;
struct binder_work work;
union {
struct rb_node rb_node; // 如果这个Binder实体还在使用,则将该节点链接到proc->nodes中。
struct hlist_node dead_node; // 如果这个Binder实体所属的进程已经销毁,而这个Binder实体又被其它进程所引用,则这个Binder实体通过dead_node进入到一个哈希表中去存放
};
struct binder_proc *proc; // 该binder实体所属的Binder进程
struct hlist_head refs; // 该Binder实体的所有Binder引用所组成的链表
int internal_strong_refs;
int local_weak_refs;
int local_strong_refs;
void __user *ptr; // Binder实体在用户空间的地址(为Binder实体对应的Server在用户空间的本地Binder的引用)
void __user *cookie; // Binder实体在用户空间的其他数据(为Binder实体对应的Server在用户空间的本地Binder自身)
unsigned has_strong_ref:1;
unsigned pending_strong_ref:1;
unsigned has_weak_ref:1;
unsigned pending_weak_ref:1;
unsigned has_async_transaction:1;
unsigned accept_fds:1;
unsigned min_priority:8;
struct list_head async_todo;
};

3、情景分析

(1)数据流向

其实结合上文,一次的数据发送。其实就是 messageParcel ->flat_binder_object -> binder_transaction_data -> binder_write_read。上文中我们说到普通数据和iremoteObjiect有区别,那区别是啥,就是发送的数据里面包含iremoteObJiect,驱动程序就会在全局哈希表binder_procs中注册一个binder_proc。那普通数据和iremote数据是如何区分呢?答案是他有两个指针一个指向普通的数据,另一个指向iremoteObject。也就是binder_transaction_data的buffer指针和offsets指针。那binder驱动在这个数据发送的过程中做了什么呢?

(2) 驱动事件循环

binder_ref-> binder_proc->binder_node。

对于发送者来说,要知道发送的数据需要传输给谁,他自身持有一个服务进程的binder_ref,通过binder_ref找到对应的binder_proc,然后通过binder_proc找到对应的binder_node(一个进程可以有多个binder_node,即可以有多个服务)。那binder_write_read中获取的数据也就会添加到宿主进程binder_proc的todo链表中。

源码调用图解

client和stub的交互过程就是 client - > stub ->client 这样看起来就像自身进程调用自己的方法一样。上图中ipcObjectStub -> OnRemoteRequest()就会向binder驱动放松数据,这也是为什么继承的子类需要重写OnRemoteRequest方法。

这里就是大概ipc调用的过程,对驱动自身的阐述比较浅薄,驱动中的多线程模型还有自身数据结构的复杂性并没有阐述。如果有机会研究后,再讲讲dsoftbus驱动和binder驱动的不同和相似之处,讲讲iremoteObJect是如何适配这两种不同驱动模型的。

​想了解更多内容,请访问:​

​51CTO和华为官方合作共建的鸿蒙技术社区​

​https://ost.51cto.com​

责任编辑:jianghua 来源: 鸿蒙社区
相关推荐

2022-07-27 14:30:15

分布式数据鸿蒙

2022-02-17 16:47:40

OpenharmonIPC通信鸿蒙

2022-07-19 20:04:31

NAPI模块鸿蒙

2022-06-14 15:07:04

IPC客户端服务端

2022-04-20 20:28:40

HDF 驱动框架鸿蒙操作系统

2022-04-29 14:56:40

通话应用源码剖析

2021-12-14 10:16:00

2021-11-26 15:34:27

2021-11-08 15:04:47

2021-09-07 15:48:28

2021-11-08 15:02:19

2021-09-08 15:09:29

2021-09-13 15:15:18

同话题下的热门内容

OpenHarmony 给你的输入法加点彩—星球崛起基于OpenHarmony Native Api框架实现控制LED灯亮灭OpenHarmony- 基于ArkUI (JS)实现数字排序小游戏DevEco Device Tool:HDF框架一键生成!HarmonyOS3.0尝鲜之关键Js Api--ServiceAbility开发HarmonyOS - 基于ArkUI (JS) 实现图片旋转验证App与Hap、Entry与Feature,BundleName与Packge,务必弄明白HarmonyOS 实现一个滑块验证

编辑推荐

HarmonyOS 2.0鸿蒙第二期开发者Beta公测申请指南HarmonyOS LYEVK-3861开发板播放《蜜雪冰城》鸿蒙HarmonyOS分布式软总线:构建低时延、高带宽的多设备虚拟网络华为HarmonyOS的强势突围: 直面物联网迷宫的蓄力进击鸿蒙HarmonyOS2.0发布会现场回忆录
我收藏的内容
点赞
收藏

51CTO技术栈公众号