Cross-layer cooperation method and system for honrong web components in cross-platform applications

Abstract

The application discloses a cross-platform application Hongmeng Web component cross-layer cooperation method and system. First, a communication association between a cross-platform application sharing layer and a Hongmeng host carrying a Hongmeng Web component is established, and component initialization information, event information and control information are transmitted based on the communication association, so that data interaction between the sharing layer and the Hongmeng Web component is realized. According to the Hongmeng Web component running state, a corresponding control request is processed, so that the control request is matched with the component control state; and according to the life cycle state of the cross-platform application sharing layer and the Hongmeng host, the communication association and the component resource are managed, so that the state consistency between the cross-platform application sharing layer, the Hongmeng host and the Hongmeng Web component is maintained.

Description

Technical Field

[0001] This invention relates to the field of application development technology, and more specifically, to a method and system for cross-layer collaboration of HarmonyOS Web components in cross-platform applications. Background Technology

[0002] With the development of cross-platform application technologies, cross-platform application sharing layers are typically used to uniformly implement application interfaces, business logic, and state management. However, different operating system platforms still need to host platform-specific components through native hosts. In HarmonyOS application scenarios, Web components are usually hosted by the HarmonyOS host. The cross-platform application sharing layer needs to pass initialization parameters and control information to HarmonyOS Web components through cross-layer communication, while also receiving runtime information such as loading, errors, messages, and navigation generated by HarmonyOS Web components.

[0003] In existing interaction methods between cross-platform applications and HarmonyOS Web components, the differences in the runtime environment and lifecycle between the cross-platform application's shared layer and the HarmonyOS host can easily lead to issues such as unstable correspondences between communication objects, untimely acquisition of component states, and mismatches between control requests and the actual runtime state of the Web component. For example, if the cross-platform application's shared layer sends loading or other control requests before the HarmonyOS Web component has the necessary control conditions, the control requests may fail to execute correctly. Furthermore, if the original communication relationships, control resources, and asynchronous tasks are not promptly released or terminated after a component instance exits or the HarmonyOS host is destroyed, invalid calls, post-destruction callbacks, and resource remnants may occur. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for cross-layer collaboration of HarmonyOS Web components in cross-platform applications.

[0005] In a first aspect, embodiments of the present invention provide a method for cross-layer collaboration of HarmonyOS Web components in cross-platform applications, including: Establish a communication relationship between the cross-platform application sharing layer and the HarmonyOS host. The cross-platform application sharing layer is used to provide cross-platform application interfaces and business logic, and the HarmonyOS host is used to carry HarmonyOS Web components. Based on the aforementioned communication association, component initialization information, event information, and control information are transmitted between the cross-platform application sharing layer and the HarmonyOS host to achieve data interaction between the cross-platform application sharing layer and the HarmonyOS Web component. Based on the running status of the HarmonyOS Web component, the control request corresponding to the HarmonyOS Web component is processed so that the control request matches the control status of the HarmonyOS Web component; Based on the lifecycle states of the cross-platform application sharing layer and the HarmonyOS host, the communication associations and resources corresponding to the HarmonyOS Web components are managed to maintain state consistency among the cross-platform application sharing layer, the HarmonyOS host, and the HarmonyOS Web components.

[0006] In one possible implementation, establishing the communication association between the cross-platform application sharing layer and the HarmonyOS host includes: The cross-platform application sharing layer creates an interface parameter object for each HarmonyOS Web component instance and passes the interface parameter object to the HarmonyOS host through the native interface call mechanism; The HarmonyOS host stores the interface parameter object itself, and writes control functions for controlling the HarmonyOS Web components based on the interface parameter object; The cross-platform application sharing layer writes event handling functions through the interface parameter object, so that the event handling function and the control function form a bidirectional communication channel based on the same interface parameter object.

[0007] In one possible implementation, the method further includes: When the HarmonyOS Web component generates a loading event, error event, message event, or navigation event, it sends event information to the cross-platform application sharing layer through the event handling function in the interface parameter object. In response to the received event information, the cross-platform application sharing layer updates the component state corresponding to the HarmonyOS Web component.

[0008] In one possible implementation, processing the control request based on the running state of the HarmonyOS Web component includes: Obtain the controller attachment status corresponding to the HarmonyOS Web component; When the controller attachment state indicates that the controller has not completed attachment, the loading command corresponding to the control request is temporarily stored. After the controller is attached, indicating that the attachment is complete, the control function is invoked to execute the loading command.

[0009] In one possible implementation, when unbinding the controller proxy relationship corresponding to the HarmonyOS Web component, the identity information of the interface parameter object corresponding to the controller proxy to be unbound is obtained; Compare the identity information of the interface parameter object with the identity information of the interface parameter object corresponding to the current HarmonyOS Web component instance; When the identity information of the interface parameter objects is consistent, the controller proxy relationship removal operation is performed to avoid resource unbinding errors between different component instances.

[0010] In one possible implementation, managing resources based on the lifecycle state of the cross-platform application sharing layer and the HarmonyOS host includes: When the component instance corresponding to the cross-platform application sharing layer exits, the event handling function binding relationship is released, the controller proxy relationship is released, the asynchronous task corresponding to the component instance is canceled, and the interface resources corresponding to the communication association are released. When the HarmonyOS host exits, the host service binding is released and any unfinished asynchronous calls are terminated.

[0011] In one possible implementation, a status identifier field is set in the interface parameter object, the status identifier field being used to characterize the communication status corresponding to the HarmonyOS Web component instance; the method further includes: When the cross-platform application sharing layer sends a control request to the HarmonyOS host, it determines whether the HarmonyOS Web component instance is in a valid communication state based on the status identifier field. When the status identifier field indicates that the HarmonyOS Web Component instance is in an invalid communication state, the control request is prevented from entering the HarmonyOS Web Component, and the corresponding request termination process is executed.

[0012] In one possible implementation, an asynchronous call management relationship is established between the HarmonyOS host and the cross-platform application sharing layer; the method further includes: When the cross-platform application sharing layer sends an asynchronous control request, it establishes a corresponding request identifier for the asynchronous control request and associates the request identifier with the interface parameter object; When the asynchronous control request is completed, canceled, or the HarmonyOS host is unbound, the corresponding asynchronous call resources are released according to the request identifier.

[0013] In one possible implementation, the cross-platform application sharing layer updates the component state based on the received event information; the event information includes event type information and event data; the method further includes: The cross-platform application sharing layer is invoked to determine the corresponding state update logic based on the event type information, and the updated component state is saved through a state container so that when the HarmonyOS Web component generates a new event, the event processing is performed based on the latest component state.

[0014] Secondly, embodiments of the present invention provide a cross-layer collaborative system for HarmonyOS Web components in a cross-platform application, including at least one service node; The service node includes a storage unit and a computing unit; the storage unit is used to store program code; the computing unit is used to run the program code to execute the cross-layer collaboration method of HarmonyOS Web components in cross-platform applications as described in the first aspect.

[0015] Compared to existing technologies, the beneficial effects provided by this invention include: by establishing a bidirectional communication association between the cross-platform application sharing layer and the HarmonyOS host, efficient transmission of component initialization information, event information, and control information is achieved, reducing repeated calls and response delays caused by periodic querying of Web component status; by processing control requests in conjunction with the running status of HarmonyOS Web components, the risk of control command execution failure or loss when the controller is not ready can be reduced; at the same time, by coordinating the management of communication relationships, control resources, and asynchronous tasks according to the lifecycle status of the cross-platform application sharing layer and the HarmonyOS host, invalid callbacks after component destruction, resource residues, and erroneous unbinding between instances can be reduced, improving the consistency, stability, and reliability of HarmonyOS Web component communication, control, and lifecycle management in cross-platform applications. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as limiting the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the steps of the cross-platform application HarmonyOS Web component cross-layer collaboration method provided in this embodiment of the invention.

[0018] Figure 2 This is a block diagram of the CMP HarmonyOS Web component collaborative system provided in an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram of a bidirectional communication relationship based on the same interface parameter object provided in an embodiment of the present invention;

[0020] Figure 4 A schematic block diagram of a computer structure provided for an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0022] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0023] In order to solve the technical problems mentioned in the background art Figure 1 This is a flowchart illustrating the cross-layer collaboration method of HarmonyOS Web components in a cross-platform application provided in this embodiment of the disclosure. The following is a detailed description of the cross-layer collaboration method of HarmonyOS Web components in a cross-platform application.

[0024] Step S201: Establish a communication relationship between the cross-platform application sharing layer and the HarmonyOS host. The cross-platform application sharing layer is used to provide cross-platform application interfaces and business logic, and the HarmonyOS host is used to carry HarmonyOS Web components. Step S202: Based on the communication association, component initialization information, event information, and control information are transmitted between the cross-platform application sharing layer and the HarmonyOS host to realize data interaction between the cross-platform application sharing layer and the HarmonyOS Web component. Step S203: Based on the running state of the HarmonyOS Web component, process the control request corresponding to the HarmonyOS Web component so that the control request matches the control state of the HarmonyOS Web component. Step S204: Based on the lifecycle states of the cross-platform application sharing layer and the HarmonyOS host, manage the communication association and the resources corresponding to the HarmonyOS Web component to maintain the consistency of the states among the cross-platform application sharing layer, the HarmonyOS host, and the HarmonyOS Web component.

