#打卡不停更#OHOS标准系统的IPC和RPC代码解读--1--概述 原创 精华
本想接着前文《OHOS标准系统的SAMGR代码解读》继续分析dmsfwk组件的实现细节,但发现涉及太多的IPC/RPC的内容了,如果对OHOS的IPC/RPC没有足够的理解,很难把dmsfwk组件理解透彻,因此我花了点时间,先整理了一下IPC/RPC相关的代码和部分流程,作为理解SAMGR相关组件的预备知识。
IPC/RPC的代码仓库,在OHOS 3.1分支上,分为ipc和ipc_lite两个仓库,在master分支上,ipc_lite仓库已经合并到ipc仓库中,因此本文在整理ipc仓库代码目录树结构时,是以当前的master分支代码为准整理的。
但由于我当前工作主要还是在OHOS 3.1分支上,所以在后面整理相关的流程图或数据结构关系图时,还是基于3.1分支代码进行的(待930版本发布后再确认是否更新到930版本)。
1.整理代码目录树结构(基于master分支)
在Linux命令行下进入 //foundation/communication/ipc/ 目录,通过tree命令将目录树结构打印出来并重定向到文本文件中。为减少干扰,直接去除test相关的目录和文件,再酌情微调一下部分目录和文件的位置。重点阅读剩下的几个BUILD.gn文件,结合几类系统分别整理BUILD.gn中的编译目标,尽可能地挖掘有用信息(后继在深入理解代码时也可以对该目录树结构补充新的信息)。
目前我整理出来的信息大概如下:
从上面的整理可以看出,Lite类型系统和STD系统,各有一套自己的IPC/RPC的实现代码。因为当前目标是要研究标准系统的dmsfwk组件(和samgr等其他组件),所以我们当前的重点是上文中的编译目标【10】【11】【12】。
通过对比【10-ipc_core】和【11-ipc_single】两个编译目标的BUILD.gn文件,可以认为【11】是【10】的子集,因为:
- 目标【10】没有定义CONFIG_IPC_SINGLE,目标【11】是有定义的。在部分共用的源代码文件中,有使用 #ifndef CONFIG_IPC_SINGLE 控制的代码,是目标【10】专用的。
- 目标【10】比目标【11】多编译几个文件,是与DBinder、DataBus相关的,用于RPC。
目前还没有非常确定【10】【11】各自的应用场景有多大的差别,但我的理解偏向于Stub/Server端多依赖【10】,而Proxy/Client端多依赖【11】,或者分布式SA多依赖【10】,普通SA多依赖【11】(有待后面有更多的理解后确认)。
不管怎样,【10】和【11】两个目标的代码是共用的,都属于IPC范畴,可以一并阅读理解。【12】则属于RPC范围,再单独阅读理解。至于Lite类型系统的编译目标,待以后有空研究的时候再补充相关总结。
2.基于Binder驱动的IPC(基于3.1 Release分支)
ipc组件根目录下的README.md文件中有提到:
IPC(Inter-Process Communication)与RPC(Remote Procedure Call)机制用于实现跨进程通信,不同的是前者使用Binder驱动,用于设备内的跨进程通信,而后者使用软总线驱动,用于跨设备跨进程通信。IPC和RPC通常采用客户端-服务器(Client-Server)模型,服务请求方(Client)可获取提供服务提供方(Server)的代理 (Proxy),并通过此代理读写数据来实现进程间的数据通信。通常,系统能力(System Ability)Server侧会先注册到系统能力管理者(System Ability Manager,缩写SAMgr)中,SAMgr负责管理这些SA并向Client提供相关的接口。Client要和某个具体的SA通信,必须先从SAMgr中获取该SA的代理,然后使用代理和SA通信。
熟悉Android系统或者做过OHOS系统移植的小伙伴,即使没有非常深入理解过Binder,但估计也会经常听到基于Binder驱动的IPC机制。
内核态的Binder驱动实现代码,在 //kernel/linux/linux-5.10/drivers/android/ 目录下。在编译Linux内核时,通过 //kernel/linux/config/linux-5.10/arch/arm(arm64)/configs/ 目录下的 xxxx_defconfig 文件中的如下配置,将Binder驱动模块编译进内核:
Binder驱动在内核向用户态进程提供服务;用户态进程通过 open(“/dev/binder”) 和 ioctl() 来使用Binder服务实现IPC。
这中间其实要经历一些非常复杂的过程,建议小伙伴们自行搜索和理解Binder在内核中实现IPC的原理和细节,我现在还无法保证未来会做这方面的总结。
但本系列文章的下一篇,将会以全景图的形式展示和讲解OHOS的用户态IPC框架的实现流程和细节。
3.基于DBinder驱动的RPC(待定)
DBinder应该是Distributed Binder的缩写。
DBinder将会涉及软总线的一些实现细节,我先看看能理解得多深入,待有所理解后再写总结。
随着技术的深入,要掌握的知识也越来越多。
文章中介绍到STD 是standard 的缩写吗?