Method, Medium, and Electronic Device for an Application to Run on the HarmonyOS

Abstract

The present application relates to the field of computer technology, and discloses a method, medium, and electronic device for running an application on a Hongmeng operating system. The electronic device includes a first application, a first mapping module, and a first virtual machine running the first application. The first mapping module stores a first mapping relationship corresponding to a first type of information and a first type of service that calls the first application. In this method, the electronic device can detect a first message belonging to the first type of information, and determine the first service corresponding to the first message from the first type of service based on the first mapping relationship. Furthermore, the electronic device can call the first virtual machine to run the first application based on the first service. In this way, normal information interaction can be carried out between the application and the Hongmeng operating system.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, medium, and electronic device for running an application on the Hongmeng operating system. Background Art

[0002] As electronic devices continue to update their HarmonyOS versions, they need to run applications that correspond to the HarmonyOS version. If the application version is incompatible with the HarmonyOS version, for example, the HarmonyOS version on a computer is 64-bit and the application is 32-bit, or if the HarmonyOS version has been updated but the application was developed based on the previous version of HarmonyOS, this may result in the application being unable to use features in the updated HarmonyOS or the application running slower. Summary of the Invention

[0003] The purpose of this application is to provide a method, medium, and electronic device for running an application on the Hongmeng operating system. The method includes:

[0004] The first aspect of the present application provides a method for running an application on a HarmonyOS operating system, which is applied to an electronic device, the electronic device comprising a first application, a first mapping module, and a first virtual machine running the first application; wherein the first mapping module stores a first mapping relationship corresponding to a first category of information of the electronic device and a first category of service that calls the first application; the method comprises: detecting a first message belonging to the first category of information, and determining, from the first category of services, a first service corresponding to the first message; and calling the first virtual machine based on the first service to run the first application.

[0005] In some implementations, the first mapping module can be a native application programming interface (NAPI). NAPI is used to convert information (e.g., functions or data types) between the ArkTS (Ark TypeScript) programming language (or JavaScript, etc.) and the C / C++ programming language. Electronic devices can use the NAPI interface to establish a mapping relationship between ArkTS and C / C++. For example, consider the mapping relationship DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). It can be understood that this statement maps the C++ function NapiManager::NapiOnCreate to onCreate. In other words, the electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the ArkTS code. It can be understood that onCreate is the function name of NapiManager::NapiOnCreate in ArkTS, while NapiManager::NapiOnCreate is the specific implementation method in C++.

[0006] It is understood that the first application can transmit information (i.e., a first message) to the HarmonyOS, invoke the first service corresponding to the first message, and run the first application in the first virtual machine based on the first service, thereby allowing the first application to run normally on the new version of the HarmonyOS. In this way, the HarmonyOS can call the functions contained in the first application through the first mapping module. The electronic device can establish communication between the HarmonyOS and the first application so that the first application can run on the HarmonyOS.

[0007] In a possible implementation of the first aspect above, the first mapping module is a native application programming interface module, the first application is an application developed based on the Lua language, and the first virtual machine is a Lua virtual machine.

[0008] It is understood that electronic devices can enable normal communication between applications developed in the Lua language and the Hongmeng operating system through the native application programming interface module. In this way, applications developed in the Lua language can run on the Hongmeng operating system.

[0009] In a possible implementation of the first aspect above, the first category of information includes an event handling function corresponding to a triggering event that triggers the first application; the first service includes NapiManager::NapiOnCreate, NapiManager::NapiOnShow, NapiManager::NapiOnHide, NapiManager::NapiOnBackPress, NapiManager::NapiOnDestroy, and NapiManager::napiNativeToCocos.

[0010] In a possible implementation of the first aspect, the event processing functions include onCreate, onShow, onHide, onBackPress, onDestroy, and nativeToCocos.

[0011] In a possible implementation of the first aspect above, the first service also includes a callback function, and calling the first virtual machine to run the first application based on the first service includes: passing a first parameter corresponding to the trigger event to the first virtual machine based on the callback function; calling the first parameter to run the first application based on the first virtual machine; wherein the first parameter includes a function of the first application.

[0012] In a possible implementation of the first aspect above, the triggering event includes: clicking a button, moving a mouse, and completing page loading.

[0013] In a possible implementation of the first aspect above, the electronic device also includes a first communication module, which is used to transmit communication data sent by the first virtual machine, and the communication data is used to call a second service of the electronic device; the method also includes: detecting that the first communication module receives the communication data of the first virtual machine; calling the second service based on the communication data, and returning the running result of the second service to the first virtual machine based on the first communication module.

[0014] Exemplarily, the first communication module may be a LuaOhosBridge class. The first virtual machine may be a Lua virtual machine. The electronic device detects a first request in which a Lua script calls an arkTS function through the LuaOhosBridge class, and the electronic device may obtain communication data of the second service in the first request through the LuaOhosBridge class. The communication data may include parameters and function names of the arkTS function called by the Lua script. The electronic device may use the arkTS function to obtain the running result of the second service and return it to the first virtual machine based on the first communication module.

[0015] It is understood that the electronic device can enable the first application (running on the first virtual machine) to call functions of the HarmonyOS through the first communication module. In this way, the electronic device can establish communication between the HarmonyOS and the first application, allowing the first application to run on the HarmonyOS.

[0016] In a possible implementation of the first aspect above, the first communication module is the LuaOhosBridge class, and the second service is a service provided by the HarmonyOS operating system; the communication data includes the function name of the second service and the calling parameters of the second service.

[0017] The second aspect of the present application provides a readable medium, on which instructions are stored. When the instructions are executed on an electronic device, the electronic device executes the method for running any one of the applications in the first aspect mentioned above on the HarmonyOS operating system.

[0018] The third aspect of this application provides an electronic device, including a memory for storing instructions executed by one or more processors of the electronic device, and a processor, which is one of the processors of the electronic device, for executing a method for running any one of the applications in the first aspect above on the HarmonyOS operating system.

[0019] The fourth aspect of this application provides a program product, which includes instructions. When the instructions are executed on an electronic device, the electronic device executes the method for running any one of the applications in the first aspect on the HarmonyOS operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1A According to some embodiments of the present application, a schematic diagram of the interaction between the Hongmeng operating system and an application is shown;

[0022] Figure 1B According to some embodiments of the present application, a schematic diagram is shown of an incompatibility between an application and a version of the Hongmeng operating system of an electronic device;

[0023] Figure 1C According to some embodiments of the present application, a schematic diagram is shown in which an application cannot be started normally;

[0024] Figure 2According to some embodiments of the present application, a flowchart of a method for running an application on the Hongmeng operating system is shown;

[0025] Figure 3 According to some embodiments of the present application, a schematic diagram of a system architecture of an electronic device is shown;

[0026] Figure 4 According to some embodiments of the present application, a schematic diagram of an embodiment of a Hongmeng native to Cocos2d-x Lua interaction system framework is shown;

[0027] Figure 5 According to some embodiments of the present application, a schematic diagram of an embodiment of interaction from Hongmeng native to Cocos2d-x Lua is shown;

[0028] Figure 6A According to some embodiments of the present application, a schematic diagram of an embodiment of a call chain from a HarmonyOS native function to a Lua function is shown;

[0029] Figure 6B According to some embodiments of the present application, a schematic diagram of a scenario in which the keyboard height changes is shown;

[0030] Figure 6C According to some embodiments of the present application, a schematic diagram of a process of changing the height of a keyboard is shown;

[0031] Figure 7 According to some embodiments of the present application, a flowchart of another method for running an application on the Hongmeng operating system is shown;

[0032] Figure 8 According to some embodiments of the present application, a schematic flow chart of a method for operating a first communication module on the Hongmeng operating system is shown;

[0033] Figure 9 According to some embodiments of the present application, a schematic flow diagram of a project creation and basic configuration method is shown;

[0034] Figure 10 According to some embodiments of the present application, a schematic structural diagram of an electronic device is shown. DETAILED DESCRIPTION

[0035] The illustrative embodiments of the present application include, but are not limited to, a method for running an application on the Hongmeng operating system, a readable medium, an electronic device, and a program product.

[0036] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0037] As mentioned above, if the application on the electronic device is incompatible with the Harmony operating system of the electronic device, it may cause the application to fail to run normally or the application to run slowly.

[0038] Next, the running process of the application in the electronic device is introduced.

[0039] It can be understood that the electronic devices mentioned in the embodiments of the present application can be called terminals, user equipment (UE), mobile phones, smart TVs, wearable devices, tablet computers, computers with wireless transceiver functions, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, and other devices.

[0040] Figure 1A A schematic diagram showing the interaction between the Hongmeng operating system and an application of an electronic device is shown.

[0041] like Figure 1A As shown, the electronic device includes application A, which may be a game application, a music application, a video player application, etc. After detecting that application A is started, the electronic device may prepare to start application A.

[0042] For example, an electronic device detects that a user clicks the icon of application A, and then the Hongmeng operating system of the electronic device can receive the corresponding launch request. This launch request usually contains information about the application to be launched, such as the package name of application A and the entry class (such as the Ability class). The system service (AbilityManagerService) (or similar services, etc.) in the Hongmeng operating system of the electronic device can be responsible for parsing the launch request and verifying its legitimacy. After the verification is passed, the Hongmeng operating system will begin to prepare the resources and environment required to launch the application.

[0043] The Hongmeng operating system of the electronic device will then create a process (such as AppSpawn) for application A. This process will contain the startup parameters of application A (such as the process name, the package name of application A, etc.).

[0044] After the process starts, Hongmeng OS loads the code for Application A and initializes its context. Application A's context is the basic environment in which Application A runs. Through Application A's context, electronic devices can access Application A's configuration file (e.g., config.json), obtain information about Application A's lifecycle (e.g., creation, running, pausing, resuming, and destroying), and implement inter-module communication. Furthermore, electronic devices can instantiate Application A's entry class (Ability) so that they can call Application A's lifecycle functions (e.g., onStart(), onResume(), onPause(), and onDestroy()) through the entry class.

[0045] Hongmeng OS can then use its own graphics rendering engine to render the interface of application A to the screen. This process involves parsing the layout file and resource file of application A into graphic elements and drawing them to the screen.

[0046] When a user interacts with Application A (such as clicking a button or entering text), Hongmeng OS can capture these events and pass them to Application A for processing. Application A responds to these events by implementing specific callback methods.

[0047] It can be understood that the above-mentioned application A needs to communicate with the Hongmeng operating system of the electronic device during operation, so as to transmit corresponding data to ensure that application A can start and run normally.

[0048] However, if Application A is incompatible with the Hongmeng OS of the electronic device, for example, the Hongmeng OS version has been updated, and the application is developed based on the previous version of the Hongmeng OS, Application A will not be able to interact properly with the Hongmeng OS of the electronic device, causing Application A to fail to start properly or run slowly.

[0049] It is understandable that if an application is incompatible with the HarmonyOS, the electronic device may cause problems such as application startup failure, errors in information transmission between the application and the HarmonyOS, slow running of the application on the HarmonyOS, user interface adaptation issues, limited application functions, electronic device security issues, and application access rights to the electronic device.

[0050] For example, Figure 1BA schematic diagram showing incompatibility between an application and the version of the HarmonyOS operating system of an electronic device.

[0051] For example, refer to Figure 1B If an application is incompatible with HarmonyOS, it will need to call HarmonyOS-specific application programming interfaces (APIs) during startup. For example, when running on HarmonyOS, an application needs to call the Ability and AbilityContext classes during startup. If the application is incompatible with HarmonyOS, the application cannot call the Ability and AbilityContext classes. As a result, the application will not start properly on HarmonyOS, resulting in startup failure.

