Operation method of application program on swan mongolian operating system, medium and electronic equipment

Abstract

The invention relates to the technical field of computers, and discloses a running method of an application program on a swan-gap operating system, a medium and electronic equipment. The electronic equipment comprises a first application program, a first mapping module and a first virtual machine running the first application program. Wherein the first mapping module stores a first mapping relation corresponding to the first type of information and the first type of service for calling the first application program. In the method, the electronic device can detect a first message belonging to a first type of information, and determine a first service corresponding to the first message from a first type of services according to a first mapping relationship. And furthermore, the electronic equipment can call the first virtual machine to run the first application program based on the first service. In this way, normal information interaction can be carried out between the application program and the swan 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 a Hongmeng operating system. Background Art

[0002] In the case where the version of Hongmeng OS in electronic devices is constantly updated, the electronic devices need to run applications corresponding to the version of Hongmeng OS. In the case where the version of the application is incompatible with the version of Hongmeng OS, for example, the version of Hongmeng OS on the computer is 64-bit and the application is 32-bit. For another example, the version of Hongmeng OS has been updated, and the application is developed based on the previous version of Hongmeng OS, which results in the application being unable to use the functions in the updated Hongmeng OS, 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: The first aspect of the present application provides a method for running an application on a Hongmeng operating system, which is applied to an electronic device, wherein the electronic device includes 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 includes: detecting a first message belonging to the first category of information, and determining a first service corresponding to the first message from the first category of services based on the first mapping relationship; and calling the first virtual machine to run the first application based on the first service.

[0004] In some implementable ways, the first mapping module may be a native application programming interface (NAPI), which is used to implement information (e.g., function or data type) conversion between arkTS (ark typeScript) programming language (or JavaScript, etc.) and C / C++ programming language. The electronic device may establish a mapping relationship between arkTS and C / C++ through the NAPI interface. For example, for the mapping relationship DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). It can be understood that this statement indicates that the C++ function NapiManager::NapiOnCreate is mapped to onCreate. That is, the electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It can be understood that onCreate is a function name of the function NapiManager::NapiOnCreate in arkTS, and the NapiManager::NapiOnCreate function is a specific implementation method in C++.

[0005] It can be understood that 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 run the first application in the first virtual machine according to the first service, so that the first application can run normally on the new version of the Hongmeng operating system. In this way, the Hongmeng operating system can call the function contained in the first application through the first mapping module. The electronic device can establish communication between the Hongmeng operating system and the first application so that the first application can run on the Hongmeng operating system.

[0006] 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.

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

[0008] In a possible implementation of the first aspect above, the first category of information includes an event processing 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.

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

[0010] 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.

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

[0012] 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.

[0013] 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 a LuaOhosBridge class, and the electronic device may obtain communication data of a second service in the first request through the LuaOhosBridge class. The communication data may include parameters and function names of the Lua script calling the arkTS function. 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.

[0014] It is understandable that the electronic device can enable the first application (running on the first virtual machine) to call the function of the Hongmeng operating system through the first communication module. In this way, the electronic device can establish communication between the Hongmeng operating system and the first application so that the first application can run on the Hongmeng operating system.

[0015] 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 Hongmeng operating system; the communication data includes the function name of the second service and the calling parameters of the second service.

[0016] 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 on the Hongmeng operating system.

[0017] The third aspect of the present 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 a Hongmeng operating system.

[0018] The fourth aspect of the present 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 Hongmeng operating system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1A According to some embodiments of the present application, a schematic diagram of interaction between the Hongmeng operating system and an application is shown; Figure 1B According to some embodiments of the present application, a schematic diagram showing incompatibility between an application and a version of the Hongmeng operating system of an electronic device is shown; Figure 1C According to some embodiments of the present application, a schematic diagram showing that an application cannot be started normally is shown; Figure 2 According to some embodiments of the present application, a flowchart of a method for running an application on the Hongmeng operating system is shown; Figure 3 According to some embodiments of the present application, a schematic diagram of a system architecture of an electronic device is shown; 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; Figure 5 According to some embodiments of the present application, a schematic diagram of an embodiment of Hongmeng native to Cocos2d-x Lua interaction is shown; Fig. 6A According to some embodiments of the present application, a schematic diagram of an embodiment of a Hongmeng native function to Lua function call chain is shown; Figure 6B According to some embodiments of the present application, a schematic diagram of a scenario in which the height of a keyboard changes is shown; 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; 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; Figure 8 According to some embodiments of the present application, a schematic flow chart of a method for operating a first communication module on a Hongmeng operating system is shown; Fig. 9 According to some embodiments of the present application, a schematic flow chart of a project creation and basic configuration method is shown; Fig.10 According to some embodiments of the present application, a schematic structural diagram of an electronic device is shown. DETAILED DESCRIPTION

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

[0022] 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 in conjunction with the accompanying drawings and specific implementation methods.

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

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

[0025] It can be understood that the electronic device mentioned in the embodiments of the present application can be called a terminal, user equipment (UE), a mobile phone, a smart TV, a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, and the like.

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

[0027] like Figure 1A As shown, the electronic device includes application A, and application A may be a game application, a music application, a video playback application, etc. After the electronic device detects that application A is started, it may prepare to start application A.

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

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

[0030] After the process is started, Hongmeng OS will load the code of application A and initialize the context of application A. The context of application A is the basic environment for the operation of application A. Electronic devices can access the configuration file of application A (such as config.json) through the context of application A, obtain the life cycle of application A (such as creation, running, pause, resumption, destruction, etc.), and realize communication between modules. In addition, electronic devices can instantiate the entry class (Ability) of application A so that they can call the life cycle functions of application A (such as onStart(), onResume(), onPause(), onDestroy(), etc.) through the entry class.

[0031] 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 files and resource files of application A into graphic elements and drawing them to the screen.

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

[0033] 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.

[0034] However, if application A is incompatible with the Hongmeng operating system of the electronic device. For example, the Hongmeng operating system version has been updated, and the application is developed based on the previous version of the Hongmeng operating system. This will cause application A to be unable to interact normally with the Hongmeng operating system of the electronic device, causing application A to fail to start normally or run slowly.

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

[0036] For example, Figure 1B A schematic diagram showing incompatibility between an application and the version of the Hongmeng operating system of an electronic device.

[0037] For example, refer to Figure 1BIn the case where the application is incompatible with the Hongmeng operating system, the application needs to call the Hongmeng operating system-specific application programming interface (API) during the startup process. For example, if the application runs on the Hongmeng operating system, the Ability class and the AbilityContext class need to be called during the application startup process. If the application is incompatible with the Hongmeng operating system, the application cannot call the Ability class and the AbilityContext class. Therefore, the application cannot start normally on the Hongmeng operating system, which leads to the failure of the application startup.

