Kmp and the method, device and equipment for cross-terminal communication of the Hongmeng system and the medium

Abstract

The application relates to a KMP and a cross-terminal communication method, device and equipment of a Hongmeng system and a medium, which comprises the following steps: compiling Kotlin code shared by the KMP into a JS code file and a.d.ts type definition file; constructing a Bridge tool module in the JS code file, and establishing a type contract for Hongmeng system calling based on the.d.ts type definition file, wherein the type contract is used for exposing a type-safe calling interface to the Hongmeng system; constructing a cross-terminal state bridge in the JS code file, monitoring state changes of the KMP through the cross-terminal state bridge, and synchronizing state change information to the Hongmeng system based on the type contract through the Bridge tool module. The application achieves the effect of realizing real-time and accurate refreshing of a UI interface of the Hongmeng system while retaining the logical multiplexing advantage of the KMP.

Description

Technical Field

[0001] This invention relates to the field of mobile application development technology, specifically to a cross-platform communication method, apparatus, device, and medium between KMP and HarmonyOS. Background Technology

[0002] With the increasing demand for multi-platform adaptation in mobile application development, developers urgently need an efficient and unified cross-platform development framework to reduce the cost of repetitive code development and improve maintenance efficiency. In the current technology ecosystem, Kotlin Multiplatform (KMP) has become a mainstream choice due to its ability to share code across platforms such as Android, iOS, and Web. However, HarmonyOS, as an important branch of domestic operating systems, is experiencing rapid expansion in its user base and technology ecosystem, necessitating the addition of support for the HarmonyOS platform in mobile applications. However, KMP has not yet provided direct support for HarmonyOS, resulting in significant cross-platform adaptation obstacles as developers must reuse KMP's shared logic while also ensuring compatibility with HarmonyOS's unique ETS language specification, ArkUI rendering framework, and differentiated native capability invocation mechanisms.

[0003] In existing technologies, shared code is compiled into JavaScript using KMP's Kotlin / JS compiler for use by the HarmonyOS ETS project. However, KMP's StateFlow, as a coroutine data stream, cannot directly map its state changes to the HarmonyOS ArkUI's responsive update mechanism. Additional adaptation is required to drive the interface refresh, which affects the user experience. Summary of the Invention

[0004] One objective of this invention is to provide a cross-platform communication method between KMP and HarmonyOS, in order to solve the problem that in the prior art, the state changes of KMP cannot be directly mapped to the responsive update mechanism of HarmonyOS ArkUI, requiring additional adaptation to drive the interface refresh, which affects the user experience; the second objective is to provide a cross-platform communication device between KMP and HarmonyOS; the third objective is to provide an electronic device; and the fourth objective is to provide a computer-readable storage medium.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A cross-platform communication method between KMP and HarmonyOS, applied to KMP, includes: compiling shared Kotlin code in KMP into JS code files and .d.ts type definition files; constructing a Bridge tool module in the JS code files and establishing a type contract for HarmonyOS system calls based on the .d.ts type definition files, wherein the type contract is used to expose type-safe calling interfaces to HarmonyOS; constructing a cross-platform state bridge in the JS code files, monitoring the state changes of KMP through the cross-platform state bridge, and synchronizing the state change information to HarmonyOS through the Bridge tool module based on the type contract.

[0007] Based on the aforementioned technical means, by compiling the Kotlin code shared by KMP into JS code files and .d.ts type definition files, a Bridge tool module is built in the JS code file, and a type contract for HarmonyOS system calls is established based on the .d.ts type definition file to expose type-safe call interfaces to HarmonyOS. At the same time, a cross-platform state bridge is built in the JS code file to monitor KMP state changes, and the state change information is synchronized to HarmonyOS through the Bridge tool module based on the type contract. This overcomes the technical obstacles of interface call breakage and inability to communicate reactive states caused by language isolation between the JS runtime and the native HarmonyOS ETS environment. It achieves the effect of real-time and accurate refresh of HarmonyOS system capabilities and UI interface while retaining the advantages of KMP logic reuse.

[0008] Furthermore, the method also includes: receiving a call request sent by the HarmonyOS system through the Bridge tool module; generating a corresponding call response based on the call request and the Kotlin code; and returning the call response to the HarmonyOS system through the Bridge tool module based on the type contract.

[0009] Based on the above technical means, the Bridge tool module receives the call request sent by the HarmonyOS system, generates the corresponding call response according to the call request and Kotlin code, and returns the call response to the HarmonyOS system through the Bridge tool module based on the type contract. This overcomes the technical obstacles of interface call breakage and data type mismatch caused by language isolation between the JS runtime and the HarmonyOS ETS native environment, and achieves efficient and stable bidirectional data interaction and technical effects while ensuring the security of cross-language call types.

[0010] Furthermore, in the componentized scenario, an Umbrella entry point is constructed so that the HarmonyOS system can access the Kotlin code through the Umbrella entry point. The Umbrella entry point is configured to converge and encapsulate the set of cross-platform shared interfaces that each business module in the KMP needs to expose to the HarmonyOS system.

[0011] Based on the above technical means, by constructing the Umbrella entry point to converge and encapsulate the set of cross-terminal shared interfaces that each business module in KMP needs to expose to the HarmonyOS system, the HarmonyOS system can access Kotlin code through this unified entry point. This overcomes the technical obstacles of complex call chains, high maintenance costs and difficult integration caused by the dispersed interfaces under the component-based architecture, and achieves the technical effects of simplifying the HarmonyOS side access process, realizing unified management of cross-terminal interfaces and improving the overall maintainability and scalability of the system.

[0012] Furthermore, the method also includes: sending a call request to the HarmonyOS system through the Bridge tool module based on the type contract; and receiving the call response from the HarmonyOS system through the Bridge tool module.

[0013] Based on the above technical means, by using the Bridge tool module based on type contracts to send call requests to the HarmonyOS system and receive call responses from the HarmonyOS system, the technical obstacles of asynchronous interaction blocking and data serialization inconsistency caused by the lack of communication protocols between the JS runtime and the HarmonyOS ETS native environment are overcome. This achieves the technical effects of realizing cross-language bidirectional asynchronous communication, ensuring the integrity of the call chain, and improving the real-time performance and stability of system interaction.

[0014] Furthermore, the method also includes: if the call request is a native capability call request of the HarmonyOS system or a third-party library call request, then converting the .d.ts type definition file of the HarmonyOS system or the third-party library into a Kotlin external interface; parsing the method identifier and parameters in the native capability call request or the third-party library call request according to the Kotlin external interface; and sending the method identifier and parameters to the HarmonyOS system through the Bridge tool module based on the type contract to trigger a HarmonyOS native or third-party library call implementation that matches the Kotlin external interface type.

[0015] Based on the aforementioned technical means, by converting the .d.ts type definition files of the HarmonyOS system or third-party libraries into Kotlin external interfaces, and parsing the method identifiers and parameters in the call requests accordingly, the information is then sent to the HarmonyOS system through the Bridge tool module based on the type contract to trigger the matching native or third-party library call implementation. This overcomes the technical obstacles of interface call ambiguity, parameter passing errors, and runtime crashes caused by the lack of native type awareness in the Kotlin / JS environment. It achieves the technical effects of realizing cross-language type security verification, ensuring accurate mapping of native capabilities, and improving the stability and development efficiency of third-party library integration.

[0016] Furthermore, sending the call request to the HarmonyOS system through the Bridge tool module includes: constructing a call request based on the target method identifier and associated parameter information, wherein the call request includes a method identifier, a parameter object, and a callback identifier; and forwarding the call request to the HarmonyOS system through the Bridge tool module, so that the HarmonyOS system triggers the execution of the business logic corresponding to the method identifier.

[0017] Based on the aforementioned technical means, by converting the .d.ts type definition files of the HarmonyOS system or third-party libraries into Kotlin external interfaces, and parsing the method identifiers and parameters in the call requests accordingly, the information is then sent to the HarmonyOS system through the Bridge tool module based on the type contract to trigger the matching native or third-party library call implementation. This overcomes the technical obstacles of interface call ambiguity, parameter passing errors, and runtime crashes caused by the lack of native type awareness in the Kotlin / JS environment. It achieves the technical effects of realizing cross-language type security verification, ensuring accurate mapping of native capabilities, and improving the stability and development efficiency of third-party library integration.

[0018] Furthermore, the step of compiling the Kotlin code shared by KMP into JS code files and .d.ts type definition files includes: adding cross-platform export annotations to the cross-platform shared object of the Kotlin code shared by KMP to obtain JS code; and generating .d.ts type definition files based on the cross-platform export annotations.

[0019] Based on the above technical means, by adding cross-platform export annotations to the cross-platform shared object of Kotlin code shared by KMP to obtain JS code, and generating .d.ts type definition files based on the cross-platform export annotations, the technical obstacles caused by the traditional manual writing of type definition files being prone to errors, high maintenance costs, and inconsistencies between the JS and Kotlin side interface contracts are overcome. This achieves the technical effects of realizing automated type mapping of cross-platform interfaces, ensuring type security verification, and improving development efficiency and code maintainability.

