OHOS标准系统的IPC和RPC代码分析

这篇文章主要介绍“OHOS标准系统的IPC和RPC代码分析”，在日常操作中，相信很多人在OHOS标准系统的IPC和RPC代码分析问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”OHOS标准系统的IPC和RPC代码分析”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！  在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类型系统的编译目标，待以后有空研究的时候再补充相关总结。  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。到此，关于“OHOS标准系统的IPC和RPC代码分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注百云主机网站，小编会继续努力为大家带来更多实用的文章！

相关推荐: C++可排序的最大块数问题怎么解决

这篇文章主要讲解了“C++可排序的最大块数问题怎么解决”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“C++可排序的最大块数问题怎么解决”吧！This question is the same as “Max C…