Hot updating method, device and equipment

Abstract

The application relates to a hot updating method, device and equipment, relates to a mobile terminal application development technical field, can be applied to the financial and medical fields, and comprises the following steps: triggering hot updating is used for isolating and decrypting an updating package through an independent HSP security domain; a dependency graph is analyzed to perform version compatibility verification; after the verification, a version number is compared through an FFI path interceptor, a loading path is dynamically redirected from a read-only area to a readable and writable sandbox area; on the premise that a single application component is not destroyed, routing stack page instances are replaced according to an updating type, and host attribute states are losslessly transmitted through serialization and deserialization during the replacement; a corresponding C++ rendering engine container is adaptively mounted according to file characteristics, and a hot updating closed loop is completed. The application avoids a cold start process, realizes zero white screen and low memory overhead, effectively transmits and shares a context state of an RN engine, eliminates business state fragmentation, and improves user experience.

Description

Technical Field

[0001] This application relates to the field of mobile application development technology, and can be applied to the financial and medical fields. Specifically, it relates to a hot update method, apparatus, and device. Background Technology

[0002] With the widespread adoption of the HarmonyOS operating system, application development based on cross-platform frameworks such as React Native (RN) is gradually migrating to HarmonyOS. RN's hot update mechanism (dynamic loading mechanism) can dynamically distribute and load the latest JavaScript Bundle (hereinafter referred to as Bundle) without redeploying the application version, thereby enabling rapid iteration and repair of business logic. However, due to the fundamental differences between HarmonyOS and traditional Android systems in terms of underlying architecture, routing mechanism, file system, and security model, existing RN dynamic loading solutions face serious technical bottlenecks and compatibility issues when applied to HarmonyOS.

[0003] Specifically, existing cross-platform frameworks, when faced with complex page or module overloading, often habitually follow Android's "multi-Activity" architecture, which manifests as frequently launching multiple UIAbility components on HarmonyOS. However, HarmonyOS's architecture design advocates a performance-optimized model of "single UIAbility + multiple Pages." Frequently launching multiple UIAbility components not only violates HarmonyOS's design guidelines, leading to noticeable cold start white screens and a significant increase in memory usage during hot updates, but more critically, it prevents the effective transfer and sharing of the React Native engine's context state between UIAbility components, resulting in fragmented business states and a substantial decline in user experience. Summary of the Invention

[0004] In view of this, this application provides a hot update method, apparatus, and device, the main purpose of which is to solve the performance-optimized model of "single UIAbility + multiple Pages" advocated in the current HarmonyOS architecture design. Frequently launching multiple UIAbility not only violates the design specifications of HarmonyOS, resulting in obvious cold start white screen and a significant increase in memory usage during hot updates, but more critically, it also fails to effectively transfer and share the RN engine's context state across UIAbility, leading to fragmented business states and a significant deterioration in user experience.

[0005] According to a first aspect of this application, a hot update method is provided, the method comprising: When a hot update is triggered, the downloaded update code package is verified and decrypted through an independent dynamic shared package HSP security domain; The dependency graph of the decrypted update code package is parsed, and the version compatibility of the update code package is checked. If the check passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the check fails, the atomic rollback mechanism is triggered to block the hot update process. Set a path interceptor on the call path of the application framework loading the updated code package. When a Bundle loading request for the read-only directory area is intercepted, read the configuration file and compare the sandbox version number of the updated code package in the read-write directory with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. While maintaining the runtime environment of a single application component without destroying it, the single Ability route decoupling mechanism is triggered to replace the route stack page instance according to the update type of the Bundle to be updated; wherein, the update type includes sub-Bundle update and main Bundle update; During the page instance replacement process, the lifecycle of the current page is intercepted, the host attribute data of the current page is extracted and serialized, the serialized host attribute data is passed to the routing stack as a routing parameter, and the host attribute data is deserialized and injected when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. During the rendering phase of a new page instance, the file header features of the updated code package or the configuration flags issued by the server are identified. Based on the identification results, the corresponding rendering engine container is dynamically matched and mounted to complete the hot update closed loop.

[0006] According to a second aspect of this application, a hot-renewal device is provided, the device comprising: The processing module is used to verify and decrypt the downloaded update code package through an independent dynamic shared package HSP security domain when a hot update is triggered. The verification module is used to parse the dependency graph of the decrypted update code package and perform version compatibility verification on the update code package. If the verification passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the verification fails, the atomic rollback mechanism is triggered to block the hot update process. The comparison module is used to set a path interceptor on the call path of the application framework loading the updated code package. When a Bundle loading request for the read-only directory area is intercepted, the configuration file is read and the sandbox version number of the updated code package in the read-write directory is compared with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. The replacement module is used to replace the routing stack page instance by triggering the single Ability routing decoupling mechanism according to the update type of the Bundle to be updated, while maintaining the runtime environment of a single application component without destroying it; wherein, the update type includes sub-Bundle update and main Bundle update; The interception module is used to intercept the lifecycle of the current page during the page instance replacement process, extract the host attribute data of the current page for serialization, pass the serialized host attribute data as routing parameters to the routing stack, and deserialize and inject the host attribute data when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. The mounting module is used to identify the file header features of the updated code package or the configuration flags issued by the server during the new page instance rendering stage, and dynamically match and mount the corresponding rendering engine container according to the identification results to complete the hot update closed loop.

[0007] According to a third aspect of this application, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the method of the first aspect described above.

[0008] According to a fourth aspect of this application, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method of the first aspect described above.