[0025] In this embodiment of the invention, an exemplary method for cross-layer collaboration of HarmonyOS Web components in a cross-platform application is provided. This method is applied to a server, which is used to uniformly manage and coordinate the data interaction process between the cross-platform application sharing layer, the HarmonyOS host, and the HarmonyOS Web components. The cross-platform application sharing layer provides a cross-platform application interface and business logic processing capabilities, while the HarmonyOS host runs within the HarmonyOS system environment and hosts the HarmonyOS Web components. The server enables communication connections, state synchronization, and resource collaborative management between the cross-platform application sharing layer and the HarmonyOS Web components.

[0026] In this embodiment, the server first establishes a communication association between the cross-platform application sharing layer and the HarmonyOS host. During the operation of the cross-platform application, when it is necessary to create a HarmonyOS Web component instance, the server establishes a corresponding communication association based on the component instance information and generates a data object describing the component instance's state and communication capabilities. This data object carries the information required for interaction between the cross-platform application sharing layer and the HarmonyOS host, enabling the cross-platform application sharing layer to send component control requests to the HarmonyOS host through this communication association, and simultaneously enabling the HarmonyOS host to provide feedback on the status information of the HarmonyOS Web component during its operation to the cross-platform application sharing layer through this communication association.

[0027] For example, when a cross-platform application needs to display web page content, the server creates a corresponding HarmonyOS Web component instance based on the page's business requirements and establishes a communication relationship between this component instance and the cross-platform application's sharing layer. This allows the sharing layer to send requests related to web page loading and page control to the HarmonyOS host, while simultaneously enabling the HarmonyOS host to report the Web component's running status back to the sharing layer. Through this communication relationship, the cross-platform application's sharing layer can control and obtain the status of the HarmonyOS Web component without directly understanding the implementation details of the HarmonyOS system's internal components.

[0028] After establishing a communication association, the server transmits component initialization information, event information, and control information between the cross-platform application sharing layer and the HarmonyOS host based on the communication association, so as to realize data interaction between the cross-platform application sharing layer and the HarmonyOS Web component.

[0029] Specifically, during the initialization phase of the HarmonyOS Web Component, the server transmits the initialization information generated by the cross-platform application sharing layer to the HarmonyOS host, enabling the HarmonyOS host to complete the HarmonyOS Web Component configuration based on the initialization information. During the operation of the HarmonyOS Web Component, the server receives event information generated by the HarmonyOS host and transmits this event information to the cross-platform application sharing layer, allowing the cross-platform application sharing layer to update its application state according to the Web Component's running status. Simultaneously, when the cross-platform application sharing layer generates control requests, the server sends the corresponding control information to the HarmonyOS host, which then performs the appropriate operations on the HarmonyOS Web Component based on the control information.

[0030] For example, during application operation, after the HarmonyOS Web component completes page loading, it generates a corresponding loading status event. The server obtains this event information and synchronizes it to the cross-platform application sharing layer, enabling the application interface to update according to the current Web component state. When a user performs web page control operations in the cross-platform application, the server receives the corresponding control request and sends the control information to the HarmonyOS host through communication association, causing the HarmonyOS Web component to perform the corresponding operation.

[0031] In this way, the server enables a two-way communication mechanism between the cross-platform application sharing layer and the HarmonyOS Web components. One direction is used to transmit control information, enabling the sharing layer to control the Web components, and the other direction is used to transmit event information, enabling the Web component state to be synchronized with the sharing layer. This avoids the resource consumption and untimely state synchronization problems caused by continuously querying the component state in the traditional method.

[0032] Furthermore, the server processes the control requests corresponding to the HarmonyOS Web Component based on the running status of the HarmonyOS Web Component, so that the control requests match the current control status of the HarmonyOS Web Component.

[0033] Specifically, after receiving a control request from the cross-platform application sharing layer, the server obtains the current running status of the HarmonyOS Web component and determines the execution method of the control request based on the running status. When the HarmonyOS Web component meets the conditions for executing the control request, the server sends the control request to the HarmonyOS host, which then controls the Web component to complete the corresponding operation. When the HarmonyOS Web component does not yet meet the execution conditions, the server coordinates the control request to ensure that it continues to execute after the execution conditions are met.

[0034] For example, during the creation of HarmonyOS Web components, due to the time difference between component initialization and control capability establishment, the HarmonyOS Web component may not yet be in a controllable state when the server receives a webpage loading request. In this case, the server will not directly execute the control request, but will instead temporarily store or delay the request based on the current component state, and continue execution after the HarmonyOS Web component enters a controllable state, thereby avoiding the control request failing due to the component's incomplete state.

[0035] Finally, the server manages the communication associations and corresponding resources of HarmonyOS Web Components based on the lifecycle states of the cross-platform application sharing layer and HarmonyOS host, in order to maintain the consistency of state among the cross-platform application sharing layer, HarmonyOS host, and HarmonyOS Web Components.

[0036] Specifically, the server obtains the status of the corresponding component instance in the cross-platform application sharing layer and the running status of the HarmonyOS host, and performs corresponding resource management operations according to the lifecycle changes. When the corresponding component instance in the cross-platform application sharing layer exits, the server terminates the communication association corresponding to the component instance and releases the running resources associated with the component instance; when the HarmonyOS host exits or becomes unavailable, the server terminates the association with the HarmonyOS host and stops executing related operations that depend on the host.

[0037] For example, when a user leaves an application page containing HarmonyOS Web components, the server detects that the corresponding component instance in the cross-platform application sharing layer has ended running. It then releases the communication resources associated with that component instance to prevent subsequent invalid events or control requests. When the HarmonyOS application exits, the server detects that the HarmonyOS host's lifecycle has ended and synchronously stops related communication tasks, ensuring that the cross-platform application sharing layer and HarmonyOS Web components maintain a consistent lifecycle state.

[0038] Through the above methods, the server establishes a unified collaboration mechanism between the cross-platform application sharing layer, HarmonyOS host, and HarmonyOS Web components, enabling the component communication process, control process, and lifecycle process to be managed according to a unified state. Compared with the existing technologies that lack a unified communication mechanism between the cross-platform sharing layer and native Web components, rely on polling for state synchronization, and have difficulty in coordinating the release of lifecycle resources, this embodiment achieves stable communication and collaborative operation of Web components in cross-platform applications through communication association establishment, bidirectional information transmission, state matching control, and lifecycle resource management.

[0039] In this embodiment of the invention, the establishment of a communication association between the cross-platform application sharing layer and the HarmonyOS host can be implemented through the following example.

[0040] The cross-platform application sharing layer creates an interface parameter object for each HarmonyOS Web component instance and passes the interface parameter object to the HarmonyOS host through the native interface call mechanism; The HarmonyOS host stores the interface parameter object itself, and writes control functions for controlling the HarmonyOS Web components based on the interface parameter object; The cross-platform application sharing layer writes event handling functions through the interface parameter object, so that the event handling function and the control function form a bidirectional communication channel based on the same interface parameter object.

[0041] In this embodiment, when establishing a communication association between the cross-platform application sharing layer and the HarmonyOS host, the server first creates an independent corresponding interface parameter object for each HarmonyOS Web component instance, and then passes the interface parameter object to the HarmonyOS host through the native interface call mechanism to establish a data association between the cross-platform sharing layer and the HarmonyOS host.

[0042] Specifically, when the cross-platform application sharing layer creates a HarmonyOS Web Component instance based on business needs, the server detects the new Web Component instance creation request and generates a corresponding interface parameter object for that instance. This interface parameter object records the communication information corresponding to the current Web Component instance and serves as a unified carrier for subsequent data exchange between the sharing layer and the HarmonyOS host. For example, when a cross-platform application enters a product details page, the page needs to display product description content. The server creates a corresponding HarmonyOS Web Component instance based on the page's business logic and generates an interface parameter object for that instance, while also associating initialization information such as the webpage address and component configuration parameters to this interface parameter object. Subsequently, the server transmits the interface parameter object to the HarmonyOS host through a native interface call mechanism, enabling the HarmonyOS host to obtain the communication data corresponding to the current Web Component instance.

[0043] After the HarmonyOS host receives the interface parameter object, the server controls the HarmonyOS host to save the interface parameter object itself, instead of recreating a corresponding data copy, and writes control functions for controlling the HarmonyOS Web components based on the interface parameter object. These control functions provide the cross-platform application sharing layer with control capabilities over the HarmonyOS Web components, enabling the server to invoke corresponding control logic according to business requests. For example, after receiving the interface parameter object, the HarmonyOS host writes the webpage loading control function, script execution control function, and page return control function into the interface parameter object. When the cross-platform application sharing layer subsequently needs to perform webpage refresh, webpage redirection, or script invocation operations, the server can obtain the corresponding control functions through the interface parameter object and invoke the Web component control capabilities in the HarmonyOS host to complete the corresponding operations.

[0044] Furthermore, the server controls the cross-platform application sharing layer to write event handling functions through the same interface parameter object, enabling the event handling functions and control functions to form a bidirectional communication channel based on the same interface parameter object. Specifically, after completing component initialization, the cross-platform application sharing layer writes the event handling function used to receive the running status of HarmonyOS Web components into the interface parameter object, allowing the HarmonyOS host to feed back the running events generated by the Web components to the sharing layer through this event handling function.

