【鸿蒙南向开发】OpenHarmony IPC 之ServiceAbility应用（系统架构）

一、重要性

OpenHarmony IPC 之 ServiceAbility 应用极其广泛。例如在 OpenHarmony 以下四个目录共找到约 1087 个子系统用到了这种机制，其重要性可见一斑。
grep -nr “::OnRemoteRequest” ./foundation/ ./base/ ./drivers/ ./kernel/
调试时 OnRemoteRequest()函数是必经之路，服务端函数有没有调起就在这里“打桩”或输出日志。

Client-Server 软件模型外加 Interface 接口共同组成了 OpenHarmony 诸多子系统的架构，使其系统的稳定性、扩展性以及进程通信能力得到加强。子系统中均可见到 Interface 接口目录、Framework 客户端目录以及 Service 服务端目录，工作重点一般集中在 Service 服务端，如下图所示。

这种软件架构提供了丰富的软件接口，又提供了灵活的接口组织策略，很容易将一个子系统与另一个子系统相连接，形成一个有机的整体。典型的通路是 Foundation→Base→Drivers(Third_paty)

传统紧凑的软件架构因扩展性、稳定性饱受诟病，与其形成了鲜明对比，如下图：

说明
以下部分内容来自参考链接，他们已经整理的很好了，此处是借花献佛！

二、IPC 介绍

IPC（Inter-Process Communication）

IPC 是用于进程间通信的技术，指的是进程间的数据交互过程。它包括各种形式的消息传递，共享资源，以及同步对象，如互斥量等，以确保安全的并发访问共享资源。IPC 通常使用 Binder 驱动，主要用于设备内的跨进程通信，如 OpenHarmony 系统中的进程间通信。

IPC 与 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 通信。三方应用可以使用 FA 提供的接口绑定服务提供方的 Ability，获取代理，进行通信。下文使用 Proxy 表示服务请求方，Stub 表示服务提供方。

总结来说，IPC 是进程间通信的方式，侧重于进程内的数据共享和资源管理。IPC 通信机制架构图如下：

IPC 代码目录

约束

●单个设备上跨进程通信时，传输的数据量最大约为 1MB，过大的数据量请使用匿名共享内存。
●不支持在 RPC 中订阅匿名 Stub 对象（没有向 SAMgr 注册 Stub 对象）的死亡通知。
●不支持把跨设备的 Proxy 对象传递回该 Proxy 对象所指向的 Stub 对象所在的设备，即指向远端设备 Stub 的 Proxy 对象不能在本设备内进行二次跨进程传递。

三、ServiceAbility 应用<