ArkTS agent-based hot repair method, device and equipment for a harmonious application and a medium

Abstract

This application discloses a method, apparatus, device, and medium for hot-fixing HarmonyOS applications based on ArkTS proxies. Applied to a target HarmonyOS application, which includes an ArkTS layer, a Native layer, and a JSVM layer, and relating to the field of computer technology, the method includes: loading patch code corresponding to the business logic to be fixed in the target HarmonyOS application; generating function references corresponding to the methods to be fixed in the business logic; intercepting business calls to the methods to be fixed using a replaced proxy entry point; determining the object type based on the complexity of the passed object in the call information; performing traffic splitting and transformation on the passed object using the object type; and performing shadow execution; determining whether a callback to the ArkTS layer is needed during the shadow execution; if a callback is needed, executing the callback using a real business instance to obtain the callback result; and determining the shadow execution result based on the callback result to complete the hot-fix operation. This improves the correctness and stability of hot-fixing.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for hot repair of HarmonyOS applications based on ArkTS proxy. Background Technology

[0002] Currently, when native applications experience online defects, the typical approach to fix them is to modify the source code, repackage, retest, re-upload, and then have users upgrade their versions. On platforms that support dynamic updates, there are also technical approaches that use class loading, AOP instrumentation, reflection replacement, and script injection to fix localized logic at runtime. However, ArkTS (an application development language) native applications are constrained by the ArkTS runtime, Native (native code) bridging capabilities, and the JSVM (a lightweight runtime environment) execution environment, making it difficult to directly migrate dynamic fixes from other platforms. For example, in high real-time businesses such as securities and payments, if a crash, boundary judgment error, asynchronous state disorder, or result write-back anomaly occurs online, and if losses cannot be stopped quickly, it can lead to continuous business interruptions, failed user asset operations, escalating complaints, and significant economic losses.

[0003] Existing, relatively similar solutions typically employ the following approach: first, obtain the patch file; then, parse the correspondence between the method to be fixed and the patch code; finally, replace the target method at runtime, or insert patch logic before and after the target method using AOP, and then let the script engine execute it. This type of solution usually focuses on patch file management, AOP information lists, patch execution methods, and patch activation processes. Achieving hotfix solely through patch files, method name mappings, and script execution fails to address the most critical issue of preserving instance semantics during ArkTS method execution. Many business methods rely on the actual `this` object, instance fields, member methods, and host object context. If these semantics are lost during cross-engine calls, even if the patch logic is executed, the correctness of the result is difficult to guarantee. If a value copying method is uniformly used for cross-engine transfer, complex objects, objects with methods, host objects, and asynchronous objects can easily lose their identity and behavioral semantics. If a reference-based storage method is uniformly used, it can easily lead to type confusion, lifecycle mismatch, duplicate wrapping, and dangling references, affecting both correctness and stability as well as performance. This results in simple and complex objects being transferred using the same strategy, making it impossible to simultaneously achieve both runtime efficiency and semantic consistency.

[0004] As can be seen from the above, improving the accuracy and stability of thermal repair is an urgent problem to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method, apparatus, device, and medium for hot-fixing HarmonyOS applications based on ArkTS proxy, which can improve the accuracy and stability of hot-fixing. The specific solution is as follows: Firstly, this application provides a hotfix method for HarmonyOS applications based on ArkTS proxy, applied to a target HarmonyOS application, the target HarmonyOS application comprising an ArkTS layer, a Native layer, and a JSVM layer, including: Load the service to be repaired in the target HarmonyOS application, load the patch code corresponding to the service to be repaired, determine the identification information corresponding to the method to be repaired in the service to be repaired, and generate the function reference corresponding to the method to be repaired; Based on the identification information and the function reference, the original method entry point corresponding to the method to be repaired is determined, and the original method entry point is replaced with a proxy entry point. The proxy entry point is used to intercept business calls to the method to be repaired in order to obtain the corresponding call information. Based on the complexity of the transmitted object in the call information, the corresponding object type is determined. The transmitted object is then split and transformed using the object type to obtain the transformed object. Based on the transformed object and the patch code, a shadow execution is performed on the method to be repaired, and it is determined whether a callback to the ArkTS layer is needed during the shadow execution process. If a callback to the ArkTS layer is required, the real business instance is determined based on the callback request initiated by the JSVM layer, and the callback is executed using the real business instance to obtain the callback result. Based on the callback result, the corresponding shadow execution result is determined to complete the corresponding hotfix operation.

[0006] Optionally, the steps of loading the service to be repaired in the target HarmonyOS application, loading the patch code corresponding to the service to be repaired, determining the identification information corresponding to the method to be repaired in the service to be repaired, and generating a function reference corresponding to the method to be repaired include: Load the service to be repaired from the target HarmonyOS application, and initialize the JSVM execution environment in the Native layer; Establish a target call channel between the ArkTS layer, the Native layer, and the JSVM layer; The patch code corresponding to the service to be repaired is loaded into the JSVM layer so that the JSVM layer can determine the class identifier of the target class corresponding to the service to be repaired, and the method identifier of the target method corresponding to the target class. Create a corresponding function reference for the target method, and transfer the class identifier and the method identifier to the ArkTS layer; Accordingly, the shadow execution of the method to be repaired based on the transformed object and the patch code includes: Based on the transformed object, the patch code, and the function reference, shadow execution is performed on the method to be repaired using the target call channel.