[0038] For example, Figure 1C A schematic diagram showing a situation in which an application cannot be started normally.

[0039] 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 prompt box 102, prompt box 102 including prompt information "The application cannot be started, please update the version of the application!" text logo, exclamation mark warning icon, "Exit" button and "Update" button. It can be understood that when electronic device 10 receives a signal from the user clicking the "Exit" button, prompt box 102 disappears and electronic device 10 displays the desktop. When electronic device 10 receives a signal from the user clicking the "Update" button, prompt box 102 disappears and electronic device 10 displays the interface for updating the application.

[0040] It is understandable that when an application is incompatible with the Hongmeng operating system, the application and the Hongmeng operating system will not be able to call each other's functions. For example, the API called by the application does not exist in the Hongmeng operating system, so the application cannot call the Hongmeng operating system function. For another example, the programming language of the Hongmeng operating system is different from the programming language of the application, so the Hongmeng operating system cannot call the application's function. In this way, the application and the Hongmeng operating system cannot transmit information, which will cause runtime errors or functional abnormalities.

[0041] To sum up, in an electronic device, if an application is incompatible with the Hongmeng operating system of the electronic device, it may lead to the inability to transmit information between the application and the Hongmeng 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.

[0042] 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.

[0043] In order to enable the application to run on different Hongmeng operating systems, the Hongmeng operating system may include a first mapping module and a first virtual machine running the first application. The first mapping module stores a first mapping relationship between different information types of the electronic device (for example, information for starting the first application, functions or data for running certain services of the first application, etc., hereinafter referred to as the first type of information) and the first type of service, wherein the first type of service is used to call the first virtual machine to run the function of the first application. Through the first mapping relationship, after the Hongmeng operating system of the electronic device detects a trigger event corresponding to the first application, the first message can be determined from the first type of information according to the trigger event, and then the electronic device can determine the corresponding first service from the first type of service based on the first mapping relationship, that is, the first service is the service corresponding to the first message, and then the electronic device can call the first virtual machine through the first service to execute the corresponding function, thereby running the first application in response to the trigger event. Among them, the programming language corresponding to the Hongmeng operating system of the electronic device and the programming language corresponding to the first application can interact with the programming language corresponding to the first service. In other words, although the Hongmeng operating system of the electronic device is not compatible with the first application, it can communicate through the language corresponding to the first service as a bridge, so that the first application can run in the Hongmeng operating system of the electronic device.

[0044] 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 the 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 the 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.

[0045] 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.

[0046] Through the above scheme, during the operation of the first application 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 according to the first service to run the first application, so that the first application can run normally on the current Hongmeng operating system.

[0047] 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 be, for example, a function based on C++ language programming. Furthermore, the developer can call the code corresponding to the first service of the Hongmeng operating system through the arkTS programming language (or JavaScript, etc.) in the arkTS adaptation layer (in the Hongmeng system, the arkTS adaptation layer is the middle layer between the application developed in the arkTS programming language and the Hongmeng operating system) (for example, calling the C++ function in the C++ function library), and call the first virtual machine through the code corresponding to the first service, so as to run the first application according to the first virtual machine to transmit information between the Hongmeng operating system and the first application.

[0048] 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.

[0049] For example, for the mapping relationship DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). It can be understood that this statement means mapping the C++ function NapiManager::NapiOnCreate to onCreate. That is, the electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It can be understood that onCreate is a function name of the function NapiManager::NapiOnCreate in arkTS, and the NapiManager::NapiOnCreate function is a specific implementation method in C++.

[0050] 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.

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

[0052] In some embodiments of the present application, the first message may be an event processing 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 a mouse, completing page loading, etc.). An electronic device may receive a triggering event and call an event processing function corresponding to the triggering event. For example, an event processing function may be onCreate (a function called when an application or display interface is initialized), onShow (a function called when an 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 an application or display interface switches from the foreground to the background, such as saving the current state of the electronic device, executing a function 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 an application or display interface is destroyed).

[0053] It is understandable 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.

[0054] In some embodiments of the present application, the electronic device further includes a first communication module (e.g., LuaOhosBridge class), and the first communication module is used for the first virtual machine to communicate with the Hongmeng operating system of the electronic device. For example, the first communication module can transmit the communication data of the second service of the Hongmeng operating system called by the first virtual machine to the Hongmeng operating system of the electronic device, and the data may include, for example, the function name and operation parameters of the second service.

[0055] 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.

[0056] 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.

[0057] The first virtual machine may be the Lua virtual machine mentioned above.

[0058] The second service may be a function in the Hongmeng operating system of the electronic device. For example, in the Hongmeng operating system, the second service may be a function of the Hongmeng 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 relevant parameters for executing the corresponding function.

[0059] 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.

[0060] In some embodiments of the present application, as described above, in order to communicate 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.

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

[0062] 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.

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

[0064] 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 to run a first application based on the first service. 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 may not be able to communicate directly with the Hongmeng operating system of the electronic device. In some embodiments of the present application, the first mapping relationship between the first service of the first application and the first message may be pre-stored in the electronic device, and 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.

[0065] It can be understood 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 can be understood 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.

[0066] For example, the first mapping relationship may be DECLARE_NAPI_FUNCTION("onCreate", NapiManager::NapiOnCreate). It can be understood that this statement indicates mapping the C++ function NapiManager::NapiOnCreate to onCreate. That is, the electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It can be understood that onCreate is a function name of the function NapiManager::NapiOnCreate in arkTS, and the NapiManager::NapiOnCreate function is a specific implementation method in C++.

[0067] In some embodiments of the present application, the first mapping relationship may further include DECLARE_NAPI_FUNCTION("onShow", NapiManager::NapiOnShow). It can be 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.

[0068] DECLARE_NAPI_FUNCTION("onHide",NapiManager::NapiOnHide). It can be understood that this statement means mapping the C++ function NapiManager::NapiOnHide to onHide. That is, the electronic device can call the C++ function NapiManager::NapiOnHide by calling onHide in the arkTS code.

[0069] DECLARE_NAPI_FUNCTION("onBackPress", NapiManager::NapiOnBackPress). It can be understood that this statement means mapping the C++ function NapiManager::NapiOnBackPress to onBackPress. That is, the electronic device can call the C++ function NapiManager::NapiOnBackPress by calling onBackPress in the arkTS code.

[0070] DECLARE_NAPI_FUNCTION("onDestroy",NapiManager::NapiOnDestroy). It can be understood that this statement means mapping the C++ function NapiManager::NapiOnDestroy to onDestroy. That is, the electronic device can call the C++ function NapiManager::NapiOnDestroy by calling onDestroy in the arkTS code.