[0052] For example, Figure 1C A schematic diagram showing a case where an application cannot be started normally.

[0053] Reference Figure 1C , application 101 is running on electronic device 10, and application 101 is incompatible with the Hongmeng operating system running on electronic device 10. In this way, when electronic device 10 receives a trigger event in which the user clicks the icon of application 101, application 101 cannot be started, resulting in a startup failure. Exemplarily, in some embodiments, electronic device 10 may display a prompt box 102, which includes a prompt message "The application cannot be started, please update the version of the application!" text logo, an exclamation point warning icon, an "Exit" button, and an "Update" button. It can be understood that when electronic device 10 receives a signal in which the user clicks the "Exit" button, prompt box 102 disappears, and electronic device 10 displays the desktop. When electronic device 10 receives a signal in which the user clicks the "Update" button, prompt box 102 disappears, and electronic device 10 displays the interface for updating the application.

[0054] Understandably, if an application is incompatible with Hongmeng OS, the two may not be able to call each other's functions. For example, an application may call an API that doesn't exist in Hongmeng OS, and therefore the application cannot call Hongmeng OS functions. Another example is that the programming language of Hongmeng OS differs from the programming language of the application, and therefore Hongmeng OS cannot call the application's functions. This prevents the application from transmitting information to Hongmeng OS, resulting in runtime errors or malfunctions.

[0055] To sum up, in an electronic device, if an application is incompatible with the Harmony operating system of the electronic device, it may lead to the inability to transmit information between the application and the Harmony operating system, and thus the inability to communicate normally, resulting in the application being unable to start normally, or the application runtime errors or functional abnormalities, affecting the user experience.

[0056] Therefore, in some embodiments of the present application, a communication method can be established between the HarmonyOS and the first application so that the first application can communicate with the HarmonyOS in the electronic device, thereby enabling the first application to run under different HarmonyOS to improve the user experience.

[0057] To enable applications to run on different HarmonyOS systems, the HarmonyOS may include a first mapping module and a first virtual machine for running the first application. The first mapping module stores a first mapping relationship between different types of electronic device information (e.g., information for launching the first application, functions or data for running certain services of the first application, etc., hereinafter referred to as first-category information) and first-category services, where the first-category services are used to invoke the first virtual machine to run the functions of the first application. Using this first mapping relationship, upon detecting a trigger event corresponding to the first application, the HarmonyOS of the electronic device can determine a first message from the first-category information based on the trigger event. The electronic device can then determine the corresponding first service from the first-category services based on the first mapping relationship. In other words, the first service is the service corresponding to the first message. The electronic device can then invoke the first virtual machine through the first service to execute the corresponding function, thereby running the first application in response to the trigger event. The programming language corresponding to the HarmonyOS of the electronic device and the programming language corresponding to the first application can both interact with the programming language corresponding to the first service. In other words, although the HarmonyOS of the electronic device is not compatible with the first application, communication can be bridged using the language corresponding to the first service, allowing the first application to run on the HarmonyOS of the electronic device.

[0058] In order to solve the problem that the application of the above-mentioned electronic device and the Hongmeng operating system cannot communicate normally, the present application provides a method for running an application on the Hongmeng operating system, which is applied to an electronic device. The electronic device includes a first application, the above-mentioned mapping module, and a first virtual machine running the first application. The first mapping module stores a first mapping relationship corresponding to a first category of information of the electronic device and various services of the first calling application. The method includes: detecting a first message belonging to the first category of information, determining a first service corresponding to the first message according to the first mapping relationship, and calling the first virtual machine to run the first application based on the first service.

[0059] Exemplarily, as described above, for the first mapping relationship DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos), nativeToCocos is the first message, and NapiManager::napiNativeToCocos is the first service.

[0060] Through the above solution, during the process of the first application running on the Hongmeng operating system, the electronic device can receive the first message corresponding to the first application, determine the corresponding first service based on the first message, and then call the first virtual machine based on the first service to run the first application. It can be understood that the first message belongs to the first category of information, and the first service belongs to the first category of services. Therefore, the first application can transmit information (i.e., the first message) with the Hongmeng operating system, call the first service corresponding to the first message, and call the first virtual machine based on the first service to run the first application, so that the first application can run normally on the current Hongmeng operating system.

[0061] In some embodiments of the present application, the Hongmeng operating system of the electronic device is Next, and the first mapping module can be a native application programming interface (NAPI), which is used to implement information (such as functions or data types) conversion between the arkTS programming language (or JavaScript, etc.) and the C / C++ programming language. The first service can, for example, be a function programmed in the C++ language. Furthermore, the developer can call the code corresponding to the first service of the Hongmeng operating system (for example, calling a C++ function in a C++ function library) through the arkTS programming language (or JavaScript, etc.) in the arkTS adaptation layer (in the Hongmeng system, the arkTS adaptation layer is the intermediate layer between the application developed in the arkTS programming language and the Hongmeng operating system) and call the first virtual machine through the code corresponding to the first service, thereby running the first application according to the first virtual machine to transmit information between the Hongmeng operating system and the first application.

[0062] In some embodiments of the present application, the electronic device can establish a mapping relationship between arkTS and C / C++ (for example, the programming language corresponding to the first service) through the NAPI interface. According to the mapping relationship, the functions in the arkTS code and the functions in the C / C++ code can call each other. Specifically, through the NAPI interface, the electronic device can call the function in the C / C++ code in the arkTS code, and the electronic device can also call the function in the arkTS code in the C / C++ code. In addition, the electronic device can convert data types between arkTS and C / C++ through the NAPI interface. For example, convert the data type in the arkTS code into the data type in the C / C++ code, or convert the data type in the C / C++ code into the data type in the arkTS code.

[0063] For example, consider the mapping relationship DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). This statement maps the C++ function NapiManager::NapiOnCreate to onCreate. This means that an electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It's understandable that onCreate is the name of the NapiManager::NapiOnCreate function in arkTS, while NapiManager::NapiOnCreate is the specific implementation method in C++.

[0064] It can be understood that the electronic device establishes a mapping relationship between arkTS and C / C++ through NAPI. Based on this mapping relationship, the electronic device can call C / C++ functions in functions in the arkTS code, and C / C++ functions can also call arkTS functions.

[0065] It is understood that electronic devices can also establish a mapping relationship between C / C++ and other programming languages ​​through NAPI, such as JavaScript, Typescript, etc.

[0066] In some embodiments of the present application, the first message may be an event handling function corresponding to a triggering event for triggering the first application. For example, a triggering event is an action or state change that occurs when a user interacts with an electronic device (such as clicking a button, moving the mouse, completing page loading, etc.). The electronic device may receive a triggering event and call an event handling function corresponding to the triggering event. For example, the event handling function may be onCreate (a function called when the application or display interface is initialized), onShow (a function called when the application or display interface switches from the background to the foreground, such as restoring the state of the application, loading data, etc.), onHide (a function called when the application or display interface switches from the foreground to the background, such as saving the current state of the electronic device, executing functions corresponding to the basic functions of the Hongmeng operating system), onBackPress (a function called when the electronic device receives a user-triggered return key), and onDestroy (a function called when the application or display interface is destroyed).

[0067] It is understood that the trigger event may also be other types of trigger events, which are not described here. The event processing function may also be other types of event processing functions, which are not described here.

[0068] In some embodiments of the present application, the electronic device further includes a first communication module (e.g., a LuaOhosBridge class), which is used to enable communication between the first virtual machine and the Hongmeng operating system of the electronic device. For example, the first communication module may transmit communication data of a second service of the Hongmeng operating system invoked by the first virtual machine to the Hongmeng operating system of the electronic device. This data may include, for example, a function name and operating parameters of the second service.

[0069] The electronic device detects a first request of the first virtual machine received by the first communication module, wherein the first request includes communication data of the second service; calls the second service based on the first request, and returns the running result of the second service to the first virtual machine based on the first communication module.

[0070] In some embodiments, the first communication module may be a LuaOhosBridge class. In some possible cases, the electronic device may call a C++ function in a Lua script through LuaOhosBridge and return the result to the Lua script.

[0071] The first virtual machine may be the aforementioned Lua virtual machine.

[0072] The second service may be a function in the Harmony operating system of the electronic device. For example, in the Harmony operating system, the second service may be a function of the Harmony operating system called in the code running in the first virtual machine. The communication data may be, for example, the function name of the second service and the relevant parameters for executing the corresponding function.

[0073] The following is a detailed description of the method for running the application mentioned in this application on the Hongmeng operating system in conjunction with an embodiment. Figure 2 As shown, a schematic diagram of a method for running an application on the Hongmeng operating system is shown, and the method is executed by the electronic device mentioned above.

[0074] In some embodiments of the present application, as described above, in order to enable communication between the first application and the Hongmeng operating system, the electronic device needs to include a first mapping module. In this way, the electronic device can establish a mapping relationship between arkTS and C / C++ through the first mapping module, so that the Hongmeng operating system can call the first application.

[0075] S201: A first message belonging to a first category of information is detected.

[0076] It can be understood that, as mentioned above, the first message can be an event processing function corresponding to a triggering event for triggering the first application. The electronic device can detect a triggering event when a user interacts with the electronic device. For example, a triggering event can be clicking a button, moving a mouse, completing page loading, etc. The triggering event can also be an event during the interaction between the first application and the Hongmeng operating system. For example, the application or display interface is initialized, the application or display interface switches from the background to the foreground, the application or display interface switches from the foreground to the background, the electronic device receives a user-triggered return key, the application or display interface is destroyed, etc.

[0077] S202: Determine a first service corresponding to the first message according to the first mapping relationship.

[0078] In some embodiments of the present application, the first mapping relationship may be a mapping relationship between a first message and a first service, and the electronic device may call a first virtual machine based on the first service to run a first application. It can be understood that the first application is an application ported to the Hongmeng operating system of the electronic device by code porting, and therefore, the first application and the Hongmeng operating system of the electronic device may not be able to communicate directly. In some embodiments of the present application, the electronic device may pre-store a first mapping relationship between the first service of the first application and the first message. After the electronic device detects the first message belonging to the first application, it may call the first virtual machine based on the first service to run the first application.

[0079] It is understandable that, as mentioned above, the electronic device can receive a trigger event and call the event processing function corresponding to the trigger event. For example, the event processing function can be onCreate, onShow, onHide, onBackPress, and onDestroy, etc. It is understandable that the above-mentioned event processing function can be the name of the function corresponding to the first service in arkTS. After detecting the above-mentioned event processing function, the Hongmeng operating system of the electronic device can determine the first service that needs to be called according to the first mapping relationship.

[0080] For example, the first mapping relationship can be DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). This statement maps the C++ function NapiManager::NapiOnCreate to onCreate. That is, an electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It can be understood that onCreate is the name of the NapiManager::NapiOnCreate function in arkTS, while the NapiManager::NapiOnCreate function is the specific implementation method in C++.

[0081] In some embodiments of the present application, the first mapping relationship may further include DECLARE_NAPI_FUNCTION("onShow", NapiManager::NapiOnShow). It is understood that this statement indicates mapping the C++ function NapiManager::NapiOnShow to onShow. That is, the electronic device can call the C++ function NapiManager::NapiOnShow by calling onShow in the arkTS code.