[0045] For example, during the loading of a product details page, after the HarmonyOS Web Component completes the page loading, it generates a loading completion event. The server sends the loading completion information to the cross-platform application sharing layer through the event handling function in the interface parameter object, causing the sharing layer to update the page state. When the user triggers a page return operation, the server sends a control request to the HarmonyOS host through the control function in the same interface parameter object, and the HarmonyOS Web Component executes the return operation. In this way, the server enables the event handling function and the control function to run together based on the same interface parameter object, forming a two-way communication channel for the sharing layer to send control information to the HarmonyOS Web Component and for the HarmonyOS Web Component to feed back event information to the sharing layer, thereby ensuring the consistency and stability of the communication relationship between the cross-platform application sharing layer and the HarmonyOS Web Component. This method corresponds to the implementation method in the technical solution where "the sharing layer creates and maintains an N-API parameter object for each ArkUI Web Component instance, the HarmonyOS host stores the object itself, and the two parties form a two-way channel on the same object."

[0046] In this embodiment of the invention, when the HarmonyOS Web component generates a loading event, an error event, a message event, or a navigation event, it sends event information to the cross-platform application sharing layer through the event handling function in the interface parameter object;

[0047] In response to the received event information, the cross-platform application sharing layer updates the component state corresponding to the HarmonyOS Web component.

[0048] In this embodiment of the invention, the server, based on the established communication association between the cross-platform application sharing layer and the HarmonyOS host, enables the HarmonyOS Web component running events to be actively fed back to the cross-platform application sharing layer. This allows the cross-platform application sharing layer to update the application status in a timely manner according to the actual running status of the HarmonyOS Web component, without having to obtain the component status through periodic queries.

[0049] Specifically, when a HarmonyOS Web component generates a loading event, error event, message event, or navigation event during operation, the server receives the corresponding event notification from the HarmonyOS host and transmits the event information to the cross-platform application sharing layer through the event handling function in the interface parameter object. The event handling function is pre-bound to the interface parameter object corresponding to the current HarmonyOS Web component instance, maintaining a corresponding communication relationship with that component instance. The server generates corresponding event information based on different event types. This event information includes the event type and the event data corresponding to that event type, and completes the event reporting through the event handling function.

[0050] For example, when displaying an online document page in a cross-platform application, the server creates a corresponding HarmonyOS Web Component instance and establishes a communication connection. When a user enters the document page, the HarmonyOS Web Component begins loading the webpage content, generating a loading completion event upon completion. After receiving this loading event, the server sends the loading completion status and corresponding page information to the cross-platform application's shared layer via the event handler function in the interface parameter object. Upon receiving the event information, the cross-platform application's shared layer updates the current page status to the loading completion status and controls the interface to display the corresponding content.

[0051] During the operation of HarmonyOS Web Components, when web page resource access fails or the server returns an error response, HarmonyOS Web Components generate error events. The server obtains data such as the error type and error information corresponding to the error event and sends it to the cross-platform application sharing layer through the event handling function. The cross-platform application sharing layer updates the application state based on the received error event, such as recording the current web page loading failure status, and displays error messages or executes exception handling procedures according to business logic.

[0052] Furthermore, when data interaction occurs between web page content and cross-platform applications, HarmonyOS Web Components generate message events. Upon receiving a message event, the server sends the message content transmitted by the web page to the cross-platform application sharing layer via an event handler function, enabling the sharing layer to update business data based on the message content. For example, after a login operation is completed on a web page, the HarmonyOS Web Components send a user authentication completion message to the server. The server then synchronizes this message to the cross-platform application sharing layer, causing the sharing layer to update the user's login status.

[0053] When a user navigates to a page within a HarmonyOS Web component, the component generates a navigation event. The server retrieves the navigation target address and navigation status information, and notifies the cross-platform application sharing layer through an event handler function, enabling the sharing layer to adjust its current business state based on the navigation result.

[0054] In the aforementioned event handling process, the server does not obtain runtime information by periodically querying the HarmonyOS Web component status through the cross-platform application shared layer. Instead, it actively generates events and sends back status information through the HarmonyOS Web component. For example, the server does not need to continuously read the page loading status, error status, or message status at fixed time intervals. Instead, it immediately receives the event and completes state synchronization when the HarmonyOS Web component generates a corresponding state change. Through this event-driven approach, the server reduces invalid state query operations, improves the information synchronization efficiency between the cross-platform application shared layer and the HarmonyOS Web component, and ensures that the application status remains consistent with the actual runtime status of the HarmonyOS Web component. This implementation corresponds to the technical mechanism in the solution where "when the ArkUI Web component generates loading, error, message, or navigation events, it directly calls the event function in the object to send them to the CMP shared layer without performing fixed-period polling."

[0055] In this embodiment of the invention, the step of processing the control request based on the running status of the HarmonyOS Web component can be implemented through the following example.

[0056] Obtain the controller attachment status corresponding to the HarmonyOS Web component; When the controller attachment state indicates that the controller has not completed attachment, the loading command corresponding to the control request is temporarily stored. After the controller is attached, indicating that the attachment is complete, the control function is invoked to execute the loading command.

[0057] In this embodiment, the server coordinates the control requests sent by the cross-platform application sharing layer according to the current running state of the HarmonyOS Web component, so that the execution timing of the control requests matches the control capability state of the HarmonyOS Web component, avoiding the problem of loading command execution failure due to the asynchronous process of HarmonyOS Web component initialization and control request sending.

[0058] Specifically, when the cross-platform application sharing layer sends a control request to the HarmonyOS Web Component, the server first obtains the attachment status of the controller corresponding to the current HarmonyOS Web Component. The controller attachment status indicates whether the controller corresponding to the HarmonyOS Web Component has completed the binding relationship with the component instance. Once the controller is attached, the server can directly invoke the HarmonyOS Web Component through the controller to perform control operations such as page loading and content updates; when the controller has not yet been attached, the server cannot temporarily perform control operations on the HarmonyOS Web Component through the controller.

[0059] For example, during the startup process of a cross-platform application, the server creates a HarmonyOS Web Component instance to display news content based on a business page request. Immediately after the component is created, the cross-platform application's shared layer sends a webpage loading request to the server, requesting the loading of the news homepage address. At this point, the HarmonyOS Web Component instance has been created, but its internal controller is still in the initialization phase and has not yet been attached. Upon receiving this loading request, the server first queries the attachment status of the controller corresponding to the current HarmonyOS Web Component to determine that the controller is in an incomplete attachment state.

[0060] When the server detects that the controller has not completed attachment, it does not directly call the control function to execute the loading command, but instead temporarily stores the loading command. The server saves the loading target information corresponding to the current loading request, including the webpage address, loading parameters, and related control information, so that the loading request can continue to be processed after the controller has the ability to execute. For example, the server temporarily stores the loading command corresponding to the news homepage address in the data area associated with the current HarmonyOS Web component instance, waiting for the subsequent controller attachment to be completed.

[0061] After the HarmonyOS Web component initialization is complete, the server retrieves the corresponding controller's attachment status again and detects that the controller has successfully attached. At this point, the server retrieves the previously stored loading command and calls the control capabilities provided by the HarmonyOS host through the control function in the interface parameter object, causing the HarmonyOS Web component to perform the webpage loading operation. After the loading command is executed, the server clears the already executed temporary requests to prevent the same loading command from being executed repeatedly.

[0062] For example, when a user enters an activity page in the application, the server receives a request to load the corresponding webpage. Since the controller is not yet ready, the server temporarily stores the activity page address. Once the HarmonyOS Web Component controller is attached, the server automatically calls the control function to execute the activity page loading command, allowing the webpage content to be displayed correctly.

[0063] In this way, the server incorporates the HarmonyOS Web Component controller state into the control request processing flow. This avoids directly executing invalid control calls before the controller has completed attachment, and promptly resumes control request execution after the controller has completed attachment. This ensures that the cross-platform application sharing layer is unaware of the internal initialization timing differences of the HarmonyOS Web Component, guaranteeing that control requests remain consistent with the HarmonyOS Web Component's running state. This implementation corresponds to the processing mechanism in the technical solution where "the ArkTS host decides whether to immediately execute or temporarily store the loading command based on the ArkUI Web controller's attachment state; if not attached, it saves the most recent command; after attachment, it executes and clears the data."

[0064] In this embodiment of the invention, when the controller proxy relationship corresponding to the HarmonyOS Web component is released, the identity information of the interface parameter object corresponding to the controller proxy to be unbound is obtained; Compare the identity information of the interface parameter object with the identity information of the interface parameter object corresponding to the current HarmonyOS Web component instance; When the identity information of the interface parameter objects is consistent, the controller proxy relationship removal operation is performed to avoid resource unbinding errors between different component instances.

[0065] In this embodiment, when the server removes the controller proxy relationship corresponding to the HarmonyOS Web component, it verifies the correspondence between the controller proxy to be unbound and the current HarmonyOS Web component instance to ensure that only the controller proxy relationship belonging to the current component instance is removed, thus avoiding erroneous unbinding due to multiple HarmonyOS Web component instances running at the same time, which would affect the normal operation of other component instances.