[0007] Optionally, the step of determining the original method entry point corresponding to the method to be repaired based on the identification information and the function reference, replacing the original method entry point with a proxy entry point, and using the proxy entry point to intercept business calls to the method to be repaired in order to obtain the corresponding call information includes: Based on the class identifier, the method identifier, and the function reference, locate the original method entry point corresponding to the method to be repaired, and replace the original method entry point with the proxy entry point; The proxy entry is used to intercept business calls to the method to be repaired in order to obtain the corresponding call information, and the call information is forwarded to the Native layer; the call information includes instance context, parameter list, module identifier, class identifier and target method identifier.

[0008] Optionally, determining the corresponding object type based on the complexity of the transmitted object in the call information, and using the object type to perform stream splitting and transformation on the transmitted object to obtain the transformed object, includes: The instance context and parameter list in the call information are identified as the object to be passed, and the corresponding object type is determined based on the complexity of the object to be passed. It is then determined whether the object type is the target basic type. If it is the target basic type, then the transmitted object is format-converted to obtain the corresponding converted object; the target basic type includes numbers, strings, and boolean values; If it is not the target basic type, then determine whether the object type is the target array type; If the target array type is specified, then each element in the transmitted object is traversed, and a recursive transformation is performed based on the traversal results to obtain the corresponding transformed object.

[0009] Optionally, after determining whether the object type is the target array type, the method further includes: If it is not the target array type, then determine whether the object type is a target type that meets a preset simple condition; the preset simple condition is that the transmitted object does not contain the prototype of the target complex object. If the target type meets the preset simple conditions, then the transmitted object is mirrored to obtain the converted object. If the target type does not meet the preset simple conditions, the transmitted object is wrapped and the resulting wrapped object is determined as the converted object; the wrapped object includes the instance context reference information and the class identifier.

[0010] Optionally, if a callback to the ArkTS layer is required, the real business instance is determined based on the callback request initiated by the JSVM layer, including: If a callback to the ArkTS layer is required, the callback request initiated by the JSVM layer is sent to the Native layer using the target access entry corresponding to the transformed object, so that the Native layer can determine whether the callback request is a callback request for a real business instance. If the callback request is for a real business instance, and the transformed object is a wrapper object, then the instance context in the wrapper object is determined to be the real business instance.

[0011] Optional, also includes: Based on the shadow execution result, a corresponding target request number is generated, and the target request number is compared with the latest request number in the service to be repaired. Based on the comparison result, it is determined whether the shadow execution result has expired. If it does not expire, the shadow execution result is written into the service to be repaired to complete the corresponding hot repair operation.

[0012] Secondly, this application provides a HarmonyOS application hotfix device based on ArkTS proxy, applied to a target HarmonyOS application, the target HarmonyOS application including an ArkTS layer, a Native layer, and a JSVM layer, comprising: The function reference generation module is used to load the service to be repaired in the target HarmonyOS application, load the patch code corresponding to the service to be repaired, determine the identification information corresponding to the method to be repaired in the service to be repaired, and generate a function reference corresponding to the method to be repaired. The object type determination module is used to determine the original method entry point corresponding to the method to be repaired based on the identification information and the function reference, replace the original method entry point with the proxy entry point, intercept the business calls to the method to be repaired using the proxy entry point to obtain the corresponding call information, determine the corresponding object type based on the complexity of the transmitted object in the call information, and perform a stream conversion on the transmitted object using the object type to obtain the converted object. The callback judgment module is used to perform shadow execution on the method to be repaired based on the transformed object and the patch code, and to determine whether the ArkTS layer needs to be accessed via callback during the shadow execution process. The execution result determination module is used to determine the real business instance based on the callback request initiated by the JSVM layer if a callback access to the ArkTS layer is required, and to execute the callback using the real business instance to obtain the callback result. Based on the callback result, the module determines the corresponding shadow execution result to complete the corresponding hotfix operation.

[0013] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the aforementioned HarmonyOS application hotfix method based on ArkTS agent.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned HarmonyOS application hotfix method based on ArkTS agent.

[0015] This application loads the service to be repaired in the target HarmonyOS application and loads the patch code corresponding to the service to be repaired. It determines the identifier information corresponding to the method to be repaired in the service to be repaired and generates a function reference corresponding to the method to be repaired. Based on the identifier information and the function reference, it determines the original method entry point corresponding to the method to be repaired and replaces the original method entry point with a proxy entry point. It uses the proxy entry point to intercept business calls to the method to be repaired to obtain corresponding call information. Based on the complexity of the passed object in the call information, it determines the corresponding object type and uses the object type to perform a stream conversion on the passed object to obtain a converted object. Based on the converted object and the patch code, it performs shadow execution on the method to be repaired and determines whether a callback to the ArkTS layer is needed during the shadow execution. If a callback to the ArkTS layer is needed, it determines the real business instance based on the callback request initiated by the JSVM layer and uses the real business instance to execute the callback to obtain the callback result. Based on the callback result, it determines the corresponding shadow execution result to complete the corresponding hot-fix operation.

