A method and system for rebuilding a sub-package running environment for an OpenHarmony platform

Abstract

The application relates to an OpenHarmony platform-oriented subpackage running environment reconstruction method and system, wherein the method creates a special XComponent component for each subpackage, bridges the life cycle of the XComponent component and the life cycle of a cocos2d-x engine, triggers initialization of the cocos2d-x engine and marking of a state to be cleaned based on the bridging through an XComponent component OnSurfaceCreated callback function and an OnSurfaceDestroyed callback function, constructs a running environment of the subpackage and completes cleaning of the running environment, and realizes isolated running of different subpackages. Therefore, the application can realize independent running of the subpackage without relying on process restart, avoids environment pollution between the subpackages, and guarantees the stability of the application.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for rebuilding a subpackage runtime environment for the OpenHarmony platform. Background Technology

[0002] As mobile applications continue to grow in size, more and more applications are adopting a subpackage architecture to split functional modules, reducing the size of the main package and supporting on-demand loading. For applications based on script-driven or dynamically loaded resources, such as game applications using the cocos2d-x engine and Lua scripting environment, subpackages typically contain script logic, resource files, and business configurations. When an application switches to or loads a new subpackage during runtime, it is necessary to ensure the independence of the subpackage's runtime environment to avoid interference from the old subpackage's runtime state with the new subpackage.

[0003] On the Android platform, applications typically load new subpackages by restarting the process or recreating the application process. When the host application detects a subpackage update or subpackage switch request, it can actively terminate the current process and restart a new process to load the target subpackage. In the new process, the script engine, resource manager, event listeners, and related runtime objects are all reinitialized, ensuring that the new subpackage starts in a clean runtime environment and avoiding the impact of cached data, memory objects, and resource references generated by the old subpackage on the new subpackage.

[0004] However, on the OpenHarmony platform, it is difficult for applications to actively trigger process restarts to reload the runtime environment during operation. When an application needs to switch sub-packages, it often has to directly load the new sub-package logic within the current process, rather than cleaning up the existing runtime environment by rebuilding the process. This results in multiple sub-packages sharing the same engine environment, which can easily cause problems such as environment pollution, resource reference conflicts, and data state interference between old and new sub-packages, affecting the stability of the application.

[0005] Therefore, in the OpenHarmony platform environment, how to enable the independent operation of sub-packages without relying on process restarts, avoid environmental pollution between sub-packages, and ensure the stability of the application has become an urgent technical problem to be solved. Summary of the Invention

[0006] The technical problem to be solved by this invention is: This invention provides a method and system for rebuilding the sub-package runtime environment for the OpenHarmony platform, which can realize the independent operation of sub-packages without relying on process restart, avoid environmental pollution between sub-packages, and ensure the stability of applications.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a method for reconstructing a subpackage runtime environment for the OpenHarmony platform, comprising: When the first startup instruction of the first sub-package is received, a first XComponent component corresponding to the first sub-package is created according to the first startup instruction, and the life cycle of the first XComponent component is bridged with the life cycle of the cocos2d-x engine. Based on the first bridge, when the first XComponent component triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized in the OnSurfaceCreated callback function to build a first runtime environment corresponding to the first sub-package, and the first sub-package is started in the first runtime environment. When the first exit instruction of the first sub-package is received, based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup, and performs a unified cleanup operation on the cocos2d-x engine according to the pending cleanup state to complete the cleanup of the first runtime environment; When the second startup instruction of the second sub-package is received, a second XComponent component corresponding to the second sub-package is created according to the second startup instruction, and the life cycle of the second XComponent component is bridged with the life cycle of the cocos2d-x engine. Based on the second bridge, the cocos2d-x engine is re-initialized to build a second runtime environment corresponding to the second sub-package, and the second sub-package is started in the second runtime environment to achieve isolated operation of the second sub-package and the first sub-package.