[0020] Furthermore, the method also includes: performing boundary convergence on the exported interfaces of the JS code file and the .d.ts type definition file to obtain the target cross-platform access interface; and exposing a standardized cross-platform interaction protocol to the HarmonyOS system based on the target cross-platform access interface.

[0021] Based on the above technical means, the target cross-platform access interface is obtained by boundary convergence of the exported interfaces of JS code files and .d.ts type definition files. Based on the target cross-platform access interface, a standardized cross-platform interaction protocol is exposed to the HarmonyOS system. This overcomes the technical obstacles of scattered and redundant cross-platform interfaces, inconsistent interaction rules leading to chaotic call chains, high adaptation costs, and lack of security control. It achieves the technical effects of simplifying the cross-platform interaction chain, unifying the HarmonyOS side access standard, reducing the difficulty of multi-version adaptation, and strengthening the security control of interface access.

[0022] Furthermore, the step of detecting the state change of the KMP through the cross-end state bridge and synchronizing the state change value to the HarmonyOS system through the Bridge tool module includes: when the cross-end state bridge receives the real-time state value of the KMP, comparing the real-time state value with the historical state value; if the real-time state value is different from the historical state value, generating state change information based on the real-time state value; and synchronizing the state change information to the HarmonyOS system through the Bridge tool module, wherein the state change information includes a state name and a real-time state value.

[0023] Based on the above technical means, when the cross-end state bridge receives the real-time state value of KMP, it compares it with the historical state value. Only when there is a difference between the two, state change information containing the state name and real-time state value is generated. The state change information is then synchronized to the HarmonyOS system through the Bridge tool module. This overcomes the technical obstacles of cross-runtime data transmission redundancy, high performance overhead, and invalid redrawing of ArkUI caused by high-frequency synchronization of full state. It achieves the technical effects of accurately filtering invalid state synchronization requests, significantly reducing cross-end communication bandwidth consumption, reducing unnecessary UI refreshes, and improving overall state synchronization efficiency and application smoothness.

[0024] Secondly, embodiments of this application provide a cross-platform communication method between KMP and HarmonyOS, applied to HarmonyOS, comprising: obtaining JS code files and .d.ts type definition files in KMP; registering a Bridge event handler in the JS code file based on a type contract established by the .d.ts type definition file, wherein the type contract is used to instruct KMP to expose type-safe call interfaces to HarmonyOS; and writing the state change values ​​received by the Bridge event handler into an AppStorage or ArkUI observable state container through a synchronized event handler to drive interface reorganization.

[0025] Based on the above technical means, by obtaining the JS code file and .d.ts type definition file in KMP, registering the Bridge event handler in the JS code file based on the type contract established by the .d.ts type definition file, and then writing the state change value received by the Bridge event handler into the AppStorage or ArkUI observable state container through the synchronization event handler to drive the interface reorganization, the technical obstacles of HarmonyOS being unable to directly recognize KMP state change events and the cross-runtime state mapping link being broken, causing ArkUI to be unable to refresh responsively, are overcome. The technical effect of achieving type-safe cross-platform state synchronization on HarmonyOS and enabling KMP state changes to accurately trigger the native ArkUI interface reorganization is achieved.

[0026] Furthermore, the method also includes: receiving a native call request or a third-party library call request sent by the KMP through the Bridge event handler; extracting the method identifier and parameters from the native call request or the third-party library call request; calling the corresponding HarmonyOS native capability or third-party library capability based on the method identifier and parameters to obtain a call response; and returning the call response to the KMP through the Bridge event handler based on the type contract.

[0027] Based on the above technical means, the Bridge event handler receives native call requests or third-party library call requests sent by KMP, extracts the method identifier and parameters in the request, calls the corresponding HarmonyOS native capabilities or third-party library capabilities based on the identifier and parameters to obtain the call response, and then returns the call response to KMP through the Bridge event handler based on the type contract. This overcomes the technical obstacles of native capability call failure caused by the cross-runtime call link between HarmonyOS and KMP and parameter type mismatch. It achieves the technical effect of realizing seamless calling of all HarmonyOS native capabilities on the KMP side and ensuring cross-terminal bidirectional call type security and data consistency.

[0028] Furthermore, the method also includes: in a componentized scenario, accessing the shared Kotlin code of KMP through the Umbrella entry point, wherein the Umbrella entry point is configured to converge and encapsulate the cross-end shared interface set that each business module in KMP needs to expose to the HarmonyOS system.

[0029] Based on the above technical means, by accessing the shared Kotlin code of KMP through the Umbrella entry point in the componentized scenario, the cross-terminal shared interface set that each business module in KMP needs to expose to the HarmonyOS system is converged and encapsulated using the Umbrella entry point. This overcomes the technical obstacles of scattered exposure of cross-terminal interfaces and fragmented call links under the componentized architecture, which leads to complex access logic on the HarmonyOS side and difficulty in unified management of multi-module interfaces. It achieves the technical effects of greatly simplifying the access process of KMP capabilities on the HarmonyOS side, realizing global unified maintenance of cross-terminal interfaces, and reducing the cost of collaborative adaptation of multiple business modules.

[0030] A cross-platform communication device between KMP and HarmonyOS, applied to KMP, includes: a compilation module for compiling shared Kotlin code of KMP into JS code files and .d.ts type definition files; a first communication module for building a Bridge tool module in the JS code files and establishing a type contract for HarmonyOS system calls based on the .d.ts type definition files, wherein the type contract is used to expose type-safe calling interfaces to HarmonyOS; and a first synchronization module for building a cross-platform state bridge in the JS code files, monitoring the state changes of KMP through the cross-platform state bridge, and synchronizing the state change information to HarmonyOS through the Bridge tool module based on the type contract.

[0031] A cross-platform communication device between KMP and HarmonyOS, applied to HarmonyOS, includes: an acquisition module for acquiring JS code files and .d.ts type definition files in KMP; and a second communication module for registering a Bridge event handler in the JS code file based on a type contract established by the .d.ts type definition file, in response to a call request sent by KMP, wherein the type contract is used to instruct KMP to expose a type-safe call interface to HarmonyOS.

[0032] The second synchronization module is used to write the received state change values ​​into the AppStorage or ArkUI observable state container through the synchronization event handler, so as to drive the interface reorganization.

[0033] An electronic device includes: a memory, a processor, and an interface;

[0034] The memory stores the instructions that the computer executes;

[0035] The processor executes computer execution instructions stored in memory, causing the processor to perform any of the methods described above.

[0036] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described above.

[0037] The beneficial effects of this invention are:

[0038] (1) This invention solves the problems of type mismatch and call link breakage between KMP and HarmonyOS across runtime by using full-link type contract and bidirectional bridging mechanism, and obtains type-safe, stable and reliable cross-terminal bidirectional call capability;

[0039] (2) This invention solves the problem that KMP-side state changes cannot accurately drive HarmonyOS UI refresh by using incremental state comparison and ArkUI state container mapping mechanism, and obtains low redundancy, high real-time cross-terminal state synchronization and native-level interface response effect.

[0040] (3) This invention solves the problem of scattered cross-end interfaces and complex access logic in componentized scenarios by unifying the convergence of cross-end shared interfaces through the Umbrella entry point, and obtains a lightweight access, easy-to-maintain and scalable engineering implementation support system. Attached Figure Description

[0041] Figure 1 A schematic diagram of the overall architecture for cross-terminal communication between KMP and HarmonyOS provided in this application embodiment;

[0042] Figure 2 A flowchart illustrating the cross-platform communication method between KMP and HarmonyOS provided in this application embodiment. Figure 1 ;

[0043] Figure 3 A schematic diagram of the architecture of the Umbrella entry point provided in the embodiments of this application;

[0044] Figure 4 A flowchart illustrating the state synchronization between KMP and HarmonyOS provided in this application embodiment;

[0045] Figure 5 A flowchart illustrating the cross-platform communication method between KMP and HarmonyOS provided in this application embodiment. Figure 2 ;

[0046] Figure 6 This is a diagram illustrating the bidirectional communication interaction between KMP and the HarmonyOS system, provided in an embodiment of this application.

[0047] Figure 7 A schematic diagram of the cross-terminal communication device between KMP and HarmonyOS provided in the embodiments of this application. Figure 1 ;

[0048] Figure 8 A schematic diagram of the cross-terminal communication device between KMP and HarmonyOS provided in the embodiments of this application. Figure 2 ;

[0049] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0050] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0051] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0052] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0053] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0054] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclusively include, for example, a product or device that includes a series of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0055] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0056] KMP is an open-source cross-platform development technology launched by JetBrains. It allows developers to write a single set of Kotlin code and efficiently reuse business logic across multiple platforms such as Android, iOS, desktop, web, and server. When combined with ComposeMultiplatform, it can also achieve cross-platform UI code sharing. It retains the performance and user experience advantages of native development on each platform while significantly reducing the workload of repetitive cross-platform code development, lowering the maintenance costs of multiple platforms, and helping enterprises to achieve simultaneous release of multi-platform functions. It has been officially supported by Google for sharing business logic between Android and iOS and is currently a highly mature production-grade cross-platform development solution.