[0082] DECLARE_NAPI_FUNCTION("onHide", NapiManager::NapiOnHide). This statement maps the C++ function NapiManager::NapiOnHide to onHide. This means that the electronic device can call the C++ function NapiManager::NapiOnHide by calling onHide in the arkTS code.

[0083] DECLARE_NAPI_FUNCTION("onBackPress", NapiManager::NapiOnBackPress). This statement maps the C++ function NapiManager::NapiOnBackPress to onBackPress. This means that the electronic device can call the C++ function NapiManager::NapiOnBackPress by calling onBackPress in the arkTS code.

[0084] DECLARE_NAPI_FUNCTION("onDestroy", NapiManager::NapiOnDestroy). This statement maps the C++ function NapiManager::NapiOnDestroy to onDestroy. This means that the electronic device can call the C++ function NapiManager::NapiOnDestroy by calling onDestroy in the arkTS code.

[0085] DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos). This statement maps the C++ function NapiManager::napiNativeToCocos to nativeToCocos. This means that electronic devices can call the C++ function NapiManager::napiNativeToCocos by calling nativeToCocos in the ArkTS code.

[0086] It is understandable that in other embodiments, the first mapping relationship may also be in other forms, which will not be described here.

[0087] S203: Calling the first virtual machine to run the first application based on the first service.

[0088] In some embodiments of the present application, the first application may be encoded based on the programming language corresponding to the first virtual machine. For example, the programming language of the first application may be Lua, and the first virtual machine may be a Lua virtual machine. After the electronic device determines the first service based on the first mapping relationship, it may call the first virtual machine based on the first service to run the first application.

[0089] For example, for the first mapping relationship DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos), nativeToCocos is the first message, and NapiManager::napiNativeToCocos is the first service. After determining that the first service is NapiManager::napiNativeToCocos through the first mapping relationship, the electronic device can call the first virtual machine based on the first service to run the first application.

[0090] In some embodiments of the present application, the electronic device can establish a mapping relationship between the Hongmeng operating system and Cocos2d-xLua through DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos). It can be understood that the electronic device can detect whether the number of parameters and parameter types of the parameters passed by the Hongmeng operating system in the process of calling the first application by the Hongmeng operating system through the NapiManager::napiNativeToCocos function are correct. In addition, the electronic device can also call a callback function through the NapiManager::napiNativeToCocos function. The callback function can pass the parameters obtained by the NapiManager::napiNativeToCocos function to the first virtual machine. The callback function can also receive the running result of the first virtual machine running the first application in response to the trigger event detected by the electronic device.

[0091] For example, the operation result may be initializing the first application or displaying an interface, or responding to a user operation (eg, clicking a button, moving a mouse), which will not be described here.

[0092] In summary, the electronic device can obtain the trigger event in the arkTS adaptation layer, and then search for the mapping relationship through the NAPI mapping mechanism to map the trigger event obtained by the arkTS adaptation layer from the programming language of the arkTS adaptation layer (for example, arkTS, JavaScript, TypeScript) to C++. During the mapping process, the electronic device can call the napiNativeToCocos function. Furthermore, in the process of the electronic device calling the napiNativeToCocos function, the electronic device can use the callback function to establish a communication process from the arkTS adaptation layer to the first virtual machine to transmit the first message. It can be understood that through the callback function, the electronic device can also obtain the result of the first virtual machine running the first application in response to the trigger event.

[0093] The following combination Figure 3 Introduce the system architecture of electronic equipment in detail. Figure 3 , which is a schematic diagram of a system architecture of an electronic device.

[0094] In some embodiments of this application, the system architecture of an electronic device is described using the Hongmeng operating system as an example. The system architecture of the Hongmeng operating system is, from top to bottom, the application layer, the framework layer, the system service layer, and the kernel layer.

[0095] The application layer includes system applications and third-party non-system applications for interacting with users. For example, in some embodiments of the present application, the application layer may include a first application. Exemplarily, the first application is ported to the Hongmeng operating system through code porting. The first application may be, for example, the Cocos2d-x Lua Community Edition game engine. It can be understood that the Cocos2d-x Lua Community Edition game engine is a game development framework developed based on the Cocos2d-x game engine and focuses on the Lua scripting language. The Cocos2d-x Lua Community Edition game engine inherits the powerful functions of the Cocos2d-x game engine and combines the simplicity and efficiency of the Lua language to improve the efficiency of developers in developing games.

[0096] Hongmeng OS applications consist of one or more feature capabilities (FA) or particle capabilities (PA). FAs have user interfaces (UIs) that provide user interaction. PAs provide the ability to run background tasks and a unified data access abstraction.

[0097] The framework layer provides a user program framework and Ability framework in multiple languages such as Java / C / C++ / JavaScript for the development of Hongmeng operating system applications, a Java UI framework for Java language, an ArkUI framework for JavaScript language and arkTS language, and a multi-language framework API open to the outside world for various software and hardware services. In some embodiments of the present application, the ArkUI framework can provide a rich development foundation such as UI components, animation mechanisms, event interactions, etc. for application development, helping developers improve the efficiency of application interface development. For example, ArkUI provides a rich set of UI components and layout methods, and developers can use these components and layouts to build the interface of an application. These components include buttons, text, lists, grids, etc., and layout methods include linear layout, grid layout, etc. ArkUI also supports an event handling mechanism, and developers can add event listeners to components to respond to user interactions. For example, when a user clicks a button, an event handling function can be triggered to execute the corresponding logic.

[0098] The ArkUI framework includes an adaptation layer for arkTS, a language extension for declarative UI development in HarmonyOS. Based on TypeScript, arkTS extends the declarative syntax for UI drawing. It allows developers to describe UI interfaces more intuitively and efficiently without having to worry about the underlying UI drawing and rendering details.

[0099] In some embodiments of the present application, arkTS is an extension and supplement to the ArkUI framework. The ArkUI framework provides a wealth of UI components and layout methods, while arkTS simplifies the UI interface development process in a declarative way. At the same time, the arkTS adaptation layer ensures that the arkTS code can run smoothly in the ArkUI framework, thereby realizing the development of cross-end applications. When the user interacts with the application interface (such as clicking a button, sliding a list, etc.), the arkTS adaptation layer can capture these interaction events and process them according to predefined logic. The processing results will be updated to the UI interface in real time, thereby providing users with a smooth interactive experience.

[0100] In some embodiments of the present application, the framework layer of the HarmonyOS operating system may also include a C++ implemented lib library, a Lua virtual machine, and a NAPI module.

[0101] Among them, the lib library implemented in C++ refers to a collection of codes such as functions, classes, objects, etc. written in the C++ programming language. These codes are compiled into static libraries (.lib, .a files) or dynamic libraries (.dll, .so files) for other C++ programs or projects to link and use at compile time or runtime.

[0102] The Lua virtual machine is the execution engine of the Lua code, responsible for interpreting and executing the Lua source code or compiled bytecode. The Lua source code is first compiled into bytecode, which is an intermediate representation. The Lua virtual machine can directly and efficiently execute code in this format. The Lua virtual machine is a core component of the Lua language. It provides an efficient and flexible script execution environment and supports multiple extension and integration mechanisms. In some embodiments of the present application, the first application can, for example, be an application developed based on Lua.

[0103] The NAPI module can store a first mapping between the first type of information on the electronic device and various services of application A. The first message can be an event handling function corresponding to a triggering event used to trigger the first application. For example, the triggering event might be the electronic device detecting a user clicking a button, moving the mouse, or the completion of a page load. The electronic device can receive the triggering event and call the corresponding event handling function. For example, the event handling function might be onCreate, onShow, onHide, onBackPress, onDestroy, etc. It will be understood that through the first mapping, the electronic device can obtain the first service corresponding to the event handling function. For example, "onCreate" is the function name of "NapiManager::NapiOnCreate" in the arkTS code, and "NapiManager::NapiOnCreate" is the function corresponding to "onCreate" after the first mapping (i.e., the first service). An example of the first mapping might be "DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). That is, after the electronic device detects that the event processing function corresponding to the trigger event is onCreate, it can determine the first service (NapiManager::NapiOnCreate) that can call application A through DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate) in the first mapping relationship.

[0104] The framework layer also includes the basic software service subsystem set, the enhanced software service subsystem set, and the hardware service subsystem set. The basic software service subsystem set, the enhanced software service subsystem set, and the hardware service subsystem set are described in detail in the system service layer.

[0105] The system service layer includes the system basic capability subsystem, the basic software service subsystem, the enhanced software service subsystem, and the hardware service subsystem. The system basic capability subsystem provides fundamental capabilities for running, scheduling, and migrating distributed applications across multiple devices in the HarmonyOS operating system. It comprises subsystems such as the distributed soft bus, distributed data management, distributed task scheduling, the Ark multi-language runtime, common basic libraries, multi-modal input, graphics, security, and AI. The basic software service subsystem provides common, general-purpose software services for the HarmonyOS operating system. It comprises subsystems such as event notification, telephony, multimedia, DFX (Design for X), and MSDP&DV. The enhanced software service subsystem provides differentiated, device-specific, capability-enhancing software services for the HarmonyOS operating system. It comprises subsystems for specialized smart screen services, wearable services, and IoT services. The hardware service subsystem set can provide hardware services for the HarmonyOS operating system. The hardware service subsystem set consists of subsystems such as location services, biometric recognition, wearable proprietary hardware services, and IoT proprietary hardware services.

[0106] The kernel layer is primarily divided into the kernel subsystem and the driver subsystem. The kernel subsystem includes the Linux kernel, LiteOS, and the kernel abstraction layer (KAL). KAL provides fundamental kernel capabilities to the upper layers of the HarmonyOS architecture by masking multi-kernel differences, including process / thread management, memory management, file system, network management, and peripheral management. The driver subsystem includes the hardware driver framework, which is the foundation of the open hardware ecosystem of HarmonyOS and provides unified peripheral access capabilities and a framework for driver development and management.

[0107] It can be understood that the ArkUI adaptation layer is located in the framework layer of the Hongmeng operating system. The NAPI module is located in the framework layer of the Hongmeng operating system. The NAPI module can expose C / C++ functions to JavaScript or arkTS applications. The virtual machine is located in the framework layer of the Hongmeng operating system. The virtual machine is responsible for running and interpreting JavaScript or arkTS code, and converting JavaScript or arkTS code into code that can be executed by the underlying system. The framework layer provides a runtime environment and necessary interface support for the virtual machine. The C++lib library is located in the system service layer of the Hongmeng operating system. The system service layer provides basic system services and libraries, including the C++ standard library. The C++ standard library provides developers with rich functions for developing high-performance native modules and applications.

[0108] The following combination Figure 4This article details an implementation of the HarmonyOS native to Cocos2d-x Lua interactive system framework. This implementation can be executed by the aforementioned electronic devices.

[0109] In some feasible ways, during the interaction between the HarmonyOS operating system (such as Next) and Cocos2d-x Lua, the electronic device receives a trigger event (such as a click event, a touch event, a key event, a mouse event, etc.) of the user interface (the user interface can be developed based on the ArkUI framework), and the arkTS adaptation layer can obtain the trigger event of the user interface and send the trigger event to the game application for processing.

[0110] As you can understand, arkTS is a programming language based on TypeScript (also known as TS). Developers can use the arkTS adaptation layer to develop user interfaces that can be displayed on multiple electronic devices. Multiple electronic devices can be multiple mobile phones, or multiple devices can also be mobile phones, computers, tablets, etc.