[0008] The beneficial effects of this invention are as follows: It creates a dedicated XComponent for each sub-package and bridges the lifecycle of the XComponent with the lifecycle of the Cocos2d-x engine. Based on this bridging and the initialization of the Cocos2d-x engine, it constructs the runtime environment for the sub-package, solving the environmental pollution problem between old and new sub-packages caused by multiple sub-packages sharing the same engine environment in existing technologies. This achieves isolated operation of different sub-packages, avoiding resource reference conflicts and data state interference between sub-packages, thus improving the stability of sub-package operation. Furthermore, it precisely triggers the initialization and marking of the Cocos2d-x engine to be cleaned up through the OnSurfaceCreated and OnSurfaceDestroyed callback functions of the XComponent, providing clear and controllable trigger boundaries for the start and stop of the Cocos2d-x engine, ensuring its stability.

[0009] Optionally, the step of the first XComponent triggering the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup based on the first bridge includes: Based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function, which calls the exit request function of the cocos2d-x engine and marks the cocos2d-x engine as pending cleanup through the exit request function.

[0010] Optionally, performing a unified cleanup operation on the cocos2d-x engine based on the state to be cleaned includes: After the main loop of the current frame of the cocos2d-x engine has finished executing, a unified cleanup operation is performed on the cocos2d-x engine according to the cleanup status before the start of the main loop of the next frame.

[0011] As described above, by calling the cocos2d-x engine's exit request function in the OnSurfaceDestroyed callback function to mark the state as pending cleanup, instead of immediately performing cleanup operations, it is ensured that all business logic in the current frame has been executed, that is, the unified cleanup operation is performed only after the main loop of the current frame has finished executing. This avoids problems such as the cleanup in the middle of the frame disrupting the runtime environment, causing cocos2d-x engine crashes, and logic errors, thus achieving a smooth connection between sub-package exit and cleanup and improving the stability of application operation.

[0012] Optionally, the unified cleanup operation includes clearing the object pool instance of the cocos2d-x engine, destroying the Lua virtual machine corresponding to the first runtime environment, destroying the audio component corresponding to the first runtime environment and clearing the audio cache, and removing all event listeners registered in the first sub-package.

[0013] As described above, the unified cleanup operation will thoroughly clean up all resources and associated objects generated during the operation of the first sub-package, achieving full cleanup and avoiding resource residues and sub-package interference caused by incomplete cleanup. This ensures the purity of the second sub-package's operating environment and improves the isolation effect between sub-packages.

[0014] Secondly, the present invention provides a subpackage runtime environment reconstruction system for the OpenHarmony platform, comprising: The bridging creation module is used to create a first XComponent component corresponding to the first sub-package according to the first startup instruction when the first startup instruction of the first sub-package is received, and to bridge the life cycle of the first XComponent component with the life cycle of the cocos2d-x engine. Based on the first bridge, when the first XComponent component triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized in the OnSurfaceCreated callback function to build a first runtime environment corresponding to the first sub-package, and the first sub-package is started in the first runtime environment. The unified cleanup module is used to, when receiving the first exit instruction of the first sub-package, based on the first bridge, trigger the OnSurfaceDestroyed callback function of the first XComponent component to mark the cocos2d-x engine as pending cleanup, and perform a unified cleanup operation on the cocos2d-x engine according to the pending cleanup state to complete the cleanup of the first running environment; The environment isolation module is used to create a second XComponent component corresponding to the second sub-package according to the second startup instruction when the second startup instruction of the second sub-package is received, and to bridge the life cycle of the second XComponent component with the life cycle of the cocos2d-x engine for the second time. Based on the second bridge, the cocos2d-x engine is re-initialized to build a second runtime environment corresponding to the second sub-package, and the second sub-package is started in the second runtime environment to achieve isolated operation of the second sub-package and the first sub-package.

[0015] The beneficial effects of this invention are as follows: It creates a dedicated XComponent for each sub-package and bridges the lifecycle of the XComponent with the lifecycle of the Cocos2d-x engine. Based on this bridging and the initialization of the Cocos2d-x engine, it constructs the runtime environment for the sub-package, solving the environmental pollution problem between old and new sub-packages caused by multiple sub-packages sharing the same engine environment in existing technologies. This achieves isolated operation of different sub-packages, avoiding resource reference conflicts and data state interference between sub-packages, thus improving the stability of sub-package operation. Furthermore, it precisely triggers the initialization and marking of the Cocos2d-x engine to be cleaned up through the OnSurfaceCreated and OnSurfaceDestroyed callback functions of the XComponent, providing clear and controllable trigger boundaries for the start and stop of the Cocos2d-x engine, ensuring its stability.