[0009] Compared with the prior art, the hot update method, apparatus, and device provided in this application can, when a hot update is triggered, verify and decrypt the downloaded update code package through an independent Dynamic Shared Package (HSP) security domain; parse the dependency graph of the decrypted update code package, and perform version compatibility verification on the update code package. If the verification passes, the update code package and its corresponding configuration file are written to the read-write directory of the application sandbox; if the verification fails, an atomic rollback mechanism is triggered to block the hot update process; a path interceptor is set on the call path of the application framework loading the update code package. When a Bundle loading request for the read-only directory area is intercepted, the configuration file is read, and the sandbox version number of the corresponding update code package in the read-write directory is compared with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is changed from the read-only area. Dynamically redirect to a read-write directory; while maintaining the runtime environment of a single application component without destruction, trigger a single-Ability route decoupling mechanism to replace the page instance in the route stack based on the update type of the Bundle to be updated; the update types include sub-Bundle updates and main Bundle updates; during the page instance replacement process, intercept the lifecycle of the current page, extract the host attribute data of the current page for serialization, pass the serialized host attribute data as route parameters to the route stack, and deserialize and inject the host attribute data when initializing the new page instance to achieve cross-route stack pass-through of business state; during the rendering stage of the new page instance, identify the file header features of the update code package or the configuration flags issued by the server, dynamically match and mount the corresponding rendering engine container according to the identification results, and complete the hot update closed loop.

[0010] According to the solution in this application, the routing stack page instance is replaced by triggering a single Ability routing decoupling mechanism based on the update type of the Bundle to be updated, while maintaining the runtime environment of a single application component without destruction. This means that regardless of whether the hot update is triggered by a child Bundle or the main Bundle, the application always runs within a pre-initialized UIAbility container. For child Bundles, instance replacement is achieved by pushing an instance onto the top of the stack; for the main Bundle, a silent restart with no screen tearing is used. Since the UIAbility host itself is not destroyed and rebuilt, the cold start process is completely avoided, achieving zero white screen and low memory overhead.

[0011] This application employs a path interception and redirection strategy using symbolic links. A path interceptor is set at the underlying C++ bridge of the React Native framework. When the engine attempts to load a new Bundle from the read-only area, the path string is dynamically replaced with the path from the sandbox's read-write area. This mechanism allows for direct reading and loading of the latest code package from the sandbox within the same UIAbility and the same React Native engine instance. Code-level updates can be completed without restarting UIAbility, providing underlying file system support for maintaining a single Ability architecture.

[0012] To address the issue of partial state loss caused by the destruction of old instances and the creation of new instances during sub-bundle updates, this application designs a hot-plug mechanism. Before pushing the old RN instance onto the routing stack and destroying it, its lifecycle is intercepted, and the host attribute data (Token, routing parameters, etc.) of the current page is extracted and passed to the routing stack as routing parameters via JSON serialization. When the new page at the top of the stack initializes a new RNInstance, the data is then deserialized and injected into the new instance. This ensures a soft landing for business logic during hard instance replacement.

[0013] The update of the sub-bundle employs a strategy of pushing the update module onto the stack, replacing the underlying instance, and injecting an overload flag. Pushing the update module onto the stack ensures normal page transition animations; injecting an overload flag and manually popping it from the stack when a return operation is detected perfectly fixes the routing stack breakage issue, making the interactive experience after hot update completely consistent with HarmonyOS's native Navigation.

[0014] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating the application environment of a hot update method provided in an embodiment of this application; Figure 2 A schematic flowchart of a hot update method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the overall process of a hot update method provided in an embodiment of this application. Figure 4 This is a flowchart of a sandbox path dynamic mapping algorithm provided in an embodiment of this application; Figure 5 This is a schematic diagram of the core code of a sandbox path dynamic mapping algorithm provided in an embodiment of this application; Figure 6 This is a schematic diagram of the core code of a single Ability routing decoupling mechanism provided in an embodiment of this application; Figure 7 A timing diagram for hot update routing and state pass-through provided in an embodiment of this application; Figure 8 This is a schematic diagram of the core code for a bimodal container adaptive mounting strategy provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a thermal renewal device provided in an embodiment of this application; Figure 10 A schematic diagram of the structure of a computer device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of another computer device provided in an embodiment of this application. Detailed Implementation

[0018] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0019] The hot update method provided in this application embodiment can be applied to, for example, Figure 1In this application environment, the client communicates with the server via the network. When a hot update is triggered by the client, the server verifies and decrypts the downloaded update code package using an independent Dynamic Shared Package (HSP) security domain. It then parses the dependency graph of the decrypted update code package and performs version compatibility checks. If the check passes, the update code package and its corresponding configuration file are written to the application sandbox's read-write directory. If the check fails, an atomic rollback mechanism is triggered, blocking the hot update process. A path interceptor is set on the call path of the application framework loading the update code package. When a Bundle loading request for the read-only directory is intercepted, the configuration file is read, and the sandbox version number of the corresponding update code package in the read-write directory is compared with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. The process involves several steps: First, while maintaining the runtime environment of a single application component without destruction, a single-Ability routing decoupling mechanism is triggered based on the update type of the Bundle to be updated to replace the page instance in the routing stack. Update types include sub-Bundle updates and main Bundle updates. During the page instance replacement process, the lifecycle of the current page is intercepted, its host attribute data is extracted and serialized, and the serialized host attribute data is passed as routing parameters to the routing stack. When initializing a new page instance, the host attribute data is deserialized and injected, enabling cross-routing state propagation across the routing stack. Second, during the new page instance rendering phase, the file header characteristics of the update code package or the configuration flags issued by the server are identified. Based on the identification results, the corresponding rendering engine container is dynamically matched and mounted, completing the hot update closed loop.

[0020] According to the solution in this application, the routing stack page instance is replaced by triggering a single Ability routing decoupling mechanism based on the update type of the Bundle to be updated, while maintaining the runtime environment of a single application component without destruction. This means that regardless of whether the hot update is triggered by a child Bundle or the main Bundle, the application always runs within a pre-initialized UIAbility container. For child Bundles, instance replacement is achieved by pushing an instance onto the top of the stack; for the main Bundle, a silent restart with no screen tearing is used. Since the UIAbility host itself is not destroyed and rebuilt, the cold start process is completely avoided, achieving zero white screen and low memory overhead.

[0021] This application employs a path interception and redirection strategy using symbolic links. A path interceptor is set at the underlying C++ bridge of the React Native framework. When the engine attempts to load a new Bundle from the read-only area, the path string is dynamically replaced with the path from the sandbox's read-write area. This mechanism allows for direct reading and loading of the latest code package from the sandbox within the same UIAbility and the same React Native engine instance. Code-level updates can be completed without restarting UIAbility, providing underlying file system support for maintaining a single Ability architecture.