[0057] HarmonyOS is a distributed operating system designed for all scenarios. Based on a microkernel architecture, it supports modular and elastic deployment, enabling seamless collaboration among multiple terminals such as mobile phones, tablets, PCs, smart home devices, and in-vehicle devices. It has the core feature of "develop once, deploy on multiple devices" and can provide architecture-level trusted security protection for various smart devices. It can also break down the ecological barriers between different devices through distributed capabilities, supporting cross-device resource sharing and efficient collaborative operation in the Internet of Things scenario.

[0058] In the field of cross-platform mobile application development and operating system adaptation, this mainly applies to application development scenarios that use KMP for business logic sharing and need to further integrate with the HarmonyOS system. In a typical architecture, the shared logic is uniformly carried by KMP, and different terminal sides are responsible for platform capability calls and interface presentation, respectively. Therefore, when adding a HarmonyOS version to an existing Android, iOS, or Web project, it is usually necessary to complete the connection with the HarmonyOS runtime environment while maintaining the reuse of shared code.

[0059] However, in the existing technology, KMP has not yet provided direct support for the HarmonyOS system. This means that while reusing KMP's shared logic, it is also necessary to be compatible with HarmonyOS's unique ETS language specification, ArkUI rendering framework, and differentiated native capability calling mechanism, which presents significant cross-platform adaptation obstacles.

[0060] Based on this, this application provides a cross-platform communication method between KMP and HarmonyOS. This method compiles the shared Kotlin code of KMP into JS code files and .d.ts type definition files. Then, a Bridge tool module is built in the JS code file, and a type contract for HarmonyOS system calls is established based on the .d.ts type definition file to expose type-safe calling interfaces to HarmonyOS. Simultaneously, a cross-platform state bridge is built in the JS code file to monitor KMP state changes and synchronizes state change information to HarmonyOS based on the type contract using the Bridge tool module. This overcomes the technical obstacles of interface call breakage and inability to communicate reactive states caused by language isolation between the JS runtime and the HarmonyOS ETS native environment. It achieves the technical effect of high-performance native capability calls and real-time accurate UI refresh while retaining the advantages of KMP logic reuse.

[0061] The cross-platform communication method between KMP and HarmonyOS provided in this application embodiment can be applied to multi-platform projects based on KMP. However, it may require additional HarmonyOS platform support, cross-platform mobile application development using Kotlin / js solutions, or KMP projects with component-based architectures. This embodiment does not impose any restrictions on these aspects.

[0062] Please see Figure 1 , Figure 1 This is a schematic diagram of the overall architecture for cross-platform communication between KMP and HarmonyOS provided in an embodiment of this application. Figure 1 As shown, the top-level Kotlin code flows down into the KMP shared code layer, where it is processed by two modules: the pure Kotlin-implemented ViewModel and the cross-platform state bridge (PlatformStateFlow) based on Kotlin coroutines. The output of ViewModel and PlatformStateFlow flows to the JS code .mjs in the JS compilation layer. The JS code .mjs generates the corresponding .d.ts type definition file and passes the data to the pure Kotlin-implemented Bridge module. The Bridge module receives both the direct output from the cross-platform state bridge (PlatformStateFlow) and the associated data from AppStorage. Finally, the Bridge module passes the data to the ETS code on the HarmonyOS ETS side via sendMessageToEts and triggerEvent. The ETS code interfaces with ArkUI to complete the UI rendering of the HarmonyOS system. At the same time, the HarmonyOS ETS side also completes state synchronization through its own AppStorage.

[0063] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0064] Please see Figure 2 , Figure 2 A flowchart illustrating the cross-platform communication method between KMP and HarmonyOS provided in this application embodiment. Figure 1 This cross-platform communication method between KMP and the HarmonyOS system is applied to KMP, such as... Figure 2 As shown, the cross-platform communication method between KMP and HarmonyOS includes at least steps S201 to S203, which are detailed below:

[0065] Step S201: Compile the Kotlin code shared by KMP into JS code files and .d.ts type definition files.

[0066] It should be noted that KMP, as the application object of methods and the source of shared code, is used to carry reusable business logic, state objects, call parameter objects, and processing logic related to state updates across platforms. The Kotlin code shared by KMP can be deployed in the commonMai (Artificial Intelligence) source code set and managed uniformly by the KotlinMultiplatform build configuration.

[0067] Specifically, the Kotlin code shared by KMP can be compiled. The compilation output includes at least one JS code file and a .d.ts type definition file. The JS code file is loaded and executed by the HarmonyOS system, and the .d.ts type definition file is used to describe the functions, classes, objects, parameter types and return types exposed by the JS code file.

[0068] For example, in Kotlin, business methods are compiled into callable JS functions, state data classes are compiled into corresponding data structure definitions, and the .d.ts type definition files synchronously record the parameter field names, field types, return value types, and nullability information of each interface.

[0069] In addition, cross-platform compatibility processing can be performed on collection types, nested object types, and enumeration types during the compilation process, so that corresponding type declarations are formed in the .d.ts type definition file, thereby ensuring that the HarmonyOS system has a clear type basis when calling JS code files.

[0070] Step S202: Build the Bridge tool module in the JS code file and establish the type contract for HarmonyOS system calls based on the .d.ts type definition file. The type contract is used to expose type-safe call interfaces to HarmonyOS.

[0071] It should be noted that the JS code file not only serves as the execution carrier of KMP shared logic, but also as the environment for cross-platform communication capabilities.

[0072] For example, a Bridge tool module can be built in a JS code file to encapsulate the cross-platform interaction process between the HarmonyOS system and the JS code file. This Bridge tool module can be set as an independent object or independent module in JS.

[0073] As the target side for cross-platform communication, HarmonyOS loads JS code files upon access. It can establish interaction with KMP shared logic based on the Bridge tool module. Correspondingly, the .d.ts type definition file provides interface names, parameter types, return types, and data structure definitions. The type contract established based on the .d.ts type definition file constrains the boundaries of the interfaces that HarmonyOS can call, enabling HarmonyOS to access the shared logic in the JS code file according to the declared parameter and return formats.

[0074] Specifically, the Bridge tool module can encapsulate cross-platform interaction messages and, in conjunction with type contracts, constrain the interface interactions between the HarmonyOS system and the JS code files. This process creates a unified and verifiable call boundary between the JS code files and the HarmonyOS system, ensuring that call parameters and return results are passed along the same type contract, reducing cross-platform adaptation discrepancies caused by unclear interface meanings or inconsistent types.

[0075] Step S203: Build a cross-platform state bridge in the JS code file, monitor the state changes of KMP through the cross-platform state bridge, and synchronize the state change information to the HarmonyOS system based on the type contract through the Bridge tool module.

[0076] In this embodiment, the cross-end state bridge is set inside the JS code file to convert the state update information generated during the operation of the KMP shared logic into state change information that can be recognized by the HarmonyOS system.

[0077] Furthermore, a cross-platform state bridge can be used to establish listening relationships with internal state sources within the KMP. These state sources can be shared state objects, data streams maintained based on Flow or StateFlow, business states managed by the event dispatcher, or other state containers that are compiled and perceptible in the JS environment. The cross-platform state bridge includes state listening and synchronization capabilities. After detecting state changes in the KMP, it synchronizes the corresponding state change information to the HarmonyOS system through the Bridge tool module.

[0078] Specifically, the state content requiring cross-platform synchronization can be pre-defined in the KMP shared code, and after being compiled into the JS code file, the cross-platform state bridge establishes a listener for the corresponding state. When a state change is detected, the cross-platform state bridge generates state change information corresponding to that state change and sends it to the HarmonyOS system through the Bridge tool module according to the type contract. For object type states, the state change information can be organized with reference to the type declaration in the .d.ts type definition file, ensuring that the state change information received by the HarmonyOS system is consistent with the previously established type contract. After receiving the state change information, the Bridge tool module forwards it to the HarmonyOS system, which then distributes the message to the corresponding UI layer or business adaptation layer based on the corresponding state content to complete the data refresh.

[0079] In one possible embodiment, the cross-platform state bridge can trigger synchronization upon detecting a state change, enabling the HarmonyOS system to obtain updated state information. Regardless of the synchronization triggering method, state change information is encapsulated through a type contract established by the Bridge tool module based on the .d.ts type definition file, ensuring that the state information received by the HarmonyOS system is compatible with the state definitions derived from the shared logic. For declarative states that the interface directly depends on, the cross-platform state bridge can synchronize relevant state changes to the HarmonyOS system, allowing the HarmonyOS system to perform corresponding state writing or interface updates upon receiving the notification.

