一、重要性
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 对象不能在本设备内进行二次跨进程传递。