[0071] DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos). It can be understood that this statement means mapping the C++ function NapiManager::napiNativeToCocos to nativeToCocos. That is, the electronic device can call the C++ function NapiManager::napiNativeToCocos by calling nativeToCocos in the arkTS code.

[0072] It can be understood that in other embodiments, the first mapping relationship may also be in other forms, which will not be described here.

[0073] S203: Invoke the first virtual machine to run the first application based on the first service.

[0074] In some embodiments of the present application, the first application may be encoded based on a 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.

[0075] Exemplarily, 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.

[0076] 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 are correct during the process of the Hongmeng operating system calling the first application through the NapiManager::napiNativeToCocos function. 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.

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

[0078] To summarize, 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.

[0079] Combine the following Figure 3 A detailed introduction to the system architecture of electronic equipment. Figure 3 , which is a schematic diagram of a system architecture of an electronic device.

[0080] In some embodiments of the present application, the system architecture of the electronic device is introduced by taking 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.

[0081] 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 by code porting, for example. 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 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.

[0082] Hongmeng OS applications consist of one or more feature capabilities (FA) or particle capabilities (PA). FA has a user interface (UI) that provides the ability to interact with users. PA provides the ability to run tasks in the background and a unified data access abstraction.

[0083] The framework layer provides a multi-language user program framework and Ability framework such as Java / C / C++ / JavaScript for Hongmeng operating system application development, 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 the application. These components include buttons, text, lists, grids, etc., and layout methods include linear layouts, grid layouts, etc. ArkUI also supports event handling mechanisms, 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.

[0084] The ArkUI framework can include the arkTS adaptation layer, which is a language extension for declarative UI development in the Hongmeng system. It is based on TypeScript and extends the declarative syntax for UI drawing. arkTS allows developers to describe the UI interface more intuitively and efficiently without having to worry about the underlying UI drawing and rendering details.

[0085] 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 development process of the UI interface 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's 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, providing users with a smooth interactive experience.

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

[0087] Among them, the lib library implemented in C++ refers to a collection of functions, classes, objects and other codes 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.

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

[0089] The NAPI module may store a first mapping relationship between the first type of information of the electronic device and various services of application A. The first message may be an event processing function corresponding to a triggering event for triggering the first application. For example, the triggering event may be that the electronic device detects that the user clicks a button, moves the mouse, the page is loaded, etc. The electronic device may receive the triggering event and call the event processing function corresponding to the triggering event. For example, the event processing function may be onCreate, onShow, onHide, onBackPress, onDestroy, etc. It can be understood that through the first mapping relationship, the electronic device can obtain the first service corresponding to the event processing function. For example, onCreate is a function name of the function NapiManager::NapiOnCreate in the arkTS code, and the NapiManager::NapiOnCreate function is the function corresponding to onCreate after passing through the first mapping relationship (ie, the first service). The first mapping relationship may be, for example, DECLARE_NAPI_FUNCTION("onCreate",NapiManager::NapiOnCreate). That is, after the electronic device detects that the event processing function corresponding to the triggering 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.

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

[0091] The system service layer includes the system basic capability subsystem set, the basic software service subsystem set, the enhanced software service subsystem set and the hardware service subsystem set. Among them, the system basic capability subsystem set can provide basic capabilities for the operation, scheduling, migration and other operations of distributed applications on multiple devices of the Hongmeng operating system. The system basic capability subsystem set consists of distributed soft bus, distributed data management, distributed task scheduling, Ark multi-language runtime, public basic library, multi-mode input, graphics, security, AI and other subsystems. The basic software service subsystem set can provide public and general software services for the Hongmeng operating system. The basic software service subsystem set consists of event notification, telephone, multimedia, DFX (Design For X), MSDP&DV and other subsystems. The enhanced software service subsystem set can provide the Hongmeng operating system with differentiated capability-enhanced software services for different devices. The enhanced software service subsystem set consists of subsystems such as smart screen proprietary services, wearable proprietary services, and IoT proprietary services. The hardware service subsystem set can provide hardware services for the Hongmeng 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.

[0092] The kernel layer is mainly divided into two parts: the kernel subsystem and the driver subsystem. The kernel subsystem includes the Linux kernel, LiteOS, kernel abstract layer (KAL), etc. KAL provides basic kernel capabilities for the upper layer of the Hongmeng operating system architecture by shielding 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 basis for the open hardware ecosystem of the Hongmeng operating system. The hardware driver framework provides unified peripheral access capabilities and driver development and management frameworks.

[0093] 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.

[0094] Combine the following Figure 4The embodiment of the Hongmeng native to Cocos2d-x Lua interactive system framework is introduced in detail. This embodiment can be executed by the electronic device mentioned above.

[0095] In some feasible ways, during the interaction between Hongmeng 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.

[0096] As you can understand, arkTS is a programming language based on TypeScript (also referred to as TS), and developers can use the arkTS adaptation layer to develop user interfaces that can be displayed on multiple electronic devices. Among them, multiple electronic devices can be multiple mobile phones, and multiple devices can also be mobile phones, computers, tablets, etc.

[0097] 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 may be a function that the first application can run. The first application may be, for example, a game application, which is developed based on the Lua language. Therefore, a corresponding Lua virtual machine may be configured in the electronic device, and the electronic device may run the first service corresponding to the game application based on the Lua virtual machine in response to the trigger event.

[0098] It is understandable that Figure 4As shown, in the process of the arkTS adaptation layer sending the trigger signal to the Lua virtual machine, the trigger signal of the arkTS adaptation layer is represented by the programming language corresponding to the arkTS adaptation layer, which can be arkTS, JavaScript, TypeScript and other programming languages. In order to call the native module of the Hongmeng operating system (the native module refers to the basic functions contained in the Hongmeng operating system, such as graphics rendering, file operation or network communication functions, etc., which are developed by C / C++), the electronic device can map the function corresponding to the trigger event of the arkTS adaptation layer to the trigger event represented by the C++ function through the NAPI module. For example, as mentioned above, DECLARE_NAPI_FUNCTION("onCreate",NapiManager::NapiOnCreate). It can be understood that this statement means mapping the C++ function NapiManager::NapiOnCreate to onCreate. That is, the electronic device can call the C++ function NapiManager::NapiOnCreate by calling onCreate in the arkTS code. It can be understood that onCreate is a function name of the function NapiManager::NapiOnCreate in arkTS, and the NapiManager::NapiOnCreate function is a specific implementation method in C++. The NAPI module can also map functions corresponding to other trigger events from 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 here.

[0099] 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 the native module through the API of the Hongmeng operating system to call system resources to run the game application.

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