[0080] In this embodiment, by first converting the KMP shared logic into executable JS artifacts and constrained type definition artifacts, and then configuring the Bridge tool module and cross-end state bridge within the same JS carrier layer, a continuous communication path is formed from interface export, call verification, message forwarding to state synchronization. This enables the HarmonyOS system to both call the KMP shared logic according to clear type boundaries and receive state change information consistent with the shared state definition, thereby completing cross-end calls and state linkage for HarmonyOS access scenarios.

[0081] In one possible embodiment, the cross-platform communication method between KMP and HarmonyOS further includes steps S301 to S303, which are detailed below:

[0082] Step S301: Receive the call request sent by the HarmonyOS system through the Bridge tool module.

[0083] Step S302: Generate the corresponding call response based on the call request and Kotlin code.

[0084] Step S303: Based on the type contract, the call response is returned to the HarmonyOS system through the Bridge tool module.

[0085] For example, the Bridge tool module is deployed within the cross-platform communication layer carried by the JS code file, serving as an intermediate adaptation unit between the HarmonyOS system and the Kotlin code. When the HarmonyOS system needs to access Kotlin capabilities, it first constructs a call request containing a method identifier, parameter list, request identifier, and postback identifier, and sends this call request to the Bridge tool module. After receiving the call request, the Bridge tool module parses the target method identifier to locate the corresponding function entry point in the Kotlin code, and then performs type mapping and format conversion on the parameter information to meet the calling requirements of the Kotlin side.

[0086] Subsequently, the Bridge utility module triggers the execution of the corresponding Kotlin code and generates a call response based on the execution result. When the Kotlin code returns basic type data, the Bridge utility module directly encapsulates it into a data object consistent with the type contract.

[0087] When Kotlin code returns collection type, object type, or nullable type data, the Bridge utility module performs serialization and encapsulation based on the field constraints, nullability constraints, and nested structure constraints defined in the type contract, thereby forming a call response that the HarmonyOS system can recognize.

[0088] After the call response is generated, the Bridge tool module further validates the response result according to the type contract, and sends the validated call response back to the HarmonyOS system.

[0089] If the response contains a return identifier, the Bridge tool module can send the response to the pre-registered receiver in the HarmonyOS system based on the return identifier.

[0090] In this embodiment, the process of HarmonyOS accessing Kotlin code can be parsed, adapted, and returned in a unified Bridge tool module. The field structure, parameter type, and return format of the called data are all constrained by the type contract, which makes the transmission of the call response more stable and ensures that the execution result obtained by HarmonyOS is consistent with the actual output of Kotlin.

[0091] In one possible implementation, the cross-platform communication method between KMP and HarmonyOS further includes the following steps, detailed below:

[0092] In a componentized environment, an Umbrella entry point is built so that the HarmonyOS system can access Kotlin code through the Umbrella entry point. The Umbrella entry point is configured to converge and encapsulate the set of cross-platform shared interfaces that each business module in KMP needs to expose to the HarmonyOS system.

[0093] For example, the Umbrella entry point serves as a unified access endpoint when KMP adopts a component-based architecture. This allows the HarmonyOS system to access the corresponding Kotlin code through this entry point without needing to interface with multiple business modules separately. The Kotlin code is the business implementation carrier shared by KMP and provided externally by the Umbrella entry point, corresponding to the capabilities that each business module needs to expose to the HarmonyOS system. The cross-platform shared interface set is the set of interfaces that each business module in KMP needs to expose to the HarmonyOS system. After the Umbrella entry point summarizes and uniformly encapsulates these interfaces, it outputs them to the HarmonyOS system through a single entry point.

[0094] Please see Figure 3 , Figure 3 A schematic diagram of the architecture of the Umbrella entry point provided in the embodiments of this application is shown below. Figure 3 As shown, each business module in KMP can be compiled to generate corresponding Kotlin artifacts, and a Umbrella entry class or Umbrella entry module can be established in the aggregation layer to include the public functions, data access functions and status acquisition functions exposed to the HarmonyOS system in each module into unified management.

[0095] The Umbrella entry point can be implemented as a static singleton object, an aggregate class, or a unified exposure file. Internally, it integrates the scattered interfaces into a unified calling plane by importing the public interfaces of each business module and reorganizing the external method signatures.

[0096] For methods with the same name, different parameters, or different return values ​​that may exist between different business modules, the Umbrella entry point can handle method renaming, parameter passing, and return result forwarding at the encapsulation layer, enabling the HarmonyOS system to call the target business logic simply by targeting the Umbrella entry point. The component-based organization method adopted ensures that each business module is compiled and maintained independently. The Umbrella entry point is only responsible for aggregating and exposing cross-platform shared interfaces. In practical applications, this entry point can also choose other module assembly methods, which this application does not limit.

[0097] Optionally, a unified UmbrellaEntryPoint can be set up in the KMP componentization project as the sole entry point for exposing cross-platform capabilities. This entry point is specifically used to aggregate ViewModel instances, core business services, state flow factories, and cross-platform bridge communication capabilities that various business modules need to expose to HarmonyOS. Each business module only needs to register and expose the necessary capabilities to this Umbrella entry point, without directly exposing its own JS artifacts. This avoids dependency confusion and version inconsistencies caused by HarmonyOS referencing multiple sub-module JS packages from the root. At the same time, the separation of responsibilities between the logic layer and the UI layer is strictly enforced within the Umbrella entry point: the business logic layer does not depend on ComposeMultiplatform or any UI implementation components on the HarmonyOS side, retaining only shared business logic written in pure Kotlin and standardized cross-platform communication interfaces. This ensures the purity and cross-platform compatibility of the shared logic and further reduces the risk of UI layer changes intruding on the core shared logic.

[0098] Specifically, when the HarmonyOS system makes a call to KMP, it first loads the JS code file or bridging mapping relationship corresponding to the Umbrella entry point, and then initiates an access request to the Kotlin code through this unified entry point. The Umbrella entry point distributes the request to the corresponding business module and returns the processing result, thus forming a converged call path.

[0099] Since the cross-platform shared interface set is uniformly encapsulated in the Umbrella entry point, the calling objects on the HarmonyOS side remain consistent. The splitting method within the business module is not directly exposed to the HarmonyOS system. Therefore, when a module is extended or replaced, only the aggregation relationship of the Umbrella entry point needs to be updated.

[0100] In this embodiment, through the Umbrella entry point, the HarmonyOS system's access to Kotlin code is converged from multiple discrete interfaces into a unified entry point. The component boundaries and external exposure boundaries remain clear. After centralized management of interfaces, the call conflicts caused by direct exposure of multiple modules can be reduced, and the HarmonyOS system-side access and subsequent maintenance can be completed through a single entry point, thereby improving the consistency of cross-terminal shared interfaces and the stability of engineering integration in componentized scenarios.

[0101] In one possible embodiment, the specific implementation process of the above-mentioned cross-terminal communication method between KMP and HarmonyOS may further include steps S401 and S402, which are described in detail below:

[0102] Step S401: Based on the type contract, send a call request to the HarmonyOS system through the Bridge tool module.

[0103] Step S402: Receive the call response from the HarmonyOS system through the Bridge tool module.

[0104] For example, KMP can send call requests to the HarmonyOS system based on type contracts through the Bridge tool module. Specifically, after receiving the call content to be sent, the Bridge tool module first parses the call signature of the target method according to the type contract, then assembles the target method identifier, parameter sequence, and necessary context information into a call request message body, and sends the message body to the HarmonyOS system through a pre-defined communication channel on the HarmonyOS side. For cases where the type contract specifies the number of parameters, parameter order, or return mapping relationship, the Bridge tool module synchronously completes field validation and type mapping during the encapsulation process, ensuring that the call request conforms to the interface format that the HarmonyOS system can recognize when it is sent.

[0105] Then, the Bridge tool module generates and forwards the call request according to the type contract. After receiving the call request, the HarmonyOS system can execute the corresponding business logic according to the preset interface name and parameter type, and associate the processing result with the return relationship corresponding to the type contract.

[0106] This allows for standardized constraints on the message format sent by the Bridge tool module. Messages must include at least a method identifier, a parameter object, and a callback identifier, ensuring that cross-language call chains are routable, callback-enabled, and scalable.

[0107] In this embodiment, the KMP calls to the HarmonyOS system are constrained by type contract and encapsulated by the Bridge tool module before being sent. The sent content is consistent with the interface definition on the HarmonyOS side, which makes the cross-terminal call relationship clearer, the interface identification more stable, and facilitates processing and response on the HarmonyOS side according to the established type rules.

[0108] In one possible embodiment, the specific implementation process of the above-mentioned cross-terminal communication method between KMP and HarmonyOS may further include steps S501 to S503, which are described in detail below:

[0109] Step S501: If the call request is a native capability call request of the HarmonyOS system or a third-party library call request, then convert the .d.ts type definition file of the HarmonyOS system or the third-party library into a Kotlin external interface.

[0110] Step S502: Based on the Kotlin external interface, parse the method identifier and parameters in the native capability call request or the third-party library call request.

[0111] Step S503: Based on the type contract, the method identifier and parameters are sent to the HarmonyOS system through the Bridge tool module to trigger the HarmonyOS native or third-party library call implementation that matches the Kotlin external interface type.