[0016] As shown above, this application first loads the method to be repaired in the HarmonyOS application, establishes a unique mapping relationship between the patch and the method to be repaired, intercepts the repair method call using a proxy entry point, does not modify the original business code, performs traffic splitting and conversion according to the complexity of the passed object, and then runs the patch repair logic to ensure that the normal use of securities business is not interrupted; it identifies in real time whether it is necessary to access the original instance to ensure that the repair logic can be connected to the real business context. In this way, the original instance is restored to execute the callback, ensuring that the this reference and instance state are completely consistent with the original business, so as to complete the complete repair logic based on the callback result. There is no need to repackage, re-upload, or upgrade users. It can fix online defects of HarmonyOS applications in seconds and can be adapted to method-level hotfix of various ArkTS HarmonyOS applications, improving the correctness and stability of hotfix. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 This application discloses a flowchart of a HarmonyOS application hotfix method based on ArkTS proxy; Figure 2 This application discloses a specific flowchart of a HarmonyOS application hotfix method based on ArkTS proxy; Figure 3 This is a timing diagram of a HarmonyOS application hotfix method based on ArkTS proxy disclosed in this application; Figure 4 This is a schematic diagram of a HarmonyOS application thermal repair device based on ArkTS agent disclosed in this application; Figure 5 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Currently, the focus is typically on patch file management, AOP information lists, patch execution methods, and patch activation processes. However, this approach struggles to address the critical issue of maintaining instance semantics during ArkTS method execution. If value copying is used uniformly for cross-engine transfers, complex objects, objects with methods, host objects, and asynchronous objects can easily lose their identity and behavioral semantics. Conversely, using a uniform reference-based approach can lead to type confusion, lifecycle mismatches, duplicate wrapping, and dangling references, impacting both correctness and stability as well as performance. This results in both simple and complex objects being passed using the same strategy, making it impossible to simultaneously achieve both operational efficiency and semantic consistency. Therefore, this application provides a HarmonyOS application hotfix method based on ArkTS proxies. This method restores the original instance execution callback, ensuring that the `this` pointer and instance state are completely consistent with the original business logic. Complete repair logic is then performed based on the callback results, eliminating the need for repackaging, re-uploading, or user upgrades. It achieves second-level repair of online defects in HarmonyOS applications and is adaptable to method-level hotfixes in various ArkTS HarmonyOS applications, improving the correctness and stability of hotfixes.

[0021] See Figure 1 As shown, this invention discloses a hotfix method for HarmonyOS applications based on ArkTS proxy, applied to a target HarmonyOS application. The target HarmonyOS application includes an ArkTS layer, a Native layer, and a JSVM layer, comprising: Step S11: Load the service to be repaired in the target HarmonyOS application, load the patch code corresponding to the service to be repaired, determine the identification information corresponding to the method to be repaired in the service to be repaired, and generate the function reference corresponding to the method to be repaired.

[0022] In this embodiment, during the startup phase of the target HarmonyOS application, all business modules requiring hotfix support (i.e., the business to be fixed) are preloaded, and a target call channel is established between the ArkTS layer, the Native layer, and the JSVM layer. Simultaneously, the JSVM execution environment is initialized in the Native layer, and the ArkTS call entry point and method replacement entry point are pre-registered for unified scheduling of subsequent fix logic. After the fix patch code is loaded into the JSVM execution environment, the JSVM layer outputs the class identifier of the target class corresponding to the business to be fixed, as well as the method set corresponding to that class. The Native layer then establishes reusable function references for each method in the method set and sends the target class identifier and target method identifier back to the ArkTS side. The target HarmonyOS application can be a financial application such as a securities application, banking application, or payment application, or a HarmonyOS application from other fields.

[0023] Specifically, the steps of loading the service to be repaired in the target HarmonyOS application, loading the patch code corresponding to the service to be repaired, determining the identification information corresponding to the method to be repaired in the service to be repaired, and generating a function reference corresponding to the method to be repaired include: loading the service to be repaired in the target HarmonyOS application; initializing the JSVM execution environment in the Native layer; establishing a target call channel between the ArkTS layer, the Native layer, and the JSVM layer; loading the patch code corresponding to the service to be repaired into the JSVM layer so that the JSVM layer can determine the class identifier of the target class corresponding to the service to be repaired and the method identifier of the target method corresponding to the target class; creating a corresponding function reference for the target method and transmitting the class identifier and the method identifier to the ArkTS layer.

[0024] Step S12: Based on the identification information and the function reference, determine the original method entry point corresponding to the method to be repaired, and replace the original method entry point with the proxy entry point. Use the proxy entry point to intercept business calls to the method to be repaired to obtain the corresponding call information. Based on the complexity of the transmitted object in the call information, determine the corresponding object type. Use the object type to perform splitting and conversion on the transmitted object to obtain the converted object.