[0066] Specifically, when a cross-platform application's shared layer component instance exits, a page switches, or a HarmonyOS Web component needs to be destroyed, the server receives a request to unbind the controller proxy relationship. The server first obtains the identity information of the interface parameter object corresponding to the controller proxy to be unbound. This interface parameter object identity information uniquely identifies the HarmonyOS Web component instance associated with the current controller proxy, enabling the server to recognize the component instance to which the controller proxy belongs.

[0067] For example, when both a product details page and an order query page are opened simultaneously in a cross-platform application, the server creates corresponding HarmonyOS Web Component instances for each page and establishes an independent interface parameter object for each Web Component instance. Specifically, the product details page corresponds to the first interface parameter object, and the order query page corresponds to the second interface parameter object. The server establishes a controller proxy relationship through the corresponding interface parameter objects, enabling the two Web Component instances to independently receive control requests and return runtime events.

[0068] When a user exits the product details page, the server initiates the destruction process for the corresponding Web component instance and retrieves the identity information of the interface parameter object corresponding to the controller proxy to be unbound. Subsequently, the server obtains the identity information of the interface parameter object corresponding to the HarmonyOS Web component instance that needs to be released and compares the two sets of identity information.

[0069] During the identity information comparison process, the server determines whether the interface parameter object corresponding to the controller proxy to be unbound is consistent with the HarmonyOS Web component instance currently being destroyed. When the identity information of the two interface parameter objects is consistent, it means that the controller proxy to be unbound belongs to the current component instance, and the server performs the controller proxy relationship unbinding operation, releasing the communication and control resources occupied by the controller proxy.

[0070] For example, when exiting a product details page, the server obtains the identity information of the interface parameter object whose controller proxy association to be unbound is the first interface parameter object. Simultaneously, it detects that the identity information of the interface parameter object of the Web component instance corresponding to the currently exiting page is also the first interface parameter object. After determining that both belong to the same component instance, the server releases the controller proxy relationship corresponding to the product details page, causing that component instance to stop receiving subsequent control calls.

[0071] If the server detects that the identity information corresponding to the controller proxy to be unbound is inconsistent with the identity information of the current HarmonyOS Web Component instance, it will not perform the controller proxy unbinding operation. For example, when the order query page is still running, and the server is processing the product details page exit process, if the identity information corresponding to the proxy to be unbound is incorrectly associated with the second interface parameter object, and the server detects the inconsistency, it will retain the controller proxy relationship corresponding to the order query page to avoid erroneously releasing resources that are currently in use.

[0072] By employing the above method, the server introduces an interface parameter object identity verification mechanism during the controller proxy unbinding process. This ensures that the controller proxy unbinding operation maintains a corresponding relationship with the specific HarmonyOS Web component instance, avoiding resource misbinding issues caused by overlapping lifecycles, different destruction orders, or asynchronous processing between multiple component instances. This improves communication stability and lifecycle management accuracy in multi-Web component scenarios across platforms. This implementation corresponds to the protection feature in the technical solution of "comparing the identity of N-API parameter objects during controller proxy unbinding to prevent the old Compose instance from unbinding the new HarmonyOS Web component instance during destruction."

[0073] In this embodiment of the invention, managing resources based on the lifecycle states of the cross-platform application sharing layer and the HarmonyOS host includes: When the component instance corresponding to the cross-platform application sharing layer exits, the event handling function binding relationship is released, the controller proxy relationship is released, the asynchronous task corresponding to the component instance is canceled, and the interface resources corresponding to the communication association are released. When the HarmonyOS host exits, the host service binding is released and any unfinished asynchronous calls are terminated.

[0074] In this embodiment, the server manages the communication associations and corresponding resources of HarmonyOS Web components in a unified manner according to the lifecycle state of the cross-platform application sharing layer and HarmonyOS host. This enables lifecycle changes such as component exit and host exit to trigger corresponding resource release operations, avoiding the problem of event callbacks, control calls or asynchronous task execution after component destruction, thereby ensuring the consistency of state between the cross-platform application sharing layer, HarmonyOS host and HarmonyOS Web components.

[0075] Specifically, when a component instance corresponding to the cross-platform application's shared layer exits, the server first detects a change in the current component instance's lifecycle state and initiates the component resource release process. Based on the identifier of the exiting component instance, the server retrieves the interface parameter object and related communication resources corresponding to that component instance, and sequentially unbinds the event handling function, controller proxy, asynchronous tasks, and interface resources associated with that component instance.

[0076] For example, in a cross-platform application, when a user opens a business page that displays web page content, the server creates a corresponding HarmonyOS Web Component instance for that page and establishes a communication link between the cross-platform application's shared layer and the HarmonyOS host. During page execution, the HarmonyOS Web Component uses event handlers to report page loading status, error messages, and page messages to the shared layer. Simultaneously, the shared layer sends control requests such as page loading and script execution to the HarmonyOS Web Component through a controller proxy. When the user exits the page, the server detects the exit event of the corresponding component instance and first unbinds the event handlers, preventing subsequent loading events and message events generated by the HarmonyOS Web Component from being sent to the already exited shared layer instance.

[0077] Subsequently, the server terminates the controller proxy relationship corresponding to the component instance, preventing the cross-platform application's shared layer from accessing the exited HarmonyOS Web component through the original control relationship. Simultaneously, the server retrieves the list of asynchronous tasks associated with the component instance and cancels any asynchronous tasks still in execution. For example, if a webpage loading request, script execution request, or state synchronization task is not yet completed, the server terminates the corresponding task based on the component's exit status, preventing callbacks to the destroyed component instance after the asynchronous task is completed.

[0078] After completing the above processing, the server releases the interface resources in the communication association corresponding to the component instance, including interface parameter objects, event handling resources, and control communication resources, so that the communication link after the component instance exits is completely disconnected.

[0079] Furthermore, when the HarmonyOS host exits, the server performs host-level resource cleanup operations based on the HarmonyOS host's lifecycle state. The server first checks whether the HarmonyOS host is in an exited state and then releases the service binding relationship with the HarmonyOS host, so that the cross-platform application sharing layer no longer sends control requests to the exited HarmonyOS host.

[0080] For example, during the overall shutdown of HarmonyOS applications, the HarmonyOS host stops running, but some incomplete web control requests or asynchronous call tasks still exist in the cross-platform application shared layer. Upon detecting the HarmonyOS host's exit, the server immediately unbinds from the host service and queries the records of currently incomplete asynchronous calls. For asynchronous calls still waiting for results from the HarmonyOS host, the server proactively terminates the corresponding call process and releases related call resources to prevent requests from being occupied indefinitely due to host unavailability.

[0081] Through the above methods, the server performs layered resource management for two lifecycle scenarios: the exit of cross-platform application shared layer component instances and the exit of the HarmonyOS host. When a component instance exits, the server releases component-level communication and runtime resources; when the host exits, the server releases host-level service resources and terminates unfinished calls. This establishes a coordinated release mechanism between different lifecycle layers, reducing the risks of invalid callbacks, resource residues, and inconsistencies in cross-layer states after destruction. This implementation corresponds to the lifecycle cleanup mechanism in the technical solution that "unbinds event fields and controller proxies, cancels component-level coroutines, and releases N-API functions when Compose exits; and releases host services and terminates unfinished requests when the HarmonyOS host is destroyed."

[0082] In this embodiment of the invention, a status identifier field is set in the interface parameter object, and the status identifier field is used to characterize the communication status corresponding to the HarmonyOS Web component instance; the method also provides the following implementation methods.

[0083] When the cross-platform application sharing layer sends a control request to the HarmonyOS host, it determines whether the HarmonyOS Web component instance is in a valid communication state based on the status identifier field. When the status identifier field indicates that the HarmonyOS Web Component instance is in an invalid communication state, the control request is prevented from entering the HarmonyOS Web Component, and the corresponding request termination process is executed.

[0084] In this embodiment, the server records and judges the current communication status of the HarmonyOS Web component instance by setting a status identifier field in the interface parameter object. This enables the cross-platform application sharing layer to determine whether to allow the execution of control operations based on the actual running status of the component when sending control requests to the HarmonyOS host, thereby avoiding invalid control calls after the component exits, resources are released, or the communication link fails.

[0085] Specifically, when establishing a communication association between the cross-platform application sharing layer and the HarmonyOS host, the server sets a status identifier field in the interface parameter object corresponding to each HarmonyOS Web component instance. This status identifier field describes whether the current HarmonyOS Web component instance is in a valid communication state, such as indicating normal component operation, communication shutdown, or resource release. The server updates the status identifier field based on changes in the HarmonyOS Web component lifecycle and the communication resource status, ensuring that the status identifier field reflects the current component instance's communicability in real time.

[0086] For example, when a product details page is opened in a cross-platform application, the server creates a corresponding HarmonyOS Web component instance and generates an interface parameter object for that instance. The server initializes the status flag field in the interface parameter object, setting the current status to a valid communication state, indicating that the HarmonyOS Web component instance has established a communication relationship. The cross-platform application's shared layer can then send control operations such as loading requests and script execution requests to the Web component through the HarmonyOS host.