[0112] For example, when a call request is a HarmonyOS native capability call request or a third-party library call request, the .d.ts type definition file corresponding to the request is read first, and the type aliases, interface declarations, function signatures and parameter modification information in the file are parsed.

[0113] When parsing the method identifier and parameters in the call request, a mapping relationship between the method name and the function signature is established based on the Kotlin external interface. The actual parameter object is split into a parameter set that is consistent with the target signature. Then, the parameter set is encapsulated into a call payload that can be recognized by the Bridge tool module. For example, the generated Kotlin interface code is placed in the KMP shared code accessible directory, so that the shared code can call the HarmonyOS side capability through the converted Kotlin API description.

[0114] Then, the .d.ts type definition files of the HarmonyOS system or third-party libraries can be converted into Kotlin external interfaces. The converted Kotlin external interfaces will retain the original method names, parameter order and type mapping relationships, so that the Kotlin side can directly access the native capabilities of HarmonyOS or third-party libraries according to the declaration.

[0115] Optionally, in some feasible embodiments, it is also supported to convert the .d.ts type definition files of HarmonyOS or third-party libraries into Kotlin external interfaces in advance. This embodiment does not impose any mandatory restrictions on the timing of this conversion operation. Developers can flexibly choose the adaptation node according to their own project's build process and dependency loading rhythm.

[0116] Finally, the Bridge tool module sends the method identifier and parameters to the HarmonyOS system according to a predetermined communication format based on the type contract. After receiving the data, the HarmonyOS system dispatches the call according to the native capability implementation or third-party library implementation corresponding to the Kotlin external interface and returns the execution result. Since the interface definition originates from the .d.ts type definition file, the converted Kotlin external interface maintains a type correspondence with the HarmonyOS system implementation. Therefore, the call content maintains signature consistency during transmission, and the KMP-side call is stably mapped to the native or third-party library functionality of HarmonyOS.

[0117] In this embodiment, by converting the .d.ts type definition files of the HarmonyOS system or third-party libraries into Kotlin external interfaces, native capability call requests and third-party library call requests have a unified typed expression. Combined with method identification and parameter parsing, as well as forwarding by the Bridge tool module, a recognizable call chain is formed from KMP to the HarmonyOS system. As a result, call requests can be accurately delivered to the HarmonyOS side in the form of contractual constraints, triggering the implementation of native capabilities or third-party libraries that match the interface type, thereby improving the consistency and executability of cross-platform calls.

[0118] In one possible embodiment, the process of sending the call request to the HarmonyOS system via the Bridge tool module may further include steps S601 and S602, which are described in detail below:

[0119] Step S601: Construct a call request based on the target method identifier and associated parameter information. The call request includes the method identifier, parameter object, and callback identifier.

[0120] Step S602: The call request is forwarded to the HarmonyOS system through the Bridge tool module, so that the HarmonyOS system can trigger the execution of the business logic corresponding to the method identifier.

[0121] For example, when the KMP side sends a call request to the HarmonyOS system through the tool module, it can first receive the target method identifier of the capability to be called and the associated parameter information corresponding to the method, and organize the associated parameter information into a serializable parameter object. The parameter object can adopt a key-value mapping structure, a data class object, or JSON carrier format to adapt to the way the HarmonyOS system parses the call request data.

[0122] Optionally, the call request may include a method identifier, a parameter object, and a callback identifier. The callback identifier may consist of a session identifier, a callback function identifier, or a request serial number, and is used to distinguish the call response paths of different call requests in multiple concurrent calls, thereby ensuring that the cross-language call chain has routable, callback-enabled, and scalable capabilities.

[0123] After receiving a call request message, the HarmonyOS system retrieves the corresponding business processing entry point based on the method identifier, deserializes the parameter object into the data structure required by the target business logic, and then executes the corresponding business logic. If the business logic is completed and a return result is generated, the HarmonyOS system sends the result back to the KMP side based on the callback identifier, thus maintaining a one-to-one correspondence between the call request and the call response.

[0124] In this embodiment, the Bridge tool module can carry the target method, input parameters and callback information in a unified message format and reliably transfer them to the HarmonyOS system for processing, thereby realizing the structured transmission and business triggering of cross-terminal calls, reducing request parsing ambiguity and improving call matching consistency.

[0125] In one possible embodiment, the specific implementation process of compiling the Kotlin code shared by KMP into JS code files and .d.ts type definition files may further include steps S701 and S702, which are detailed below:

[0126] Step S701: Add a cross-platform export annotation to the cross-platform shared object of the Kotlin code shared by KMP to obtain the JS code.

[0127] Step S702: Generate .d.ts type definition files based on cross-platform exported annotations.

[0128] For example, using the native Kotlin / JS platform KMP, the shared Kotlin code to be reused is compiled into JS code and .d.ts type definition files by the JS (IR) compiler. This allows the HarmonyOS ETS side to identify and call objects, methods, and data structures exported by KMP in a type-safe manner. Annotations are added to ViewModel, Intent, State, Bridge parameter objects, and necessary data classes that need to be accessed by the HarmonyOS side, such as adding @OptIn(ExperimentalJsExport::class) and @JsExport annotations, making them accessible exports in the JS compilation artifacts.

[0129] Specifically, in terms of compilation implementation, when building the Kotlin / JS compilation chain, the compiler first scans the cross-platform export annotations on cross-platform shared objects, includes the code members marked with these annotations into the export set, and then converts them into JS code files that can be loaded by the HarmonyOS system. Simultaneously, based on the export scope identified by the annotations, the compiler extracts the method names, parameter types, return types, and nullability information of each member, and generates a .d.ts type definition file corresponding to the JS code file to describe the type constraints of the JS interface. This .d.ts type definition file maintains the same name or a mapping association with the JS code file so that the HarmonyOS system can automatically establish the correspondence between interface declarations and implementation artifacts during import.

[0130] In this embodiment, by adding cross-platform export annotations to the cross-platform shared object of Kotlin code in KMP to generate JS code, and then automatically generating .d.ts type definition files based on the annotations, the KMP cross-platform export process is automated, the type definitions are naturally aligned with the business code, and the type security and development efficiency of cross-platform calls on the HarmonyOS side are greatly improved.

[0131] In one possible embodiment, the specific implementation process of the above-mentioned cross-terminal communication method between KMP and HarmonyOS may further include steps S801 and S802, which are detailed below:

[0132] Step S801: Perform boundary convergence on the exported interfaces of the JS code file and the .d.ts type definition file to obtain the target cross-platform access interface.

[0133] Step S802: Expose a standardized cross-platform interaction protocol to the HarmonyOS system based on the target cross-platform access interface.

[0134] For example, it can read all exported declarations from JS code files and .d.ts type definition files, and parse the functions, objects, constants and type identifiers that can be directly called by the HarmonyOS system. Based on the interface name, parameter signature, return value type and accessible domain, it can perform consistency comparison, and merge, remove or redirect exported items that have semantic duplication, naming conflicts, scattered hierarchies or do not meet external call constraints to form a target cross-end access interface with clear boundaries.

[0135] Furthermore, a standardized cross-platform interaction protocol can be defined between the HarmonyOS system and JS code files. The protocol imposes unified constraints on interface identifiers, request parameters, return structures, exception identifiers, and version compatibility fields, and maps interface calls to message carriers with fixed formats, thereby enabling the HarmonyOS system to access shared logic according to the same rules.

[0136] In this embodiment, by performing boundary convergence on the export interfaces of JS code files and .d.ts type definition files to obtain the target cross-end access interface, and then exposing a standardized cross-end interaction protocol to the HarmonyOS system based on this interface, the problems of poor cross-end interaction compatibility and redundant calling logic caused by the original fragmented and chaotic cross-end interfaces and inconsistent types are overcome. This achieves the effect of standardization, low coupling and significantly improved maintainability of the interaction link between KMP shared code and HarmonyOS ETS.

[0137] In one possible embodiment, the specific implementation process of detecting KMP state changes through a cross-end state bridge and synchronizing the state change values ​​to the HarmonyOS system through the Bridge tool module may further include steps S901 to S903, which are detailed below:

[0138] Step S901: When the cross-end state bridge receives the real-time state value of KMP, it compares the real-time state value with the historical state value.

[0139] Step S902: If the real-time status value is different from the historical status value, then generate status change information based on the real-time status value.

[0140] Step S903: Synchronize the status change information to the HarmonyOS system through the Bridge tool module. The status change information includes the status name and the real-time status value.

[0141] For example, after receiving the real-time status value pushed by KMP, the cross-end status bridge can first read the corresponding historical status value in the local status cache and compare the two at the field level or object level. If the comparison result shows that the two are consistent, no synchronization data is generated.

[0142] If there is a difference between the real-time status value and the historical status value, the status item name corresponding to the difference will be combined with the current real-time status value to form status change information, and the local historical status value cache will be updated so that subsequent comparisons will be based on the latest status.