[0101] It is understandable that electronic devices can directly access the native modules of the Hongmeng operating system through C++ functions, and C++ contains cross-platform function interfaces, so that codes written in C++ can run on the Hongmeng operating system, which can improve the portability of the code. Therefore, when the electronic device runs the NAPI module and the Lua virtual machine, the NAPI module and the Lua virtual machine need to call the lib library implemented in C++ to realize information interaction with C++.

[0102] For example, Figure 1C As shown, after the arkTS adaptation layer obtains the click event of the user clicking the icon 101 of the game application, the arkTS adaptation layer sends the function corresponding to the click event (such as the function written by arkTS) to the NAPI module. The electronic device maps the function corresponding to the click event of the arkTS adaptation layer to the corresponding C++ function through the NAPI module, and the electronic device calls the Lua virtual machine through the C++ function.

[0103] In some achievable ways, 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. Then, the arkTS adaptation layer responds to the trigger event.

[0104] It can be 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 can be understood that the 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.

[0105] 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.

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

[0107] In some achievable ways, electronic devices can map Hongmeng native TS functions (such as arkTS, TypeScript, etc.) to C++ functions through the NAPI module. Specifically, electronic devices can map Hongmeng native TS functions to C++ functions through the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos). In this way, electronic devices can enable functions in Hongmeng native code to interact with Lua functions through C++. That is, electronic devices can establish an interactive entry from Hongmeng native code to the Cocos2d-x Lua environment through the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos).

[0108] In some achievable ways, parameter processing can establish a process from Hongmeng native TS function to Lua function, which may include parameter processing and callback mechanism. NapiManager::napiNativeToCocos in the NAPI module includes parameter processing and callback mechanism, and the electronic device can set the Lua callback function during the initialization of the NAPI module.

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

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

[0111] In some achievable manners, the electronic device can verify whether the parameter quantity and parameter type are correct based on the acquired parameter information, and generate abnormal prompt information if the electronic device confirms that the parameter quantity or parameter type is incorrect.

[0112] Exemplarily, 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 type is 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 of parameters and parameter types are correct.

[0113] 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 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: S501: triggering a callback function.

[0114] In some implementable methods, as described above, the electronic device can receive a trigger event through the arkTS adaptation layer, and the trigger event can be a click event, a touch event, a key event, a mouse event, etc.

[0115] It can be 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 interaction between the Hongmeng native TS function and the Lua function.

[0116] Exemplarily, the callback function executed by the electronic device may be an A_callback function, i.e., A_callback (TYPEpara) {}, and the electronic device may obtain the parameter para through the callback function A_callback function. It can be understood that para is the information that needs to be transmitted during the information interaction process from the Hongmeng native TS function to the Lua function, and para includes functionId and buffer.

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

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

[0119] In some achievable ways, after the callback function is triggered, the electronic device needs to determine whether the Lua stack is available.

[0120] It is understandable that the electronic device can perform information interaction 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 parameter of the callback function and save the parameter in the Lua stack.

[0121] In some achievable ways, 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: Case 1: The electronic device has not initialized the Lua environment. In this case, the electronic device calling the callback function will cause the electronic device to have undefined behavior, and may even cause the program to crash.

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

[0123] Case 3: Insufficient stack space will cause stack overflow. Therefore, if the electronic device occupies the 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.

[0124] 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 that the Lua stack is empty.

[0125] In some achievable ways, when the electronic device does not have a valid Lua environment, the electronic device may determine that the Lua stack is empty, and thus the callback function cannot be executed. In this way, the electronic device may continue to execute S503.

[0126] In some other achievable ways, when the electronic device has a valid Lua environment, the electronic device can determine that the Lua stack is not empty, and then execute the callback function. In this way, the electronic device can continue to execute S504.

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

[0128] In some practicable ways, when the electronic device does not have a valid Lua environment, the electronic device can determine that the Lua stack is empty and the callback function cannot be executed. In this way, the electronic device can generate a prompt message (e.g., "Lua stack is empty, callback function cannot be executed!") to prompt the user that the electronic device cannot execute the callback function.

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

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

[0131] Exemplarily, 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 achievable methods, 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.

[0132] 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 interaction from the Hongmeng native function to the Lua function.

[0133] The following is a detailed description of the implementation of the Hongmeng native function to Lua function call chain. Fig. 6A As shown, a flow chart of the call chain from Hongmeng native function to Lua function is shown. The method can be executed by the electronic device mentioned above. The call chain from Hongmeng native function to Lua function may include the following process: S601: Hongmeng native terminal triggers the call (driven by user operation or system event).

[0134] 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.

[0135] It is understood that the trigger event can be a trigger event operated by a user, 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 disconnection, timer triggering, etc. It is understood that, as mentioned above, the electronic device can receive the trigger event operated by the user through the arkTS adaptation layer.

[0136] 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.

[0137] 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.

[0138] S602: Find the mapping relationship (NAPI_CALL mapping mechanism).

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

[0140] It is understandable that Figure 6C As shown, after the arkTS adaptation layer obtains the keyboard 203 height change information, the mobile phone 200 can send the keyboard 203 height change information to the NAPI layer. In this way, the mobile phone 200 can find the programming language corresponding to the arkTS adaptation layer (such as arkTS, JavaScript, TypeScript, etc.) to C++ NAPI_CALL mapping mechanism through the NAPI module. For example, the electronic device can establish a mapping mechanism from Hongmeng native code to Cocos2d-x Lua environment through the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napiNativeToCocos).

[0141] It is understandable that in the statement DECLARE_NAPI_FUNCTION("nativeToCocos", NapiManager::napi NativeToCocos), the trigger event is the function of Hongmeng OS calling Cocos2d-x Lua. The mapping relationship is mapping the function nativeToCocos to the function NapiManager::napiNativeToCocos. The first message is the function nativeToCocos. The first service is the function NapiManager::napiNativeToCocos.

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

[0143] In some achievable embodiments, the electronic device may process the trigger event through the napiNativeToCocos function.

[0144] As mentioned above, the electronic device enters the napiNativeToCocos function. First, the electronic device can verify whether the number of parameters and parameter types are correct. If the number of parameters and parameter types are correct, the electronic device can call the Lua callback function to process the triggering event. The details of the electronic device entering the napiNativeToCocos function are as described in the above Hongmeng native to Cocos2d-x Lua interaction method, which will not be described here.

[0145] S604: Lua callback function processing.

[0146] In some achievable ways, the electronic device can process the trigger event through the Lua callback function. The details of the electronic device Lua callback function processing are as follows Figure 5 The callback mechanism is described in , so it will not be described here.

[0147] For example, Figure 6C As shown, the mobile phone 200 obtains the Lua callback function in the NAPI layer. It can be understood that the Lua callback function is a function located in the NAPI layer, and the electronic device can call the Lua virtual machine through the Lua callback function. In this way, the electronic device can run an application in the Lua virtual machine to respond to a trigger event (such as UI rendering, etc.).

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

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