[0087] During the normal operation of the component, when the cross-platform application shared layer generates a control request, after receiving the control request, the server first obtains the status identifier field in the interface parameter object corresponding to the current HarmonyOS Web component instance, and determines whether the current component instance is in a valid communication state based on the status identifier field.

[0088] For example, when a user clicks the "Refresh Page" button on a product details page, the cross-platform application shared layer generates a page reload control request and sends it to the server. Upon receiving this control request, the server queries the status flag field in the current interface parameter object. Detecting that this field indicates the HarmonyOS Web Component instance is in a valid communication state, the server continues the control flow, sending the control request to the HarmonyOS host and driving the HarmonyOS Web Component to complete the page refresh operation through a control function.

[0089] Furthermore, the server synchronously updates the status flag field when the component's lifecycle changes. For example, when a user exits the current page, the server updates the status flag field in the corresponding interface parameter object to an invalid communication state based on the component instance's exit status, indicating that the HarmonyOS Web component instance can no longer receive control requests.

[0090] When a cross-platform application's shared layer generates a control request after a component exits, the server receives the request and reads the status flag field from the interface parameter object again. Since the current status flag field indicates that the component instance is in an invalid communication state, the server determines that the control request does not meet the execution conditions and therefore prevents the control request from entering the HarmonyOS Web component, while simultaneously executing the corresponding request termination process.

[0091] For example, after the page is closed, the backend business logic may still generate a web page script execution request. The server detects that the corresponding HarmonyOS Web component has released communication resources, immediately rejects the script execution request, and returns a component unavailable status result to the cross-platform application sharing layer, causing the sharing layer to stop waiting for the HarmonyOS Web component to respond.

[0092] Through the above method, the server establishes a communication status judgment mechanism using the status flag field in the interface parameter object, ensuring that the execution process of control requests remains consistent with the actual lifecycle state of the HarmonyOS Web component. During the effective operation of the component, the server allows control requests to be transmitted and executed normally; when the component is in a release, exit, or communication failure state, the server actively prevents invalid requests from entering the HarmonyOS Web component and completes request termination processing, thereby reducing invalid calls, avoiding abnormal callbacks after destruction, and improving the stability of Web component communication in cross-platform applications. This implementation method corresponds to the design concept in the technical solution of preventing event processing after release through a release flag and ensuring the idempotency of resource release.

[0093] In this embodiment of the invention, an asynchronous call management relationship is established between the HarmonyOS host and the cross-platform application sharing layer; the method also provides the following implementation methods.

[0094] When the cross-platform application sharing layer sends an asynchronous control request, it establishes a corresponding request identifier for the asynchronous control request and associates the request identifier with the interface parameter object; When the asynchronous control request is completed, canceled, or the HarmonyOS host is unbound, the corresponding asynchronous call resources are released according to the request identifier.

[0095] In this embodiment, the server establishes an asynchronous call management relationship between the cross-platform application sharing layer and the HarmonyOS host, and uniformly manages the asynchronous control requests initiated by the cross-platform application sharing layer. This enables each asynchronous control request to be associated with the corresponding HarmonyOS Web component instance, and releases the corresponding resources in a timely manner when the request is completed, canceled, or unbound by the HarmonyOS host, thus avoiding request residues or invalid callbacks during the asynchronous call process.

[0096] Specifically, when the server sends an asynchronous control request to the HarmonyOS host at the cross-platform application sharing layer, it first creates a corresponding request identifier for the current asynchronous control request. This request identifier uniquely identifies the current asynchronous call task, enabling the server to accurately identify the execution status and resource information of each request even when multiple asynchronous requests exist simultaneously. Subsequently, the server associates the request identifier with the interface parameter object corresponding to the current HarmonyOS Web component instance, establishing a correspondence between the asynchronous request and the specific component instance.

[0097] For example, in cross-platform applications, after a user opens an online video page, the page's business logic needs to execute a webpage script through a HarmonyOS Web component to obtain the video playback status. After receiving the asynchronous control request for script execution sent by the cross-platform application's shared layer, the server generates a unique request identifier for the request and associates this identifier with the corresponding interface parameter object of the current online video page. The server records the HarmonyOS Web component instance to which the asynchronous request belongs through the interface parameter object, enabling it to quickly locate the corresponding control task and resource information based on the request identifier.

[0098] During the execution of asynchronous control requests, the server continuously manages the request status and updates the corresponding request information based on the execution results returned by the HarmonyOS host. For example, after receiving a script execution request, the HarmonyOS host controls the HarmonyOS Web component to execute the webpage script and returns the execution result upon completion. The server locates the corresponding asynchronous call record based on the request identifier, returns the execution result to the cross-platform application shared layer, and releases the asynchronous call resources corresponding to the request, including the request record, callback information, and temporary data.

[0099] Furthermore, when an asynchronous control request is cancelled, the server locates the corresponding asynchronous call resource based on the request identifier and performs cancellation processing. For example, if a user exits the current page during webpage loading, the cross-platform application's shared layer no longer needs the previously sent asynchronous webpage loading request. After detecting the component instance's exit status, the server finds the incomplete asynchronous call task based on the request identifier associated with the interface parameter object, cancels the corresponding task, releases the resources occupied by the request, and prevents the asynchronous task from continuing to access the exited component instance.

[0100] When the HarmonyOS host is unbound, the server also performs asynchronous resource release operations based on the request identifier. For example, during the shutdown of a HarmonyOS application, the HarmonyOS host stops providing control capabilities for Web components, but there are still asynchronous call requests waiting for results in the cross-platform application's shared layer. After detecting the host's unbound state, the server retrieves all incomplete asynchronous requests based on the request identifier associated with the interface parameter object, terminates the corresponding call process, and releases related callback resources, ensuring that asynchronous requests do not continue to wait for the no longer available HarmonyOS host.

[0101] Through the above methods, the server establishes an asynchronous call management mechanism centered on request identifiers. This enables asynchronous control requests to remain associated with specific HarmonyOS Web component instances, covering various lifecycle scenarios such as request completion, active cancellation, and host unbinding. During asynchronous calls, the server can accurately locate and promptly release request resources, reducing resource consumption, invalid callbacks, and state inconsistencies caused by asynchronous task remnants during cross-platform communication. This implementation corresponds to the cancelable asynchronous call registration management mechanism proposed in the technical solution, which associates cancelable continuation bodies, callback registration information, and pending processing sets, and releases the corresponding function callback resources upon completion, cancellation, or unbinding from the HarmonyOS host.

[0102] In this embodiment of the invention, the cross-platform application sharing layer updates the component state according to the received event information; the event information includes event type information and event data; the method also provides the following implementation methods.

[0103] The cross-platform application sharing layer is invoked to determine the corresponding state update logic based on the event type information, and the updated component state is saved through a state container so that when the HarmonyOS Web component generates a new event, the event processing is performed based on the latest component state.

[0104] In this embodiment, the server updates and manages the component state in the cross-platform application sharing layer based on the event information generated by the HarmonyOS Web component. This enables the cross-platform application sharing layer to continuously save the latest running state of the HarmonyOS Web component and execute the corresponding processing logic according to the latest component state when new event information is received, thereby ensuring the state synchronization between the cross-platform application sharing layer and the HarmonyOS Web component.

[0105] Specifically, when a HarmonyOS Web component generates a runtime event, the server receives the corresponding event information through the event handling function in the interface parameter object. The event information includes event type information and event data corresponding to the event type. The event type information indicates the category to which the current event belongs, such as a loading event, error event, message event, or navigation event; the event data describes the specific content corresponding to the current event, such as the loading address, loading result, error message, message content, or navigation target information.

[0106] For example, when displaying web page content in a cross-platform application, the server establishes a communication relationship between the cross-platform application's shared layer and the HarmonyOS Web Component. When the HarmonyOS Web Component completes loading the web page resources, a loading event is generated. Upon receiving this loading event, the server obtains the event type information, determines that the current event belongs to a loading state change event, and further obtains the loading result information from the event data. Based on the state update logic corresponding to the loading event, the server updates the current component state to "loading complete" and saves the updated component state to the state container.

[0107] The state container is used to store the state information of HarmonyOS Web components currently maintained in the cross-platform application sharing layer, enabling business logic in the sharing layer to execute subsequent processing based on the latest state. For example, the state container stores information such as the current webpage loading state, page address, error status, and message interaction status. When the user continues to operate the application page, the server can directly obtain the current component state from the state container without having to query the HarmonyOS Web component's running status again.

[0108] Furthermore, when the server receives different types of event information, it selects the corresponding state update logic based on the event type. For example, when an error event occurs during the access of a webpage by a HarmonyOS web component, the server identifies the event type as an error event and parses the error code and error description information in the event data according to the error event handling logic. It then updates the component state in the state container to a loading error state and saves the corresponding error information. When a new loading event or recovery event is subsequently received, the server performs the corresponding state transition processing based on the current state saved in the state container.

[0109] For example, in an online video playback page, the HarmonyOS Web component first generates a loading completion event, and the server updates the page state in the state container to a normal operating state. When a network anomaly causes the Web component to generate an error event, the server updates the state container according to the error event, adjusts the current component state to an abnormal state, and records the network error information. When the network recovers, the HarmonyOS Web component generates a loading event again. The server reads the historical state information in the state container, determines that the current component is in the abnormal recovery process, and processes the new loading event according to the corresponding state update logic.

