EventBusSA system based on Hongmeng L2 rich devices

Abstract

The eventBusSA system based on Hongmeng L2 rich devices includes multiple Apps, eventBus system services, and brokers; the publishing function of the sending end of the App is configured to provide a publishing function through an IPC call to the SA service registered to SAMGR; the eventBus system service forwards the relevant message of the App to the broker after receiving it; the receiving end of the App subscribes to the broker through the socket method. The receiving end App of the present invention only needs to subscribe to the message, and the sending end App sends the corresponding message to complete the internal message loop.

Description

Technical Field

[0001] The present invention relates to the field of eventBusSA systems, and in particular to an eventBusSA system based on Hongmeng L2 rich devices. Background Art

[0002] The traditional openharmony Hongmeng SA (system ability) service is implemented internally using the binder driver. The SA service can provide fa, pa (feature ability, particle ability) with the ability to call across processes by registering with samger, but the SA itself cannot actively send messages to pa, fa (feature ability, particle ability). The eventBusSa system provides both the ability of ordinary pa, fa (feature ability, particle ability) to call (communicate) across processes and the ability of sa (system ability) to communicate back to pa, fa (feature ability, particle ability). It provides a complete internal event broadcast loop mechanism for the end-side device. Summary of the invention

[0003] In view of the above, the object of the present invention is to provide an eventBusSA system based on Hongmeng L2 rich devices, including multiple Apps, eventBus system services, and brokers;

[0004] The publishing function of the sending end of the App is configured to provide the publishing function by calling the SA service registered to SAMGR through IPC;

[0005] The SAMGR is configured to manage all SAs and provides an interface for registering and obtaining all SA services;

[0006] The SA is configured as a system service-level process, which runs in the background and provides some cross-process calling interfaces that can be called by other processes;

[0007] The eventBus system service receives the relevant message from the App and forwards it to the broker. In the entire openharmony project, the eventBus module is added, and the entire source code is compiled and configured by writing and configuring the GN script to generate the corresponding product image. When the corresponding image is burned into the specified product, the system of the product has the ability of the eventBus system service.

[0008] The broker is located on the MQTT server of the terminal, and provides local message sending and subscription related functions through MQTT connection;

[0009] The receiving end of the App subscribes to messages from the broker via socket;

[0010] Specifically, the sender of App sends a message, App requests eventBus service from SAMGR, eventBus provides registration service to SAMGR, SAMGR returns the registration result to eventBus, the eventBus connects to the broker, the broker starts itself, the broker returns the connection result to eventBus, and App obtains the relevant interface of eventBus;

[0011] The sender of the App sends the message to the eventBus through the publish connection. The eventBus returns the interface call result to the App. The eventBus forwards the message to the broker. The receiver of the App receives the message by subscribing to the broker.

[0012] As a further improvement of the above solution:

[0013] Preferably, the IPC call is implemented through a binder.

[0014] Preferably, the App includes feature ability and particle ability.

[0015] Preferably, the feature ability is configured to exist on a related page, providing the user with the ability to interact.

[0016] Preferably, the particle ability is configured as an interface-less ability, supporting templates of Service ability and data ability.

[0017] Compared with the prior art, the present invention has the following beneficial effects:

[0018] By adopting the technical solution of the present invention, the App, eventBus, and broker of the present invention complete the internal message publishing and subscription on the device side through three-party linkage. Traditional App message transmission requires knowing the App package name of the other party before sending the specified information to the other party. The combination of eventBus and broker breaks away from this traditional rut. The receiving App only needs to subscribe to the message, and the sending App sends the corresponding message to complete the internal message cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a flow chart of the structure of the present invention.

[0020] Figure 2 It is a timing diagram of the process of the present invention.

[0021] Figure numerals: 1. App application layer; 2. System service layer. DETAILED DESCRIPTION

[0022] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

[0023] In the description of the present invention, unless otherwise specified, "plurality" means two or more than two; the orientations or positional relationships indicated by the terms "upper", "lower", "left", "right", "inner", "outer", "front end", "rear end", "head", "tail", etc. are based on the orientations or positional relationships shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", "third", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0024] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "connected" and "connection" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0025] Example:

[0026] like Figure 1-2 As shown, the eventBusSA system based on Hongmeng L2 rich devices includes multiple apps, eventBus system services, and brokers;

[0027] The publishing function of the sending end of the App is configured to provide the publishing function by calling the SA service registered to SAMGR through IPC;

[0028] The eventBus system service forwards the App-related message to the broker after receiving it;