[0150] It can be understood that, as described above, the first communication module can be a LuaOhosBridge class. The first virtual machine can be a Lua virtual machine. The electronic device detects a first request in which a Lua script calls an arkTS function through a LuaOhosBridge class, and the electronic device can obtain communication data of a second service in the first request through the LuaOhosBridge class. The communication data may include parameters and function names of the Lua script calling the arkTS function.

[0151] For example, in the process of Lua script calling 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 parameter 1 and parameter 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 calls arkTS function B as the first request. The communication data includes function name B, parameter 1, and parameter 2. The second service is arkTS function B.

[0152] 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.

[0153] It can be understood that the first request is a request for the 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.

[0154] For example, in the process of the Lua script calling arkTS function B (parameter 1, parameter 2), the electronic device can obtain the running result of arkTS function B (second service) and save the running result in the memory (such as Lua stack). It can be understood that the function in the LuaOhosBridge class can obtain the running result from the memory where the running result is saved and return the running result to the Lua virtual machine.

[0155] Combine the following 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 a Hongmeng operating system is shown, and the method 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: S801: Save the current Lua state and create a data table.

[0156] In some achievable ways, saving the current Lua state means that the electronic device assigns the pointer L of the current Lua state to the first variable (for example, s_luaState=L). In this way, the readability of the code can be increased, and the developer can more easily obtain the Lua state through the first variable.

[0157] It can be understood that Lua state refers to an independent Lua runtime environment. Among them, the Lua runtime environment includes a stack, a global variable table, and environment parameters. Electronic devices can embed Lua scripts in the C++ language through Lua states. In this way, electronic devices can call Lua functions in C++ applications, which can enable applications to achieve more diverse functions.

[0158] In some achievable methods, establishing a data table means that the electronic device saves the 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. In this way, the electronic device only needs to obtain the parameter information from the data table without accessing the parameter-related Lua function, which can improve the security of the code.

[0159] It can be understood 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.

[0160] For example, the electronic device can save the string "callStaticMethod" and the callOhosStaticMethod function in the LuaOhosBridge class in the data table. Furthermore, the electronic device can also establish an association relationship between the string "callStaticMethod" and the callOhosStaticMethod function through lua_rawset, that is, (callStaticMethod, callOhosStaticMethod), and then save (callStaticMethod, callOhosStaticMethod) in the data table.

[0161] It can be 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".

[0162] 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.

[0163] In some achievable ways, the electronic device can set the data table as a global variable. For example, lua_setglobal(L, "LuaOhosBridge"). In this way, the electronic device can directly call the callStaticMethod function in the data table to facilitate calling the Hongmeng native TS function in the Lua script.

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

[0165] In some achievable ways, 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 needs of the Lua script calling the Hongmeng native TS function. If the number and type of parameters do not meet the requirements, the electronic device can push the error message into the Lua stack and return. If the number and type of parameters meet the requirements, the electronic device continues to execute S803.

[0166] Exemplarily, function a in the code requires three parameters, and the three parameters and the corresponding data types of the parameters are: function name (string), class name (string), 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 of the parameter is 3 and the parameter types are all strings, the electronic device can continue to execute S803.

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

[0168] S803: Obtain the module name and function name of the Lua script that calls the Hongmeng native TS function (such as a JavaScript function) from the Lua state, and assemble them to complete the complete function name.

[0169] 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.

[0170] 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, which obtains the module name MyModule and the function name myStaticMethod from the Lua script and concatenates them into a complete function name, namely the MyModule::myStaticMethod function. Therefore, the electronic device can call the myStaticMethod static function in the MyModule module by calling the MyModule::myStaticMethod function.

[0171] It can be understood that electronic devices can use the callOhosStaticMethod function to call a Hongmeng native TS function in a Lua script. Usually, the callOhosStaticMethod function usually accepts some parameters, which may include the function name, the class name to which the function belongs, etc.

[0172] In some achievable ways, the electronic device can use a mapping mechanism (for example, JSFunction::getFunction( fullMethodName)) to get the JavaScript function (for example, jsFunction) corresponding to the MyModule::myStaticMethod function.

[0173] For example, through the JSFunction::getFunction(fullMethodName) function, the electronic device can use the string "MyModule::myStaticMethod" as a 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 methods, which is not limited here.

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

[0175] In some achievable ways, 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 achievable ways, 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 LUA_TSTRING into std::string.

[0176] It can be understood that the electronic device can also concatenate all the parameters in the data table in the form of a string and assign the string to the parameter args.

[0177] Exemplarily, if the parameter passed in is a Lua table, the electronic device can convert it into a parameter args of std::string type of C++ by traversing the table. It can be understood that during the traversal process, the electronic device can perform corresponding conversions according to the Lua type of the parameter (such as number LUA_TNUMBER, Boolean LUA_TBOOLEAN, string LUA_TSTRING, function LUA_TFUNCTION), and concatenate the key-value pairs into a string form and add them to args. The electronic device can detect that the parameters stored in the data table and the parameter values ​​corresponding to the parameters include {"name","ABC"}, {"age","30"}, {"city","BEIJING"}, then the electronic device concatenates all the parameters in the table in the form of a string, and can obtain the string "name=ABC&age=30&city=BEIJING", and assigns the string "name=ABC&age=30&city=BEIJING" to the parameter args to execute S805.

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

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

[0180] In some feasible methods, the electronic device can execute the corresponding Hongmeng 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).

[0181] It is understandable that the electronic device can also call the complete method name after splicing (for example, MyModule::myStaticMethod). Then, the corresponding function jsFunction is obtained through the JSFunction::getFunction(fullMethodName) function. Among them, fullMethodName is the complete method name after splicing, and JSFunction::getFunction is a function written in C++ language.

[0182] 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.

[0183] In summary, in order to call the Hongmeng native TS function in the Lua script, first, the electronic device can save the current Lua state and establish a data table, which contains the parameter information (including parameter name, parameter value, parameter type, etc.) that the electronic device needs to pass in the process of calling the Hongmeng native TS function in the Lua script. Then, 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 Hongmeng native TS function in the Lua script, and splice the module name and function name into a complete function name and assign it to the parameter args, so that the electronic device calls jsFunction.invokestd::string(args) to execute the corresponding function, and convert the execution result into a string, save it in the memory and return it. In this way, the electronic device can call the Hongmeng native TS function in the Lua script.

[0184] It can be understood that through the above method, electronic devices can call Hongmeng native TS functions in Lua scripts to realize communication from the game engine Lua layer (such as Cocos2d-x Lua Community Edition) to Hongmeng 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.

