IPC Kit Basic Introduction: Understanding the Inter - Process Communication Architecture of HarmonyOS

This article aims to deeply explore the technical details of the Huawei HarmonyOS Next system (up to API 12 as of now), and is summarized based on actual development practices. It mainly serves as a carrier for technical sharing and communication. Mistakes and omissions are inevitable. Colleagues are welcome to put forward valuable opinions and questions so that we can make progress together. This article is original content, and any form of reprint must indicate the source and the original author.
In HarmonyOS application development, inter - process communication (IPC) is a key element in constructing complex application architectures. The IPC Kit provides developers with powerful inter - process communication capabilities, enabling different processes to cooperate efficiently and achieve a rich variety of functions.

Basic Concepts of Inter - Process Communication

Definitions and Differences between IPC and RPC

IPC (Inter - Process Communication), that is, inter - process communication within a device. It is mainly used for data interaction and method invocation between different processes on the same device. For example, multiple service processes in an application may need to cooperate with each other, and at this time IPC plays an important role. IPC uses the Binder driver to achieve communication between processes. It is like establishing an efficient logistics channel (Binder driver) between different workshops (processes) in the same factory (device) to facilitate their information transfer and collaborative production.
RPC (Remote Procedure Call), that is, inter - process communication between devices. When it comes to cross - device functional collaboration, such as in a multi - device linkage scenario, RPC comes in handy. It allows a process on one device to call a method of a process on another device. It is as if different factories (devices) can remotely request collaborative production. RPC relies on the soft bus driver to achieve cross - device communication.

Why IPC and RPC are Needed

Each process has independent resources and memory space in the operating system. This is like each family has its own independent space and property and cannot be accessed arbitrarily by others. Without IPC and RPC, there would be no effective information sharing and collaboration between processes, and the functions of the application would be greatly limited. For example, in a music playback application, the playback service process needs to communicate with the user interface process to update the playback status, display lyrics, etc., which requires IPC to achieve. In a smart home scenario, when a mobile phone controls a smart speaker to play music, RPC is needed to achieve cross - device communication.

Core Architecture and Working Principle of IPC Kit

Usage Scenarios and System Ability Registration of the Client - Server Model

The IPC Kit usually adopts the Client - Server model for inter - process communication. In this model, there is a clear role division.
The Server side, that is, the service provider, is like the kitchen of a restaurant, responsible for providing various foods (services). In the IPC Kit, the Server side needs to register its own service with the System Ability Manager (SAMgr) first. This is like a restaurant registering its menu (service capabilities) with a food platform (SAMgr) so that customers (Client side) can know what foods (services) it can provide.
The Client side, that is, the party requesting the service, is similar to a customer. When the Client side needs to use the service of the Server side, it must first obtain the proxy Proxy object of the Server side from the SAMgr, and then communicate with the Server side through this proxy object. This is like a customer finding the menu (Proxy) of a restaurant on a food platform, and then placing an order (initiating a request) according to the menu. The kitchen (Server) prepares the food (processes the request) according to the order, and finally the waiter (driver) delivers the food to the customer's table (returns the processing result).

Different Communication Mechanisms Using the Binder and Soft Bus (Soft Bus) Drivers

In IPC communication, when using the Binder driver, it establishes an efficient communication link within the device. The Binder driver is like an internal dedicated expressway, and data between processes can be transmitted quickly and stably. For example, in a large enterprise (device), different departments (processes) conduct frequent data exchanges through the internal high - speed network (Binder driver) to ensure the efficient operation of the business.
RPC communication relies on the soft bus driver, and the soft bus driver is like a transportation network connecting different cities (devices). It enables processes on different devices to communicate across device boundaries. For example, in a cross - city chain enterprise, branches (devices) in different cities can share information and conduct business collaboration through the public transportation network (soft bus driver). For example, the headquarters (a process on one device) can remotely control the promotional activities (call methods) of a branch (a process on another device).

Application Scenarios of IPC Kit

Background Service Invocation by IPC

One of the typical application scenarios of IPC in HarmonyOS applications is background service invocation. For example, in a download application, its background download service process is responsible for downloading files, and the user interface process needs to obtain the download progress, pause or continue the download, and other operations. Through the IPC mechanism, the user interface process can communicate with the background download service process to achieve these functions. This is like when you download a movie on your mobile phone, the download interface (user interface process) can display the download progress in real time (obtain information from the background service process), and you can also pause or continue the download (send requests to the background service process).

Multi - Terminal Collaborative Applications of RPC

RPC plays an important role in multi - terminal collaborative scenarios. Taking a smart home as an example, your mobile phone (one device) can call the music playback method of a smart speaker (another device) through RPC to achieve remote control of music playback. Or in a distributed office scenario, you can remotely access and edit and save file resources on the company server (another device) from your computer (one device), which are all practical applications of RPC in achieving inter - process communication between cross - devices.

Sample Code and Diagrams

The following is a simple example code for system ability registration:

// Assume this is a custom service class that inherits from a certain system service base class
public class MyService extends SystemAbility {
    private static final int MY_SERVICE_ID = 12345;
    public MyService() {
        super(MY_SERVICE_ID);
    }
    @Override
    public void onStart() {
        // Perform initialization work of the service here
        super.onStart();
    }
    @Override
    public void onStop() {
        // Perform stop and cleanup work of the service here
        super.onStop();
    }
    // Define the method provided by the service
    public void doSomething() {
        // Specific service logic
    }
}
// Register the service when the application starts
public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        MyService myService = new MyService();
        try {
            // Register the service with the System Ability Manager
            SystemAbilityManager.addSystemAbility(myService);
        } catch (SystemAbilityManager.SystemAbilityError error) {
            // Handle the case of registration failure
            error.printStackTrace();
        }
    }
}

The following is a simple schematic diagram of the Client - Server architecture (here is a text description, and a professional architecture diagram can be actually drawn):
| Component | Description |
|---|---|
| Client Side | The process that initiates a request to the Server side and calls the methods of the Server side by obtaining the proxy Proxy object of the Server side. |
| Proxy | Located in the Client side process, it has the same interface definition as the Server side and is responsible for forwarding the requests of the Client side to the Server side and passing the return results of the Server side to the Client side. |
| Server Side | The process that provides services and contains the specific business logic implementation. |
| Stub | Located in the Server side process, it receives the requests forwarded by the Proxy, calls the actual business methods of the Server side, and returns the results to the Proxy. |
| System Ability Manager (SAMgr) | Responsible for managing system capabilities (services), providing an interface for the Client side to obtain the proxy object of the Server side, and coordinating the registration, query, and startup of services. |
| Binder Driver (IPC) or Soft Bus Driver (RPC) | Responsible for transmitting data and messages between processes and achieving inter - process communication. |
Through the above introduction to the IPC Kit, I hope that everyone can better understand the inter - process communication mechanism in HarmonyOS, so as to use IPC and RPC more flexibly in application development and build powerful and efficiently collaborative application programs. Next time, we will deeply explore the development practices of the IPC Kit, including how to write efficient IPC communication code and other content. Stay tuned! Haha, that's all for today's explanation. I hope I didn't confuse you. If you have any questions, feel free to come to me, the "technical old driver"!