[0143] Among them, the Bridge tool module can encapsulate the status change information in a data format that can be recognized by the HarmonyOS system and send it to the HarmonyOS system. After receiving it, the HarmonyOS system can locate the corresponding status binding item based on the status name and complete the interface rendering or business status refresh based on the real-time status value.

[0144] Please see Figure 4 , Figure 4 The flowchart of state synchronization between KMP and HarmonyOS provided in the embodiments of this application is as follows: Figure 4 As shown, a cross-end state bridge, PlatformStateFlow, is defined on the KMP side. <t>This allows it to inherit from or delegate to MutableStateFlow. <t>Furthermore, an `onValueChanged(oldValue, newValue)` callback is added at the state change entry points such as value writing and `compareAndSet`. When the KMPViewModel updates the state data, `PlatformStateFlow`... <t>First, update the internal values ​​of the StateFlow, then compare the old and new values. If the old and new values ​​differ, trigger the onValueChanged callback. The onValueChanged callback encapsulates the state name and the latest state value into a Bridge message, and then synchronizes it to the HarmonyOS ETS side via the Bridge tool. After receiving the state change message, the HarmonyOS ETS side writes the state to the AppStorage or other ArkUI observable state container. When ArkUI detects changes in the AppStorage or state container, it triggers component reorganization, achieving responsive refresh of the HarmonyOS interface to changes in the KMPViewModel state.

[0145] In this embodiment, the cross-end state bridge can generate synchronization content only when the state changes. The Bridge tool module is responsible for stably transmitting the structured state change information to the HarmonyOS system, so that the HarmonyOS system can obtain the same state update results as the KMP side and maintain the determinism and consistency of state synchronization.

[0146] On the other hand, please see Figure 5 , Figure 5 A flowchart illustrating the cross-platform communication method between KMP and HarmonyOS provided in this application embodiment. Figure 2 This cross-platform communication method between KMP and HarmonyOS is applied to HarmonyOS, such as... Figure 2 As shown, the cross-platform communication method between KMP and HarmonyOS includes at least steps S1001 to S1003, which are detailed below:

[0147] Step S1001: Obtain the JS code file and .d.ts type definition file from KMP.

[0148] On the HarmonyOS side, the JS code file generated by KMP and the corresponding .d.ts type definition file can be read according to a preset path, and the two are bound as the same communication unit. The JS code file here is used to carry the JavaScript output after the KMP shared code is compiled by Kotlin / JS (KotlinJavaScript), and is the basic object for subsequent execution logic loading, interface attachment, and event registration on the HarmonyOS side; the .d.ts type definition file is used to provide the type information corresponding to the JS code file, including the interface name, method name, parameter structure, parameter type, return type, and callback data structure definition. The HarmonyOS side uses this to establish the type constraint relationship that subsequent cross-platform calls depend on.

[0149] In one possible implementation, after reading the JS code file, the HarmonyOS system first performs a code availability check, including file existence verification, version identifier verification, and exported object verification. Then, it reads the .d.ts type definition file, parses its declarations, and generates an intermediate description object. This intermediate description object includes at least the interface identifier, method signature, parameter order, parameter type mapping, and return value mapping. If, during the reading process, the module name, version number, or exported object name of the JS code file is found to be inconsistent with the .d.ts type definition file, the current communication link initialization is terminated and the exception information is recorded to ensure that the subsequent registration process uses a one-to-one corresponding set of artifacts.

[0150] Step S1002: Based on the type contract established in the .d.ts type definition file, register the Bridge event handler in the JS code file. The type contract is used to instruct KMP to expose type-safe calling interfaces to the HarmonyOS system.

[0151] For example, after reading the JS code file and the .d.ts type definition file, the .d.ts type definition file is parsed to extract the declared module interfaces, method signatures, parameter names, parameter types, nullability, return value types, and event callback structures. The parsed results are then converted into a contract model recognizable by the HarmonyOS side. This contract model is the type contract, and its core function is to establish a unified calling boundary between the HarmonyOS system and the KMP shared code, ensuring that the callable interfaces, allowed data formats, and allowed return data formats are fixed during registration.

[0152] Specifically, each interface declaration in the .d.ts file can be mapped to a contract record. Each contract record contains at least a unique interface identifier, method name, input parameter list, output parameter structure, event name, and event payload structure. Then, based on this contract record, a Bridge event handler is registered in the runtime context of the JS code file. The Bridge event handler is used to receive event messages and state change notifications from the KMP side or the JS runtime environment on the HarmonyOS system side, and to perform message identification, parameter validation, and event dispatch according to the type contract.

[0153] Step S1003: By synchronizing the event handler, the state change values ​​received through the Bridge event handler are written to the AppStorage or ArkUI observable state container to drive the interface reorganization.

[0154] For example, after the Bridge event handler completes the reception and type validation of the state change message, it transfers the state payload that satisfies the type contract to the synchronous event handler. The synchronous event handler is used to convert the cross-platform incoming state data into a state source that the ArkUI interface can directly listen to, and is responsible for writing the state change value to AppStorage or the ArkUI observable state container. In specific implementation, the synchronous event handler first receives a standardized message object from the Bridge event handler. This message object includes at least the state name, state value, state value type, source module identifier, and change sequence number; then, it determines the writing target according to preset mapping rules. When the state belongs to globally shared data, the state name is mapped to a key name in AppStorage, and the state value is written to the corresponding key-value position according to the type defined by the contract; when the state belongs to page-level or component-level observable data, the state name is mapped to the target field in the ArkUI observable state container, and the container performs the field update.

[0155] In this application, AppStorage is used to store state change values ​​written through synchronous event handlers and serves as the data source for ArkUI's responsive UI updates; the ArkUI observable state container is used to hold state change values ​​and is listened to by ArkUI, and changes in the container fields trigger the reorganization of the bound components.

[0156] In some feasible implementations, the synchronous event handler can also perform formatting before writing. Formatting includes basic type conversion, object field renaming, null value normalization, and list structure reorganization to ensure consistency between the state payload from the KMP side and the bound fields of the HarmonyOS interface. For example, when the Bridge event handler receives a state change value that is a composite structure containing a state name, state value, and object data, the synchronous event handler first parses the structure according to the contract model, then writes the value part to the corresponding key in AppStorage, and writes the object part to the target object field in the ArkUI observable state container. After writing is complete, the ArkUI framework detects the data change and triggers page component reorganization.

[0157] In this embodiment, by obtaining the KMP's JS code file and .d.ts type definition file, registering a Bridge event handler on the JS side based on the type contract established by the .d.ts, and then writing the received state change values ​​into the AppStorage or ArkUI observable state container through the synchronous event handler, the problem of traditional KMP and HarmonyOS cross-terminal calls lacking strong type constraints and having a fragmented and error-prone state synchronization link is overcome. This achieves a smooth cross-terminal linkage effect where KMP exposes a type-safe call interface to the HarmonyOS system and state changes can efficiently drive the reorganization of the ArkUI interface.

[0158] In one possible embodiment, the specific implementation process of the cross-terminal communication method between KMP and HarmonyOS may further include steps S1101 to S1104, which are detailed below:

[0159] Step S1101: Receive native call requests or third-party library call requests sent by KMP through the Bridge event handler.

[0160] Step S1102: Extract the method identifier and parameters from the native call request or the third-party library call request.

[0161] Step S1103: Based on the method identifier and parameters, call the corresponding HarmonyOS native capability or third-party library capability to obtain the call response.

[0162] Step S1104: Based on the type contract, the call response is returned to KMP through the Bridge event handler.

[0163] For example, the Bridge event handler can listen for call events from KMP. When a call event arrives, it first determines whether it is a native call request or a third-party library call request based on the type field in the request body. Then, it parses the method identifier, parameter set, and optional context information from the request payload. On the HarmonyOS side, the target capability object can be retrieved from a pre-established capability mapping table based on the method identifier. The native capability object can correspond to HarmonyOS native interfaces such as system file access, network requests, and sensor readings, while the third-party library capability object can correspond to encapsulated encryption, serialization, or business tool library interfaces. If the request parameter is a basic type, it is directly passed by value according to the type contract. If the request parameter is a composite type, the field deserialization can be completed first, and then it can be converted into the input parameter structure required by the target capability, and then the call response can be obtained.

[0164] The call response can include execution results, status codes, and error messages. It is encapsulated by the Bridge event handler according to the type contract established in the .d.ts type definition file and then sent back to the KMP, enabling the KMP side to receive and process the response according to the defined interface type. Since the field structure, data type, and null value constraints of the returned data are all subject to the type contract, the KMP side can directly perform type validation and subsequent logic dispatch upon receiving the response. In practical applications, the Bridge event handler can use an event callback mechanism to send the response to the KMP.

[0165] In this embodiment, the Bridge event handler receives native or third-party library call requests sent by KMP, extracts the method identifier and parameters in the request, calls the corresponding HarmonyOS native or third-party library capabilities, and then sends the call response back to KMP based on the pre-agreed type contract. This overcomes the problems of traditional KMP and HarmonyOS cross-end capability calls having no strong type constraints and chaotic and error-prone request-response links. It achieves the effect of full-link type security for cross-end capability calls and stable and efficient scheduling of HarmonyOS native and third-party capabilities by KMP.