[0110] In this way, the server enables the cross-platform application sharing layer to maintain the state of HarmonyOS Web components based on an event-driven approach, and saves the latest component state through a state container, allowing subsequent event processing to refer to the current valid state. This method avoids the problem of fragmented state information between different events, enabling the cross-platform application sharing layer to continuously process new events generated by HarmonyOS Web components by combining existing states, thereby improving the consistency and reliability of Web component state management in cross-platform applications. This implementation corresponds to the design concept in the technical solution that "the CMP sharing layer uses an updated state container to save the latest event handlers and component states, so that long-standing communication functions can still execute processing based on the latest state after component state changes."

[0111] This embodiment describes a server as the execution entity. The server can correspond to at least one service node executing the program code of this invention. It includes a storage unit for storing the program code and a computing unit for running the program code. During the operation of the cross-platform application, the server uniformly manages the communication relationships, event transmission, control requests, and lifecycle resources between the cross-platform application sharing layer, HarmonyOS host, and HarmonyOS Web components.

[0112] Please refer to the following: Figure 2 , Figure 2 This is a block diagram of the CMP HarmonyOS Web Component Collaboration System provided in this embodiment of the invention. This embodiment is applied to the Compose Multiplatform cross-platform application scenario, where Compose Multiplatform (CMP) is a multi-platform declarative interface framework. The cross-platform application sharing layer uses a shared Compose UI to provide cross-platform application interfaces, business logic, and state organization capabilities. The HarmonyOS host is implemented using ArkTS and serves as the host layer carrying the HarmonyOS ArkUI Web components and HarmonyOS system capabilities. The cross-platform application sharing layer interacts with the HarmonyOS host through a native interface call mechanism. In this embodiment, the native interface call mechanism can specifically adopt the N-API mechanism, establishing a cross-language communication relationship between the Kotlin / CMP sharing layer and the HarmonyOS ArkTS host through N-API parameter objects.

[0113] The server establishes a corresponding communication relationship for each HarmonyOS Web component instance, enabling different Web component instances to have independent communication objects, event handling relationships, control capabilities, and lifecycle boundaries. Thus, a Web component instance, from creation, controller attachment, normal operation, to component exit and host destruction, can coordinate its state around the corresponding communication object.

[0114] In a specific application scenario, a cross-platform application provides business pages containing web page content, such as product details, activity introductions, and online documents. When a user enters the product details page, the server creates a corresponding HarmonyOS Web Component instance based on the page creation request of the cross-platform application's shared layer, and creates an interface parameter object for that HarmonyOS Web Component instance. This interface parameter object corresponds to an N-API parameter object in the N-API implementation. Its object identity remains unchanged during the lifetime of the Web Component instance, and it serves as a common carrier for exchanging initialization information, event capabilities, and control capabilities between the cross-platform application's shared layer and the HarmonyOS host.

[0115] During the interface parameter object creation phase, the server writes the initialization information required by the current HarmonyOS Web component into it. This initialization information includes the URL to be loaded, optional HTML content, component configuration attributes, and information related to handling Web component runtime events. For example, the interface parameter object corresponding to a product details page contains the product details webpage address and the Web component configuration used by the current page. When the business side directly provides HTML content, HTML data can also be saved simultaneously. Different Web component instances correspond to different interface parameter objects, achieving isolation between component instances through the object identity of the interface parameter object.

[0116] The server transmits the interface parameter object to the HarmonyOS ArkTS host via N-API. Upon receiving the interface parameter object, the HarmonyOS host saves the interface parameter object itself, rather than reading its attributes and regenerating a new copy. Thus, the cross-platform application sharing layer and the HarmonyOS host operate on the same interface parameter object with the same object identity. By saving the object itself, it ensures that if one side adds or modifies function capabilities to the object later, the other side can still obtain the corresponding capabilities from the same object, avoiding the interruption of the bidirectional communication link due to event functions or control functions existing in different objects caused by object copying.

[0117] Please refer to the following: Figure 3 , Figure 3 This is a schematic diagram illustrating a bidirectional communication relationship based on the same interface parameter object, provided by an embodiment of the present invention. After the HarmonyOS host saves the interface parameter object, the server controls the HarmonyOS host to write control functions for operating HarmonyOS Web components into the interface parameter object. These control functions include webpage loading control functions, script execution control functions, and page return control functions. The cross-platform application sharing layer writes loading event handling functions, error event handling functions, message event handling functions, and navigation event handling functions into the same interface parameter object. Thus, a single interface parameter object simultaneously contains event receiving capabilities provided by the cross-platform application sharing layer and Web component control capabilities provided by the HarmonyOS host.

[0118] Specifically, an event uplink channel is formed from the HarmonyOS Web Components to the cross-platform application sharing layer; a control downlink channel is formed from the cross-platform application sharing layer to the HarmonyOS Web Components. The server thus utilizes the same interface parameter object to complete bidirectional capability organization, without needing to establish two separate and difficult-to-match cross-language communication connections.

[0119] After the cross-platform application sharing layer and HarmonyOS host form a two-way communication channel based on the same interface parameter object, the server further coordinates the event handling, component status, control requests, controller attachment status, communication status, asynchronous calls, and lifecycle resources of HarmonyOS Web components.

[0120] During the normal operation of HarmonyOS Web Components, the server obtains the Web Component state using an event-driven approach, rather than using a periodic query method to read the component state. When the ArkUI Web Component generates a load event, error event, message event, or navigation event, the HarmonyOS host obtains the corresponding event and sends the event information directly to the cross-platform application shared layer through the event handling function in the current interface parameter object.

[0121] For example, the server controls the HarmonyOS Web Component to load a product details webpage. When the webpage starts loading, the HarmonyOS Web Component generates a loading event; after the webpage finishes loading, it generates a corresponding loading completion event. The server sends the loading status and corresponding page information to the cross-platform application sharing layer through the loading event handler function in the interface parameter object. After receiving this information, the cross-platform application sharing layer updates the current page state, enabling the application interface to close the loading prompt and display the webpage content.

[0122] When a webpage fails to access a page, the HarmonyOS Web Component generates an error event. The server passes the error type, error code, or error description, etc., to the shared layer through an error event handling function. The shared layer updates the component state based on the error event and performs error display, reloading, or business exception handling. When a webpage sends business data to the application via the Web messaging mechanism, the server forwards the message data to the shared layer through a message event handling function. For example, after completing a business operation within the webpage, a completion message is sent, and the shared layer can modify the native page's business state based on this message.

[0123] When a page redirect occurs within a webpage, the HarmonyOS Web Component generates a navigation event. The server retrieves the navigation target information and sends it to the shared layer through the navigation event handler function. Furthermore, the navigation event handler function can synchronously return a navigation determination result. Based on the returned Boolean determination value, the HarmonyOS Web Component determines whether the current navigation request should continue to be executed by the Web Component or be intercepted and processed by the cross-platform application.

[0124] This embodiment no longer requires the cross-platform application sharing layer to query loading status, error codes, or message sequence numbers at fixed intervals. The original method, which performed status reads every 50 milliseconds, still required continuous querying even when no new events were present, and new events could only be detected in the next query cycle. With the direct event callbacks of this embodiment, cross-layer event processing is only triggered when a HarmonyOS Web component actually generates an event, thereby reducing redundant scheduling during event-free periods and improving the timeliness of component state changes being transmitted to the sharing layer.

[0125] To enable the cross-platform application sharing layer to process events based on continuous state, the server further establishes a state container in the sharing layer. After receiving event information returned by the HarmonyOS Web component, the server extracts event type information and event data from the event information, determines the corresponding state update logic based on the event type information, and then saves the updated component state through the state container.

[0126] For example, a product details page first generates a loading event, and the server updates the component status in the state container to "loading". After the page loads, the component status is updated to "loading complete". When an error event occurs during page execution, the server records the abnormal state and corresponding error data in the state container; after a successful reload, the normal state is restored based on the new loading event. Message events and navigation events can also execute corresponding business processes based on the current component state stored in the state container.

[0127] The state container can also store the latest event handling state or event handling logic, ensuring that long-term N-API event functions can still be associated with the current valid processing state after Compose is reorganized, instead of continuing to use outdated states. Therefore, when HarmonyOS Web components continuously generate new events, the server always executes event handling based on the latest component state in the shared layer, achieving continuous synchronization between the Web component's running state and the Compose page's business state.

[0128] In the downlink control direction, the server determines the actual timing of the control request execution based on the current running state of the HarmonyOS Web component. Since the ArkUI Web controller may complete its attachment later than the time when the cross-platform application's shared layer creates the Web component and issues the load command, the server first obtains the attachment state of the Web component controller when processing the load request.

[0129] The controller attachment state includes at least an unattached state and an attached state. When the controller has completed attachment, the server directly controls the HarmonyOS Web component to execute the loading command through the loading control function in the interface parameter object; when the controller has not yet completed attachment, the server does not immediately execute the loading command, but temporarily stores the content to be loaded corresponding to the loading command.