[0022] To address the issue of partial state loss caused by the destruction of old instances and the creation of new instances during sub-bundle updates, this application designs a hot-plug mechanism. Before pushing the old RN instance onto the routing stack and destroying it, its lifecycle is intercepted, and the host attribute data (Token, routing parameters, etc.) of the current page is extracted and passed to the routing stack as routing parameters via JSON serialization. When the new page at the top of the stack initializes a new RNInstance, the data is then deserialized and injected into the new instance. This ensures a soft landing for business logic during hard instance replacement.

[0023] The update of the sub-bundle employs a strategy of pushing the update module onto the stack, replacing the underlying instance, and injecting an overload flag. Pushing the update module onto the stack ensures normal page transition animations; injecting an overload flag and manually popping it from the stack when a return operation is detected perfectly fixes the routing stack breakage issue, making the interactive experience after hot update completely consistent with HarmonyOS's native Navigation.

[0024] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the hot update method provided in this application embodiment includes the following steps: Step 101: When a hot update is triggered, the downloaded update code package is verified and decrypted through an independent dynamic shared package (HSP) security domain.

[0025] In this step, to ensure the security of the hot update process and prevent malicious tampering of the update package, this solution innovatively utilizes the HSP (HarmonyOS Shared Package) feature of the HarmonyOS system to construct an independent security domain. The specific implementation process is as follows: First, the core logic for hot update can be pre-encapsulated as an independent HSP module. This core logic includes, but is not limited to, the logic for downloading the update code package, MD5 integrity verification logic, and AES decryption logic. This HSP module is configured with an independent memory address space and runtime sandbox during compilation and runtime, isolating it from the main application process (HAP). By configuring an independent runtime sandbox for the HSP module through the AppScope configuration file, the HSP module has a memory address space and file access permissions independent of the main application process at runtime.

[0026] Secondly, the main application can only communicate with the HSP module through the preset interfaces exposed by the HSP module (such as the fetchAndVerifyBundle interface) to call the download and verification functions, without directly accessing the decryption key.

[0027] Finally, within the HSP module's independent memory space, the update code package downloaded from the server undergoes an MD5 integrity check to ensure the file is undamaged and untampered with. After successful verification, the update code package is decrypted using a pre-configured AES key. Because the HSP module is isolated from the main application process, and the decryption key exists only in the HSP's independent memory, the main application process cannot directly access the decryption key in the HSP module's memory space. Even if the main application process is maliciously injected or attacked, attackers cannot reverse engineer the decryption key within the HSP, thus ensuring the security of the update code package.

[0028] In actual implementation, when a hot update event is triggered (e.g., a new version notification from the server or a user actively triggering an update check), the main application calls the interface exposed by the HSP module, instructing the HSP module to download the update code package from a preset server address. The HSP module performs the download operation in its independent runtime environment. After the download is complete, the downloaded update code package is subjected to MD5 integrity verification in the HSP module's independent memory space to confirm that the update code package has not been tampered with or corrupted during transmission. After the verification passes, the update code package is further decrypted using the built-in AES decryption key to obtain the decrypted update code package and the corresponding version configuration file (such as version_config.json).

[0029] It is worth noting that, since the decryption key is stored only in the independent memory space of the HSP module, and the HSP module has independent process-level isolation protection, even if an attacker obtains memory access to the main application process through root or jailbreaking, they will not be able to read or export the decryption key in the memory of the HSP module, thus fundamentally preventing the risk of key leakage.

[0030] The overall method flowchart of this application is as follows: Figure 3As shown, when a hot update is triggered, the package is first downloaded and decrypted through the HSP security domain; then, version compatibility is checked through the dependency graph to determine whether to allow the update; after allowing the update, the loading request is redirected from the read-only zone to the read-write zone using sandbox path mapping; subsequently, the single Ability routing decoupling mechanism is triggered to replace the page instance, and business continuity is maintained at the moment of replacement through a lossless state injection mechanism; finally, when the instance is created and rendered, the corresponding C++ rendering engine is dynamically matched by mounting a dual-modal container to complete the entire hot update closed loop.

[0031] Step 102: Parse the dependency graph of the decrypted update code package and perform version compatibility verification on the update code package. If the verification passes, write the update code package and the corresponding configuration file to the read-write directory of the application sandbox; if the verification fails, trigger the atomic rollback mechanism to block the hot update process.

[0032] In complex business scenarios, HarmonyOS applications often adopt a modular architecture of "main bundle + multiple sub-business bundles". There are version dependencies between different bundles. For example, a specific version of a sub-business bundle may depend on a baseline version of the main bundle (such as 2.1.0 and above). If the main and sub-bundle versions do not match, it may lead to module loading failure, blank screen, or even application crash.

[0033] Therefore, this embodiment adds a dependency graph verification step after the HSP module decrypts the updated code package and before writing it into the sandbox. Specifically, it first parses the dependency tree declared in the header of the decrypted updated code package. In practice, the dependency tree can be declared in JSON format in the header metadata of the Bundle file, for example: "dependencies": {"mainBundle": ">=2.1.0"}, indicating that the version of the main Bundle that the current sub-Bundle depends on must be 2.1.0 or higher. The system reads this dependency declaration and extracts the baseline version number of the main Bundle that the updated code package depends on.

[0034] At the same time, the system obtains the actual version number of the currently running main bundle (e.g., 2.0.0). The actual version number of the currently running main bundle can be read from the version configuration file loaded when the application starts, or directly obtained from the currently running bundle instance. The extracted baseline version number of the main bundle is compared with the actual version number of the currently running main bundle.

[0035] If the comparison results show that the actual version number of the currently running main bundle is higher than or equal to the baseline version number of the main bundle, the version compatibility check is deemed to have passed, and the hot update process is allowed to continue. The updated code package and the corresponding configuration file are written to the application sandbox's readable and writable directory (such as the files directory) for subsequent path redirection.