[0025] In this embodiment, the original method entry point corresponding to the method to be repaired is located based on the class identifier, the method identifier, and the function reference. The original method entry point is replaced with a proxy entry point. The proxy entry point is used to intercept business calls to the method to be repaired, without executing the original method. The instance context, parameter list, module identifier, class identifier, and target method identifier of the business call are captured, and the above information is forwarded to the Native layer.

[0026] Specifically, the process of determining the original method entry point corresponding to the method to be repaired based on the identification information and the function reference, replacing the original method entry point with a proxy entry point, and using the proxy entry point to intercept business calls to the method to be repaired in order to obtain corresponding call information includes: locating the original method entry point corresponding to the method to be repaired based on the class identifier, the method identifier, and the function reference, and replacing the original method entry point with a proxy entry point; intercepting business calls to the method to be repaired using the proxy entry point to obtain corresponding call information, and forwarding the call information to the Native layer; the call information includes instance context, parameter list, module identifier, class identifier, and target method identifier.

[0027] Understandably, after the Native layer receives the instance context and parameter list, it performs a complexity determination on the cross-engine passed object. If the type of the passed object is the target basic type, the passed object is directly converted into the basic value corresponding to the target engine, thus obtaining the converted object. If it is the target array type, the elements in the passed object are traversed and recursively converted to obtain the corresponding converted object.

[0028] Specifically, determining the corresponding object type based on the complexity of the transmitted object in the call information, and then using the object type to perform splitting and conversion on the transmitted object to obtain the converted object, includes: determining the instance context and parameter list in the call information as the transmitted object, determining the corresponding object type based on the complexity of the transmitted object, and determining whether the object type is a target basic type; if it is the target basic type, then performing format conversion on the transmitted object to obtain the corresponding converted object; the target basic type includes numbers, strings, and booleans; if it is not the target basic type, then determining whether the object type is a target array type; if it is the target array type, then traversing each element in the transmitted object, and performing recursive conversion based on the traversal results to obtain the corresponding converted object.

[0029] Understandably, if the transmitted object belongs to neither the target basic type nor the target array type, it is determined whether the object type meets a preset simple condition. In one specific implementation, the preset simple condition is that the transmitted object has no function attributes and its prototype is a generic prototype. If it is the target type, the transmitted object is mirrored to obtain the converted object. If it is not the target type, it indicates that the transmitted object meets a preset complex condition, i.e., it is a complex object containing functions, instances, or host semantics. If the preset complex condition is met, the transmitted object is wrapped, and the function references and target class identifiers of the original object are retained to obtain the converted object.

[0030] Specifically, after determining whether the object type is the target array type, the process further includes: if it is not the target array type, determining whether the object type is a target type that satisfies a preset simple condition; the preset simple condition is that the transmitted object does not contain a target complex object prototype; if it is a target type that satisfies the preset simple condition, performing attribute mirroring on the transmitted object to obtain a converted object; if it is not a target type that satisfies the preset simple condition, wrapping the transmitted object and determining the resulting wrapped object as the converted object; the wrapped object includes the instance context reference information and the class identifier.

[0031] Step S13: Based on the transformed object and the patch code, perform shadow execution on the method to be repaired, and determine whether the ArkTS layer needs to be accessed via callback during the shadow execution process.

[0032] In this embodiment, the JSVM layer executes a shadow implementation based on the transformed object, the patch code, and the function reference through the target invocation channel. This shadow implementation replaces the original method in executing business repair logic and determines whether it needs to access ArkTS object properties, call ArkTS member methods, or update instance fields. All of these operations are callback accesses to the ArkTS layer. Specifically, the shadow execution of the method to be repaired based on the transformed object and the patch code includes: performing shadow execution of the method to be repaired based on the transformed object, the patch code, and the function reference using the target invocation channel.

[0033] Step S14: If a callback to the ArkTS layer is required, the real business instance is determined based on the callback request initiated by the JSVM layer, and the callback is executed using the real business instance to obtain the callback result. Based on the callback result, the corresponding shadow execution result is determined to complete the corresponding hotfix operation.

[0034] In this embodiment, if a callback to the ArkTS layer is required, in one specific implementation, for a complex transfer object corresponding to the preset complex condition, the callback request is sent to the Native layer through the target access entry corresponding to the wrapped object. It is then determined whether the callback request is for a specific real instance; that is, whether a real instance exists in the callback request. If it does, the transformed object is restored to the original ArkTS instance, with the original ArkTS instance as the sole caller. Member method calls, attribute reads, and attribute writes are distinguished according to request type, and corresponding operations are performed to obtain the corresponding callback result. In another specific implementation, for a simple transfer object corresponding to the preset simple condition, a callback request is directly initiated through the pre-registered ArkTS call entry. The request content in the callback request is assigned or read / written to obtain the callback result.

[0035] Specifically, if a callback to the ArkTS layer is required, determining the real business instance based on the callback request initiated by the JSVM layer includes: if a callback to the ArkTS layer is required, sending the callback request initiated by the JSVM layer to the Native layer using the target access entry corresponding to the transformed object, so that the Native layer can determine whether the callback request is a callback request for a real business instance; if it is a callback request for a real business instance, and the transformed object is a wrapper object, then determining the instance context in the wrapper object as the real business instance.