[0185] It is understandable that before the application is ported to the Hongmeng operating system, developers can first create projects and perform basic configurations on electronic devices to provide a basic environment for the application to run on the Hongmeng operating system. The basic environment includes external libraries, compiled file configurations, etc.

[0186] Combine the following Fig. 9This chapter introduces the project creation and basic configuration methods in detail. Fig. 9 As shown, a schematic diagram of the process of a project creation and basic configuration method is shown. The method can be executed by the electronic device mentioned above. The project creation and basic configuration method may include the following process: S901: Establish project engineering and basic configuration.

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

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

[0189] It can be understood that the Quick-Cocos2dx-Community project is an open source project based on the Cocos2d-x engine. Developers can use the Quick-Cocos2dx-Community project to develop games using the Lua language. In 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 information.

[0190] In some achievable ways, the electronic device can add multiple modules to a native Hongmeng native C++ project. Specifically, the electronic device can add multiple modules in the Cocos2d engine to a native Hongmeng native C++ project. Exemplarily, the multiple modules can be CCApplication module, CCCommon module, CCDevice, CCFileUtils module, CCGLView module, CCTextBitmap module, etc.

[0191] It can be understood that in the Hongmeng operating system, electronic devices can adapt relevant information of game applications through the CCApplication module according to the Hongmeng operating system's regulations for managing the life cycle of applications (for example, starting, pausing, resuming, and closing game applications, etc.). For example, electronic devices can set the operating environment information of game applications (for example, screen size, device model, etc.) through the CCApplication module, and the environment information complies with the regulations of the Hongmeng system. In this way, the game application can be guaranteed to run smoothly in the Hongmeng system.

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

[0193] In some feasible ways, electronic devices can also add NAPI (native api, NAPI) related modules to the native Hongmeng native c++ project. Specific NAPI modules may include NapiHelper, NapiValueConverter, InputNapi, RawFileUtils, SensorNapi, egl_core, plugin_render, etc.

[0194] In some achievable ways, in the process of porting Cocos2d-x Lua Community Edition to Hongmeng OS, the electronic device can use NAPI module to establish a mapping relationship from TS (typescript, TS) function to C++ function. Exemplarily, using NAPI module, the mapping relationship can be DECLARE_NAPI_FUNCTION("onCreate",NapiManager::NapiOnCreate). It can be understood that this statement means mapping C++ function NapiManager::NapiOnCreate to onCreate function. The electronic device can call C++ function NapiManager::NapiOnCreate through onCreate function in TS code.

[0195] 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 other programming languages ​​(for example, arkTS, TypeScript, JavaScript). Therefore, electronic devices can use DECLARE_NAPI_FUNCTION to call C++ functions in TS functions to build information interaction between TS functions and C++ functions in the Hongmeng operating system.

[0196] As you can understand, JavaScript is a programming language used to develop interactive operations between web pages and users. TypeScript is an open source programming language. TypeScript adds object-oriented features such as type system, class, interface, etc. on the basis of JavaScript to improve the maintainability and readability of the code. TypeScript code will be converted into JavaScript code during compilation.

[0197] 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.

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

[0199] In some achievable ways, external library support and project engineering compilation settings refer to the electronic device adding the external library to the Quick-Cocos2dx-Community project code and setting the corresponding CmakeLists.txt file to ensure that the electronic device can correctly identify the external library during the compilation and linking process. In addition, the electronic device can set the CmakeLists.txt file under the entry / src / main / cpp / directory and the cocos / directory in the Quick-Cocos2dx-Community project to ensure the normal operation of the project.

[0200] In some achievable methods, the electronic device can add support for external libraries related to the Hongmeng operating system under the external directory of the Quick-Cocos2dx-Community project.

[0201] Exemplarily, the external library can be a 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: set(lib_name xxhash) / / Set a variable lib_name, whose value is xxhash. Used for subsequent references to the library name set(target_name ext_${lib_name}) / / Set a variable target_name, whose value is ext_xxhash project(${lib_name}) / / defines the project name as lib_name add_library(${target_name} STATIC xxhash.c) / / Create a static library ext_xxhash target_include_directories(${target_name} PUBLIC.) / / Set the public include directory to the current directory set_target_properties(${target_name} PROPERTIES ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR} / lib" LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR} / lib" FOLDER "External" ) / *ARCHIVE_OUTPUT_DIRECTORY specifies the output directory of the generated static library files (such as .a or .lib files). LIBRARY_OUTPUT_DIRECTORY specifies the output directory of the generated shared library files (such as .so or .dll files). FOLDER classifies the target into the External folder. * / It is understandable that the external library may also be a library with other functions, which is not limited here.

[0202] In some achievable ways, the electronic device can make various settings for the newly created project in the CmakeLists.txt file in the entry / src / main / cpp / directory. It is understandable that the entry / src / main / cpp / directory contains the files that are first executed when the project is started (such as main.cpp and napi_init.cpp). The electronic device can use this file to initialize the engine and start the game.

[0203] In some achievable ways, the electronic device can determine the minimum version of CMake by configuring the CmakeLists.txt file. For example, the electronic device can determine that the minimum version of CMake is 3.10 through the statement cmake_minimum_required(VERSION 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 and stop the code running process when running the code.

[0204] In some achievable ways, 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).

[0205] In some achievable ways, the electronic device can determine the key path by configuring the CmakeLists.txt file. For example, the electronic device can 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 can 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.

[0206] In some achievable ways, the electronic device may define an OHOS macro, which is used to determine whether a specific code segment in a project is compiled on the Hongmeng platform. For example, as shown in the following code, the electronic device may determine whether the code segment between #ifdef and #endif is compiled on the Hongmeng platform.

[0207] #ifdef OHOS / / Code snippet #endif It can be understood that the electronic device can check whether the current operating system is the Hongmeng operating system in the CMakeLists.txt file. When the previous operating system is the Hongmeng operating system, the electronic device can define the OHOS macro.

[0208] For example, if(CMAKE_SYSTEM_NAME STREQUAL "OpenHarmony") / / Check if it is Hongmeng operating system add_definitions(-D OHOS) / / If it is Hongmeng operating system, define OHOS macro message(STATUS "Building for OpenHarmony Next") / / Output information: Compiling on Hongmeng OS else() message(STATUS "Building for other platform") / / If it is not Hongmeng operating system, output information: compile on other platforms (i.e. operating systems) endif() In some achievable ways, the electronic device can set other variables in the project in the CMakeLists.txt file according to actual needs. For example, the electronic device can set the compiler flag through the statement "${CMAKE_CXX_FLAGS}-frtti-fexceptions-fsigned-char" to determine that when compiling C++ code, the electronic device enables runtime type information (frtti), exception handling (fexceptions) and signed character type (fsigned-char), so that the compiler obtains clear compilation instructions.