[0036] If the comparison results show that the actual version number of the currently running main bundle is lower than the baseline version number of the main bundle, the version compatibility check is deemed to have failed. In this case, forcibly loading the updated code package will inevitably cause a Native layer crash due to version mismatch. Therefore, the system triggers an atomic rollback mechanism, automatically deleting the updated code package and its corresponding configuration files already downloaded to the temporary directory or sandbox directory, blocking subsequent sandbox path redirection and route replacement operations, and forcing the use of the application's built-in path (i.e., the read-only resource directory within the HAP package) to load the old version bundle file. Through this atomic rollback mechanism, the risk of Native layer crashes due to cross-version incompatibility is eliminated from the system's underlying layer, ensuring the stable operation of the application.

[0037] Step 103: Set up a path interceptor on the call path of the application framework loading the update code package. When a Bundle loading request for the read-only directory area is intercepted, read the configuration file and compare the sandbox version number of the corresponding update code package in the read-write directory with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path will be dynamically redirected from the read-only area to the read-write directory.

[0038] HarmonyOS employs a strict sandbox isolation model between HAP packages and applications. The resource directories (such as resourceDir) within the HAP package are absolutely read-only partitions, preventing application processes from writing to or overwriting any files within them. This means that directly overwriting the hot-update code package into the HAP package's internal path will result in write permission denial and hot update failure. To address this technical challenge, this embodiment abandons the traditional approach of "modifying read-only files" and innovatively designs a dynamic sandbox path mapping algorithm based on "version number comparison + path redirection," such as... Figure 4 As shown in the flowchart, the algorithm clearly illustrates the complete decision-making and execution process from intercepting the loading request to completing the path replacement. Figure 5 This is a schematic diagram of the core code of the sandbox path dynamic mapping algorithm provided in the embodiments of this application. For example... Figure 5 As shown, the specific code implements the logic for registering the path interceptor, reading the version configuration file, comparing the version number, and dynamically replacing the path string.

[0039] Specifically, when the application framework initializes and calls the underlying C++ script loading interface (such as the `loadScript` or `requireBundle` method) to read the JS Bundle file, a path interceptor is set at the FFI interface that bridges the ArkTS layer and C++. This path interceptor is used to intercept all loading requests for the Bundle file.

[0040] When the application starts, it first reads the locally persisted version configuration file. The version configuration file can be used to record the current version number and storage path of each bundle. The version configuration file can be generated or updated when it is decrypted by the HSP module in step 101 and written to the sandbox.

[0041] When the path interceptor intercepts a Bundle loading request for a read-only directory area (such as resourceDir within the HAP package), it extracts the Bundle identifier (e.g., businessBundleA) from the loading request. Then, it queries the version configuration file to determine if the directory file corresponding to the Bundle identifier exists in the sandbox's read-write directory, and whether the sandbox version number (sandbox_ver) is greater than the base version number (base_ver) built into the HAP package.

[0042] If the condition is met (i.e., a corresponding sandbox file exists, and the sandbox version number is higher than the base version number), a redirection algorithm is triggered: the original Bundle loading request path string (e.g., harmony / resource / dir / businessBundleA.bundle) is dynamically replaced with the patch Bundle path in the sandbox's read-write directory (e.g., harmony / sandbox / userPath / businessBundleA_patch.bundle), achieving a symbolic link effect for the loading path. Through this path redirection, the RN framework actually loads the new version Bundle file located in the read-write sandbox directory, rather than the old version Bundle file in the HAP package's read-only directory, thus flexibly bypassing the read-only storage limitation of the HarmonyOS system.

[0043] Step 104: Under the premise of maintaining the runtime environment of a single application component without destroying it, trigger the single Ability route decoupling mechanism to replace the route stack page instance according to the update type of the Bundle to be updated; where the update type includes sub-Bundle update and main Bundle update.

[0044] Traditional cross-platform frameworks, when faced with hot update scenarios, often habitually follow the "multi-Activity" approach of the Android platform. On HarmonyOS, this manifests as frequently creating and launching multiple UIAbility (i.e., application components). This approach directly violates the optimal performance design model of "single UIAbility + multiple Pages" recommended by HarmonyOS, leading to significant issues such as cold start white screen and exponentially increased memory usage during hot updates.

[0045] Therefore, this embodiment maintains a single EntryAbility instance throughout the entire process without destroying it, performing page-level routing stack operations and instance replacement only within a single Ability. Specifically, it first determines the update type of the Bundle to be updated. The update type can be determined based on the Bundle's identifier or configuration information.

[0046] If the bundle to be updated is a main bundle (such as the core business module of the application), then the update type is determined to be a main bundle update; if the bundle to be updated is a sub-business bundle (such as an independent business function module), then the update type is determined to be a sub-bundle update.

[0047] When the update type is a sub-bundle update, a lightweight strategy combining "top-of-stack push + underlying instance replacement" is adopted. Specifically, the page corresponding to the updated React Native module can be pushed onto the top of the current route stack using the route stack push interface provided by the ArkUI framework (e.g., the pushPathByName method). The advantage of this approach is that the route stack push operation ensures that page transition animations and interactive behaviors fully comply with the HarmonyOS native Navigation specification, without the user's awareness. Simultaneously or subsequently, the old React Native instance associated with the old page is destroyed at the underlying level, releasing corresponding resources and preventing memory leaks. To facilitate subsequent route stack management, an overload flag (e.g., the isRNReload flag) is injected into the route parameters during the process of pushing the new page onto the route stack, marking that the current page is a newly pushed page after a hot update.

[0048] When a user triggers the physical back button or performs a back gesture, the system determines whether a manual pop operation is needed based on the reload flag carried by the current page. If the reload flag is valid (e.g., isRNReload is true), the system calls the route stack pop interface (e.g., the pop method) to pop the current page from the route stack, returning to the previous page below the top of the stack, thus restoring the page to its state before the update. This perfectly fixes the route stack breakage issue caused by page replacement under a single Ability.