[0111] In some achievable methods, in the process of a game application receiving a trigger event sent by the arkTS adaptation layer, the electronic device first receives the trigger event sent by the arkTS adaptation layer through the NAPI module, and then passes the trigger event to the Lua virtual machine. For example, the Hongmeng operating system of the electronic device can determine the corresponding event trigger function based on the trigger event, and then determine the first service corresponding to the event trigger function based on the first mapping relationship. In some embodiments of the present application, the first service can be a function that the first application can run. The first application can be, for example, a game application, which is developed based on the Lua language. Therefore, a corresponding Lua virtual machine can be configured in the electronic device, and the electronic device can run the first service corresponding to the game application based on the Lua virtual machine to respond to the trigger event.

[0112] It is understandable that Figure 4As shown, when the arkTS adaptation layer sends a trigger signal to the Lua virtual machine, the trigger signal is represented by the programming language corresponding to the arkTS adaptation layer, which can be arkTS, JavaScript, TypeScript, or other programming languages. To call native modules of the HarmonyOS (native modules refer to basic functions included in the HarmonyOS, such as graphics rendering, file operations, or network communication, which are developed in C / C++), electronic devices can use the NAPI module to map the function corresponding to the trigger event of the arkTS adaptation layer to the trigger event represented by a C++ function. For example, as described above, DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate) maps the C++ function NapiManager::NapiOnCreate to onCreate. This means that the electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It can be understood that onCreate is the function name of NapiManager::NapiOnCreate in arkTS, while NapiManager::NapiOnCreate is the specific implementation method in C++. The NAPI module can also map functions corresponding to other trigger events to C++ functions, including DECLARE_NAPI_FUNCTION("onShow", NapiManager::NapiOnShow), DECLARE_NAPI_FUNCTION("onHide", NapiManager::NapiOnHide), DECLARE_NAPI_FUNCTION("onBackPress", NapiManager::NapiOnBackPress), DECLARE_NAPI_FUNCTION("onDestroy", NapiManager::NapiOnDestroy), etc., which are not described in detail here.

[0113] It can be understood that in the process of running game applications in the Lua virtual machine, the Lua virtual machine needs to interact with native modules through the API of the HarmonyOS operating system to call system resources to run game applications.

[0114] Therefore, electronic devices can use the NAPI module to establish a mapping relationship from the programming language corresponding to the arkTS adaptation layer (such as arkTS, JavaScript, TypeScript, etc.) to C++, and electronic devices can use the Lua virtual machine to perform information exchange between the Lua programming language and C++. In this way, the programming language corresponding to the arkTS adaptation layer and the Lua programming language can exchange information through C++.

[0115] It is understood that electronic devices can directly access native modules of the HarmonyOS through C++ functions. Furthermore, C++ includes cross-platform function interfaces, allowing code written in C++ to run on the HarmonyOS, which improves code portability. Therefore, when electronic devices run the NAPI module and the Lua virtual machine, they need to call the C++-implemented lib library to interact with C++.

[0116] For example, Figure 1C As shown, after the arkTS adaptation layer receives a click event from a user clicking on the game application's icon 101, it sends the function corresponding to the click event (e.g., a function written by arkTS) to the NAPI module. The electronic device uses the NAPI module to map the function corresponding to the arkTS adaptation layer click event to a corresponding C++ function, which then calls the Lua virtual machine through the C++ function.

[0117] In some possible implementations, after the Lua virtual machine executes the operation corresponding to the trigger event, the electronic device sends the execution result to the NAPI module, which then sends it to the arkTS adaptation layer. In turn, the arkTS adaptation layer responds to the trigger event.

[0118] It is understood that the Lua virtual machine runs the Lua function corresponding to the trigger event and obtains the result obtained by the game application processing the Lua function corresponding to the trigger event. It is understood that this result is a Lua function. The electronic device maps the Lua function corresponding to the result into a C++ function through the Lua virtual machine, and then maps the C++ function into a function corresponding to the arkTS adaptation layer through the NAPI module, so that the result corresponding to the trigger event can be run in the arkTS adaptation layer to respond to the user's trigger event.

[0119] It can be understood that since the game application is written in Lua language. Therefore, when the arkTS adaptation layer receives a trigger event, the electronic device needs to pass the trigger event to the game application to obtain the result obtained by the game application processing the trigger event, and pass the result to the arkTS adaptation layer to respond to the trigger event. In this way, the electronic device needs to establish information interaction between the function corresponding to the arkTS adaptation layer and the Lua function to perform information interaction between the game application and the electronic device.

[0120] The following combination Figure 5 This article introduces the implementation of the interaction between Hongmeng native code and Cocos2d-x Lua in detail. Figure 5 As shown, a flow chart of an embodiment of interaction from Hongmeng native code to Cocos2d-x Lua is shown, and this method can be executed by the electronic device mentioned above.

[0121] In some implementations, electronic devices can map HarmonyOS native TS functions (such as arkTS and TypeScript) to C++ functions using the NAPI module. Specifically, electronic devices can use the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos) to map HarmonyOS native TS functions to C++ functions. This allows functions in HarmonyOS native code to interact with Lua functions via C++. Specifically, electronic devices can use the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos) to establish an interactive entry point between HarmonyOS native code and the Cocos2d-x Lua environment.

[0122] In some implementations, parameter processing can establish a flow from a HarmonyOS native TS function to a Lua function, including parameter processing and a callback mechanism. NapiManager::napiNativeToCocos in the NAPI module includes parameter processing and a callback mechanism, and electronic devices can set Lua callback functions during NAPI module initialization.

[0123] In some implementable manners, the electronic device may obtain parameter information of the callback function receiving parameters, where the parameter information may include the number of parameters, the parameter type (eg, napi_number, napi_string), the parameter value, and the like.

[0124] For example, an electronic device can use the statement NAPI_CALL (env, napi_get_cb_info (env,info,&argc, args, nullptr, nullptr)) to obtain the callback function's parameter information, including the number of parameters (argc) and the parameter values (args). It can be understood that the electronic device can use this statement to call the napi_get_cb_info function to obtain the callback function's parameter information. The NAPI_CALL macro checks the return value of napi_get_cb_info and throws an exception if the return value is not napi_ok.

[0125] In some possible implementations, the electronic device may verify whether the number of parameters and the type of parameters are correct based on the acquired parameter information, and generate an abnormality prompt message if the electronic device determines that the number of parameters or the type of parameters are incorrect.

[0126] For example, if the callback function needs to accept 3 parameters, and the parameter types of the 3 parameters are character type, integer type, and character type, respectively. Therefore, if the electronic device detects that the number of parameters received by the callback function is 2, the number of parameters is incorrect, and the electronic device can generate an abnormal prompt message. If the electronic device detects that the parameter types of the parameters received by the callback function are character type, character type, and character type, respectively, the parameter types are incorrect, and the electronic device can generate an abnormal prompt message (for example, napi_throw_type_error). If the electronic device detects that the number of parameters received by the callback function is 3, and the parameter types are character type, integer type, and character type, respectively, the number and type of parameters are correct.

[0127] In some implementable ways, after the electronic device verifies that the number and type of parameters are correct, the electronic device can obtain the parameter values (for example, if the number of parameters is 2, the electronic device can obtain the parameter values through napi_get_value_int32 and napi_get_value_string_utf8 respectively), and convert the parameter values into the corresponding C++ data types (for example, the function id (functionId) is an integer type, and the parameter string (buffer) is a string type). Furthermore, the electronic device can use the callback mechanism to interact from Hongmeng native to Cocos2d-x Lua. For example, the electronic device can call luaCallback_ to run the callback function, which can pass functionId and buffer. Specifically, the process of the callback mechanism includes:

[0128] S501: triggering a callback function.

[0129] In some implementable ways, as mentioned above, the electronic device can receive a trigger event through the arkTS adaptation layer. The trigger event can be a click event, a touch event, a key event, a mouse event, etc.

[0130] It is understood that the trigger event can trigger the callback function in the Hongmeng operating system. The electronic device can use the callback function to pass parameters, which are the information exchanged during the information exchange process between the Hongmeng native TS function and the Lua function.

[0131] For example, the callback function executed by the electronic device can be an A_callback function, i.e., A_callback(TYPEpara){}. The electronic device can then obtain the parameter para through the callback function A_callback. It can be understood that para is the information required to pass during the information exchange process between the HarmonyOS native TS function and the Lua function, and para includes functionId and buffer.

[0132] In some implementations, the electronic device can also use other functions to call the callback function to improve code efficiency. For example, the electronic device can use the SetLuaCallback function to save the callback function luaCallback_. As mentioned above, the callback function is called during the interaction process.

[0133] S502: Determine whether the Lua stack is available.

[0134] In some implementable manners, after triggering the callback function, the electronic device needs to determine whether the Lua stack is available.

[0135] It is understood that electronic devices can exchange information between C++ and Lua through the Lua stack. That is, if the Lua stack is available, the electronic device can use the information that the C++ function needs to pass as the parameters of the callback function and save the parameters in the Lua stack.

[0136] In some implementations, when the callback function is triggered, the electronic device first checks whether the Lua stack is available. If the Lua stack is empty (for example, stack == nullptr), the electronic device can determine that there is no valid Lua environment to execute the callback function, and the electronic device cannot execute the callback function. Generally, there are four situations in which the electronic device does not have a valid Lua environment, namely:

[0137] Case 1: The electronic device has not yet initialized the Lua environment. In this case, calling the callback function will cause the electronic device to have undefined behavior, and may even cause the program to crash.

[0138] Case 2: The electronic device has destroyed the Lua environment. In this case, calling the callback function will cause the electronic device to have undefined behavior and may even cause the program to crash.

[0139] Case 3: Insufficient stack space can cause a stack overflow. Therefore, if the electronic device occupies stack space before executing the callback function, the electronic device will not have sufficient memory resources to execute the callback function. This will result in the electronic device not having a valid Lua environment.

[0140] Case 4: If the electronic device detects that a thread has accessed the Lua stack, in order to prevent multiple threads from accessing the Lua stack at the same time, the electronic device will pop up a prompt message indicating that the Lua stack is empty.

[0141] In some implementable manners, when the electronic device does not have a valid Lua environment, the electronic device may determine that the Lua stack is empty and thus cannot execute the callback function.

[0142] In other possible implementations, when the electronic device has a valid Lua environment, the electronic device may determine that the Lua stack is not empty and then execute the callback function.

[0143] S503: Output corresponding log information to prompt that the Lua stack is unavailable.

[0144] In some implementations, if the electronic device does not have a valid Lua environment, the electronic device may determine that the Lua stack is empty and therefore cannot execute the callback function. Thus, the electronic device may generate a prompt message (e.g., "Lua stack is empty, cannot execute callback function!") to inform the user that the electronic device cannot execute the callback function.

[0145] S504: Execute the Lua function at the top of the Lua stack and pass parameters.

[0146] In some implementable manners, when the electronic device has a valid Lua environment, the electronic device may determine that the Lua stack is not empty and then execute the Lua function.

[0147] For example, the electronic device can create a shared pointer parameter to save the parameter param to be passed and construct an anonymous function lambda. Inside the lambda function, the electronic device can first push the called Lua function (the Lua function corresponding to functionId) into the Lua stack through cocos2d::LuaBridge::pushLuaFunctionById(functionId). Then, the electronic device can use cocos2d::LuaBridge::getStack()->pushString (parameter->c_str()) to push the buffer into the Lua stack. Finally, the electronic device can execute the Lua function at the top of the Lua stack through cocos2d::LuaBridge::getStack()->executeFunction (1) and pass a buffer. It can be understood that in some feasible ways, the electronic device can be scheduled by cocos2d::Director::getInstance()->getScheduler()->performFunctionInCocosThread(lambda) to ensure that the method is executed in the thread environment of the game engine.