[0016] Optionally, the unified cleanup module includes: The exit marking module is used to, based on the first bridge, trigger the OnSurfaceDestroyed callback function of the first XComponent component to call the exit request function of the cocos2d-x engine in the OnSurfaceDestroyed callback function, and mark the cocos2d-x engine as pending cleanup through the exit request function.

[0017] Optionally, the unified cleanup module specifically comprises: After the main loop of the current frame of the cocos2d-x engine has finished executing, a unified cleanup operation is performed on the cocos2d-x engine according to the cleanup status before the start of the main loop of the next frame.

[0018] As described above, by calling the cocos2d-x engine's exit request function in the OnSurfaceDestroyed callback function to mark the state as pending cleanup, instead of immediately performing cleanup operations, it is ensured that all business logic in the current frame has been executed, that is, the unified cleanup operation is performed only after the main loop of the current frame has finished executing. This avoids problems such as the cleanup in the middle of the frame disrupting the runtime environment, causing cocos2d-x engine crashes, and logic errors, thus achieving a smooth connection between sub-package exit and cleanup and improving the stability of application operation.

[0019] Optionally, the unified cleanup operation includes clearing the object pool instance of the cocos2d-x engine, destroying the Lua virtual machine corresponding to the first runtime environment, destroying the audio component corresponding to the first runtime environment and clearing the audio cache, and removing all event listeners registered in the first sub-package.

[0020] As described above, the unified cleanup operation will thoroughly clean up all resources and associated objects generated during the operation of the first sub-package, achieving full cleanup and avoiding resource residues and sub-package interference caused by incomplete cleanup. This ensures the purity of the second sub-package's operating environment and improves the isolation effect between sub-packages. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating a method for reconstructing a subpackage runtime environment for the OpenHarmony platform, as provided in this embodiment. Figure 2 This is a schematic diagram of the overall process of a subpackage runtime environment reconstruction method for the OpenHarmony platform provided in this embodiment; Figure 3 This is a schematic diagram of the structure of a subpackage runtime environment reconstruction system for the OpenHarmony platform provided in this embodiment.

[0022] [Explanation of Labels in the Attached Image] 1. A subpackage runtime environment reconstruction system for the OpenHarmony platform; 2. Bridge creation module; 3. Unified cleanup module; 31. Exit marking module; 4. Environmental isolation module. Detailed Implementation

[0023] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0024] Example 1 Please refer to Figures 1 to 2 This invention provides a method for rebuilding a subpackage runtime environment for the OpenHarmony platform, comprising the following steps: S1. When the first startup instruction of the first sub-package is received, a first XComponent component corresponding to the first sub-package is created according to the first startup instruction, and the life cycle of the first XComponent component is first bridged with the life cycle of the cocos2d-x engine. Based on the first bridge, when the first XComponent component triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized in the OnSurfaceCreated callback function to build a first runtime environment corresponding to the first sub-package, and the first sub-package is started in the first runtime environment. In this embodiment, a single worker thread is created to run all the logic of the cocos2d-x engine. For example... Figure 2 As shown, when the first startup instruction of the first sub-package is received, a first XComponent corresponding to the first sub-package is created according to the first startup instruction. The first startup instruction at this time refers to the user clicking to enter the first sub-package; the specific first startup instruction can be set according to the actual situation. The first XComponent provides a graphics surface, which is specifically used to carry image rendering results. Each frame of image drawn by the cocos2d-x engine using OpenGL or Vulkan can be output to this graphics surface for display. The lifecycle of the first XComponent is bridged with the lifecycle of the cocos2d-x engine. The lifecycle of the first XComponent includes creation, destruction, display, and hiding, while the lifecycle of the cocos2d-x engine includes a startup state and a stop state. This first bridge between the lifecycles of the first XComponent and the cocos2d-x engine is the foundation of the entire technical solution; subsequent initialization and unified cleanup operations all depend on this first bridge. In fact, by using the OnSurfaceCreated and OnSurfaceDestroyed callback functions of the first XComponent as the trigger points for the initialization and marking of the state to be cleaned up in the cocos2d-x engine, a clear and controllable trigger boundary is provided for the start and stop of the cocos2d-x engine.