[0049] When the update type is a main Bundle update, a "silent restart" strategy within a single Ability is adopted. Main Bundle updates involve changes to the application's core business logic. If a "stack replacement" approach using sub-Bundles is employed, inconsistent page states may result due to these core logic changes. Therefore, this embodiment uses the `terminateSelf` method in conjunction with the `startAbility` method carrying a no-flashback parameter to restart the current UIAbility. Specifically, the `terminateSelf` method is first called to destroy the current Ability instance, and then the `startAbility` method is immediately called to restart the same Ability, carrying a no-flashback flag parameter (e.g., setting the window animation to no animation or transparent transition) in the Intent. Because the restarted Ability inherits the process space of the original Ability, process-level global variables and singleton objects are shared, ensuring that the login state and other context states are not lost while the main Bundle code is updated, and avoiding memory leaks and state fragmentation caused by restarting a new Ability. Figure 6 As shown, Figure 6 This is a schematic diagram of the core code of the single Ability routing decoupling mechanism provided in the embodiments of this application. The specific code implements the logic of pushing the top of the sub-Bundle update stack and replacing the underlying instance, as well as the logic of silent restarting the main Bundle update.

[0050] Step 105: During the page instance replacement process, intercept the lifecycle of the current page, extract the host attribute data of the current page for serialization, pass the serialized host attribute data as a routing parameter to the routing stack, and deserialize and inject the host attribute data when initializing the new page instance to realize the transparent transmission of business status across the routing stack.

[0051] Step 104 implements a "hard replacement" of the page instance (i.e., the old instance is destroyed and a new instance is created). However, if only instance replacement is performed without state migration, the new page instance will lose its original business state (such as user login tokens, page routing parameters, form data, etc.), resulting in a fragmented user experience. To solve this problem, this embodiment designs a cross-routing stack state lossless injection and pass-through mechanism.

[0052] Specifically, before the page instance replacement operation is performed in step 104 (i.e., before the new page is pushed onto the route stack and the old page is destroyed), the lifecycle function of the current page (i.e., the old page) is intercepted first. The lifecycle function can be onWillDisappear or an equivalent lifecycle callback. By intercepting the lifecycle function, the initialization property data (initProps) of the current page is obtained. The initialization property data includes, but is not limited to, complex data such as login token, route parameters, user state data, and page context information.

[0053] Subsequently, the obtained initialization attribute data is converted into a string format using a JSON stringification method (such as JSON.stringify). The converted string is then passed as a route parameter to the push interface of the route stack.

[0054] Next, when a new React Native instance is created and initialized on the new page at the top of the stack, the system retrieves the serialized string from the route parameters, restores the string to a JavaScript object using a JSON deserialization method (such as JSON.parse), and injects the restored object into the data.properties property of the newly created React Native instance without modification. Through the complete process of serialization transmission and deserialization injection described above, lossless pass-through of the old page's business state to the new page is achieved, ensuring a "soft landing" of business logic during instance "hard replacement," and realizing true "hot-plugging."

[0055] like Figure 7 As shown, Figure 7 The hot update routing and state pass-through sequence diagram provided for the embodiments of this application clearly shows the complete interaction sequence from user-triggered hot update, to route stack push, state extraction and serialization, old instance destruction, new instance creation, state deserialization injection, until page rendering is completed.

[0056] Step 106: During the new page instance rendering stage, identify the file header features of the updated code package or the configuration flags issued by the server, dynamically match and mount the corresponding rendering engine container based on the identification results, and complete the hot update closed loop.

[0057] The application framework employs two different rendering engine modes: one is a rendering engine based on the Metro bundler (MetroBaseRN container), and the other is a traditional BaseRN rendering engine (BaseRN container). The compilation method, packaging format, and rendering bridging logic of the bundle files differ between the two modes. Current solutions fix the rendering engine type during application compilation and packaging, making dynamic switching at runtime impossible, and preventing engine-level upgrades through hot updates.

[0058] To this end, this embodiment pre-configures a first rendering engine container and a second rendering engine container in the loading layer of the host Ability. The first rendering engine container corresponds to the MetroBaseRN container, and the second rendering engine container corresponds to the traditional BaseRN container. After the hot update bundle is downloaded and processed through steps 101 to 105, during the new page instance rendering stage, the system first reads a specific byte segment from the header of the update code package as an engine feature identifier; or, it reads the configuration flags (e.g., the isMetroAvailable flag) issued by the server. Based on the reading result, it determines the type of underlying C++ rendering bridge engine required by the current bundle.

[0059] If the file header characteristics or configuration flags indicate support for the Metro bundler (i.e., isMetroAvailable is true), the MetroBaseRN rendering engine container is dynamically mounted, and the corresponding rendering engine instance is initialized. The updated code package is then rendered using the new engine. If the file header characteristics or configuration flags indicate that the Metro bundler is not supported (i.e., isMetroAvailable is false or does not exist), the traditional BaseRN rendering engine container is dynamically mounted, and the corresponding rendering engine instance is initialized. The updated code package is then rendered using the traditional engine.

[0060] Through the aforementioned bimodal container adaptive mounting logic, this embodiment achieves the ability to dynamically switch the underlying C++ rendering bridge engine within a single Ability. This means that hot updates can not only update JS business code, but also upgrade or switch the rendering engine at runtime, realizing a dimensional upgrade from "code hot updates" to "engine hot updates," greatly expanding the application scope and technical depth of hot updates.

[0061] like Figure 8 As shown, Figure 8 This is a schematic diagram of the core code for the bimodal container adaptive mounting strategy provided in the embodiments of this application. The specific code implements file header feature recognition, configuration flag reading, and dynamic mounting logic for containers of different rendering engines.

[0062] In summary, according to the hot update method provided in this application, compared with the prior art, this application can, when a hot update is triggered, verify and decrypt the downloaded update code package through an independent Dynamic Shared Package (HSP) security domain; parse the dependency graph of the decrypted update code package, and perform version compatibility verification on the update code package. If the verification passes, the update code package and its corresponding configuration file are written to the read-write directory of the application sandbox; if the verification fails, an atomic rollback mechanism is triggered to block the hot update process; a path interceptor is set on the call path of the application framework loading the update code package. When a Bundle loading request for the read-only directory area is intercepted, the configuration file is read, and the sandbox version number of the corresponding update code package in the read-write directory is compared with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is changed from the read-only area. Dynamically redirect to a read-write directory; while maintaining the runtime environment of a single application component without destruction, trigger a single-Ability route decoupling mechanism to replace the page instance in the route stack based on the update type of the Bundle to be updated; the update types include sub-Bundle updates and main Bundle updates; during the page instance replacement process, intercept the lifecycle of the current page, extract the host attribute data of the current page for serialization, pass the serialized host attribute data as route parameters to the route stack, and deserialize and inject the host attribute data when initializing the new page instance to achieve cross-route stack pass-through of business state; during the rendering stage of the new page instance, identify the file header features of the update code package or the configuration flags issued by the server, dynamically match and mount the corresponding rendering engine container according to the identification results, and complete the hot update closed loop.