[0036] Understandably, the shadow implementation continues to execute based on the callback result to obtain the shadow execution result, which is the complete result of the hotfix. For complex objects that have already established cross-engine mapping relationships, existing mapping results are reused first during subsequent repeated transmissions, rather than creating new wrapper objects, to maintain the identity stability of the same business object throughout the entire hotfix execution and avoid state drift and duplicate wrapping issues in asynchronous links. In addition, before updating the instance state in the shadow implementation, the latest request identifier recorded in the instance is read and compared with the identifier carried in the current response. If the current response belongs to an old request, the current state write-back is terminated; if the current response meets the timing conditions, the query results, title list, or other page states are written back to avoid expired results overwriting the latest state. Specifically, this also includes: generating a corresponding target request number based on the shadow execution result, comparing the target request number with the latest request number in the business to be repaired, and determining whether the shadow execution result has expired based on the comparison result; if it has not expired, the shadow execution result is written to the business to be repaired to complete the corresponding hotfix operation.

[0037] As shown above, this application first loads the method to be repaired in the HarmonyOS application, establishes a unique mapping relationship between the patch and the method to be repaired, intercepts the repair method call using a proxy entry point, does not modify the original business code, performs traffic splitting and conversion according to the complexity of the passed object, and then runs the patch repair logic to ensure that the normal use of securities business is not interrupted; it identifies in real time whether it is necessary to access the original instance to ensure that the repair logic can be connected to the real business context. In this way, the original instance is restored to execute the callback, ensuring that the this reference and instance state are completely consistent with the original business, so as to complete the complete repair logic based on the callback result. There is no need to repackage, re-upload, or upgrade users. It can repair online defects of HarmonyOS applications in seconds and can be adapted to method-level hotfix of various ArkTS HarmonyOS applications, improving the correctness and stability of hotfix.

[0038] As can be seen from the above embodiments, this application distinguishes different object types based on the complexity of the transmitted object and uses shadow execution to achieve hot repair of the service to be repaired. Therefore, the process of distinguishing different object types based on the complexity of the transmitted object and using shadow execution to achieve hot repair of the service to be repaired is described.

[0039] Combination Figure 2 and Figure 3 As shown, this embodiment of the invention discloses a specific hotfix method for HarmonyOS applications based on ArkTS proxy, applied to a target HarmonyOS application. The target HarmonyOS application includes an ArkTS layer, a Native layer, and a JSVM layer, comprising: In this embodiment, the JSVM execution environment is started and configured, and a target call channel is established between the ArkTS, Native, and JSVM layers. Simultaneously, the ArkTS call entry point and method replacement entry point are pre-registered. The ArkTS call entry point serves as a general channel for subsequent callback access to ArkTS, and the method replacement entry point serves as a channel for issuing proxy replacement instructions to the ArkTS layer. Then, patch code is loaded, the target classes and methods to be repaired are determined, and reusable function references are generated for each target method. Simultaneously, class identifiers and method identifiers are sent back to the ArkTS layer. Based on these identifiers, the entry point of the original method is located and replaced with a proxy entry point. When a user triggers a business call, the proxy directly intercepts the call to the original method, without executing the original logic, and simultaneously captures complete call information. This call information includes the instance context (i.e., the real business instance), parameter list, module identifier, class identifier, and target method identifier. All call information is forwarded to the Native layer. It is worth noting that the proxy entry point can also be set in the instance method distribution table, module exported method table, or unified call scheduling table, as long as the real instance and parameter list can be obtained before the original method is officially executed.

[0040] Understandably, after receiving the instance context and parameter list, the Native layer performs a complexity determination on the cross-engine passed object. If the type of the passed object is the target basic type, such as number, string, or boolean value, the passed object is directly converted to the basic value corresponding to the target engine, thus obtaining the converted object. If it is the target array type, each element in the passed object is traversed and recursively converted to obtain the corresponding converted object. If the passed object is neither the target basic type nor the target array type, it is determined whether the object type meets the preset simple condition. If it is the target type, i.e., a simple type, such as a general prototype or a pure data object without function attributes, the passed object is mirrored to obtain the converted object. If it is not the target type, it indicates that the passed object meets the preset complex condition, i.e., a complex object with a complex prototype, function members, and instance semantics. If the preset complex condition is met, the passed object is wrapped, and the wrapping structure includes the function reference of the original object and the target class identifier to obtain the converted object. It's worth noting that auxiliary information such as type tags, lifecycle handles, and object numbers can also be added to the wrapper structure to facilitate instance restoration and object management during the ArkTS callback. Furthermore, this method determines whether an object is simple or complex through prototype chain checks and checks of its own property function members. Conditions such as host object type, built-in object type, asynchronous object type, and serializability can also be added, as long as the split processing is implemented.