[0025] Based on the first bridge, when the first XComponent triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized within the OnSurfaceCreated callback function. Specifically, the OnSurfaceCreated callback function is triggered when the underlying graphics surface of the first XComponent is ready to be drawn. The initialization of the cocos2d-x engine includes: creating the Director, creating the renderer, loading configurations, etc., to build the first runtime environment corresponding to the first sub-package, and start the first sub-package within the first runtime environment.

[0026] S2. When the first exit instruction of the first sub-package is received, based on the first bridge, the first XComponent component triggers the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup, and performs a unified cleanup operation on the cocos2d-x engine according to the pending cleanup state to complete the cleanup of the first running environment. In this embodiment, as Figure 2 As shown, when the first exit instruction of the first sub-package is received, the first exit instruction at this time means: the user returns to the main interface or switches to another sub-package. The specific first exit instruction can be set according to the actual situation. Based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup. According to the pending cleanup state, a unified cleanup operation is performed on the cocos2d-x engine to complete the cleanup of the first runtime environment. The unified cleanup operation includes clearing the object pool instance of the cocos2d-x engine, destroying the Lua virtual machine corresponding to the first runtime environment, destroying the audio component corresponding to the first runtime environment and clearing the audio cache, and removing all event listeners registered in the first sub-package. That is, the cleanup of the first runtime environment is a full cleanup to avoid any residue affecting the purity of the second runtime environment of the second sub-package.

[0027] At this point, step S2, which involves the first XComponent triggering the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup based on the first bridge, includes: S21. Based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function, which calls the exit request function of the cocos2d-x engine and marks the cocos2d-x engine as pending cleanup through the exit request function.

[0028] In this embodiment, as Figure 2 As shown, based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function. Within the OnSurfaceDestroyed callback function, the exit request function of the cocos2d-x engine is called. This exit request function is cc.Director->end(), and it marks the cocos2d-x engine as pending cleanup. At this point, the exit request function only marks the engine and does not perform any cleanup.

[0029] At this point, the unified cleanup operation performed on the cocos2d-x engine according to the state to be cleaned in step S2 includes: S22. After the main loop of the current frame of the cocos2d-x engine has finished executing, before the main loop of the next frame begins, a unified cleanup operation is performed on the cocos2d-x engine according to the state to be cleaned up.

[0030] In this embodiment, as Figure 2 As shown, since all business logic in the Cocos2d-x engine is processed within the core main loop (the main loop), which executes once per frame, a unified cleanup operation is performed on the Cocos2d-x engine after the current frame's main loop finishes execution and before the next frame's main loop begins. This unified cleanup operation is not simply a delayed cleanup, but rather a frame synchronization mechanism that aligns the unified cleanup operation to the boundary of the Cocos2d-x engine's main loop. The unified cleanup operation only occurs at specific checkpoints: after the current frame's main loop finishes execution and before the next frame's main loop begins, rather than at arbitrary times.

[0031] S3. When the second startup instruction of the second sub-package is received, a second XComponent component corresponding to the second sub-package is created according to the second startup instruction, and the life cycle of the second XComponent component is bridged with the life cycle of the cocos2d-x engine. Based on the second bridge, the cocos2d-x engine is re-initialized to build a second runtime environment corresponding to the second sub-package, and the second sub-package is started in the second runtime environment to achieve isolated operation of the second sub-package and the first sub-package.

[0032] In this embodiment, as Figure 2As shown, when the second startup instruction of the second sub-package is received, a second XComponent component corresponding to the second sub-package is created according to the second startup instruction. Similarly, the lifecycle of the second XComponent component is bridged with the lifecycle of the cocos2d-x engine for the second time. Based on the second bridge, the cocos2d-x engine is re-initialized, a second runtime environment corresponding to the second sub-package is constructed, and the second sub-package is started in the second runtime environment to achieve isolated operation of the first sub-package and the second sub-package.