[0148] In this way, the electronic device can execute the callback function and pass parameters. It can be understood that the parameters are the information for information exchange between the Hongmeng native function and the Lua function.

[0149] The following is a detailed description of the implementation of the Hongmeng native function to Lua function call chain. Figure 6A As shown, a flowchart of the call chain from the Hongmeng native function to the Lua function is shown. The method can be executed by the electronic device mentioned above. The call chain from the Hongmeng native function to the Lua function may include the following process:

[0150] S601: HarmonyOS native terminal triggers the call (driven by user operation or system event).

[0151] In some feasible ways, the HarmonyOS native trigger call means that the electronic device running the HarmonyOS operating system receives a trigger event and needs to call the background operation of the application.

[0152] It is understood that the trigger event can be a trigger event caused by a user operation, such as a click event, a touch event, a key event, a mouse event, etc. The trigger event can also be driven by a system event, such as device startup, network connection disconnection, timer triggering, etc. It is understood that, as mentioned above, the electronic device can receive the trigger event of the user operation through the arkTS adaptation layer.

[0153] For example, Figure 6B As shown, the mobile phone 200 can display the keyboard 203 in response to the user clicking the input box 202. The mobile phone 200 can also respond to the user clicking other areas 204 of the mobile phone interface, and the keyboard 203 disappears from the mobile phone interface, and the mobile phone interface only displays the input box 202.

[0154] It is understandable that Figure 6C As shown, the mobile phone 200 monitors the Hongmeng operating system (such as Next) Figure 6B The height change of the keyboard 203 in the mobile phone 200 can obtain the user's click event through the arkTS adaptation layer, and obtain the keyboard 203 height change information through the arkTS adaptation layer.

[0155] S602: Search for a mapping relationship (NAPI_CALL mapping mechanism).

[0156] In some implementable embodiments, in response to a trigger event received by an electronic device, the electronic device may use the NAPI_CALL mapping mechanism of the NAPI module to look up the mapping relationship between the programming language of the trigger event and the programming language of the application program to send the trigger event to the application program for processing.

[0157] It is understandable that Figure 6C As shown, after the arkTS adaptation layer obtains information about the height change of keyboard 203, mobile phone 200 can send this information to the NAPI layer. This allows mobile phone 200 to use the NAPI module to find the NAPI_CALL mapping mechanism for programming languages corresponding to the arkTS adaptation layer (e.g., arkTS, JavaScript, TypeScript, etc.) to C++. For example, an electronic device can establish a mapping mechanism from HarmonyOS native code to the Cocos2d-x Lua environment using the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos).

[0158] It is understandable that in the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napi

[0159] In the NativeToCocos (Context context) example, the triggering event is the Hongmeng OS calling the Cocos2d-x Lua function. The mapping relationship is mapping the nativeToCocos function to the NapiManager::napiNativeToCocos function. The first message is the nativeToCocos function. The first service is the NapiManager::napiNativeToCocos function.

[0160] S603: Enter the napiNativeToCocos function (C++).

[0161] In some implementable manners, the electronic device may process the trigger event through the napiNativeToCocos function.

[0162] As previously described, the electronic device enters the napiNativeToCocos function. First, the electronic device verifies the correct number and type of parameters. If so, the electronic device calls the Lua callback function to handle the triggering event. The details of the electronic device entering the napiNativeToCocos function are described in the HarmonyOS native to Cocos2d-x Lua interaction method above and are not detailed here.

[0163] S604: Lua callback function processing.

[0164] In some possible implementations, the electronic device can process the trigger event through the Lua callback function. Figure 5 The callback mechanism is described in , so it will not be described here.

[0165] For example, Figure 6C As shown, mobile phone 200 obtains a Lua callback function at the NAPI layer. It is understood that a Lua callback function is a function located at the NAPI layer, and the electronic device can use it to call the Lua virtual machine. This allows the electronic device to run applications in the Lua virtual machine in response to triggering events (such as UI rendering).

[0166] The following is a detailed description of the process of Lua calling Hongmeng native TS function mentioned in this application in conjunction with an embodiment. Figure 7 As shown, the method is executed by the electronic device mentioned above.

[0167] S701: Detecting a first request from a first virtual machine received by a first communication module, where the first request includes communication data of a second service.

[0168] It is understood that, as described above, the first communication module may be a LuaOhosBridge class. The first virtual machine may be a Lua virtual machine. The electronic device detects a first request from a Lua script to call an arkTS function via the LuaOhosBridge class, and the electronic device may obtain communication data of the second service in the first request via the LuaOhosBridge class. The communication data may include parameters and function name of the arkTS function called by the Lua script.

[0169] For example, when a Lua script calls arkTS function B (parameter 1, parameter 2), the electronic device can obtain the function name (the function name is B) and parameters (the parameters are parameters 1 and 2) of function B through the LuaOhosBridge class (first communication module). It can be understood that the Lua script runs in the Lua virtual machine. The Lua script calling arkTS function B is the first request. The communication data includes function name B, parameter 1, and parameter 2. The second service is arkTS function B.

[0170] S702: Call the second service based on the first request, and return the running result of the second service to the first virtual machine based on the first communication module.

[0171] It can be understood that the first request is a request by a Lua script to call the arkTS function through the LuaOhosBridge class. The second service is the arkTS function called by the Lua script. The electronic device can use the arkTS function to obtain the running result of the second service and return it to the first virtual machine based on the first communication module.

[0172] For example, when a Lua script calls arkTS function B (parameter 1, parameter 2), the electronic device can obtain the execution result of arkTS function B (the second service) and save it in memory (e.g., the Lua stack). It is understood that functions in the LuaOhosBridge class can obtain the execution result from the memory where the execution result is saved and return the execution result to the Lua virtual machine.

[0173] The following combination Figure 8 The operation process of the first communication module is described in detail. Figure 8 As shown, a schematic diagram of a method for running a first communication module on the Hongmeng operating system is shown, which can be executed by the electronic device mentioned above. It can be understood that the first communication module can be used for a Lua script to call a Hongmeng native TS function (such as an arkTS function), and the Lua script calling the Hongmeng native TS function is the first request, and the Lua script runs on a Lua virtual machine (i.e., the first virtual machine). The process includes:

[0174] S801: Save the current Lua state and create a data table.

[0175] In some implementations, saving the current Lua state means that the electronic device assigns a pointer L of the current Lua state to a first variable (e.g., s_luaState = L). This improves code readability and allows developers to more easily access the Lua state through the first variable.

[0176] As you can understand, a Lua state refers to an independent Lua runtime environment. This Lua runtime environment includes the stack, global variable table, and environment parameters. Electronic devices can use Lua states to embed Lua scripts in C++. This allows electronic devices to call Lua functions from within C++ applications, enabling more diverse application functionality.

[0177] In some implementations, establishing a data table involves the electronic device storing parameter information that the Lua script needs to pass to the Hongmeng operating system in the data table. The parameter information includes parameter name, parameter value, parameter type, etc. This allows the electronic device to obtain the parameter information only from the data table without accessing the parameter-related Lua functions, which improves code security.

[0178] It is understandable that the data structure of the data table implemented by the electronic device can be an object, an array, a dictionary, a stack, etc., which is not limited here.

[0179] For example, the electronic device can store the string "callStaticMethod" and the callOhosStaticMethod function in the LuaOhosBridge class in a data table. Furthermore, the electronic device can use lua_rawset to establish an association between the string "callStaticMethod" and the callOhosStaticMethod function, namely (callStaticMethod, callOhosStaticMethod), and then store (callStaticMethod, callOhosStaticMethod) in the data table.

[0180] It is understood that the electronic device can use the "callStaticMethod" string as a key. According to the semantics of the "callStaticMethod" string, the "callStaticMethod" string can represent "calling a static function."

[0181] It can be understood that for (callStaticMethod, callOhosStaticMethod), when the electronic device detects the function call string "callStaticMethod" in the code, the electronic device will execute the callOhosStaticMethod function.

[0182] In some implementations, the electronic device can set the data table as a global variable. For example, lua_setglobal(L, "LuaOhosBridge"). This allows the electronic device to directly call the callStaticMethod function in the data table to facilitate calling Hongmeng native TS functions in Lua scripts.

[0183] S802: Determine whether the number and type of parameters in the data table meet the requirements of the Lua script calling the HarmonyOS native TS function.

[0184] In some implementations, parameter verification refers to the electronic device checking the number and type of parameters in the data table to determine whether the number and type of parameters meet the requirements of the Lua script calling the HarmonyOS native TS function. If the number and type of parameters do not meet the requirements, the electronic device can push an error message into the Lua stack and return it. If the number and type of parameters meet the requirements, the electronic device continues to execute S803.

[0185] For example, function a in the code requires three parameters, and the three parameters and their corresponding data types are: function name (string), class name (string), and parameter (string). Based on this, the electronic device can first check whether the number of parameters stored in the memory (such as the stack) is 3, and then check whether the data type of each parameter is a string. When the electronic device detects an error message, for example, the electronic device detects that the number of parameters in the memory is not 3. The electronic device can output a prompt message "Error: The number of parameters is incorrect, 3 parameters are required!", and the code returns 1, so that when the electronic device detects an error, the code can correctly exit the running state. When the electronic device detects that the number of parameters is 3 and the parameter types are all strings, the electronic device can continue to execute S803.

[0186] It can be understood that the parameters in the data table are the communication data of the Lua script calling the HarmonyOS native TS function.

[0187] S803: Obtain the module name and function name of the Lua script calling the HarmonyOS native TS function (such as JavaScript function) from the Lua state, and splice together to complete the complete function name.

[0188] In some feasible methods, when the electronic device verifies that the number and type of parameters are correct, the electronic device can obtain the module name and function name of the JavaScript function called in the Lua script, complete the complete function name, and obtain the corresponding JavaScript function object.

[0189] For example, an electronic device can obtain a Lua script that needs to call the myStaticMethod static function in the MyModule module. Based on this, the electronic device can implement a bridge function callOhosStaticMethod at the C++ level. This function obtains the module name MyModule and the function name myStaticMethod from the Lua script and concatenates them into a complete function name, namely MyModule::myStaticMethod function. Therefore, the electronic device can call the myStaticMethod static function in the MyModule module by calling the MyModule::myStaticMethod function.

[0190] It is understandable that electronic devices can use the callOhosStaticMethod function to call a HarmonyOS native TS function in a Lua script. Typically, the callOhosStaticMethod function usually accepts some parameters, which may include the function name, the class name to which the function belongs, etc.

[0191] In some possible implementations, the electronic device may use a mapping mechanism (eg, JSFunction::getFunction(

[0192] fullMethodName)) to get the JavaScript function (for example, jsFunction) corresponding to the MyModule::myStaticMethod function.

[0193] For example, through the JSFunction::getFunction(fullMethodName) function, the electronic device can use the string "MyModule::myStaticMethod" as the key value to retrieve the corresponding JavaScript function from the mapping table. The mapping table can be set by the developer himself or obtained by other means, which is not limited here.

[0194] S804: Concatenate parameter information in the data table to obtain concatenated parameters.

[0195] In some possible implementations, the electronic device can obtain parameter information. As described above, the electronic device can obtain the data table in S801 and obtain all parameter information in the data table. In some possible implementations, the electronic device can convert the parameter type corresponding to the parameter into a C++ type data type. For example, the electronic device can convert a LUA_TSTRING into a std::string.