[0041] Furthermore, after receiving the transformed object, the JSVM layer executes the shadow implementation in the patch code. During execution, if the transformed object corresponds to a basic type or a simple object, the original ArkTS instance is not affected; if the transformed object corresponds to a complex object, the real ArkTS instance cannot be directly accessed. If the shadow implementation needs to access the ArkTS layer via callback, for basic types or simple objects, the callback is initiated directly through the ArkTS call entry point to locate the variables / properties in the ArkTS layer, complete the assignment or reading, and obtain the corresponding callback result; for complex objects, the JSVM layer initiates the callback through the access entry point of the transformed object. After receiving the request, the Native layer restores the real business instance of the ArkTS layer based on the original function reference in the transformed object, uses this instance as the call receiver, performs read property / call method / write field operations to obtain the callback result, and returns the callback result to the shadow implementation of the JSVM layer to continue executing subsequent logic to obtain the shadow execution result.

[0042] In this embodiment, if the execution result of the shadow implementation is the result of asynchronous business operations, such as network requests or background loading, and needs to be written back to the ArkTS instance, then asynchronous verification is initiated. Specifically, the request identifier carried in the current response, i.e., the unique number generated when the asynchronous request was initiated, is read, and the latest request identifier stored in the ArkTS instance is read. The two identifiers are compared to determine if they match. If they match, it indicates that the shadow execution result has not expired and is a valid result, and the write-back to the ArkTS instance state continues. If they do not match, it indicates that the shadow execution result has expired, and the write-back process terminates, discarding the expired result to prevent old data from overwriting the new state. It is worth noting that this method uses a request identifier or event identifier to determine whether the asynchronous result has expired. Timestamps, sequence numbers, version numbers, round markers, or other markers that can distinguish the order of new and old requests can also be used, as long as they can prevent old results from overwriting the new state.

[0043] As can be seen from the above, this application intercepts the repair method call using a proxy entry point, and performs traffic splitting and transformation according to the complexity of the object passed in the call information. For complex objects, a wrapper is used, and the patch repair logic is executed in shadow form. It also determines whether the original instance needs to be accessed during the execution process to restore the original instance and execute the callback. In this way, the complete repair logic is completed based on the callback result. Through stable mapping reuse and asynchronous timing protection mechanisms, the risks of duplicate wrapping and writing back expired results are reduced, which is conducive to improving the correctness, stability and engineering feasibility of hot repair.

[0044] Accordingly, see Figure 4 As shown, this application also provides a HarmonyOS application hotfix device based on ArkTS proxy, applied to a target HarmonyOS application, the target HarmonyOS application including an ArkTS layer, a Native layer and a JSVM layer, including: The function reference generation module 11 is used to load the service to be repaired in the target HarmonyOS application, load the patch code corresponding to the service to be repaired, determine the identification information corresponding to the method to be repaired in the service to be repaired, and generate a function reference corresponding to the method to be repaired. The object type determination module 12 is used to determine the original method entry point corresponding to the method to be repaired based on the identification information and the function reference, replace the original method entry point with the proxy entry point, intercept the business calls for the method to be repaired using the proxy entry point to obtain the corresponding call information, determine the corresponding object type based on the complexity of the transmitted object in the call information, and perform a split conversion on the transmitted object using the object type to obtain the converted object. The callback judgment module 13 is used to perform shadow execution on the method to be repaired based on the transformed object and the patch code, and to determine whether the ArkTS layer needs to be accessed via callback during the shadow execution process. The execution result determination module 14 is used to determine the real business instance based on the callback request initiated by the JSVM layer if a callback access to the ArkTS layer is required, and to execute the callback using the real business instance to obtain the callback result. Based on the callback result, the corresponding shadow execution result is determined to complete the corresponding hotfix operation.

[0045] In some specific embodiments, the function reference generation module 11 may specifically include: The execution environment initialization unit is used to load the service to be repaired in the target HarmonyOS application and initialize the JSVM execution environment in the Native layer. The target channel establishment unit is used to establish a target call channel between the ArkTS layer, the Native layer, and the JSVM layer; The identifier determination unit is used to load the patch code corresponding to the service to be repaired into the JSVM layer, so that the JSVM layer can determine the class identifier of the target class corresponding to the service to be repaired, and the method identifier of the target method corresponding to the target class; An identifier transmission unit is used to create a corresponding function reference for the target method and transmit the class identifier and the method identifier to the ArkTS layer. Accordingly, the callback judgment module 13 may specifically include: The shadow execution unit is used to perform shadow execution of the method to be repaired based on the transformed object, the patch code, and the function reference, and by utilizing the target call channel.

[0046] In some specific embodiments, the object type determination module 12 may specifically include: An entry replacement unit is used to locate the original method entry corresponding to the method to be repaired based on the class identifier, the method identifier, and the function reference, and replace the original method entry with a proxy entry. The call information forwarding unit is used to intercept business calls to the method to be repaired using the proxy entry point, so as to obtain the corresponding call information and forward the call information to the Native layer; the call information includes instance context, parameter list, module identifier, class identifier and target method identifier.

[0047] In some specific embodiments, the object type determination module 12 may specifically include: The object determination unit is used to determine the instance context and parameter list in the call information as the object to be passed, determine the corresponding object type based on the complexity of the object to be passed, and determine whether the object type is the target basic type. An object conversion unit is used to perform format conversion on the transmitted object if it is the target basic type, so as to obtain the corresponding converted object; the target basic type includes numbers, strings and booleans; An object type determination unit is used to determine whether the object type is a target array type if it is not the target basic type. The recursive conversion unit is used to traverse each element in the transmitted object if the target array type is the target array type, and to perform recursive conversion based on the traversal results to obtain the corresponding converted object.