[0063] According to the solution in this application, the routing stack page instance is replaced by triggering a single Ability routing decoupling mechanism based on the update type of the Bundle to be updated, while maintaining the runtime environment of a single application component without destruction. This means that regardless of whether the hot update is triggered by a child Bundle or the main Bundle, the application always runs within a pre-initialized UIAbility container. For child Bundles, instance replacement is achieved by pushing an instance onto the top of the stack; for the main Bundle, a silent restart with no screen tearing is used. Since the UIAbility host itself is not destroyed and rebuilt, the cold start process is completely avoided, achieving zero white screen and low memory overhead.

[0064] This application employs a path interception and redirection strategy using symbolic links. A path interceptor is set at the underlying C++ bridge of the React Native framework. When the engine attempts to load a new Bundle from the read-only area, the path string is dynamically replaced with the path from the sandbox's read-write area. This mechanism allows for direct reading and loading of the latest code package from the sandbox within the same UIAbility and the same React Native engine instance. Code-level updates can be completed without restarting UIAbility, providing underlying file system support for maintaining a single Ability architecture.

[0065] To address the issue of partial state loss caused by the destruction of old instances and the creation of new instances during sub-bundle updates, this application designs a hot-plug mechanism. Before pushing the old RN instance onto the routing stack and destroying it, its lifecycle is intercepted, and the host attribute data (Token, routing parameters, etc.) of the current page is extracted and passed to the routing stack as routing parameters via JSON serialization. When the new page at the top of the stack initializes a new RNInstance, the data is then deserialized and injected into the new instance. This ensures a soft landing for business logic during hard instance replacement.

[0066] The update of the sub-bundle employs a strategy of pushing the update module onto the stack, replacing the underlying instance, and injecting an overload flag. Pushing the update module onto the stack ensures normal page transition animations; injecting an overload flag and manually popping it from the stack when a return operation is detected perfectly fixes the routing stack breakage issue, making the interactive experience after hot update completely consistent with HarmonyOS's native Navigation.

[0067] Based on the above Figure 1 To specifically implement the method shown, this embodiment provides a hot-update device, such as... Figure 9 As shown, the device includes: a processing module 31, a verification module 32, a comparison module 33, a replacement module 34, an interception module 35, and a mounting module 36; Processing module 31 is used to verify and decrypt the downloaded update code package through an independent dynamic shared package HSP security domain when a hot update is triggered; The verification module 32 is used to parse the dependency graph of the decrypted update code package and perform version compatibility verification on the update code package. If the verification passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the verification fails, the atomic rollback mechanism is triggered to block the hot update process. The comparison module 33 is used to set a path interceptor on the call path of the application framework loading the update code package. When a Bundle loading request for the read-only directory area is intercepted, the configuration file is read and the sandbox version number of the update code package corresponding to the read-write directory is compared with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. The replacement module 34 is used to replace the routing stack page instance by triggering the single Ability routing decoupling mechanism according to the update type of the Bundle to be updated, while maintaining the single application component's operating environment without destruction; wherein, the update type includes sub-Bundle update and main Bundle update; The interception module 35 is used to intercept the lifecycle of the current page during the page instance replacement process, extract the host attribute data of the current page for serialization, pass the serialized host attribute data as a routing parameter to the routing stack, and deserialize and inject the host attribute data when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. Mounting module 36 is used to identify the file header features of the updated code package or the configuration flags issued by the server during the new page instance rendering stage, and dynamically match and mount the corresponding rendering engine container according to the identification results to complete the hot update closed loop.

[0068] In specific application scenarios, processing module 31 can be used to encapsulate hot update logic into an independent HSP module. The HSP module is configured with an independent memory addressing space and a running sandbox. The main application calls the download and verification functions through the preset interface exposed by the HSP module. In the independent memory space of the HSP module, the downloaded update code package is subjected to MD5 integrity verification and AES decryption.

[0069] In specific application scenarios, the verification module 32 can be used to parse the dependency tree declared in the header of the updated code package, obtain the baseline version of the main bundle that the updated code package depends on, and obtain the actual version of the currently running main bundle; compare the actual version of the main bundle with the baseline version of the main bundle; if the actual version of the main bundle is higher than or equal to the baseline version of the main bundle, the verification is deemed to pass, and the updated code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the actual version of the main bundle is lower than the baseline version of the main bundle, the verification is deemed to fail, the atomic rollback mechanism is triggered, the downloaded sandbox file is deleted, subsequent sandbox path redirection and route replacement are blocked, and the old bundle file is forced to be loaded using the application's built-in path.

[0070] In specific application scenarios, the comparison module 33 can be used to set the path interceptor at the FFI interface bridging the ArkTS layer and C++ when the application framework initializes and calls the underlying C++ script loading interface; read the locally persistent version configuration file, which records the current version number and storage path of each Bundle; when the path interceptor intercepts a Bundle loading request for the read-only directory area, it extracts the Bundle identifier from the Bundle loading request, queries the version configuration file, and if it is determined that the read-write directory contains the directory file corresponding to the Bundle identifier, and the sandbox version number is greater than the base version number, it triggers a redirection algorithm to dynamically replace the path string of the read-only directory area of ​​the Bundle loading request with the sandbox path in the sandbox read-write directory, thereby bypassing the read-only storage restriction of the HarmonyOS system with a soft link effect.

[0071] In specific application scenarios, the replacement module 34 can be used to: if the update type is the sub-Bundle update, adopt a stack top push combined with underlying instance replacement strategy to load the updated page module to the top of the route stack through the route stack push interface and destroy the old page instance at the bottom layer; inject a reload flag into the page at the top of the route stack; when a physical back button trigger or a back gesture operation is detected, perform a route stack pop operation according to the reload flag to restore the page state before the update; if the update type is the main Bundle update, adopt a silent restart strategy to call its own termination interface and combine it with a start interface without screen flicker parameters to restart the current UIAbility.