[0130] For example, in a cross-platform application's shared layer, the product details page URL is provided immediately after its creation. However, at this time, the ArkUI Web component has already entered the creation process, and its Web controller has not yet been attached. After reading the controller's attachment flag, the server determines that it is currently in an unattached state, and therefore saves the URL as content to be loaded, rather than immediately invoking the Web controller, which is not yet available.

[0131] When the ArkUI Web controller completes its attachment, the server updates the controller's attachment flag, reads the previously stored content, executes the loading operation through the control function, and clears the corresponding stored information after the loading call is complete. Therefore, the shared layer does not need to be aware of when the HarmonyOS-side Web controller completes initialization; it only needs to provide the required content according to the normal business process.

[0132] In this embodiment, loading temporary storage can employ single-slot overwrite semantics, meaning the server stores the most recent loading command that has not yet been executed. When multiple URL or HTML updates occur consecutively before the controller attaches, previously unexecuted loading targets are overwritten by the updated loading targets, and the most recently valid loaded content is executed after the controller attaches. For example, if an initial address and an updated business address are generated sequentially during page creation, the server ultimately retains the updated business address and loads it after the controller attaches, thus ensuring that the final Web content remains consistent with the latest business state of the shared layer.

[0133] The content to be loaded can involve both URLs and optional HTML. After the controller is attached, the server determines the specific loading path based on the currently saved loading content, and can execute the corresponding control function according to either HTML priority or URL loading path. After execution, the pending state is cleared to avoid the same temporary loading command being executed repeatedly.

[0134] To prevent older component instances from incorrectly relinquishing control of newer component instances due to overlapping component lifecycles, the server also manages controller proxy relationships based on the object identity of the interface parameter object. When relinquishing the controller proxy corresponding to a HarmonyOS Web component, the server first obtains the identity information of the interface parameter object associated with the controller proxy to be relinquished, then obtains the identity information of the interface parameter object corresponding to the current Web component instance, and compares whether the two are the same object.

[0135] For example, when cross-platform application pages switch rapidly or Compose is recombined, the old Web component instance enters the destruction process, while a new Web component instance is created. The server maintains separate interface parameter objects for the old and new instances. When the old instance performs controller proxy unbinding, the server compares the interface parameter object carried by the old instance's cleanup operation with the interface parameter object associated with the current controller proxy. If the two identities match, the server performs unbinding; if the two identities do not match, the current proxy relationship is not terminated.

[0136] Therefore, the delayed lifecycle cleanup operation of the old Compose instance will not mistakenly terminate the controller proxy corresponding to the new HarmonyOS Web Component instance, thus achieving resource isolation between different Web Component instances.

[0137] Furthermore, the server can set a status identifier field in each interface parameter object. This status identifier field is used to indicate whether the current HarmonyOS Web component instance is in a valid communication state. When the component is running normally and the communication link is valid, the server keeps the status identifier field in a valid state; when the component instance enters an exit, release, or communication unavailable state, the status identifier field is updated to an invalid state or a released state.

[0138] Whenever a cross-platform application's shared layer sends a control request to the HarmonyOS host, the server first determines whether the current HarmonyOS Web Component instance still has valid communication capabilities based on the status flag field in the interface parameter object. If the status is valid, the server continues with the controller attachment determination and subsequent control processing; if the status is invalid, the server prevents the control request from entering the HarmonyOS Web Component and terminates the current request.

[0139] For example, a delayed script execution request might still arrive after the page has been closed. Upon receiving this request, the server reads the status flag field from the interface parameter object to determine that the corresponding Web component instance has been released. Therefore, it no longer executes the script control functions in the interface parameter object and terminates the request as if the component were unavailable. This prevents the destroyed component from continuing to receive control calls.

[0140] The status flag can also serve as the basis for idempotent control of resource release. After the server performs resource release, it sets the status to "released". When it receives a duplicate release request or a late event, it directly stops subsequent processing based on the status, thereby avoiding duplicate release of function objects or continued access to related resources after release.

[0141] In implementations requiring cross-layer asynchronous capability calls, the server also establishes an asynchronous call management relationship between the HarmonyOS host and the cross-platform application shared layer. The server sets up an asynchronous call registry to associate current asynchronous requests, cancelable objects, N-API callbacks, and sets of pending requests.

[0142] When a cross-platform application's shared layer sends an asynchronous control request to the HarmonyOS host, the server creates a corresponding request identifier for the asynchronous control request and associates the request identifier with the interface parameter object corresponding to the Web component instance that initiated the call. Simultaneously, the server registers the relevant callback resources or asynchronous execution context into the pending processing set.

[0143] For example, if the shared layer needs to invoke asynchronous system capabilities through HarmonyOS, the server generates a request identifier for this call and records the request identifier, the current interface parameter object, and the corresponding callback in the asynchronous call registry. After HarmonyOS completes processing and returns the result, the server finds the corresponding call in the registry based on the request identifier, returns the result to the shared layer, and releases the N-API callback and other asynchronous call resources used by the request.

[0144] When the shared layer actively cancels an asynchronous request, the server also finds the corresponding pending call based on the request identifier, terminates the corresponding execution context, and releases callback resources. When the HarmonyOS host is unbound, the server iterates through the asynchronous requests that are still in a pending state, ends the incomplete calls based on the corresponding request identifier, and terminates the calls with the host becoming unavailable or with the corresponding termination result, thereby avoiding requests remaining in a waiting state for a long time after the host exits.

[0145] Therefore, the release of asynchronous call resources must cover at least three conditions: normal completion, request cancellation, and unbinding from the HarmonyOS host.

[0146] In terms of lifecycle management, the server implements layered cleanup according to the Web component instance-level lifecycle and the HarmonyOS host-level lifecycle.

[0147] When the Compose component instance corresponding to the cross-platform application's shared layer exits, the server first cuts off the event and control reachability paths of the exited component instance. The server clears or unbinds the load event, error event, message event, and navigation event handlers in the interface parameter object, so that events generated by the HarmonyOS Web component will no longer enter the exited shared layer component instance; then, based on the identity verification result of the interface parameter object, it releases the corresponding controller proxy, preventing the shared layer from continuing to operate the exited Web component through the old control proxy.

[0148] The server then cancels the component-level asynchronous task or coroutine scope corresponding to the Web component instance, ensuring that any ongoing asynchronous processing does not continue beyond the component instance's lifecycle. After the event and control reachability paths are broken and the execution context is canceled, the server sets the release flag for the interface resources and sequentially releases the N-API functions and related interface resources associated with the communication.

[0149] Therefore, the component-level cleanup in this embodiment adopts a processing order of "first disconnecting reachable paths, then canceling execution contexts, and finally releasing function objects." This order causes event functions and controller agents to first lose access to paths that have already exited instances, then stops asynchronous tasks that may still be running, and finally releases cross-language function resources, thereby reducing the risk of late-arriving events accessing already released function objects during the destruction process.

[0150] For example, when a user returns to the application's homepage from the product details page, the server detects that the Compose component instance corresponding to the product details page has exited. The server first unbinds the event handler function fields in the corresponding interface parameter object, then removes the controller delegate of the product details web component through object identity verification; subsequently, it cancels the coroutine scope and any unfinished component-level tasks corresponding to that page, sets the release state, and releases the relevant N-API functions one by one. After completing the above processing, the original communication relationships of the product details web component can no longer enter the destroyed page state.

[0151] When the entire HarmonyOS host exits, the server further performs host-level resource management. The server unbinds the HarmonyOS host service, preventing cross-platform applications from accessing HarmonyOS system capabilities through the original host service entry point. Simultaneously, it terminates any incomplete cross-layer calls based on asynchronous call registration information and releases corresponding resources. If necessary, it can also synchronously clean up the runtime state related to the exited host within the shared layer.

[0152] For example, when a user directly closes a HarmonyOS application, some system capability calls have not yet returned. After the server detects that the ArkTS host has entered a destroyed state, it removes the host service reference and terminates unfinished requests according to the pending set, causing waiting shared layer tasks to end in a host unavailable state, instead of continuing to wait for the no longer existing HarmonyOS host.

[0153] Therefore, this embodiment can be summarized as a continuous processing flow from S1 to S6. The server first executes S1, creating and maintaining a shared interface parameter object for each HarmonyOS Web component instance, and writing initialization properties and event capabilities; it then executes S2, passing the object to the HarmonyOS host via N-API, ensuring the HarmonyOS host retains the object itself rather than a copy of its properties; in S3, the HarmonyOS host writes loading, script execution, and return control capabilities to the same object, while the cross-platform application shared layer writes event handling capabilities, thus forming a bidirectional communication channel for event uplink and control downlink; in S4, when a Web component generates loading, error, message, or navigation events, the shared layer is directly called back via event functions, and the component state is updated by the state container without fixed-period polling; in S5, upon receiving a loading control request, the loading command is executed immediately or temporarily stored based on the ArkUI Web controller attachment state, and execution resumes after the controller attachment is complete; finally, in S6, when the lifecycle of a component instance or HarmonyOS host ends, event unbinding, proxy unbinding, task cancellation, function release, host service unbinding, and termination of incomplete requests are implemented according to different levels.