[0166] In one possible embodiment, the specific implementation process of the cross-terminal communication method between KMP and HarmonyOS may further include steps S1201 and S1202, which are detailed below:

[0167] In step S1201, a call request is sent to KMP through the Bridge event handler to trigger the execution of business logic in the Kotlin code shared by KMP.

[0168] Step S1202: Receive the call response returned by the Bridge tool module, and distribute the call response to the corresponding processing logic of the HarmonyOS system through the Bridge event handler.

[0169] For example, the Bridge event handler is deployed in the HarmonyOS-side JS runtime environment to receive call intents initiated by the HarmonyOS interface layer or business layer. It then encapsulates these intents into a request object recognizable by the KMP side before sending it to the shared Kotlin code. The call request can carry a method identifier, a parameter set, and call context information. The method identifier indicates the entry point of the business logic to be executed, the parameter set represents the input data required for business processing, and the call context information maintains object references or session identifiers in the call chain, enabling the KMP shared code to obtain complete execution conditions when triggered on the HarmonyOS side.

[0170] After the Kotlin code shared by KMP is compiled and exposed as a callable JavaScript function, the Bridge event handler triggers the execution of the corresponding function based on the request content. Within KMP, the function performs business validation, data transformation, or domain calculations to form a call response. The Bridge tool module, acting as the JS-side bridging unit, is responsible for receiving the data object returned by KMP and converting it into a response carrier directly recognizable by HarmonyOS. This response carrier can be a structured object containing status codes, result data, and error information. Upon receiving the call response from the Bridge tool module, the Bridge event handler distributes it to the pre-bound corresponding processing logic within the HarmonyOS system based on the method identifier or event type in the response. This processing logic then performs UI updates, status writing, or subsequent business logic interactions.

[0171] Optionally, the Bridge event handler and the Bridge tool module can exchange data through a unified message channel. The message channel uses object serialization to transmit requests and responses to ensure data integrity when interacting across runtime environments.

[0172] In this embodiment, by sending a call request to KMP through the Bridge event handler to trigger the execution of the business logic of the shared Kotlin code in KMP, receiving the call response returned by the Bridge tool module, and distributing the response to the corresponding processing logic in the HarmonyOS system, the HarmonyOS side can stably trigger the Kotlin business logic on the KMP side, and the cross-terminal bidirectional call full-link closed loop and orderly scheduling are achieved.

[0173] In one possible embodiment, the specific implementation process of the above-mentioned cross-terminal communication method between KMP and HarmonyOS may further include the following steps:

[0174] In a component-based scenario, the Kotlin code shared by KMP is accessed through the Umbrella entry point. The Umbrella entry point is configured to converge and encapsulate the set of cross-platform shared interfaces that each business module in KMP needs to expose to the HarmonyOS system.

[0175] For example, because KMP's component-based engineering can build different business modules into independent Kotlin library modules, each module retains its own business logic and external capability definition, and the interface aggregation is completed by the Umbrella entry point during compilation or assembly.

[0176] The Umbrella entry point unifies and aggregates cross-platform capabilities scattered across different business modules, providing a stable call boundary to the outside world. When the HarmonyOS system accesses the KMP shared logic through this boundary, it can directly obtain the interface response after module integration and coordinate with the aforementioned Bridge communication link to achieve consistency in shared code calls and interface exposure. As a result, the cross-platform capabilities of multiple business modules are output through a unified entry point, reducing the coupling of HarmonyOS to the scattered implementation of modules.

[0177] In this embodiment, by configuring the Umbrella entry point in the componentized scenario, the cross-end shared interface set exposed by each business module of KMP to HarmonyOS is converged and encapsulated, and the HarmonyOS system is provided with unified access to the KMP shared Kotlin code. This reduces the problems of scattered exposure of cross-end interfaces, chaotic call chains, and difficulty in managing inter-module dependencies and coupling in traditional componentized scenarios. It achieves the effect of unified management and control of KMP cross-end interfaces and a significant improvement in the call efficiency and maintainability of HarmonyOS accessing KMP shared code.

[0178] Please see Figure 6 , Figure 6 The bidirectional communication interaction diagram between KMP and HarmonyOS provided in this application embodiment shows that since the Bridge tool module, as the communication unit on the JS side, and the Bridge event handler, as the communication unit on the HarmonyOS side, complete the full-link interaction of request forwarding, parameter pass-through, and response return through the agreed unified communication contract, they jointly support cross-terminal capability interoperability and business logic linkage between KMP and the native side of HarmonyOS. Therefore, the Bridge tool module on the JS side and the Bridge event handler on the HarmonyOS ETS side can be integrated and named JsEtsBridgeUtil.

[0179] like Figure 6 As shown, when the KMP / JS side needs to call HarmonyOS ETS native capabilities, the JS side sends a structured message carrying the target method name and input parameters via sendMessageToEts(message, callback). The unified encapsulated JsEtsBridgeUtil accurately delivers the routed message to the HarmonyOS system side, which then triggers various HarmonyOS native capabilities such as MQTT, log reading / writing, and system time retrieval. After execution, the result is returned to JsEtsBridgeUtil via a preset callback (callback(result), which ultimately passes the result back to the KMP side. In scenarios where the HarmonyOS system actively calls KMP side capabilities, the HarmonyOS ETS side pre-registers and binds event listeners via on(eventName, callback). When the KMP / JS side triggers a business event, it calls triggerEvent(eventName, data) to push the corresponding event identifier and business data. JsEtsBridgeUtil is responsible for the accurate distribution of cross-platform events and the secure transmission of parameters throughout the process. For the specific implementation process, please refer to the above embodiments, which will not be repeated here.

[0180] Figure 7 A schematic diagram of the cross-terminal communication device between KMP and HarmonyOS provided in the embodiments of this application. Figure 1 ,like Figure 7 As shown, the cross-platform communication device 70 between KMP and HarmonyOS provided in this embodiment is applied to KMP. The device 70 includes: a compilation module 710, used to compile the Kotlin code shared by KMP into JS code files and .d.ts type definition files; a first communication module 720, used to build a Bridge tool module in the JS code file and establish a type contract for HarmonyOS system calls based on the .d.ts type definition file. The type contract is used to expose type-safe calling interfaces to HarmonyOS; and a first synchronization module 730, used to build a cross-platform state bridge in the JS code file, monitor the state changes of KMP through the cross-platform state bridge, and synchronize the state change information to HarmonyOS through the Bridge tool module based on the type contract.

[0181] In one possible embodiment, the first communication module 720 is further configured to: receive a call request sent by the HarmonyOS system through the Bridge tool module; generate a corresponding call response based on the call request and Kotlin code; and return the call response to the HarmonyOS system through the Bridge tool module based on the type contract.

[0182] In one feasible embodiment, the device 70 further includes a Umbrella entry module for constructing a Umbrella entry in a componentized context, so that the HarmonyOS system can access Kotlin code through the Umbrella entry. The Umbrella entry is configured to converge and encapsulate the set of cross-end shared interfaces that each business module in KMP needs to expose to the HarmonyOS system.

[0183] In one feasible embodiment, the first communication module 720 is further configured to send a call request to the HarmonyOS system through the Bridge tool module based on a type contract; and to receive a call response from the HarmonyOS system through the Bridge tool module.

[0184] In one feasible embodiment, the device 70 further includes an interface conversion module, configured to convert the .d.ts type definition file of the HarmonyOS system or the third-party library into a Kotlin external interface if the call request is a native capability call request of the HarmonyOS system or a third-party library call request; parse the method identifier and parameters in the native capability call request or the third-party library call request according to the Kotlin external interface; and send the method identifier and parameters to the HarmonyOS system through the Bridge tool module based on the type contract to trigger the HarmonyOS native or third-party library call implementation that matches the Kotlin external interface type.

[0185] In one feasible embodiment, the first communication module 720 is further configured to construct a call request based on the target method identifier and associated parameter information to be called, wherein the call request includes a method identifier, a parameter object and a callback identifier; and forward the call request to the HarmonyOS system through the Bridge tool module so that the HarmonyOS system triggers the execution of the business logic corresponding to the method identifier.

[0186] In one feasible embodiment, the compilation module 710 is further configured to add cross-end export annotations to the cross-end shared object of Kotlin code shared by KMP to obtain JS code; and generate .d.ts type definition files based on the cross-end export annotations.

[0187] In one feasible implementation, the compilation module 710 is further configured to perform boundary convergence on the exported interfaces of the JS code file and the .d.ts type definition file to obtain the target cross-end access interface; and expose a standardized cross-end interaction protocol to the HarmonyOS system based on the target cross-end access interface.

[0188] In one possible embodiment, the first synchronization module 730 is further configured to: when the cross-end state bridge receives the real-time state value from the KMP, compare the real-time state value with the historical state value; if the real-time state value is different from the historical state value, generate state change information based on the real-time state value; and synchronize the state change information to the HarmonyOS system through the Bridge tool module, wherein the state change information includes the state name and the real-time state value.

[0189] Figure 8 A schematic diagram of the cross-terminal communication device between KMP and HarmonyOS provided in the embodiments of this application. Figure 2 ,like Figure 8 As shown, the cross-platform communication device 80 between KMP and HarmonyOS provided in this embodiment is applied to HarmonyOS. The device 80 includes: an acquisition module 810, used to acquire JS code files and .d.ts type definition files in KMP; a second communication module 820, used to register a Bridge event handler in the JS code file based on the type contract established by the .d.ts type definition file to respond to the call request sent by KMP. The type contract is used to instruct KMP to expose a type-safe call interface to HarmonyOS; and a second synchronization module 830, used to write the received state change values ​​into AppStorage or ArkUI observable state container through the synchronization event handler to drive interface reorganization.

[0190] In one feasible embodiment, the second communication module 820 is further configured to: receive a native call request or a third-party library call request sent by KMP through a Bridge event handler; extract the method identifier and parameters from the native call request or the third-party library call request; call the corresponding HarmonyOS native capability or third-party library capability based on the method identifier and parameters to obtain a call response; and return the call response to KMP through the Bridge event handler based on the type contract.

[0191] In one feasible implementation, the second communication module 820 is further configured to send a call request to KMP via the Bridge event handler to trigger the execution of business logic in the Kotlin code shared by KMP; receive the call response returned by the Bridge tool module; and distribute the call response to the corresponding processing logic of the HarmonyOS system via the Bridge event handler.

[0192] In one feasible implementation, the device 80 further includes an access module for accessing Kotlin code shared by KMP through a Umbrella entry in a componentized scenario. The Umbrella entry is configured to converge and encapsulate the set of cross-end shared interfaces that each business module in KMP needs to expose to the HarmonyOS system.

[0193] The cross-terminal communication device between KMP and HarmonyOS provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0194] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device 90 provided in this embodiment includes at least one processor 910 and a memory 920. Optionally, the electronic device 90 further includes a communication component 930. The processor 910, memory 920, and communication component 930 are connected via a bus 940.