[0072] In specific application scenarios, the interception module 35 can be used to intercept the lifecycle functions of the current page, obtain the initialization attribute data of the current page, the initialization attribute data including login token and routing parameters; convert the initialization attribute data into string format using JSON stringification method; and pass the converted string as a parameter to the push interface of the routing stack.

[0073] In specific application scenarios, the mounting module 36 can be used to mount the MetroBaseRN rendering engine container if the file header features or configuration flags indicate support for the Metro packer; and to mount the traditional BaseRN rendering engine container if the file header features or configuration flags indicate that the Metro packer is not supported.

[0074] This application provides a hot update mechanism that, while maintaining the runtime environment of a single application component without destruction, triggers a single Ability routing decoupling mechanism to replace the page instance of the route stack based on the update type of the Bundle to be updated. This means that regardless of whether the hot update is triggered by a child Bundle or the main Bundle, the application always runs within a pre-initialized UIAbility container. For child Bundles, instance replacement is achieved by pushing an instance onto the top of the stack; for the main Bundle, a silent restart with no screen-flashing parameters is used. Since the UIAbility host itself is not destroyed and rebuilt, the cold start process is completely avoided, achieving zero white screen and low memory overhead.

[0075] This application employs a path interception and redirection strategy using symbolic links. A path interceptor is set at the underlying C++ bridge of the React Native framework. When the engine attempts to load a new Bundle from the read-only area, the path string is dynamically replaced with the path from the sandbox's read-write area. This mechanism allows for direct reading and loading of the latest code package from the sandbox within the same UIAbility and the same React Native engine instance. Code-level updates can be completed without restarting UIAbility, providing underlying file system support for maintaining a single Ability architecture.

[0076] To address the issue of partial state loss caused by the destruction of old instances and the creation of new instances during sub-bundle updates, this application designs a hot-plug mechanism. Before pushing the old RN instance onto the routing stack and destroying it, its lifecycle is intercepted, and the host attribute data (Token, routing parameters, etc.) of the current page is extracted and passed to the routing stack as routing parameters via JSON serialization. When the new page at the top of the stack initializes a new RNInstance, the data is then deserialized and injected into the new instance. This ensures a soft landing for business logic during hard instance replacement.

[0077] The update of the sub-bundle employs a strategy of pushing the update module onto the stack, replacing the underlying instance, and injecting an overload flag. Pushing the update module onto the stack ensures normal page transition animations; injecting an overload flag and manually popping it from the stack when a return operation is detected perfectly fixes the routing stack breakage issue, making the interactive experience after hot update completely consistent with HarmonyOS's native Navigation.

[0078] Specific limitations regarding the hot-update device can be found in the limitations of the hot-update method above, and will not be repeated here. Each module in the aforementioned hot-update device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0079] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a hot-update method on the server side.

[0080] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a hot-update method on the client side.

[0081] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: When a hot update is triggered, the downloaded update code package is verified and decrypted through an independent dynamic shared package HSP security domain. The dependency graph of the decrypted update code package is parsed, and the version compatibility of the update code package is checked. If the check passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the check fails, the atomic rollback mechanism is triggered to block the hot update process. Set a path interceptor on the call path of the application framework loading the updated code package. When a Bundle loading request for the read-only directory area is intercepted, read the configuration file and compare the sandbox version number of the updated code package in the read-write directory with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. While maintaining the runtime environment of a single application component without destroying it, the single Ability route decoupling mechanism is triggered to replace the route stack page instance according to the update type of the Bundle to be updated; wherein, the update type includes sub-Bundle update and main Bundle update; During the page instance replacement process, the lifecycle of the current page is intercepted, the host attribute data of the current page is extracted and serialized, the serialized host attribute data is passed to the routing stack as a routing parameter, and the host attribute data is deserialized and injected when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. During the rendering phase of a new page instance, the file header features of the updated code package or the configuration flags issued by the server are identified. Based on the identification results, the corresponding rendering engine container is dynamically matched and mounted to complete the hot update closed loop.

[0082] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: When a hot update is triggered, the downloaded update code package is verified and decrypted through an independent dynamic shared package HSP security domain; The dependency graph of the decrypted update code package is parsed, and the version compatibility of the update code package is checked. If the check passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the check fails, the atomic rollback mechanism is triggered to block the hot update process. Set a path interceptor on the call path of the application framework loading the updated code package. When a Bundle loading request for the read-only directory area is intercepted, read the configuration file and compare the sandbox version number of the updated code package in the read-write directory with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. While maintaining the runtime environment of a single application component without destroying it, the single Ability route decoupling mechanism is triggered to replace the route stack page instance according to the update type of the Bundle to be updated; wherein, the update type includes sub-Bundle update and main Bundle update; During the page instance replacement process, the lifecycle of the current page is intercepted, the host attribute data of the current page is extracted and serialized, the serialized host attribute data is passed to the routing stack as a routing parameter, and the host attribute data is deserialized and injected when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. During the rendering phase of a new page instance, the file header features of the updated code package or the configuration flags issued by the server are identified. Based on the identification results, the corresponding rendering engine container is dynamically matched and mounted to complete the hot update closed loop.

[0083] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0084] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0086] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0087] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A hot update method, characterized in that, The method includes: When a hot update is triggered, the downloaded update code package is verified and decrypted through an independent dynamic shared package HSP security domain; The dependency graph of the decrypted update code package is parsed, and the version compatibility of the update code package is checked. If the check passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox; if the check fails, the atomic rollback mechanism is triggered to block the hot update process. Set a path interceptor on the call path of the application framework loading the updated code package. When a Bundle loading request for the read-only directory area is intercepted, read the configuration file and compare the sandbox version number of the updated code package in the read-write directory with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. While maintaining the runtime environment of a single application component without destroying it, the single Ability route decoupling mechanism is triggered to replace the route stack page instance according to the update type of the Bundle to be updated; wherein, the update type includes sub-Bundle update and main Bundle update; During the page instance replacement process, the lifecycle of the current page is intercepted, the host attribute data of the current page is extracted and serialized, the serialized host attribute data is passed to the routing stack as a routing parameter, and the host attribute data is deserialized and injected when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. During the rendering phase of a new page instance, the file header features of the updated code package or the configuration flags issued by the server are identified. Based on the identification results, the corresponding rendering engine container is dynamically matched and mounted to complete the hot update closed loop.