[0196] It is understandable that the electronic device may also concatenate all parameters in the data table in the form of a string and assign the string to the parameter args.

[0197] For example, if the incoming parameter is a Lua table, the electronic device can convert it into a C++ parameter args of type std::string by traversing the table. It is understood that during the traversal process, the electronic device can perform corresponding conversions based on the parameter's Lua type (e.g., number LUA_TNUMBER, Boolean LUA_TBOOLEAN, string LUA_TSTRING, function LUA_TFUNCTION), concatenate the key-value pairs into a string, and add them to args. The electronic device can detect that the parameters and corresponding parameter values stored in the data table include {"name","ABC"}, {"age","30"}, and {"city","BEIJING"}. The electronic device then concatenates all the parameters in the table into a string, obtaining the string "name=ABC&age=30&city=BEIJING", and assigns the string "name=ABC&age=30&city=BEIJING" to the parameter args, thereby executing S805.

[0198] It is understandable that the electronic device concatenates all parameters in the data table in the form of a character string, and the resulting character string may also be in other forms, which is not limited here.

[0199] S805: Call jsFunction.invokestd::string(args) to execute the corresponding HarmonyOS native TS function, and convert the execution result into a string and save it in memory.

[0200] In some feasible methods, the electronic device can execute the corresponding HarmonyOS native TS function by calling the jsFunction.invokestd::string(args) function, and convert the execution result of the jsFunction.invokestd::string(args) function into a string and push it into the memory (such as the Lua stack).

[0201] It's understandable that electronic devices can also call the concatenated full method name (e.g., MyModule::myStaticMethod). They can then retrieve the corresponding function, jsFunction, using the JSFunction::getFunction(fullMethodName) function. Here, fullMethodName is the concatenated full method name, and JSFunction::getFunction is a C++ function.

[0202] It can be understood that the jsFunction.invoke(std::string(args)) function is a function written in C++ language, and the electronic device can pass the string parameter args through this function and execute the above jsFunction function.

[0203] To summarize, in order to call a HarmonyOS native TS function in a Lua script, first, the electronic device can save the current Lua state and create a data table. This data table contains the parameter information (including parameter name, parameter value, parameter type, etc.) that the electronic device needs to pass when calling the HarmonyOS native TS function in the Lua script. Next, the electronic device can check the number of parameters and parameter types. If the number of parameters and parameter types are correct, the electronic device can obtain the module name and function name corresponding to the function that calls the HarmonyOS native TS function in the Lua script, and concatenate the module name and function name into a complete function name and assign it to the parameter args, so that the electronic device can call jsFunction.invokestd::string(args) to execute the corresponding function, convert the execution result into a string, save it in memory, and return it. In this way, the electronic device can call the HarmonyOS native TS function in the Lua script.

[0204] It can be understood that through the above method, electronic devices can call HarmonyOS native TS functions in Lua scripts to realize communication from the game engine Lua layer (such as Cocos2d-x Lua Community Edition) to HarmonyOS native code, enabling applications to flexibly transfer data and perform operations between the two environments, greatly enhancing the interactivity and flexibility of the system, and providing strong support for developers to develop complex cross-environment applications.

[0205] It is understood that before porting an application to Hongmeng OS, developers can first create a project and perform basic configuration on the electronic device to provide a basic environment for the application to run on Hongmeng OS. The basic environment includes external libraries, compiled file configuration, etc.

[0206] The following combination Figure 9This chapter introduces the project creation and basic configuration methods in detail. Figure 9 FIG. 1 shows a flow chart of a method for project creation and basic configuration, which can be executed by the electronic device mentioned above. The method for project creation and basic configuration may include the following process:

[0207] S901: Establish project engineering and basic configuration.

[0208] In some feasible methods, establishing a project project and basic configuration means that the electronic device establishes a project project under a specific directory of the HarmonyOS operating system, and the electronic device can add multiple modules with different functions to the project project.

[0209] For example, in the process of porting the Cocos2d-x Lua Community Edition to the HarmonyOS operating system (such as Next), the electronic device can first create a native HarmonyOS native C++ project project in the Quick-Cocos2dx-Community / tests / lua-tests directory of the Quick-Cocos2dx-Community project code.

[0210] As you can understand, the Quick-Cocos2dx-Community project is an open-source project based on the Cocos2d-x engine. Developers can use it to develop games using the Lua language. Within the Quick-Cocos2dx-Community project, electronic devices can detect that the Quick-Cocos2dx-Community / tests / lua-tests directory contains test cases for testing the interaction between Lua scripts and the Cocos2d-x engine.

[0211] In some implementations, an electronic device can add multiple modules to a native HarmonyOS C++ project. Specifically, an electronic device can add multiple modules from the Cocos2D engine to a native HarmonyOS C++ project. For example, the multiple modules can include a CCApplication module, a CCCommon module, a CCDevice module, a CCFileUtils module, a CCGLView module, a CCTextBitmap module, and the like.

[0212] It is understood that in HarmonyOS, electronic devices can use the CCApplication module to adapt game application-related information according to HarmonyOS's regulations for managing application lifecycles (e.g., launching, pausing, resuming, and closing game applications). For example, electronic devices can use the CCApplication module to set the game application's operating environment information (e.g., screen size, device model, etc.), and this environment information complies with HarmonyOS regulations. This ensures that game applications run smoothly in HarmonyOS.

[0213] It is understood that in Hongmeng OS, electronic devices can use the CCFileUtils module to manage file operations (e.g., file search, reading, writing, deleting, and modifying) related to game applications. For example, electronic devices can use the CCFileUtils module to set a file search path or check whether a file exists.

[0214] In some implementations, electronic devices can also add NAPI (native API, NAPI)-related modules to the native HarmonyOS native C++ project. Specific NAPI modules may include NapiHelper, NapiValueConverter, InputNapi, RawFileUtils, SensorNapi, egl_core, plugin_render, etc.

[0215] In some implementations, when porting the Cocos2d-x Lua Community Edition to the Hongmeng OS, electronic devices can use the NAPI module to establish a mapping between TypeScript (TS) functions and C++ functions. For example, using the NAPI module, this mapping might be DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). This statement maps the C++ function NapiManager::NapiOnCreate to the onCreate function. The electronic device can then call the C++ function NapiManager::NapiOnCreate from the onCreate function in the TS code.

[0216] It can be understood that DECLARE_NAPI_FUNCTION declares a function that can convert a function expressed in the C++ programming language into a function expressed in another programming language (for example, arkTS, TypeScript, or JavaScript). Therefore, electronic devices can use DECLARE_NAPI_FUNCTION to call C++ functions from TS functions, thereby establishing information exchange between TS functions and C++ functions in the Hongmeng operating system.

[0217] As you can understand, JavaScript is a programming language used to develop web pages and interact with users. TypeScript is an open-source programming language. Based on JavaScript, TypeScript adds object-oriented features such as a type system, classes, and interfaces to improve code maintainability and readability. TypeScript code is converted into JavaScript during compilation.

[0218] It is understandable that electronic devices can use other modules to provide functional support for native Hongmeng native C++ project engineering, which will not be described here.

[0219] S902: External library support and project compilation settings.

[0220] In some implementations, external library support and project compilation settings involve adding external libraries to the Quick-Cocos2dx-Community project code and configuring the corresponding CmakeLists.txt file to ensure that the electronic device can correctly identify the external library during the compilation and linking process. Furthermore, the electronic device can configure the CmakeLists.txt files in the entry / src / main / cpp / and cocos / directories of the Quick-Cocos2dx-Community project to ensure proper project operation.

[0221] In some feasible ways, electronic devices can add support for external libraries related to the HarmonyOS under the external directory of the Quick-Cocos2dx-Community project.

[0222] For example, the external library can be the xxHash library. It is understood that the electronic device can perform data verification, data indexing and other functions through the xxHash library. The electronic device can configure the CmakeLists.txt file in the external directory to ensure that during the compilation and linking process, the electronic device can correctly identify the xxHash library and apply the xxHash library to the development code of the application. Specifically, the CmakeLists.txt file may include:

[0223] set(lib_name xxhash) / / Set a variable lib_name, whose value is xxhash. It is used to refer to the library name in the future.

[0224] set(target_name ext_${lib_name}) / / Set a variable target_name, its value is ext_xxhash

[0225] project(${lib_name}) / / defines the project name as lib_name

[0226] add_library(${target_name} STATIC xxhash.c) / / Create a static library ext_xxhash

[0227] target_include_directories(${target_name} PUBLIC.) / / Set the public include directory to the current directory

[0228] set_target_properties(${target_name} PROPERTIES

[0229] ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR} / lib"

[0230] LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR} / lib"

[0231] FOLDER "External" )

[0233] / *ARCHIVE_OUTPUT_DIRECTORY specifies the output directory for generated static library files (e.g., .a or .lib files). LIBRARY_OUTPUT_DIRECTORY specifies the output directory for generated shared library files (e.g., .so or .dll files). FOLDER categorizes this target into the External folder. * /

[0234] It is understandable that the external library may also be a library with other functions, which is not limited here.

[0235] In some implementations, the electronic device can configure various settings for the newly created project in the CmakeLists.txt file in the entry / src / main / cpp / directory. It should be understood that the entry / src / main / cpp / directory contains the files that are first executed upon project startup (such as main.cpp and napi_init.cpp). The electronic device can use these files to initialize the engine and launch the game.

[0236] In some achievable ways, electronic devices can configure the CmakeLists.txt file to determine the minimum version of CMake. For example, electronic devices can use the statement cmake_minimum_required(VERSION 3.10) to determine that the minimum version of CMake is 3.10. Therefore, if the CMake version installed in the Hongmeng operating system is lower than 3.10, the electronic device will report an error when running the code and the code execution process will be stopped.

[0237] In some achievable manners, the electronic device may determine the project name by configuring the CmakeLists.txt file. For example, the electronic device may determine that the project name may be nativerender through a statement project(nativerender).

[0238] In some achievable embodiments, the electronic device may determine the key path by configuring the CmakeLists.txt file. For example, the electronic device may set the COCOS2DX_ROOT_PATH variable through the statement set(COCOS2DX_ROOT_PATH " / path / to / cocos2d-x" CACHE PATH "Cocos2d-x root directory"), and the COCOS2DX_ROOT_PATH variable specifies the root directory / path / to / cocos2d-x of Cocos2d-x. For another example, the electronic device may set the CLASSES_PATH variable through the statement set(CLASSES_PATH "${CMAKE_CURRENT_SOURCE_DIR} / Classes" CACHE PATH "Pathto project classes"), and the CLASSES_PATH variable specifies the path of the class files in the project.

[0239] In some implementations, an electronic device can define an OHOS macro, which is used to determine whether a specific code segment in a project is compiled on the HarmonyOS platform. For example, as shown below, the electronic device can determine that the code segment between #ifdef and #endif is compiled on the HarmonyOS platform.

[0240] #ifdef OHOS

[0241] / / Code snippet

[0242] #endif

[0243] It can be understood that the electronic device can check whether the current operating system is the HarmonyOS in the CMakeLists.txt file. When the previous operating system is the HarmonyOS, the electronic device can define the OHOS macro.

[0244] For example,

[0245] if(CMAKE_SYSTEM_NAME STREQUAL "OpenHarmony") / / Check if it is Hongmeng operating system

[0246] add_definitions(-D OHOS) / / If it is Hongmeng operating system, define OHOS macro

[0247] message(STATUS "Building for OpenHarmony Next") / / Output information: Compiling on Hongmeng OS