[0029] The receiving end of the App subscribes to messages from the broker via socket.

[0030] The IPC call is implemented through binder.

[0031] The App includes feature ability and particle ability.

[0032] The feature ability is configured to exist on a related page, providing the user with the ability to interact.

[0033] The particle ability is configured as an interface-less ability, supporting templates for Service ability and dataability.

[0034] The SA is configured as a system service-level process, which runs in the background and provides some cross-process calling interfaces that can be provided to other processes for calling.

[0035] The SAMGR is configured to manage all SAs and provides interfaces for registering and obtaining all SA services.

[0036] The broker is located on the MQTT server on the terminal and provides local message sending and subscription related functions through MQTT connection.

[0037] The working principle of the present invention is: using eventBus service, adopting the source code construction method. In the whole openharmony project, add eventBus module, compile the whole source code by writing and configuring GN script, and generate the corresponding product image. When the corresponding image is burned into the specified product, the system of the product has the ability of eventBus system service;

[0038] Use broker service and build from source code. In the whole openharmony project, add broker module, compile the whole source code by writing and configuring GN scripts, and generate the corresponding product image. When the corresponding image is burned into the specified product, the system of the product will have the ability of broker system service.

[0039] Including App application layer 1 and system service layer 2, the publishing function of each App message is provided by the SA service registered to SAMGR through IPC call (binder implementation). The traditional IPC methods on Linux, such as pipes, message queues, and sockets, require two memory copies to implement one process communication, which is too inefficient; the shared memory method does not require copying, but multi-process synchronization is complex to manage. The Binder driver uses one memory copy, which is lower than shared memory in terms of performance and better than other methods.

[0040] App message subscription function: App subscribes to messages from broker (socket mode), and eventBus forwards messages from App to broker after receiving them, so that the subscribed App receives the messages.

[0041] The sender of App sends a message, App requests eventBus service from SAMGR, eventBus provides registration service to SAMGR, SAMGR returns the registration result to eventBus, the eventBus connects to broker, the broker starts itself, the broker returns the connection result to eventBus, and App obtains the relevant interface of eventBus;

[0042] The sender of the App sends the message to the eventBus through the publish connection. The eventBus returns the interface call result to the App. The eventBus forwards the message to the broker. The receiver of the App receives the message by subscribing to the broker.

[0043] The above-mentioned embodiments are only preferred embodiments of the present invention, and cannot be used to limit the scope of rights of the present invention. As mentioned above, modifications, equivalent changes, improvements, etc. made according to the scope of the patent application of the present invention are still within the scope covered by the present invention.

Claims

1. The eventBusSA system based on Hongmeng L2 rich devices is characterized by: Including multiple apps, eventBus system services, and brokers; The publishing function of the sending end of the App is configured to provide the publishing function by calling the SA service registered to SAMGR through IPC; The SAMGR is configured to manage all SAs and provides an interface for registering and obtaining all SA services; The SA is configured as a system service-level process, which runs in the background and provides some cross-process calling interfaces that can be called by other processes; The eventBus system service receives the relevant message from the App and forwards it to the broker. In the entire openharmony project, the eventBus module is added, and the entire source code is compiled and configured by writing and configuring the GN script to generate the corresponding product image. When the corresponding image is burned into the specified product, the system of the product has the ability of the eventBus system service. The broker is located on the MQTT server of the terminal, and provides local message sending and subscription related functions through MQTT connection; The receiving end of the App subscribes to messages from the broker via socket; Specifically, the sender of App sends a message, App requests eventBus service from SAMGR, eventBus provides registration service to SAMGR, SAMGR returns the registration result to eventBus, the eventBus connects to the broker, the broker starts itself, the broker returns the connection result to eventBus, and App obtains the relevant interface of eventBus; The sender of the App sends the message to the eventBus through the publish connection. The eventBus returns the interface call result to the App. The eventBus forwards the message to the broker. The receiver of the App receives the message by subscribing to the broker.

2. The eventBusSA system based on Hongmeng L2 rich device according to claim 1 is characterized in that: The IPC call is implemented through binder.

3. The eventBusSA system based on Hongmeng L2 rich device according to claim 1 is characterized in that: The App includes feature ability and particle ability.

4. The eventBusSA system based on Hongmeng L2 rich device according to claim 3 is characterized in that: The feature ability is configured to exist on a related page, providing the user with the ability to interact.

5. The eventBusSA system based on Hongmeng L2 rich device according to claim 3 is characterized in that: The particle ability is configured as an ability without an interface, and supports templates of Service ability and data ability.

Images