本文旨在深入探讨华为鸿蒙HarmonyOS Next系统（截止目前API12）的技术细节，基于实际开发实践进行总结。主要作为技术分享与交流载体，难免错漏，欢迎各位同仁提出宝贵意见和问题，以便共同进步。本文为原创内容，任何形式的转载必须注明出处及原作者。
在HarmonyOS应用开发中，进程间通信（IPC）是构建复杂应用架构的关键要素。IPC Kit为开发者提供了强大的进程间通信能力，使不同进程之间能够高效协作，实现丰富多样的功能。
进程间通信的基本概念
IPC和RPC的定义与区别
IPC（Inter - Process Communication），即设备内的进程间通信。它主要用于同一设备上不同进程之间的数据交互与方法调用。比如说，一个应用中的多个服务进程可能需要相互协作，此时IPC就发挥了重要作用。IPC使用Binder驱动来实现进程间的通信，就像是在同一个工厂（设备）内不同车间（进程）之间建立了高效的物流通道（Binder驱动），方便它们传递信息和协作生产。
RPC（Remote Procedure Call），也就是设备间的进程间通信。当涉及到跨设备的功能协同，比如多设备联动场景下，RPC就派上用场了。它允许一个设备上的进程调用另一个设备上进程的方法，仿佛是不同工厂（设备）之间可以远程请求协作生产一样。RPC依赖软总线驱动来达成跨设备的通信。
为什么需要IPC和RPC
每个进程在操作系统中都有独立的资源和内存空间，这就好比每个家庭都有自己的独立空间和财产，不能随意被他人访问。如果没有IPC和RPC，进程之间就无法进行有效的信息共享和协作，应用的功能将会受到极大限制。例如，一个音乐播放应用，播放服务进程需要与用户界面进程通信，以更新播放状态、显示歌词等，这就需要IPC来实现。而在智能家居场景中，手机控制智能音箱播放音乐，就需要RPC来实现跨设备的通信。
IPC Kit的核心架构与工作原理
Client - Server模型的使用场景与系统能力（System Ability）注册
IPC Kit通常采用Client - Server模型进行进程间通信。在这个模型中，有明确的角色划分。
Server端，也就是服务提供方，就像一个餐厅的厨房，负责提供各种美食（服务）。在IPC Kit中，Server端需要先将自己的服务注册到系统能力管理者（System Ability Manager，缩写SAMgr）中，这就好比餐厅把自己的菜单（服务能力）注册到一个美食平台（SAMgr）上，让顾客（Client端）能够知道它能提供哪些美食（服务）。
Client端，即请求服务的一方，类似于顾客。当Client端需要使用Server端的服务时，必须先从SAMgr中获取该Server端的代理Proxy对象，然后通过这个代理对象与Server端进行通信。这就如同顾客在美食平台上找到餐厅的菜单（Proxy），然后根据菜单点菜（发起请求），厨房（Server）根据订单准备食物（处理请求），最后通过服务员（驱动）将食物送到顾客桌上（返回处理结果）。
使用Binder和软总线（Soft Bus）驱动的不同通信机制
在IPC通信中，当使用Binder驱动时，它在设备内部建立了一条高效的通信链路。Binder驱动就像是一条内部专用高速公路，进程之间的数据可以快速、稳定地传输。例如，在一个大型企业内部（设备），不同部门（进程）之间通过内部高速网络（Binder驱动）进行频繁的数据交换，确保业务的高效运转。
而RPC通信依赖软总线驱动，软总线驱动则像是连接不同城市（设备）之间的交通网络。它使得不同设备上的进程能够跨越设备边界进行通信。例如，在一个跨城市的连锁企业中，不同城市的分店（设备）之间可以通过公共交通网络（软总线驱动）进行信息共享和业务协同，比如总部（一个设备上的进程）可以远程控制分店（另一个设备上的进程）的促销活动（调用方法）。
IPC Kit的应用场景
IPC的后台服务调用
在HarmonyOS应用中，IPC的典型应用场景之一是后台服务调用。比如，一个下载应用，它的后台下载服务进程负责下载文件，而用户界面进程需要获取下载进度、暂停或继续下载等操作。通过IPC机制，用户界面进程可以与后台下载服务进程进行通信，实现这些功能。这就好比你在手机上下载一部电影，下载界面（用户界面进程）可以实时显示下载进度（从后台服务进程获取信息），你还可以暂停或继续下载（向后台服务进程发送请求）。
RPC的多端协同应用
RPC在多端协同场景中发挥着重要作用。以智能家居为例，你的手机（一个设备）可以通过RPC调用智能音箱（另一个设备）的播放音乐方法，实现远程控制音乐播放。或者在分布式办公场景中，你可以从电脑（一个设备）上远程访问公司服务器（另一个设备）上的文件资源，进行编辑和保存，这都是RPC实现跨设备进程间通信的实际应用。
示例代码与图示
以下是一个简单的系统能力注册示例代码：
// 假设这是一个自定义的服务类，继承自某个系统服务基类
public class MyService extends SystemAbility {
private static final int MY_SERVICE_ID = 12345;
public MyService() {
super(MY_SERVICE_ID);
}
@Override
public void onStart() {
// 在这里进行服务的初始化工作
super.onStart();
}
@Override
public void onStop() {
// 在这里进行服务的停止清理工作
super.onStop();
}
// 定义服务提供的方法
public void doSomething() {
// 具体的服务逻辑
}
}
// 在应用启动时注册服务
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
MyService myService = new MyService();
try {
// 向系统能力管理者注册服务
SystemAbilityManager.addSystemAbility(myService);
} catch (SystemAbilityManager.SystemAbilityError error) {
// 处理注册失败的情况
error.printStackTrace();
}
}
}
下面是Client - Server架构图的简单示意（此处为文字描述，实际可以绘制专业的架构图）：
| 组件 | 描述 |
|---|---|
| Client端 | 向Server端发起请求的进程，通过获取Server端的代理Proxy对象来调用Server端的方法。 |
| Proxy | 位于Client端进程，它具有和Server端相同的接口定义，负责将Client端的请求转发给Server端，并将Server端的返回结果传递给Client端。 |
| Server端 | 提供服务的进程，包含具体的业务逻辑实现。 |
| Stub | 位于Server端进程，它接收Proxy转发的请求，调用Server端的实际业务方法，并将结果返回给Proxy。 |
| System Ability Manager (SAMgr) | 负责管理系统能力（服务），为Client端提供获取Server端代理对象的接口，同时协调服务的注册、查询和启动等操作。 |
| Binder驱动（IPC）或软总线驱动（RPC） | 负责在进程之间传递数据和消息，实现进程间的通信。 |
通过以上对IPC Kit的介绍，希望大家能够更好地理解HarmonyOS中的进程间通信机制，从而在应用开发中更加灵活地运用IPC和RPC，构建出功能强大、高效协作的应用程序。下次我们将深入探讨IPC Kit的开发实践，包括如何编写高效的IPC通信代码等内容，敬请期待！哈哈，今天的讲解就到这里啦，希望没有把大家绕晕，如果有什么问题，随时来找我这个“技术老司机”哦！
Top comments (0)