[0248] else()

[0249] message(STATUS "Building for other platform") / / If it is not Hongmeng OS, output information: Compiled on other platforms (i.e. operating systems)

[0250] endif()

[0251] In some implementations, the electronic device can set other project variables in the CMakeLists.txt file based on actual needs. For example, the electronic device can set compiler flags using the statement "${CMAKE_CXX_FLAGS}-frtti-fexceptions-fsigned-char" to ensure that when compiling C++ code, the electronic device enables runtime type information (frtti), exception handling (fexceptions), and the signed character type (fsigned-char), so that the compiler receives clear compilation instructions.

[0252] In some implementations, electronic devices can add compilation source files, such as main.cpp and napi_init.cpp, to the CMakeLists.txt file. They can also set the search path for project header files in the CMakeLists.txt file. This includes header files for each module in the engine (such as the Cocos2d-x engine) as well as header files for external libraries. This ensures that the compiler can find all necessary header files, ensuring a smooth compilation process and avoiding compilation errors caused by missing header files.

[0253] In some feasible ways, electronic devices can also link library files required by the project, such as cocos2d, luacocos2d, extra_static, lua_extensions_static, lua_test, hilog-lib, libuv-lib, etc. It can be understood that these library files each have different functions and together build the basic environment for the engine to run.

[0254] For example, the cocos2d library provides basic graphics rendering and scene management functions; the luacocos2d library enables information exchange between Lua and the Cocos2d engine; and libraries such as hilog-lib and libuv-lib provide logging and asynchronous event processing functions. It is understood that electronic devices can link these library files together to ensure that the various functional modules of the engine can function properly, allowing applications to run stably and efficiently.

[0255] In some achievable manners, the electronic device may configure the project in a CmakeLists.txt file in the cocos / directory of the project.

[0256] In some achievable embodiments, the electronic device can compile and configure the CMakeLists.txt file in the cocos / 2d / directory and the CMakeLists.txt file in the cocos / 3d / directory. It is understood that, as previously described, the electronic device can configure the CMakeLists.txt file in the cocos / 2d / directory and the CMakeLists.txt file in the cocos / 3d / directory by setting `set(lib_name xxhash)`, `project(${lib_name}`, or other items in the CMakeLists.txt file, without limitation.

[0257] As you can understand, the cocos / 2d / directory contains classes and functions related to 2D graphics rendering. These classes and functions can be used to handle various graphical elements in 2D games, such as animations and scenes. The cocos / 3d / directory contains classes and functions related to 3D graphics rendering. These classes and functions can be used to handle various graphical elements in 3D games, such as 3D models, cameras, and lights.

[0258] In some achievable methods, the electronic device can also set the COCOS_HEADER variable and the COCOS_SRC variable in CMakeLists.txt. It is understandable that the electronic device can set the header files required for the project through the COCOS_HEADER variable, and the electronic device can set the source files required for the project through the COCOS_SRC variable. For example, the COCOS_HEADER variable can be set to COCOS_HEADER=D:\cocos2d-x-4.0\cocos, that is, the header files in the D:\cocos2d-x-4.0\cocos directory are the header files required to compile the project. The COCOS_SRC variable can be set to COCOS_SRC=D:\cocos2d-x-4.0\cocos, that is, the source files in the D:\cocos2d-x-4.0\cocos directory are the source files required to compile the project.

[0259] As you can understand, during the compilation process, the compiler can set the required header files for the project based on the COCOS_HEADER variable. The compiler can also set the required source files for the project based on the COCOS_SRC variable. This prevents compilation errors caused by the compiler being unable to obtain the required header or source files.

[0260] In some implementations, electronic devices can also link external libraries in CMakeLists.txt. For example, these libraries may include external, extra_static, lua_extensions_static, libohaudio.so, and libavplayer.so. libohaudio.so and libavplayer.so provide audio and video playback functionality for the project. Other libraries can be used based on actual needs and are not detailed here.

[0261] In some feasible ways, the electronic device can also set relevant compilation definitions and target properties in CMakeLists.txt. For example, the electronic device can set the output directory of the library set(CMAKE_LIBRARY_OUTPUT_DIRECTORY${CMAKE_CURRENT_SOURCE_DIR} / output / libs), and the library files generated by compiling the project will be placed in the output / libs directory under the root directory of the project. The electronic device can set(MY_LIBRARY_VERSION "1.0.0") to set the version number of the library to 1.0.0. The electronic device can also set other project-related compilation definitions and target properties in CMakeLists.txt according to actual conditions, without limitation here.

[0262] It is understood that the electronic device can set the variables in the CmakeLists.txt file in the cocos folder according to the above method. The electronic device can also set other variables in the CmakeLists.txt file according to the above method, which is not limited here.

[0263] It can be understood that electronic devices can add compiled files in CmakeLists.txt according to the above method for all levels of sub-directories of the project. For example, under the 2d sub-directory, set a list of 2D-related header files and source files. Among them, the header files can be CCActionPageTurn3D.h and CCActionTween.h, and the source files can be CCActionCamera.cpp and CCActionCatmullRom.cpp. In this way, the correct compilation and integration of the 2D engine function in the project can be ensured. During the compilation process, the compiler will accurately process the 2D-related files according to CmakeLists.txt, organically combine the various functional modules together, and form a complete and efficient 2D engine subsystem, providing a solid foundation for the 2D function application of the entire engine.

[0264] S903: Quick engine integration and function addition.

[0265] In some achievable ways, the Quick engine integration and function addition refers to the electronic device integrating the Quick engine into the root directory of the Cocos2d-x engine and adding configuration to the CmakeLists.txt file in the root directory of the Cocos2d-x engine.