[0209] In some achievable ways, the electronic device can add compilation source files, such as main.cpp and napi_init.cpp, in the CMakeLists.txt file. The electronic device can also set the search path of the header files of the project in the CMakeLists.txt file, which includes the header files of each module in the engine (such as the Cocos2d-x engine) and the header files of the external library. Therefore, the compiler can fully find all necessary header files, thereby ensuring that the compilation process can proceed smoothly and avoiding compilation errors caused by missing header files.

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

[0211] For example, the cocos2d library can provide basic graphics drawing, scene management and other functions; the luacocos2d library can provide information interaction between Lua and the Cocos2d engine; the hilog-lib and libuv-lib libraries can provide logging, asynchronous event processing and other functions. It is understood that the electronic device can link the above library files together to ensure that the various functional modules of the engine can work properly and enable the application to run stably and efficiently.

[0212] In some achievable ways, the electronic device may set up the project in the CmakeLists.txt file in the cocos / directory of the project.

[0213] In some achievable ways, the electronic device can compile and set the CMakeLists.txt in the cocos / 2d / directory and the CMakeLists.txt in the cocos / 3d / directory. It can be understood that, for the CMakeLists.txt in the cocos / 2d / directory and the CMakeLists.txt in the cocos / 3d / directory, as described above, the electronic device can set set(lib_name xxhash), can also set project(${lib_name}), and can also set other items in the CMakeLists.txt file, which are not limited here.

[0214] 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 process various graphic elements in 2D games, such as animations, scenes, etc. The cocos / 3d / directory contains classes and functions related to 3D graphics rendering. These classes and functions can be used to process various graphic elements in 3D games, such as 3D models, cameras, lights, etc.

[0215] In some achievable ways, the electronic device can also set the COCOS_HEADER variable and the COCOS_SRC variable in CMakeLists.txt. It can be understood 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.

[0216] It can be understood that during the compilation process, the compiler can set the header file required for the project according to the COCOS_HEADER variable to obtain the header file required for compiling the project. The compiler can also set the source file required for the project according to the COCOS_SRC variable to obtain the source file required for compiling the project. This avoids compilation errors caused by the compiler being unable to obtain the header file or source file required for compiling the project.

[0217] In some achievable ways, the electronic device can also link external libraries in CMakeLists.txt. For example, the external library can include external, extra_static, lua_extensions_static, libohaudio.so, and libavplayer.so. libohaudio.so and libavplayer.so can provide audio and video playback functions for the project. Other libraries can be used according to the actual situation of the library, which will not be described here.

[0218] 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.

[0219] It is understandable that the electronic device can set the variables in the CmakeLists.txt file under 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.

[0220] It can be understood that the electronic device can add compiled files in CmakeLists.txt according to the above method for all levels of subdirectories of the project. For example, in the 2d subdirectory, set a list of 2D-related header files and source files. Among them, the header files can be CCActionPageTurn3D.h, CCActionTween.h, and the source files can be CCActionCamera.cpp, 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 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.

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

[0222] 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.

[0223] Exemplarily, adding configuration in the CmakeLists.txt file in the root directory of the Cocos2d-x engine may include that the electronic device adds libraries under the extra_static directory and the lua_extensions_static directory to the Cocos2d-x engine, and adds compilation definitions (as described above, the compilation definitions may be the output directory, version number, etc. of the library) for the libraries under the extra_static directory and the lua_extensions_static directory, so that the code of the project can access the header files under the extra directory and the lua_extensions_static directory. In addition, the electronic device may also link with different libraries (for example, linking static libraries such as external, extra_static, and lua_extensions_static) to provide libraries for the compilation process and linking process of the project to ensure the correct operation of the project. The electronic device may also set other items in the CmakeLists.txt file. For example, add_subdirectory, which can add the code under the specified directory to the compilation system of the project so that the code can be recognized and processed by the compiler. target_link_libraries, this command can link 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 can define compile-time macros, such as CC_LUA_ENGINE_ENABLED macro is set 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, the CC_LUA_ENGINE_ENABLED macro setting 1 is essential for the collaboration between 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 can be closely integrated with the Cocos2d engine to jointly provide powerful functional support for application development.

[0224] In other achievable ways, the Quick engine integration and function addition refers to the electronic device adding the Cocos2d-x engine to load the Quick engine code in AppDelegate.cpp. It can be understood that AppDelegate.cpp is responsible for initializing and managing the life cycle of the electronic device. Through the AppDelegate.cpp file, during the process of starting, pausing, and resuming the application corresponding to the project project, the electronic device can correctly handle various resources (such as network resources, computing resources, etc.) and states (such as starting, pausing, and resuming the application).

[0225] Specifically, the electronic device can register various functional modules of the Quick engine (for example, graphics rendering module, audio processing module, physical engine module, network communication module) in Lua through the quickmoduleregister function in AppDelegate.cpp. The logic of the quickmoduleregister function in the AppDelegate.cpp file includes: First, the electronic device can use the luaopen_luaextensionsmore(L) function to open the Lua extension function, which can provide different functions (such as network communication, file operations, etc.). Then, since in the Lua programming environment, the global table G is a container for storing project global variables and functions, the electronic device can use the lua_getglobal(L,"G") function to obtain the global table G in Lua. Then, the electronic device can call different functions in the form of "register_all...", such as register_all_quick_manual(L), etc., which can register various functional modules of the Quick engine in the Lua environment so that the code in the Lua script can call the code in the Quick engine. Next, the electronic device can use the luaopen_cocos2dx_extra_lua_binding(L) function to register the Lua binding function, which is related to the extra functions of the Cocos2d engine (for example, file processing, network communication, etc.), and use the register_all_FileManager_lua_binding(L) function to register the Lua binding related to the file manager, or use other functions to register the Lua binding related to other extra functions. Finally, the electronic device can use lua_pop(L,1) to pop the top element of the stack to keep the Lua stack balanced. It can be understood that calling quickmoduleregister(L) in the applicationDidFinishLaunching function ensures that the Quick engine's functional modules can be registered in the Lua environment in a timely manner when the application is started, thereby providing complete Quick engine functional support for the operation of the entire application.

[0226] Exemplarily, 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 included 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 functions included in the Quick engine can be called during the running of the application.

[0227] In other possible implementations, the integration and function addition of the Quick engine means that the electronic device can add other libraries to the Quick engine according to implementation requirements. The following takes the integration of the Gif (graphics interchange format, Gif) library into the Quick engine as an example to describe the process of adding other libraries to the Quick engine.

[0228] Exemplarily, 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 process of compiling the project.