[0048] In some specific embodiments, the HarmonyOS application hotfix device based on ArkTS proxy may further include: The type determination unit is used to determine whether the object type is a target type that satisfies a preset simple condition if it is not the target array type; the preset simple condition is that the transmitted object does not contain a target complex object prototype. The attribute mirroring unit is used to perform attribute mirroring on the transmitted object if the target type meets the preset simple conditions, so as to obtain the transformed object. An object wrapping unit is used to wrap the transmitted object if it is not a target type that meets the preset simple conditions, and to determine the wrapped object as the converted object; the wrapped object includes the instance context reference information and the class identifier.

[0049] In some specific embodiments, the execution result determination module 14 may specifically include: The callback request sending unit is used to send the callback request initiated by the JSVM layer to the Native layer using the target access entry corresponding to the transformed object if a callback access to the ArkTS layer is required, so that the Native layer can determine whether the callback request is a callback request for a real business instance. The instance determination unit is used to determine the instance context in the wrapping object as the real business instance if the callback request is for a real business instance and the transformed object is a wrapping object.

[0050] In some specific embodiments, the HarmonyOS application hotfix device based on ArkTS proxy may further include: The execution result judgment unit is used to generate a corresponding target request number based on the shadow execution result, compare the target request number with the latest request number in the service to be repaired, and determine whether the shadow execution result has expired based on the comparison result. The execution result writing unit is used to write the shadow execution result to the service to be repaired if it does not expire, so as to complete the corresponding hot repair operation.

[0051] Furthermore, embodiments of this application also disclose an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the HarmonyOS application hotfix method based on ArkTS proxy disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0052] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0053] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0054] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the HarmonyOS application hotfix method based on ArkTS agent executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0055] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned HarmonyOS application hotfix method based on ArkTS agent. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0056] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0057] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0058] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0059] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0060] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for hot fixing a HongMeng application based on an ArkTS agent, characterized in that, Applied to a target HarmonyOS application, the target HarmonyOS application includes an ArkTS layer, a Native layer, and a JSVM layer, including: Load the service to be repaired in the target HarmonyOS application, load the patch code corresponding to the service to be repaired, determine the identification information corresponding to the method to be repaired in the service to be repaired, and generate the function reference corresponding to the method to be repaired; Based on the identification information and the function reference, the original method entry point corresponding to the method to be repaired is determined, and the original method entry point is replaced with a proxy entry point. The proxy entry point is used to intercept business calls to the method to be repaired to obtain the corresponding call information. The object type of the object being passed in the call information is determined, and the object being passed is split and transformed using the object type to obtain the transformed object. The call information includes instance context, parameter list, module identifier, class identifier, and target method identifier. Based on the transformed object and the patch code, a shadow execution is performed on the method to be repaired, and it is determined whether a callback to the ArkTS layer is needed during the shadow execution process. If a callback to the ArkTS layer is required, the real business instance is determined based on the callback request initiated by the JSVM layer, and the callback is executed using the real business instance to obtain the callback result. Based on the callback result, the corresponding shadow execution result is determined to complete the corresponding hotfix operation. The step of determining the object type of the transmitted object in the call information and using the object type to perform splitting and conversion on the transmitted object to obtain the converted object includes: determining the instance context and parameter list in the call information as the transmitted object, determining the object type of the transmitted object, and determining whether the object type is a target basic type; if it is the target basic type, then performing format conversion on the transmitted object to obtain the corresponding converted object; the target basic type includes numbers, strings, and booleans; if it is not the target basic type, then determining whether the object type is a target array type; if it is the target array type, then traversing each element in the transmitted object and performing recursive conversion based on the traversal results to obtain the corresponding converted object; The process of determining whether the object type is a target array type further includes: if it is not the target array type, determining whether the object type is a target type that satisfies a preset simple condition; the preset simple condition is that the transmitted object does not contain a target complex object prototype; if it is a target type that satisfies the preset simple condition, performing attribute mirroring on the transmitted object to obtain a converted object; if it is not a target type that satisfies the preset simple condition, wrapping the transmitted object and determining the resulting wrapped object as the converted object; the wrapped object includes the instance context reference information and the class identifier. Specifically, the step of determining the real business instance based on the callback request initiated by the JSVM layer if a callback access to the ArkTS layer is required includes: if a callback access to the ArkTS layer is required, the callback request initiated by the JSVM layer is sent to the Native layer using the target access entry corresponding to the transformed object, so that the Native layer can determine whether the callback request is a callback request for a real business instance; if it is a callback request for a real business instance, and the transformed object is a wrapper object, then the instance context in the wrapper object is determined as the real business instance.