[0033] Example 2 Please refer to Figure 3 The present invention provides a subpackage runtime environment reconstruction system 1 for the OpenHarmony platform, including: a bridging creation module 2, a unified cleanup module 3, an exit marking module 31, and an environment isolation module 4.

[0034] Among them, the bridging creation module 2 is used to create a first XComponent component corresponding to the first sub-package according to the first startup instruction when the first startup instruction of the first sub-package is received, and to bridge the life cycle of the first XComponent component with the life cycle of the cocos2d-x engine. Based on the first bridge, when the first XComponent component triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized in the OnSurfaceCreated callback function to build a first runtime environment corresponding to the first sub-package, and the first sub-package is started in the first runtime environment. The unified cleanup module 3 is used to, when receiving the first exit instruction of the first sub-package, based on the first bridge, trigger the OnSurfaceDestroyed callback function of the first XComponent component to mark the cocos2d-x engine as a state to be cleaned, and perform a unified cleanup operation on the cocos2d-x engine according to the state to be cleaned, so as to complete the cleanup of the first running environment; The environment isolation module 4 is used to create a second XComponent component corresponding to the second sub-package according to the second startup instruction when the second startup instruction of the second sub-package is received, and to bridge the life cycle of the second XComponent component with the life cycle of the cocos2d-x engine for the second time. Based on the second bridge, the cocos2d-x engine is re-initialized to build a second runtime environment corresponding to the second sub-package, and the second sub-package is started in the second runtime environment to achieve isolated operation of the second sub-package and the first sub-package.

[0035] Specifically, the unified cleanup module 3 includes: The exit marking module 31 is used to, based on the first bridge, trigger the OnSurfaceDestroyed callback function of the first XComponent component to call the exit request function of the cocos2d-x engine in the OnSurfaceDestroyed callback function, and mark the cocos2d-x engine as pending cleanup through the exit request function.

[0036] Specifically, the unified cleanup module 3 is as follows: After the main loop of the current frame of the cocos2d-x engine has finished executing, a unified cleanup operation is performed on the cocos2d-x engine according to the cleanup status before the start of the main loop of the next frame.

[0037] Specifically, the unified cleanup operation includes clearing the object pool instances of the cocos2d-x engine, destroying the Lua virtual machine corresponding to the first runtime environment, destroying the audio component corresponding to the first runtime environment and clearing the audio cache, and removing all event listeners registered in the first sub-package.

[0038] Since the systems / devices described in the above embodiments of the present invention are systems / devices used to implement the methods of the above embodiments of the present invention, those skilled in the art can understand the specific structure and modifications of the systems / devices based on the methods described in the above embodiments of the present invention, and therefore will not be repeated here. All systems / devices used in the methods of the above embodiments of the present invention fall within the scope of protection of the present invention.

[0039] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0040] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0041] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In claims that enumerate several means, several of these means may be embodied by the same hardware. The use of the terms first, second, third, etc., is merely for convenience of expression and does not indicate any order. These terms can be understood as part of the component names.

[0042] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0043] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0044] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A method for reconstructing a subpackage runtime environment for the OpenHarmony platform, characterized in that, include: When the first startup instruction of the first sub-package is received, a first XComponent component corresponding to the first sub-package is created according to the first startup instruction, and the life cycle of the first XComponent component is bridged with the life cycle of the cocos2d-x engine. Based on the first bridge, when the first XComponent component triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized in the OnSurfaceCreated callback function to build a first runtime environment corresponding to the first sub-package, and the first sub-package is started in the first runtime environment. When the first exit instruction of the first sub-package is received, based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup, and performs a unified cleanup operation on the cocos2d-x engine according to the pending cleanup state to complete the cleanup of the first runtime environment; When the second startup instruction of the second sub-package is received, a second XComponent component corresponding to the second sub-package is created according to the second startup instruction, and the life cycle of the second XComponent component is bridged with the life cycle of the cocos2d-x engine. Based on the second bridge, the cocos2d-x engine is re-initialized to build a second runtime environment corresponding to the second sub-package, and the second sub-package is started in the second runtime environment to achieve isolated operation of the second sub-package and the first sub-package.