[0195] In the specific implementation process, at least one processor 910 executes computer execution instructions stored in memory 920, causing at least one processor 910 to execute the above-mentioned cross-end communication method between KMP and HarmonyOS.

[0196] The specific implementation process of processor 910 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0197] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0198] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0199] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0200] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned cross-terminal communication method between KMP and HarmonyOS.

[0201] This application also provides a computer-readable storage medium storing computer-executable instructions. When the processor executes the computer-executable instructions, the above-described cross-terminal communication method between KMP and HarmonyOS is implemented.

[0202] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0203] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0204] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0205] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0206] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0207] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0208] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0209] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.< / t> < / t> < / t>

Claims

1. A cross-platform communication method between KMP and HarmonyOS, characterized in that, Applied to KMP, including: Compile the Kotlin code shared by KMP into JS code files and .d.ts type definition files; The Bridge tool module is built in the JS code file, and a type contract for HarmonyOS system calls is established based on the .d.ts type definition file. The type contract is used to expose type-safe calling interfaces to HarmonyOS. A cross-platform state bridge is built in the JS code file. The state changes of the KMP are monitored through the cross-platform state bridge, and the state change information is synchronized to the HarmonyOS system through the Bridge tool module based on the type contract.

2. The method according to claim 1, characterized in that, The method further includes: The Bridge tool module receives the call request sent by the HarmonyOS system. Based on the call request and the Kotlin code, generate the corresponding call response; Based on the type contract, the call response is returned to the HarmonyOS system through the Bridge tool module.

3. The method according to claim 1 or 2, characterized in that, The method further includes: In a componentized environment, an Umbrella entry point is constructed so that the HarmonyOS system can access the Kotlin code through the Umbrella entry point. The Umbrella entry point is configured to converge and encapsulate the set of cross-platform shared interfaces that each business module in the KMP needs to expose to the HarmonyOS system.

4. The method according to claim 1 or 2, characterized in that, The method further includes: Based on the aforementioned type contract, a call request is sent to the HarmonyOS system through the Bridge tool module; The Bridge tool module receives the call response from the HarmonyOS system.

5. The method according to claim 4, characterized in that, The method further includes: If the call request is a native capability call request of the HarmonyOS system or a third-party library call request, then the .d.ts type definition file of the HarmonyOS system or the third-party library will be converted into a Kotlin external interface; Based on the Kotlin external interface, parse the method identifier and parameters in the native capability call request or the third-party library call request; Based on the type contract, the method identifier and parameters are sent to the HarmonyOS system through the Bridge tool module to trigger a HarmonyOS native or third-party library call implementation that matches the Kotlin external interface type.

6. The method according to claim 4, characterized in that, Sending the call request to the HarmonyOS system via the Bridge tool module includes: Based on the target method identifier and associated parameter information to be invoked, a call request is constructed, which includes a method identifier, a parameter object, and a callback identifier; The Bridge tool module forwards the call request to the HarmonyOS system, so that the HarmonyOS system can trigger the execution of the business logic corresponding to the method identifier.

7. The method according to claim 1 or 2, characterized in that, The process of compiling the KMP-shared Kotlin code into JS code files and .d.ts type definition files includes: Add a cross-platform export annotation to the cross-platform shared object of the Kotlin code shared by KMP to obtain the JS code; Based on the cross-platform exported annotations, generate a .d.ts type definition file.

8. The method according to claim 7, characterized in that, The method further includes: Boundary convergence is performed on the exported interfaces of the JS code file and the .d.ts type definition file to obtain the target cross-platform access interface; Based on the target cross-platform access interface, a standardized cross-platform interaction protocol is exposed to the HarmonyOS system.

9. The method according to claim 1 or 2, characterized in that, The step of detecting the state changes of the KMP through a cross-end state bridge and synchronizing the state change values ​​to the HarmonyOS system through the Bridge tool module includes: When the cross-end state bridge receives the real-time state value of the KMP, it compares the real-time state value with the historical state value. If the real-time status value is different from the historical status value, then status change information is generated based on the real-time status value; The Bridge tool module synchronizes the status change information to the HarmonyOS system. The status change information includes the status name and the real-time status value.

10. A cross-platform communication method between KMP and HarmonyOS, characterized in that, Applied to the HarmonyOS system, including: Retrieve the JS code file and .d.ts type definition file from KMP; Based on the type contract established by the .d.ts type definition file, a Bridge event handler is registered in the JS code file. The type contract is used to instruct the KMP to expose a type-safe calling interface to the HarmonyOS system. By synchronizing the event handler, the state change values ​​received through the Bridge event handler are written to the AppStorage or ArkUI observable state container to drive the interface reorganization.

11. The method according to claim 10, characterized in that, The method further includes: The Bridge event handler receives native call requests or third-party library call requests sent by the KMP. Extract the method identifier and parameters from the native call request or the third-party library call request; Based on the method identifier and parameters, the corresponding HarmonyOS native capability or third-party library capability is invoked to obtain the invocation response; Based on the type contract, the call response is returned to the KMP through the Bridge event handler.

12. The method according to claim 10, characterized in that, The method further includes: The Bridge event handler sends a call request to the KMP to trigger the execution of business logic in the shared Kotlin code of the KMP. The system receives the call response returned by the Bridge tool module and distributes the call response to the corresponding processing logic of the HarmonyOS system through the Bridge event handler.

13. The method according to claim 10, characterized in that, The method further includes: In a component-based scenario, the Kotlin code shared by KMP is accessed through the Umbrella entry point. The Umbrella entry point is configured to converge and encapsulate the set of cross-platform shared interfaces that each business module in KMP needs to expose to the HarmonyOS system.

14. A cross-platform communication device between KMP and HarmonyOS, characterized in that, Applied to KMP, including: The compilation module is used to compile the Kotlin code shared by KMP into JS code files and .d.ts type definition files; The first communication module is used to build the Bridge tool module in the JS code file and establish a type contract for HarmonyOS system calls based on the .d.ts type definition file. The type contract is used to expose type-safe call interfaces to HarmonyOS. The first synchronization module is used to build a cross-platform state bridge in the JS code file, monitor the state changes of the KMP through the cross-platform state bridge, and synchronize the state change information to the HarmonyOS system through the Bridge tool module based on the type contract.

15. A cross-platform communication device between KMP and HarmonyOS, characterized in that, Applied to the HarmonyOS system, including: The module is used to retrieve JS code files and .d.ts type definition files from KMP. The second communication module is used to register a Bridge event handler in the JS code file based on the type contract established by the .d.ts type definition file to respond to the call request sent by the KMP. The type contract is used to instruct the KMP to expose a type-safe call interface to the HarmonyOS system. The second synchronization module is used to write the received state change values ​​into the AppStorage or ArkUI observable state container through the synchronization event handler, so as to drive the interface reorganization.

16. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 13.

Images