2. The HarmonyOS application hotfix method based on ArkTS proxy according to claim 1, characterized in that, The process includes loading the service to be repaired from the target HarmonyOS application, loading the patch code corresponding to the service to be repaired, determining the identification information corresponding to the method to be repaired in the service to be repaired, and generating a function reference corresponding to the method to be repaired, including: Load the service to be repaired from the target HarmonyOS application, and initialize the JSVM execution environment in the Native layer; Establish a target call channel between the ArkTS layer, the Native layer, and the JSVM layer; The patch code corresponding to the service to be repaired is loaded into the JSVM layer so that the JSVM layer can determine the class identifier of the target class corresponding to the service to be repaired, and the method identifier of the target method corresponding to the target class. Create a corresponding function reference for the target method, and transfer the class identifier and the method identifier to the ArkTS layer; Accordingly, the shadow execution of the method to be repaired based on the transformed object and the patch code includes: Based on the transformed object, the patch code, and the function reference, shadow execution is performed on the method to be repaired using the target call channel.

3. The HarmonyOS application hotfix method based on ArkTS proxy according to claim 2, characterized in that, The process involves determining the original method entry point corresponding to the method to be repaired based on the identification information and the function reference, replacing the original method entry point with a proxy entry point, and using the proxy entry point to intercept business calls to the method to be repaired in order to obtain the corresponding call information, including: Based on the class identifier, the method identifier, and the function reference, locate the original method entry point corresponding to the method to be repaired, and replace the original method entry point with the proxy entry point; The proxy entry is used to intercept business calls to the method to be repaired in order to obtain the corresponding call information, and the call information is forwarded to the Native layer; the call information includes instance context, parameter list, module identifier, class identifier and target method identifier.

4. The HarmonyOS application hotfix method based on ArkTS proxy according to any one of claims 1 to 3, characterized in that, Also includes: Based on the shadow execution result, a corresponding target request number is generated, and the target request number is compared with the latest request number in the service to be repaired. Based on the comparison result, it is determined whether the shadow execution result has expired. If it does not expire, the shadow execution result is written into the service to be repaired to complete the corresponding hot repair operation.

5. A HarmonyOS application hot-repair device based on ArkTS proxy, characterized in that, Applied to a target HarmonyOS application, the target HarmonyOS application includes an ArkTS layer, a Native layer, and a JSVM layer, including: The function reference generation module is used to load the service to be repaired in the target HarmonyOS application, load the patch code corresponding to the service to be repaired, determine the identification information corresponding to the method to be repaired in the service to be repaired, and generate a function reference corresponding to the method to be repaired. The object type determination module is used to determine the original method entry point corresponding to the method to be repaired based on the identification information and the function reference, replace the original method entry point with a proxy entry point, intercept business calls to the method to be repaired using the proxy entry point to obtain the corresponding call information, determine the object type of the transmitted object in the call information, and perform stream conversion on the transmitted object using the object type to obtain the converted object; the call information includes instance context, parameter list, module identifier, class identifier, and target method identifier; The callback judgment module is used to perform shadow execution on the method to be repaired based on the transformed object and the patch code, and to determine whether the ArkTS layer needs to be accessed via callback during the shadow execution process. The execution result determination module is used to determine the real business instance based on the callback request initiated by the JSVM layer if a callback access to the ArkTS layer is required, and to execute the callback using the real business instance to obtain the callback result. Based on the callback result, the corresponding shadow execution result is determined to complete the corresponding hotfix operation. Specifically, the object type determination module is used to identify the instance context and parameter list in the call information as the transmitted object, determine the object type of the transmitted object, and determine whether the object type is a target basic type. If it is the target basic type, the transmitted object is format-converted to obtain the corresponding converted object. The target basic type includes numbers, strings, and booleans. If it is not the target basic type, the object type is determined to be a target array type. If it is the target array type, each element in the transmitted object is traversed, and recursive conversion is performed based on the traversal results to obtain the corresponding converted object. Specifically, the HarmonyOS application hotfix device based on ArkTS proxy is further configured to, if not the target array type, determine whether the object type is a target type that meets a preset simple condition; the preset simple condition is that the transmitted object does not contain a target complex object prototype; if it is a target type that meets the preset simple condition, perform attribute mirroring on the transmitted object to obtain a converted object; if it is not a target type that meets the preset simple condition, wrap the transmitted object and determine the resulting wrapped object as the converted object; the wrapped object includes the instance context reference information and the class identifier; Specifically, the execution result determination module is used to send the callback request initiated by the JSVM layer to the Native layer using the target access entry corresponding to the transformed object if a callback access to the ArkTS layer is required. This allows the Native layer to determine whether the callback request is a callback request for a real business instance. If it is a callback request for a real business instance, and the transformed object is a wrapper object, then the instance context in the wrapper object is determined to be a real business instance.

6. An electronic device, characterized in that, Applied to a target HarmonyOS application, the target HarmonyOS application includes an ArkTS layer, a Native layer, and a JSVM layer, including: Memory, used to store computer programs; A processor for executing the computer program to implement the HarmonyOS application hotfix method based on ArkTS agent as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, Used to store computer programs, wherein the computer programs, when executed by a processor, implement the HarmonyOS application hotfix method based on ArkTS agent as described in any one of claims 1 to 4.

Images