[0154] The S1-S6 mentioned above are not independent technical processes, but rather they all revolve around the same CMP HarmonyOS Web Component instance, uniformly defining object identity, bidirectional capabilities, controller attachment state, and destruction boundaries. The parameter object's identity is used to determine which Web Component instance the event and control capability belong to; the controller attachment state determines when the control command is executed; the state flag determines whether communication is still valid; the state container maintains the latest business state used by event processing; and lifecycle management determines when the aforementioned objects, functions, control proxies, and asynchronous resources expire and are released.

[0155] From a system architecture perspective, the HarmonyOS Web component cross-layer collaborative system in the cross-platform application corresponding to this embodiment includes at least one service node. Each service node includes a storage unit and a computing unit. The storage unit stores program code for executing the aforementioned methods, and the computing unit runs the program code to complete the aforementioned processing. Functionally, the system may include shared parameter object management, event and control function binding, controller attachment buffering, and lifecycle coordination. It may further include asynchronous call registration functionality.

[0156] Among them, the shared parameter object management function is used to create and maintain interface parameter objects for each HarmonyOS Web Component instance, enabling initialization properties, event functions, and control functions to be organized based on the same object; the event and control function binding function is used to establish the event uplink capability from HarmonyOS Web Component to the cross-platform application shared layer and the control downlink capability from the shared layer to HarmonyOS Web Component; the controller attachment buffer function is used to manage the URL or HTML to be loaded according to the attachment state of the ArkUI Web controller; the lifecycle coordination function is used to complete the resource cleanup of the corresponding level when the component instance exits and when the HarmonyOS host exits; and the asynchronous call registration function is used to uniformly manage asynchronous requests, request identifiers, callback resources, and pending collections.

[0157] Throughout the entire operation, the key technical states maintained by the server include at least the following: interface parameter objects corresponding to each Web component instance and continuously reused; attached state indicating whether the ArkUI Web controller is attached or not; URLs or HTML to be loaded that were last not executed; event function fields for carrying loading, error, message, and navigation event capabilities; control function fields for carrying return, script execution, and loading capabilities; state flags indicating whether communication resources have been released; component-level coroutines or asynchronous tasks for limiting the liveness boundaries of asynchronous processing; and host service state indicating whether the HarmonyOS host service is still bound. These states work together to enable the server to maintain the component communication state, control state, and lifecycle state within the same Web component instance.

[0158] The method provided in this embodiment eliminates the need to read the HarmonyOS Web component state at fixed intervals. Once an event is generated by the HarmonyOS Web component, it can proactively transmit it to the cross-platform application sharing layer. By maintaining the same interface parameter object identity, event functions and control functions can stably correspond to the same Web component instance. Through controller attachment state and pending command management, loading requests arriving before the controller has completed attachment can continue to execute after attachment is complete. Object identity verification prevents the old instance from mistakenly deleting the new instance controller proxy during the destruction process. State identifiers prevent invalid control requests after release. A state container ensures that subsequent events are processed based on the latest component state. Asynchronous call registration relationships enable asynchronous resources to be released promptly upon completion, cancellation, and host unbinding. Furthermore, through component-level and host-level layered lifecycle cleanup, event functions, controller proxies, asynchronous tasks, N-API functions, host services, and incomplete requests have clear destruction boundaries.

[0159] Therefore, this embodiment realizes a complete collaborative closed loop for cross-platform application sharing layer, HarmonyOS ArkTS host and ArkUI Web component from creation, object passing, bidirectional communication, controller attachment, event handling to resource destruction, so that the three can be consistent in terms of object identity, control execution state, application business state and life cycle state, and reduce the risks of polling overhead, loss of control commands, component instance mismatch, post-destruction callback and cross-language resource residue.

[0160] This invention provides a computer device 100, which includes a processor and a non-volatile memory storing computer instructions. When the computer instructions are executed by the processor, the computer device 100 executes the aforementioned cross-platform application HarmonyOS Web component cross-layer collaboration method. For example... Figure 4 As shown, Figure 4 This is a structural block diagram of a computer device 100 provided in an embodiment of the present invention. The computer device 100 includes a memory 111, a processor 112, and a communication unit 113. To enable data transmission or interaction, the memory 111, processor 112, and communication unit 113 are electrically connected to each other directly or indirectly. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0161] For illustrative purposes, the foregoing description has been made with reference to specific embodiments. However, the foregoing illustrative discussions are not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Numerous modifications and variations are possible in accordance with the foregoing teachings. These embodiments were chosen and described in order to best illustrate the principles of the present disclosure and its practical application, thereby enabling those skilled in the art to best utilize the disclosure and to employ various embodiments with different modifications to suit a particular intended application.

Claims

1. A method for cross-layer collaboration of HarmonyOS Web components in cross-platform applications, characterized in that, include: Establish a communication relationship between the cross-platform application sharing layer and the HarmonyOS host. The cross-platform application sharing layer is used to provide cross-platform application interfaces and business logic, and the HarmonyOS host is used to carry HarmonyOS Web components. Based on the aforementioned communication association, component initialization information, event information, and control information are transmitted between the cross-platform application sharing layer and the HarmonyOS host to achieve data interaction between the cross-platform application sharing layer and the HarmonyOS Web component. Based on the running status of the HarmonyOS Web component, the control request corresponding to the HarmonyOS Web component is processed so that the control request matches the control status of the HarmonyOS Web component; Based on the lifecycle states of the cross-platform application sharing layer and the HarmonyOS host, the communication associations and resources corresponding to the HarmonyOS Web components are managed to maintain state consistency among the cross-platform application sharing layer, the HarmonyOS host, and the HarmonyOS Web components.

2. The method according to claim 1, characterized in that, The establishment of a communication link between the cross-platform application sharing layer and the HarmonyOS host includes: The cross-platform application sharing layer creates an interface parameter object for each HarmonyOS Web component instance and passes the interface parameter object to the HarmonyOS host through the native interface call mechanism; The HarmonyOS host stores the interface parameter object itself, and writes control functions for controlling the HarmonyOS Web components based on the interface parameter object; The cross-platform application sharing layer writes event handling functions through the interface parameter object, so that the event handling function and the control function form a bidirectional communication channel based on the same interface parameter object.

3. The method according to claim 2, characterized in that, The method further includes: When the HarmonyOS Web component generates a loading event, error event, message event, or navigation event, it sends event information to the cross-platform application sharing layer through the event handling function in the interface parameter object. In response to the received event information, the cross-platform application sharing layer updates the component state corresponding to the HarmonyOS Web component.

4. The method according to claim 2, characterized in that, The step of processing the control request based on the running status of the HarmonyOS Web component includes: Obtain the controller attachment status corresponding to the HarmonyOS Web component; When the controller attachment state indicates that the controller has not completed attachment, the loading command corresponding to the control request is temporarily stored. After the controller is attached, indicating that the attachment is complete, the control function is invoked to execute the loading command.

5. The method according to claim 2, characterized in that, The method further includes: When unbinding the controller proxy relationship corresponding to the HarmonyOS Web component, obtain the identity information of the interface parameter object corresponding to the controller proxy to be unbound; Compare the identity information of the interface parameter object with the identity information of the interface parameter object corresponding to the current HarmonyOS Web component instance; When the identity information of the interface parameter objects is consistent, the controller proxy relationship removal operation is performed to avoid resource unbinding errors between different component instances.

6. The method according to claim 5, characterized in that, The management of resources based on the lifecycle states of the cross-platform application sharing layer and the HarmonyOS host includes: When the component instance corresponding to the cross-platform application sharing layer exits, the event handling function binding relationship is released, the controller proxy relationship is released, the asynchronous task corresponding to the component instance is canceled, and the interface resources corresponding to the communication association are released. When the HarmonyOS host exits, the host service binding is released and any unfinished asynchronous calls are terminated.

7. The method according to claim 2, characterized in that, The interface parameter object is configured with a status identifier field, which is used to characterize the communication status corresponding to the HarmonyOS Web component instance; the method further includes: When the cross-platform application sharing layer sends a control request to the HarmonyOS host, it determines whether the HarmonyOS Web component instance is in a valid communication state based on the status identifier field. When the status identifier field indicates that the HarmonyOS Web Component instance is in an invalid communication state, the control request is prevented from entering the HarmonyOS Web Component, and the corresponding request termination process is executed.

8. The method according to claim 2, characterized in that, The method further includes establishing an asynchronous call management relationship between the HarmonyOS host and the cross-platform application sharing layer; When the cross-platform application sharing layer sends an asynchronous control request, it establishes a corresponding request identifier for the asynchronous control request and associates the request identifier with the interface parameter object; When the asynchronous control request is completed, canceled, or the HarmonyOS host is unbound, the corresponding asynchronous call resources are released according to the request identifier.

9. The method according to claim 3, characterized in that, The cross-platform application sharing layer updates the component state based on the received event information; The event information includes event type information and event data; the method further includes: The cross-platform application sharing layer is invoked to determine the corresponding state update logic based on the event type information, and the updated component state is saved through a state container so that when the HarmonyOS Web component generates a new event, the event processing is performed based on the latest component state.

10. A cross-platform application HarmonyOS Web component cross-layer collaborative system, characterized in that, Includes at least one service node; The service node includes a storage unit and a computing unit; the storage unit is used to store program code; the computing unit is used to run the program code to execute the HarmonyOS Web component cross-layer collaboration method in any one of claims 1 to 9.

Images