[0229] It can be understood that by integrating the Gif library into the Quick engine, the application can obtain the image processing function and image display function of the Gif library, thereby enriching the visual effects of the application 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 (for example, characters, scenery, etc.), special effects (for example, blurring, brightening, etc.) or animations (for example, object movement, switching interfaces, etc.) to make the game screen more attractive. For another example, in the interface design of an application, an electronic device can use Gif images to display dynamic icons, guide interfaces or prompt information, etc., to enhance the visual appeal and information communication effect of the application to users.

[0230] It can be understood 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. The 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. The configuration also includes configuring the CmakeLists.txt file contained in the electronic device project project according to actual needs. In this way, the electronic device can establish a project project that ports the code to different Hongmeng operating systems so that the code can run on different Hongmeng operating systems.

[0231] In some achievable methods, the electronic device may compile the source code of the application using an integrated development environment (IDE) (eg, DevEco Studio) according to the configuration items (eg, COCOS2DX_ROOT_PATH, CLASSES_PATH, etc.) contained in the CMakeLists.txt file to obtain a .so library file corresponding to the application.

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

[0233] It can be understood that the .so library file is a dynamic link library file. The electronic device can save the reusable code and reusable data in the source code corresponding to the application in the .so library file. In addition, the electronic device can load the .so library file when the application is running.

[0234] 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.

[0235] Exemplarily, during the process of compiling source code, the electronic device 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.

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

[0237] 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 Hongmeng Next system, such as memory management, thread scheduling and other requirements, set appropriate compilation options, such as optimization level, target architecture, etc., to ensure that the compiled library files can run stably and efficiently in the Hongmeng Next system. In some feasible ways, the application can also communicate with the Hongmeng operating system in other ways.

[0238] In some achievable ways, the electronic device can receive a message string sent by the game engine and extract the parameters in the message string. The parameters are then encapsulated into event data, and the event data is marked with a specific symbol mark (such as "dispatchCocos") to indicate that the event data is data related to the game engine. Finally, the electronic device can send the event data to the HarmonyOS native business end (such as a game application) and return a prompt message indicating that the call is successful. This method implements the function of sending messages and data from a game engine (such as Cocos) to a HarmonyOS native business end (such as a game application).

[0239] For example, an electronic device can be in the CocosDispatcher class. The electronic device 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, and finally return 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 Hongmeng native business end.

[0240] The electronic device can also use the init function to initialize the workerPort (workerPort is a 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.

[0241] In some achievable ways, the electronic device can also extract parameters from the message string and assign the parameters to specific keys. Then, the electronic device can print the event data corresponding to the parameters to the console (such as a display interface or a log file). Finally, a prompt message indicating success is returned. This method can establish an association between the game engine and the Hongmeng native business end (such as a game application) in terms of function calls.

[0242] Exemplarily, the electronic device can also use the registerScriptHandler function to extract the parameters in the message string, and then store it in CocosDispatcher.funEventData according to the function identifier fun in the parameter, 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 Hongmeng 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.

[0243] In some achievable ways, electronic devices can also use a thread (such as Worker) and the interface of the game application (such as Native API) to implement cross-language function calls and data transfer. Specifically, electronic devices can register the functions defined in the arkTS (or JavaScript) code to the native environment of the game engine so that the functions can be called in the game code. Electronic devices can also set thread message listeners, and pass corresponding parameters according to the type of messages listened to, and execute the corresponding logic of the game application.

[0244] 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 the functions related to the worker thread initialization and the functions related to the 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 registered 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.

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

[0246] It can be understood that through the above method, electronic devices can achieve close integration and efficient interaction between the business end of the HarmonyOS 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 HarmonyOS 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.

[0247] 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 Hongmeng operating system.

[0248] 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 Hongmeng operating system.

[0249] 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 running method of the application provided by the aforementioned embodiments on the Hongmeng operating system.

[0250] Next, combine Fig.10 Introduce the structure of electronic equipment. Fig.10 A schematic diagram of the structure of an electronic device provided by an embodiment of the present application is shown. It is to be understood that the structure illustrated 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 certain components, or split certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0251] 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.

[0252] 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 processor (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), etc. Different processing units may be independent devices or integrated into one or more processors.

[0253] 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.

[0254] A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or circulated. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. Repeated access is avoided, the waiting time of the processor 110 is reduced, and the efficiency of the system is improved. The processor 110 may be used to execute the code detection method in the present application.

[0255] In some embodiments, the processor 110 may include one or more interfaces. The interface 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, etc.

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

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

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

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

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

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

[0262] It is understandable that the interface connection relationship between the modules illustrated in the embodiment 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.

[0263] The charging management module 140 is used to receive charging input from a charger, where the charger can be a wireless charger or a wired charger.

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

[0265] 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.

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

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

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

[0269] 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 technology (NFC), infrared technology (IR), etc.

[0270] 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0285] 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.

[0286] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0287] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the electronic device by inserting the SIM card interface 195 or removing the SIM card interface 195. The electronic device can support 1 or N SIM card interfaces, where N is a positive integer greater than 1.

[0288] It is to be understood that the structure illustrated in the present application does not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more or fewer components than shown in the figure, or combine some components, or split some 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.

[0289] The various embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware or a combination of these implementation methods. The embodiments of the present 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.

[0290] Program code can be applied to input instructions to perform the functions described in this application 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.

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

[0292] It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are only used 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 including 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, the elements defined by the sentence "including one" do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0293] Although the present application has been illustrated 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 first mapping module, and a first virtual machine running the first application; wherein the first mapping module stores a first mapping relationship between first type of information of the electronic device and a first type of service calling the first application; the method includes: detecting a first message belonging to the first category of information, and determining, according to the first mapping relationship, a first service corresponding to the first message from the first category of services; The first virtual machine is called based on the first service to run the first application.

2. The method according to claim 1, characterized in that: 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.

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; The first service includes NapiManager::NapiOnCreate, NapiManager::NapiOnShow, NapiManager::NapiOnHide, NapiManager::NapiOnBackPress, NapiManager::NapiOnDestroy, and NapiManager::napiNativeToCocos.

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

5. The method according to claim 3, characterized in that: The first service also includes a callback function, and the calling the first virtual machine to run the first application based on the first service includes: Based on the callback function, a first parameter corresponding to the trigger event is passed to the first virtual machine; based on the first virtual machine, the first parameter is called to run the first application; wherein the first parameter includes a function of the first application.

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

7. The method according to claim 1, characterized in that The electronic device further comprises a first communication module, the first communication module is used to transmit communication data sent by the first virtual machine, the communication data is used to call 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.

8. The method according to claim 7, 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.

9. 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 8.

10. 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 the electronic device, and is used to execute the method according to any one of claims 1 to 8.

11. 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 8.

Images