[0266] For example, adding configurations to the CmakeLists.txt file in the root directory of the Cocos2d-x engine can include the electronic device adding libraries in the extra_static directory and the lua_extensions_static directory to the Cocos2d-x engine, and adding compilation definitions for the libraries in the extra_static directory and the lua_extensions_static directory (as described above, compilation definitions can include the library's output directory, version number, etc.) so that the project code can access the header files in the extra and lua_extensions_static directories. Furthermore, the electronic device can link different libraries together (for example, linking static libraries such as external, extra_static, and lua_extensions_static) to provide libraries for the project's compilation and linking processes to ensure proper operation. The electronic device can also set other items in the CmakeLists.txt file. For example, the add_subdirectory command adds code in a specified directory to the project's compilation system, allowing the compiler to recognize and process the code. target_link_libraries, this command links the cocos2d engine with library files such as external and extra_static to ensure that they can work together and call each other at runtime. target_compile_definitions, this command defines compile-time macros, such as setting the CC_LUA_ENGINE_ENABLED macro to 1 to indicate that the electronic device has enabled the Lua engine. Since the Quick engine relies on the support of the Lua engine for many functional implementations, setting the CC_LUA_ENGINE_ENABLED macro to 1 is crucial for the collaborative work of the Quick engine and the Cocos2d engine. It can be understood that through the combined effect of the configuration in CmakeLists.txt, the Quick engine and the Cocos2d engine can be closely integrated, jointly providing powerful functional support for application development.

[0267] In other implementations, Quick engine integration and feature addition involves adding the Cocos2d-x engine to the device's AppDelegate.cpp file to load the Quick engine. As you can see, AppDelegate.cpp is responsible for initializing and managing the device's lifecycle. This file ensures that the device correctly handles various resources (such as network resources and computing resources) and states (such as application startup, pausing, and resuming) during the launch, pause, and resume of the project's corresponding application.

[0268] Specifically, electronic devices can register various Quick Engine functional modules (e.g., graphics rendering module, audio processing module, physics engine module, network communication module) in Lua using the `quickmoduleregister` function in `AppDelegate.cpp`. The logic of the `quickmoduleregister` function in `AppDelegate.cpp` includes the following: First, the electronic device uses the `luaopen_luaextensionsmore(L)` function to open Lua extension functions, which provide various functions (e.g., network communication, file operations, etc.). Next, since the `global table G` in the Lua programming environment is a container for project global variables and functions, the electronic device uses the `lua_getglobal(L,"G")` function to retrieve the `global table G` in Lua. The electronic device can then call various `register_all..."` functions, such as `register_all_quick_manual(L),` to register the various Quick Engine functional modules in the Lua environment, enabling code in Lua scripts to call code in the Quick Engine. Next, the electronic device can use the luaopen_cocos2dx_extra_lua_binding(L) function to register Lua binding functions related to the Cocos2d engine's additional functionality (e.g., file handling, network communication, etc.). It can also use the register_all_FileManager_lua_binding(L) function to register Lua bindings related to the file manager, or use other functions to register Lua bindings related to other additional functionality. Finally, the electronic device can use lua_pop(L,1) to pop the top element of the stack to maintain the balance of the Lua stack. It can be understood that calling quickmoduleregister(L) in the applicationDidFinishLaunching function ensures that the Quick engine's functional modules are promptly registered with the Lua environment when the application starts, thereby providing complete Quick engine functional support for the entire application.

[0269] For example, the quickmoduleregister(L) function is called in the applicationDidFinishLaunching function. When the application corresponding to the project is started, the electronic device can register the functional modules contained in the Quick engine (for example, graphics rendering module, audio processing module, physics engine module, network communication module) into the Lua environment, so that the application can call the functions contained in the Quick engine during its operation.

[0270] In other implementations, Quick Engine integration and feature addition means that electronic devices can add other libraries to the Quick Engine based on implementation requirements. The following uses the integration of the Graphics Interchange Format (GIF) library into the Quick Engine as an example to describe the process of adding other libraries to the Quick Engine.

[0271] For example, first, the electronic device obtains the source files GifTools_luabinding.cpp and GifTools.cpp related to the Gif library. The source files can provide the interaction function between the Gif library and the Quick engine, as well as the image processing function contained in the Gif library. Then, the electronic device can use the file (GLOB) command to search for all .cpp files in the extensions / Gif directory and all .c files in the extensions / Gif / gif_lib directory, and add the file names of the found .cpp files and .c files to the SRC_FILES list in the CmakeLists.txt file. In this way, the electronic device can identify the source files of the Gif library and call the source files of the Gif library during the compilation of the project.

[0272] It's understandable that by integrating the GIF library into the Quick Engine, applications gain access to the library's image processing and display capabilities, enriching the application's visuals and providing users with a more vivid and rich interactive experience. For example, in game development, electronic devices can use GIF images to display dynamic game elements (e.g., characters, scenery, etc.), special effects (e.g., blurring, brightening, etc.), or animations (e.g., object movement, interface switching, etc.), making the game screen more engaging. For another example, in application interface design, electronic devices can use GIF images to display dynamic icons, guide interfaces, or prompts, enhancing the application's visual appeal and information delivery.

[0273] It is understandable that in the process of porting code to an electronic device, the electronic device needs to first create a project project and configure the project project. This configuration includes adding different functional modules (such as NAPI) and different libraries (including static libraries, dynamic libraries, external libraries, and other libraries) according to actual needs. This configuration also includes configuring the CmakeLists.txt file contained in the project project of the electronic device according to actual needs. In this way, the electronic device can establish a project project to port the code to different HarmonyOS operating systems so that the code can run on different HarmonyOS operating systems.

[0274] In some feasible ways, the electronic device can use an integrated development environment (IDE) (such as DevEco Studio) to compile the source code of the application according to the configuration items (such as COCOS2DX_ROOT_PATH, CLASSES_PATH, etc.) contained in the CMakeLists.txt file to obtain the .so library file corresponding to the application.

[0275] As you can understand, an integrated development environment (IDE) is a software application that developers use to write, debug, and test code.

[0276] It is understood that a .so library file is a dynamic link library file. An electronic device can store reusable code and reusable data in the source code corresponding to an application in a .so library file. Furthermore, the electronic device can load the .so library file when the application is running.

[0277] It can be understood that during the compilation process, the configuration items contained in the CMakeLists.txt file obtained by the electronic device can provide all the parameters required by the compiler in the process of compiling the source code corresponding to the application.

[0278] For example, when the electronic device compiles the source code, it needs to obtain the minimum version of CMake contained in the CMakeLists.txt file. Therefore, the electronic device can determine that the minimum version of CMake is 3.10 by reading the statement cmake_minimum_required(VERSION 3.10) in the CMakeLists.txt file.

[0279] During the compilation process, ensure that all dependencies are correctly linked and that the compilation options meet the requirements of the Hongmeng Next system. This requires carefully checking the path settings, library file references, and compilation options in the CMakeLists.txt file to ensure that there are no omissions or errors.

[0280] For example, it is necessary to ensure that the paths of all external libraries are set correctly so that the compiler can find and link these libraries. At the same time, according to the characteristics of the HarmonyOS Next system, such as memory management and thread scheduling, appropriate compilation options such as optimization level and target architecture should be set to ensure that the compiled library files can run stably and efficiently in the HarmonyOS Next system. In some feasible ways, applications can also communicate with the HarmonyOS through other means.

[0281] In some implementations, an electronic device can receive a message string sent by a game engine and extract parameters from the message string. The parameters are then encapsulated into event data and marked with a specific symbol (e.g., "dispatchCocos") to indicate that the event data is game engine-related. Finally, the electronic device can send the event data to a HarmonyOS native service (e.g., a game application) and return a prompt indicating a successful call. This method implements the function of sending messages and data from a game engine (e.g., Cocos) to a HarmonyOS native service (e.g., a game application).

[0282] For example, an electronic device can be in the CocosDispatcher class. It can receive a message string through the cocosToNative function, first extract the parameters in the message through the extractParameters function, then encapsulate these parameters into event data of the emitter.EventData type, and send an event named "dispatchCocos" through the emitter.emit function. Finally, it returns a string indicating that the native call was successful. It can be understood that the cocosToNative function implements the function of sending messages and data from the Cocos engine end to the HarmonyOS native service end.

[0283] The electronic device can also use the init function to initialize the workerPort (workerPort is the global scope object of the Worker thread) and use the workerPort to save information related to the Worker thread for subsequent communication and operation in a multi-threaded environment.

[0284] In some implementations, the electronic device can also extract parameters from the message string and assign the parameters to specific keys. The electronic device can then print the event data corresponding to the parameters to a console (e.g., a display interface or log file). Finally, a prompt message indicating success is returned. This method can establish a function call association between the game engine and the HarmonyOS native service end (e.g., a game application).

[0285] For example, the electronic device can also use the registerScriptHandler function to extract the parameters in the message string, and then store the function identifier fun in the parameter into CocosDispatcher.funEventData, and print out the relevant event data information (event data of type emitter.EventData). Finally, the electronic device can return a string indicating that the registration of the HarmonyOS native function is successful. It can be understood that the electronic device can use the registerScriptHandler function to handle script registration-related operations and establish an association between the engine and the native business end in terms of function calls.

[0286] In some implementations, electronic devices can use a thread (e.g., a Worker) and a game application interface (e.g., a Native API) to implement cross-language function calls and data transfer. Specifically, electronic devices can register functions defined in arkTS (or JavaScript) code with the game engine's native environment, making them callable from within the game code. Electronic devices can also set up thread message listeners and, based on the type of messages they listen for, pass corresponding parameters to execute the corresponding logic in the game application.

[0287] Exemplarily, the electronic device can obtain different context information of the thread. For example, the electronic device obtains workerContext and napiContext respectively through nativeRender.getContext. These two context objects correspond to functions related to worker thread initialization and functions related to native API respectively. Then, the electronic device can call workerContext.workerInit and napiContext.nativeEngineStart respectively to ensure that the Worker thread and the game native engine are in a normal startup state. Then. The electronic device can use NapiHelper.registerFunctions to register the function, and use napiContext.registerFunction as the specific implementation of the registration function, and register the cocosToNative and registerScriptHandler functions in the CocosDispatcher class to the native API context, so that these functions can be called at the native API level.

[0288] Finally, the electronic device can listen for the onmessage event corresponding to the workerPort. When the electronic device receives a message with the data type "postToCocos", it can call the native code through the napiContext.nativeToCocos function and pass the corresponding parameters CocosDispatcher.funEventData [data.functionId] and data.value.

[0289] It can be understood that through the above method, electronic devices can achieve close integration and efficient interaction between the business end of the Harmony operating system and the game engine, ensuring that the two can work together to provide users with a complete application experience, so that applications ported to the Harmony operating system based on the Quick engine can seamlessly connect between business logic and engine functions, give full play to the advantages of both, and meet the needs of users in different scenarios.

[0290] An embodiment of the present application also provides a readable medium, which stores instructions. When the instructions are executed by a device, the device implements the method for running the application provided by the aforementioned embodiments on the HarmonyOS operating system.

[0291] An embodiment of the present application also provides a program product, which, when executed on a device, can enable the device to implement the method for running the application provided in the aforementioned embodiments on the HarmonyOS operating system.

[0292] An embodiment of the present application also provides an electronic device, which includes: a memory for storing instructions executed by one or more processors of the electronic device, and a processor, which is one of the one or more processors of the electronic device, for implementing the method of running the application provided in the aforementioned embodiments on the Harmony operating system.

[0293] Next, combine Figure 10 Introduce the structure of electronic equipment. Figure 10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown. It will be understood that the structure shown in the embodiment of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown in the figure, or combine or split certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0294] The electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0295] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0296] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0297] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or is reusing. If the processor 110 needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves system efficiency. The processor 110 can be used to execute the code detection method described in this application.

[0298] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface.

[0299] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL).

[0300] The PCM interface can also be used for audio communication to sample, quantize and encode analog signals.

[0301] The UART interface is a universal serial data bus used for asynchronous communication.

[0302] The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193.

[0303] The GPIO interface can be configured through software. The GPIO interface can be configured as a control signal or a data signal.

[0304] The USB interface 130 is an interface that complies with USB standard specifications, and specifically may be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc.

[0305] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present invention is only a schematic illustration and does not constitute a structural limitation of the electronic device. In other embodiments of the present application, the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0306] The charging management module 140 is configured to receive charging input from a charger, which may be a wireless charger or a wired charger.

[0307] The power management module 141 is used to connect the battery 142 , the charging management module 140 and the processor 110 .

[0308] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.

[0309] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in an electronic device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0310] The mobile communication module 150 can provide wireless communication solutions for electronic devices, including 2G / 3G / 4G / 5G, etc. The mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc.

[0311] A modem processor may include a modulator and a demodulator.

[0312] The wireless communication module 160 can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0313] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150 , and antenna 2 is coupled to wireless communication module 160 , so that the electronic device can communicate with the network and other devices through wireless communication technology.

[0314] The electronic device realizes the display function through the GPU, the display screen 194, and the application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor.

[0315] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel.

[0316] The electronic device can realize the shooting function through the ISP, camera 193, video codec, GPU, display 194 and application processor.

[0317] The ISP is used to process data fed back by the camera 193 .

[0318] The camera 193 is used to capture still images or videos.

[0319] Digital signal processors are used to process digital signals. In addition to processing digital image signals, they can also process other digital signals.

[0320] Video codecs are used to compress or decompress digital video.

[0321] NPU is a neural-network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn.

[0322] The external memory interface 120 may be used to connect an external memory card.

[0323] The internal memory 121 may be used to store computer-executable program codes, where the executable program codes include instructions.

[0324] The electronic device can implement audio functions through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0325] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals.

[0326] The headphone jack 170D is used to connect a wired headphone and can be the USB interface 130 or a 3.5mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0327] The buttons 190 include a power button, a volume button, etc. The buttons 190 can be mechanical buttons or touch buttons.

[0328] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback.

[0329] The indicator 192 may be an indicator light, which may be used to indicate the charging status, power level changes, messages, missed calls, notifications, etc.

[0330] SIM card interface 195 is used to connect a SIM card. A SIM card can be connected to and disconnected from the electronic device by inserting or removing it from the SIM card interface 195. An electronic device may support one or N SIM card interfaces, where N is a positive integer greater than one.

[0331] It should be understood that the structures illustrated in this application do not constitute specific limitations on electronic devices. In other embodiments, the electronic device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0332] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. The embodiments of this application can be implemented as a computer program or program code executed on a programmable system, which includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0333] Program code can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit, or a microprocessor.

[0334] Program code can be implemented with a high-level programming language or an object-oriented programming language to communicate with the processing system. Where necessary, program code can also be implemented in assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0335] It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "including a" does not exclude the presence of other identical elements in the process, method, article or device that includes the element.

[0336] While the present application has been shown and described with reference to certain embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the present application.

Claims

1. A method for running an application on a Hongmeng operating system, applied to an electronic device, characterized in that: The electronic device includes a first application, a native application programming interface module, and a first virtual machine running the first application; wherein the first application is incompatible with the Hongmeng operating system, and the native application programming interface module stores a first mapping relationship between first-category information of the electronic device and a first-category service that calls the first application; the method includes: detecting a first message belonging to the first category of information, and determining, based on the first mapping relationship, a first service corresponding to the first message from the first category of services, wherein the first message is determined based on a triggering event corresponding to the first application program and received by the electronic device, a programming language of the first category of services is different from a programming language of the triggering event of the first application program, and the first service further includes a callback function; passing a first parameter corresponding to the triggering event to the first virtual machine based on the callback function; The first application is run based on the first virtual machine calling the first parameter; wherein the first parameter includes a function of the first application.

2. The method according to claim 1, characterized in that The first application is an application developed based on the Lua language, and the first virtual machine is a Lua virtual machine.

3. The method according to claim 1 or 2, characterized in that The first type of information includes an event processing function corresponding to a triggering event that triggers the first application.

4. The method according to claim 3, characterized in that The event handling functions include onCreate, onShow, onHide, onBackPress, onDestroy, and nativeToCocos.

5. The method according to claim 3, characterized in that The triggering events include: clicking a button, moving the mouse, and completing page loading.

6. The method according to claim 1, characterized in that The electronic device further includes a first communication module, the first communication module being configured to transmit communication data sent by the first virtual machine, the communication data being used to invoke a second service of the electronic device; The method further includes: detecting that the first communication module receives communication data of the first virtual machine; A second service is called based on the communication data, and an operation result of the second service is returned to the first virtual machine based on the first communication module.

7. The method according to claim 6, characterized in that The first communication module is the LuaOhosBridge class, and the second service is a service provided by the Hongmeng operating system; the communication data includes the function name of the second service and the calling parameters of the second service.

8. A readable medium, characterized in that The readable medium stores instructions, which, when executed on an electronic device, enable the electronic device to execute the method according to any one of claims 1 to 7.

9. An electronic device, characterized in that: include: a memory for storing instructions to be executed by one or more processors of the electronic device, and The processor is one of the processors of an electronic device, and is configured to execute the method according to any one of claims 1 to 7.

10. A program product, characterized in that The program product includes instructions, and when the instructions are executed on an electronic device, the electronic device implements the method according to any one of claims 1 to 7.

Images