2. The method for reconstructing a subpackage runtime environment for the OpenHarmony platform as described in claim 1, characterized in that, Based on the first bridge, the first XComponent component triggering the OnSurfaceDestroyed callback function to mark the cocos2d-x engine as pending cleanup includes: Based on the first bridge, the first XComponent triggers the OnSurfaceDestroyed callback function, which calls the exit request function of the cocos2d-x engine and marks the cocos2d-x engine as pending cleanup through the exit request function.

3. The method for reconstructing a subpackage runtime environment for the OpenHarmony platform as described in claim 1, characterized in that, The step of performing a unified cleanup operation on the cocos2d-x engine based on the state to be cleaned includes: After the main loop of the current frame of the cocos2d-x engine has finished executing, a unified cleanup operation is performed on the cocos2d-x engine according to the state to be cleaned up before the start of the main loop of the next frame.

4. The method for reconstructing a subpackage runtime environment for the OpenHarmony platform as described in claim 1, characterized in that, The unified cleanup operation includes clearing the object pool instances of the cocos2d-x engine, destroying the Lua virtual machine corresponding to the first runtime environment, destroying the audio component corresponding to the first runtime environment and clearing the audio cache, and removing all event listeners registered in the first sub-package.

5. A subpackage runtime environment reconstruction system for the OpenHarmony platform, characterized in that, include: The bridging creation module is used to create a first XComponent component corresponding to the first sub-package according to the first startup instruction when the first startup instruction of the first sub-package is received, and to bridge the life cycle of the first XComponent component with the life cycle of the cocos2d-x engine. Based on the first bridge, when the first XComponent component triggers the OnSurfaceCreated callback function, the cocos2d-x engine is initialized in the OnSurfaceCreated callback function to build a first runtime environment corresponding to the first sub-package, and the first sub-package is started in the first runtime environment. The unified cleanup module is used to, when receiving the first exit instruction of the first sub-package, based on the first bridge, trigger the OnSurfaceDestroyed callback function of the first XComponent component to mark the cocos2d-x engine as pending cleanup, and perform a unified cleanup operation on the cocos2d-x engine according to the pending cleanup state to complete the cleanup of the first running environment; The environment isolation module is used to create a second XComponent component corresponding to the second sub-package according to the second startup instruction when the second startup instruction of the second sub-package is received, and to bridge the life cycle of the second XComponent component with the life cycle of the cocos2d-x engine for the second time. Based on the second bridge, the cocos2d-x engine is re-initialized to build a second runtime environment corresponding to the second sub-package, and the second sub-package is started in the second runtime environment to achieve isolated operation of the second sub-package and the first sub-package.

6. The subpackage runtime environment reconstruction system for the OpenHarmony platform as described in claim 5, characterized in that, The unified cleanup module includes: The exit marking module is used to, based on the first bridge, trigger the OnSurfaceDestroyed callback function of the first XComponent component to call the exit request function of the cocos2d-x engine in the OnSurfaceDestroyed callback function, and mark the cocos2d-x engine as pending cleanup through the exit request function.

7. The subpackage runtime environment reconstruction system for the OpenHarmony platform as described in claim 5, characterized in that, The unified cleanup module specifically includes: After the main loop of the current frame of the cocos2d-x engine has finished executing, a unified cleanup operation is performed on the cocos2d-x engine according to the state to be cleaned up before the start of the main loop of the next frame.

8. The subpackage runtime environment reconstruction system for the OpenHarmony platform as described in claim 5, characterized in that, The unified cleanup operation includes clearing the object pool instances of the cocos2d-x engine, destroying the Lua virtual machine corresponding to the first runtime environment, destroying the audio component corresponding to the first runtime environment and clearing the audio cache, and removing all event listeners registered in the first sub-package.

Images