2. The hot update method according to claim 1, characterized in that, The process of verifying and decrypting the downloaded update code package through an independent dynamic shared package (HSP) security domain includes: The hot update logic is encapsulated as an independent HSP module, which is configured with an independent memory addressing space and a runtime sandbox. The main application calls the download and verification functions through the preset interface exposed by the HSP module; Within the independent memory space of the HSP module, the downloaded update code package undergoes MD5 integrity verification and AES decryption.

3. The hot update method according to claim 1, characterized in that, The dependency graph of the decrypted update code package is parsed, and the version compatibility of the update code package is checked. If the check passes, the update code package and the corresponding configuration file are written to the read-write directory of the application sandbox. If the verification fails, an atomic rollback mechanism is triggered, blocking the hot update process, including: Parse the dependency tree declared in the header of the updated code package to obtain the baseline version of the main bundle that the updated code package depends on, and obtain the actual version of the currently running main bundle; Compare the actual version of the main bundle with the baseline version of the main bundle; If the actual version of the main bundle is higher than or equal to the baseline version of the main bundle, the verification is deemed successful, and the updated code package and the corresponding configuration file are written to the read-write directory of the application sandbox. If the actual version of the main bundle is lower than the baseline version of the main bundle, the verification is deemed to fail, triggering the atomic rollback mechanism to delete the downloaded sandbox file, block subsequent sandbox path redirection and route replacement, and force the old bundle file to be loaded using the application's built-in path.

4. The hot update method according to claim 1, characterized in that, The step of setting a path interceptor on the call path of loading the updated code package in the application framework, when intercepting a Bundle loading request for the read-only directory area, reads the configuration file, compares the sandbox version number of the updated code package corresponding to the read-write directory with the base version number built into the HAP package, and if the sandbox version number is greater than the base version number, dynamically redirects the loading path from the read-only area to the read-write directory, including: When the application framework initializes and calls the underlying C++ script loading interface, the path interceptor is set at the FFI interface that bridges the ArkTS layer and C++. Read the locally persisted version configuration file, which records the current version number and storage path of each Bundle; When the path interceptor intercepts a Bundle loading request for the read-only directory area, it extracts the Bundle identifier from the Bundle loading request, queries the version configuration file, and if it determines that the directory file corresponding to the Bundle identifier exists in the read-write directory and the sandbox version number is greater than the base version number, it triggers a redirection algorithm to dynamically replace the path string of the read-only directory area in the Bundle loading request with the sandbox path in the sandbox read-write directory, thereby bypassing the read-only storage restriction of the HarmonyOS system with a soft link effect.

5. The hot-update method according to claim 1, characterized in that, The step of triggering the single-Ability route decoupling mechanism to replace the route stack page instance based on the update type of the Bundle to be updated includes: If the update type is the sub-Bundle update, a stack top push combined with underlying instance replacement strategy is adopted to load the updated page module to the top of the route stack through the route stack push interface, and destroy the old page instance at the bottom layer. If the update type is the main Bundle update, a silent restart strategy is adopted to call its own termination interface and combine it with the start interface without screen flicker parameters to restart the current UIAbility.

6. The hot update method according to claim 5, characterized in that, After loading the updated page module onto the top of the route stack via the route stack push interface and destroying the old page instance at the bottom layer, the method further includes: Inject an overload flag into the page at the top of the routing stack; When a physical back button trigger or a back gesture operation is detected, a route stack pop operation is performed according to the reload flag, restoring the page state to its state before the update.

7. The hot update method according to claim 1, characterized in that, The step of extracting the host attribute data of the current page, performing serialization processing, and passing the serialized host attribute data as routing parameters to the routing stack includes: Intercept the lifecycle functions of the current page and obtain the initialization attribute data of the current page, including the login token and routing parameters; The initialization attribute data is converted into a string format using the JSON stringification method; The converted string is passed as a parameter to the push interface of the routing stack.

8. The hot update method according to claim 1, characterized in that, The step of dynamically matching and mounting the corresponding rendering engine container based on the recognition results includes: If the file header features or configuration flags indicate support for the Metro Packer, then mount the MetroBaseRN rendering engine container. If the file header features or configuration flags indicate that the Metro packer is not supported, then the traditional BaseRN rendering engine container is mounted.

9. A thermal renewal device, characterized in that, include: The processing module is used to verify and decrypt the downloaded update code package through an independent dynamic shared package HSP security domain when a hot update is triggered. The verification module is used to parse the dependency graph of the decrypted update code package, perform version compatibility verification on the update code package, and if the verification passes, write the update code package and the corresponding configuration file into the read-write directory of the application sandbox. If the verification fails, the atomic rollback mechanism is triggered, blocking the hot update process; The comparison module is used to set a path interceptor on the call path of the application framework loading the updated code package. When a Bundle loading request for the read-only directory area is intercepted, the configuration file is read and the sandbox version number of the updated code package in the read-write directory is compared with the base version number built into the HAP package. If the sandbox version number is greater than the base version number, the loading path is dynamically redirected from the read-only area to the read-write directory. The replacement module is used to replace the routing stack page instance by triggering the single Ability routing decoupling mechanism according to the update type of the Bundle to be updated, while maintaining the runtime environment of a single application component without destroying it; wherein, the update type includes sub-Bundle update and main Bundle update; The interception module is used to intercept the lifecycle of the current page during the page instance replacement process, extract the host attribute data of the current page for serialization, pass the serialized host attribute data as routing parameters to the routing stack, and deserialize and inject the host attribute data when initializing a new page instance, so as to realize the transparent transmission of business status across the routing stack. The mounting module is used to identify the file header features of the updated code package or the configuration flags issued by the server during the new page instance rendering stage, and dynamically match and mount the corresponding rendering engine container according to the identification results to complete the hot update closed loop.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the hot update method as described in any one of claims 1 to 8.

Images