Code updating method and device, equipment and storage medium

Abstract

This application discloses a code update method, apparatus, device, and storage medium, relating to the field of code compilation technology. The method includes: acquiring code files from a cross-platform project and generating an abstract syntax tree (AST) and a code dependency graph corresponding to the code files; identifying changed code units and affected code sets in the code files based on the AST and dependency graph, and obtaining an incremental code set through code trimming and compression; performing compilation processing on the incremental code set in conjunction with historical compilation results of code unaffected by the changes, generating an incremental update package adapted to the target platform; and distributing the incremental update package to the target platform for merging verification and runtime verification, completing the incremental update of the cross-platform code. This application can accurately identify code changes and their impact scope in cross-platform development scenarios, reduce redundant code participation in compilation and lower the overhead of repeated compilation, while also reducing the size of the update package and improving code compilation and update efficiency.

Description

Technical Field

[0001] This application relates to the field of code compilation technology, and in particular to a code updating method, apparatus, device and storage medium. Background Technology

[0002] With the development of cross-platform development technologies (such as Kotlin Multiplatform), the same set of business code needs to be adapted to multiple terminal platforms simultaneously, resulting in a significant increase in code size and compilation complexity. Existing compilation optimization and update solutions generally employ a full compilation approach during the compilation phase, and a full update or incremental update based on file differences during the update phase. Furthermore, the compilation paths for different platforms such as Android and iOS differ significantly in cross-platform scenarios, further increasing the overall cost of compilation and updates.

[0003] Existing technologies have significant drawbacks: incremental identification is coarse-grained, only able to judge changes at the file level, and cannot accurately identify the impact range of code structure levels; there is a lack of effective analysis and trimming mechanisms for code execution paths, and a large amount of unreachable code still participates in the compilation process; compilation artifacts cannot be safely reused based on dependencies, resulting in insufficient reuse capabilities; cross-platform adaptation costs are high, and the same logic code needs to be compiled repeatedly on different platforms, causing a large waste of computing and storage resources. Summary of the Invention

[0004] The main objective of this application is to provide a code update method, apparatus, device, and storage medium, which aims to accurately identify code changes and their impact in cross-platform development scenarios, reduce redundant code in compilation and reduce repeated compilation overhead, while reducing the size of the update package and improving code compilation and update efficiency.

[0005] To achieve the above objectives, this application proposes a code update method, the method comprising: Obtain the code files of a cross-platform project and generate the corresponding abstract syntax tree and code dependency graph for the code files; Based on the abstract syntax tree and the code dependency graph, the modified code units and the affected code set in the code file are identified, and the incremental code set is obtained through code trimming and code compression. Based on the historical compilation results of the code that has not been affected by the changes, the incremental code set is compiled to generate an incremental update package adapted to the target platform; The incremental update package is sent to the target platform for merging verification and runtime verification, thus completing the incremental update of the cross-platform code.

[0006] In one possible implementation, generating the abstract syntax tree and code dependency graph corresponding to the code file includes: Perform syntax parsing on the code file to generate an abstract syntax tree corresponding to each code unit in the code file; Based on the abstract syntax tree, function call relationships and module dependency relationships are extracted, and the association relationships between each code unit are established. Based on the relationships between the code units, a code dependency graph is constructed to represent structural dependencies.

[0007] In one possible implementation, the step of identifying modified code units and affected code sets in the code file based on the abstract syntax tree and the code dependency graph, and obtaining an incremental code set through code pruning and code compression, includes: Based on the abstract syntax tree and the code dependency graph, feature extraction processing is performed to generate a structured code fingerprint corresponding to each code unit in the code file. The structured code fingerprint includes syntax structure features, function call chain features, and interface signature features. The current version's structured code fingerprint is compared with the structured code fingerprints of historical versions to identify the changed code units, and the set of affected code is calculated through the code dependency graph. The affected code set is subjected to path analysis, cuttable code identification, and code removal. The processing results are then compressed and structurally optimized with the changed code units to form an incremental code set.

[0008] In one possible implementation, the path analysis, trimmable code identification, and code removal processing of the affected code set includes: Syntax parsing is performed on the affected code set, and multiple basic code blocks are divided using conditional branches, loop relationships, jump relationships, and function call relationships as basic block boundaries. Based on the program execution flow between the basic code blocks, a function-level control flow graph is established. Combined with the function call relationships between the basic code blocks, the function-level control flow graphs are integrated to form a global control flow graph, which is used to completely represent the code execution path topology. Starting from the basic code block at the program execution entry point, the execution path of the global control flow graph is traversed to identify all reachable paths. Code units not covered by any reachable path are identified as trimmable code, and the trimmable code is removed.

[0009] In one possible implementation, the step of traversing the execution path along the global control flow graph, starting from the basic code block at the program execution entry point, identifying all reachable paths, and determining code units not covered by any reachable path as trimmable code includes: Obtain the basic code block corresponding to the program execution entry point, and add the basic code block to the initial execution set of the path traversal. The program execution entry point includes the application startup entry point, the business entry point, and the configuration enabled module entry point. Based on the initial execution set, recursive traversal processing is performed along the global control flow graph for conditional branches, loop structures, jump logic and function calls until all reachable paths are traversed. Code units that are not covered by any reachable path are subjected to multi-dimensional screening and are identified as code that can be trimmed.

[0010] In one possible implementation, the step of combining the historical compilation results of the unaffected code with the incremental code set to generate an incremental update package adapted to the target platform includes: Perform a range filtering process on the code units in the code file to determine the code that has not been affected by the changes; For the code that has not been affected by the changes, the historical compilation results are called and the corresponding historical compilation artifacts are directly reused. The incremental code set is compiled to generate incremental compilation artifacts, and the incremental compilation artifacts are integrated with the reused historical compilation artifacts to generate an incremental update package adapted to the target platform.

[0011] In one possible implementation, the step of sending the incremental update package to the target platform for merging verification and runtime verification to complete the incremental update of cross-platform code includes: The incremental update package is transmitted to the target platform, and data integrity verification is performed on the incremental update package. The verified incremental update package is merged and integrated with the local original compilation artifacts to obtain an integrated update package. Perform runtime verification on the integrated update package, and perform update completion processing or version rollback processing based on the verification results.

[0012] Furthermore, to achieve the above objectives, this application also proposes a code updating device, which includes: The acquisition module is used to acquire the code files of cross-platform projects and generate the abstract syntax tree and code dependency graph corresponding to the code files; The trimming module is used to identify the changed code units and the affected code set in the code file based on the abstract syntax tree and the code dependency graph, and to obtain the incremental code set through code trimming and code compression. The compilation module is used to combine the historical compilation results of the code that has not been affected by the changes, perform compilation processing on the incremental code set, and generate an incremental update package adapted to the target platform; The update module is used to distribute the incremental update package to the target platform for merging verification and runtime verification, thereby completing the incremental update of cross-platform code.

[0013] In addition, to achieve the above objectives, this application also proposes a code update device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the code update method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the code update method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the code update method described above.

[0016] This application provides a code update method, apparatus, device, and storage medium. The code update method obtains the code files of a cross-platform project and generates an abstract syntax tree and a code dependency graph corresponding to the code files. Based on the abstract syntax tree and the code dependency graph, it identifies the changed code units and the set of affected code in the code files. Through code trimming and compression, it obtains an incremental code set. Combining this with the historical compilation results of the unaffected code, it performs compilation processing on the incremental code set to generate an incremental update package adapted to the target platform. The incremental update package is then distributed to the target platform for merging verification and runtime verification, completing the incremental update of cross-platform code. This enables accurate identification of code changes and their impact scope in cross-platform development scenarios, reduces redundant code in compilation and lowers the overhead of repeated compilation, while also reducing the size of the update package and improving code compilation and update efficiency. Attached Figure Description

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

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

[0019] Figure 1This is a flowchart illustrating the code update method of this application in Embodiment 1. Figure 2 This is a flowchart illustrating Embodiment 2 of the code update method of this application; Figure 3 This is a schematic diagram of the module structure of the code update device according to an embodiment of this application; Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the code update method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or code update system capable of implementing the above functions. The following description uses a code update system as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, embodiments of this application provide a code update method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the code update method of this application, provided in Embodiment 1.

[0025] In this embodiment, the code update method includes steps S11 to S14: Step S11: Obtain the code file of the cross-platform project and generate the abstract syntax tree and code dependency graph corresponding to the code file; It's important to note that cross-platform projects refer to software development projects where the same set of business logic can adapt to multiple different terminal operating systems. These projects employ source code sharing, intermediate artifact reuse, and platform-specific compilation logic, making it impossible to run directly across operating systems using the same set of machine code binary files. The project is divided into shared code modules and platform-specific code modules. The shared code modules only contain general business logic, data operations, and general algorithms, without calling platform-specific system interfaces. The platform-independent pre-compiled artifacts and intermediate compiled files generated by the shared code modules can be shared across multiple platform compilation processes. Each platform then combines its own proprietary code to complete localized compilation. KotlinMultiplatform, Flutter, and Qt are commonly used development frameworks under this architecture. For example, in a client project developed using KotlinMultiplatform, the general business logic is concentrated in the shared code module, while Android and iOS each have their own platform-specific code.

[0026] Furthermore, code files refer to source code documents written by developers that carry the business logic of the program; abstract syntax trees refer to structured data models that have stripped away the code text format and represent the code syntax hierarchy, statement logic and semantic structure with a tree node structure; code dependency graphs refer to topological graphs built with code units as nodes and relationships as directed edges, used to globally visualize and represent the call and dependency links of the entire project's code.

[0027] In one possible implementation, the system reads the full source code files of the project based on the Kotlin Multiplatform framework; in another possible implementation, the system pulls the code files of shared modules, Android-specific modules, and iOS-specific modules in batches, and completes the parsing and modeling step by step.

[0028] Specifically, the system calls the source code parsing engine to read all the project's code files sequentially, performs lexical analysis and syntax parsing file by file according to the programming language syntax rules, breaks down various statements, functions, and class nodes, and constructs an abstract syntax tree corresponding to each file; extracts the calling relationships between functions and the import dependencies between different code modules from the abstract syntax tree, and builds the overall project's code dependency graph based on the extracted related data through a topology graphing algorithm.

[0029] For example, for a cross-platform app project developed using Kotlin Multiplatform, the system reads all .kt code files under the common shared module, Android module, and iOS module respectively, parses them one by one to generate the corresponding abstract syntax tree, and then generates the code dependency graph of the entire project based on the inter-module references and cross-module function call data.

[0030] Step S12: Based on the abstract syntax tree and the code dependency graph, identify the changed code units and the set of affected code in the code file, and obtain the incremental code set through code trimming and code compression. It should be noted that: a code unit refers to an independent code component with functions, classes, and interfaces as the smallest unit of division; a modified code unit refers to a code unit whose syntax, function implementation, or interface definition has changed compared to the historical baseline version; an affected code set refers to the set of all related code that needs to be compiled synchronously due to changes in modified code units or the existence of call relationships, based on the code dependency graph; code pruning refers to the process of filtering and removing redundant code that cannot be called and executed during runtime through execution path analysis; code compression refers to the process of simplifying the format of the pruned and effective code, removing invalid comments, and optimizing the code structure; and the incremental code set refers to the smallest set of code to be compiled after pruning and optimization, containing only the modified and necessary affected code.

[0031] The purpose of this step is to refine the identification of changes from coarse-grained file-level changes to precise code unit-level changes, eliminating invalid and redundant code and reducing the size of the code to be compiled. In one possible implementation, the system locates changed code units using structured code fingerprint comparison; in another, the system initially filters candidate changed code based on line-of-speech differences, followed by secondary verification using a syntax tree. Furthermore, the affected code set is range-finding using a dependency closure algorithm to ensure that all code with dependencies is included in the statistical scope.

[0032] Specifically, the system relies on the abstract syntax tree to extract three types of feature data: syntax structure, function call chain, and interface signature to generate structured code fingerprints for each code unit. The current version fingerprint is compared with the fingerprints of historical versions using a hash operation. If the fingerprints are inconsistent, it is determined that the code unit has been changed. The code dependency graph is traversed from the changed code unit as the starting point to calculate the complete set of affected code. A global control flow graph is constructed for the set of affected code. The entire execution path is traversed based on the application startup entry point and business entry point. The code that can be trimmed and removed is filtered out that is not covered by the reachable path. Finally, redundant comments are removed and invalid fields are simplified to complete the compression optimization of the remaining valid code, and the results are summarized to form an incremental code set. For example, if a developer modifies a utility function within the common shared module, the system locates the modified code unit by fingerprint comparison, then finds the relevant code that calls the function on both Android and iOS based on the dependency graph, forming an affected code set. Through control flow path analysis, the system removes the backup branch code that cannot be triggered to execute within the set, and after compression and optimization, obtains the final incremental code set.

[0033] Step S13: Combine the historical compilation results of the code that has not been affected by the changes, perform compilation processing on the incremental code set to generate an incremental update package adapted to the target platform; It should be noted that "unaffected code" refers to all code units that are neither part of the changed code unit nor within the scope of the affected code set, and whose code logic remains unchanged; "historical compilation results" refers to the compilation artifacts such as binary artifacts and library files generated after the compilation of previous versions of the project; "incremental compilation processing" refers to a compilation method that only compiles the incremental code set and does not compile the entire project as a whole; "target platform" refers to the Android system platform or iOS system platform, etc.; "incremental update package" refers to a lightweight upgrade installation data package that only contains the compilation artifacts corresponding to the incremental code and is used for partial upgrades on the terminal.

[0034] The purpose of this step is to reuse historically compiled files with stable, unmodified code, avoiding redundant compilation and only compiling the changed code to generate lightweight upgrade packages adapted to different systems. In one possible implementation, historical compilation artifacts of shared code modules can be directly reused on both Android and iOS platforms; in another possible implementation, platform-specific code can only reuse historical compilation artifacts on its corresponding single target platform. Furthermore, the system stores historical compilation artifacts by platform category and sets up artifact version indexes for easy retrieval.

[0035] Specifically, the system uses the code dependency graph and fingerprint comparison results as filtering conditions to select all code units that have not been affected by the changes. Based on the code unit index, it reads from the local artifact repository and directly loads the corresponding historical compilation artifacts. It calls the platform-specific compilation chain to perform compilation operations only on the incremental code set to generate incremental compilation artifacts. The incremental compilation artifacts and the reused historical compilation artifacts are integrated according to the platform packaging rules and packaged into corresponding incremental update packages for Android and iOS respectively. For example, in a cross-platform project, most of the business code remains unchanged. The system directly reuses the historical compiled files of the entire unmodified code and only compiles the previously generated incremental code set using the Android compilation chain and the iOS compilation chain respectively, packaging them into an Android APK differential upgrade package and an Apple IPA incremental update package.

[0036] Step S14: The incremental update package is sent to the target platform for merging verification and running verification to complete the incremental update of the cross-platform code.

[0037] It should be noted that "deployment" refers to the transmission process of the incremental update package to the corresponding terminal device through the backend service link; "merge verification" refers to the process in which the terminal, after receiving the update package, first verifies the integrity of the data packet, and then merges and integrates the incremental compilation artifacts with the local original compilation artifacts; "run verification" refers to the verification operation in which the terminal starts the application to execute preset test cases and verify whether the program can run normally after the artifact merging is completed; and "version rollback" refers to the fallback logic of canceling the update and restoring the original compilation artifacts before the update when verification is abnormal.

[0038] The purpose of this step is to securely complete a partial upgrade on the terminal, mitigating program anomalies caused by upgrade failure through verification and rollback mechanisms. In one possible implementation, an MD5 checksum is used to verify the integrity of the update package; in another, a CRC cyclic redundancy check algorithm is used to verify the integrity of the update package data. Furthermore, the update is only confirmed to be effective if both integrity verification and runtime verification pass; any failure in either stage will trigger a version rollback.

[0039] Specifically, the system pushes incremental update packages to the target terminal via a backend push link. The terminal reads the update package's verification field and compares it with the original verification code to complete the integrity verification. If the verification is successful, the incremental compilation artifacts within the update package are split and merged with the historical compilation artifacts stored on the local disk to form an integrated program package. The terminal launches the application and executes preset functional test cases to complete the runtime verification. If the verification is successful, the new version of the program is saved; if the verification fails, the newly added incremental artifacts are automatically deleted, and the program is rolled back to the original version before the upgrade. For example, the server sends the iOS incremental update package to the Apple mobile client. The client first verifies the installation package for integrity using the MD5 value, then merges the newly added compiled files within the package with the existing local program files, launches the app to complete the basic functional runtime test, and if no errors are reported, the update is complete. If a crash occurs, the app is automatically rolled back to the previous usable version.

[0040] This embodiment achieves structured code modeling by constructing an abstract syntax tree and code dependency graph from cross-platform source code. It accurately locates the scope of changes at the code unit level using structured fingerprints, and eliminates unreachable redundant code through execution path analysis of the control flow graph, forming a lightweight incremental code set. Unmodified code directly reuses historical compilation artifacts, avoiding repeated cross-platform compilation. Only the streamlined incremental code is compiled to generate a lightweight incremental update package. The terminal then securely completes the version upgrade through update package verification, runtime verification, and an exception rollback mechanism. Compared to the traditional full compilation + full update solution, this approach refines the granularity of change identification and trims invalid code at the code structure level, significantly reducing the amount of code to be compiled, effectively improving overall project compilation efficiency and reducing upgrade package size. Furthermore, the shared code cross-platform artifact reuse mechanism reduces resource consumption caused by repeated compilation on both Android and iOS platforms. Simultaneously, the terminal's multi-layered verification and rollback strategy effectively avoids application crashes caused by incremental update errors, balancing compilation efficiency, upgrade costs, and software update stability.

[0041] In one feasible implementation, generating the abstract syntax tree and code dependency graph corresponding to the code file includes: Step S21: Perform syntax parsing processing on the code file to generate an abstract syntax tree corresponding to each code unit in the code file; It should be noted that syntax parsing refers to the process of converting linear text into structured data by performing lexical and syntactic analysis on the text strings of a code file according to the syntax rules of the programming language. A code unit refers to an independent logical unit of code within a code file, with classes, functions, methods, and interfaces as the smallest unit of division. In one possible implementation, the system uses a recursive descent parser to perform syntax parsing; in another possible implementation, the system uses the LALR parsing engine. Furthermore, each node of the abstract syntax tree carries a unique identifier, syntax type, and location information, facilitating precise location of the code unit.

[0042] Specifically, the system calls a cross-platform syntax parsing component to read the text content of the code file. First, lexical analysis is performed to break down the code text into basic lexical units such as keywords, identifiers, constants, and operators. Then, syntax analysis is performed to combine and match these lexical units according to preset syntax rules, constructing a tree structure representing the code's logical hierarchy and semantic structure. Finally, an abstract syntax tree is generated for each independent code unit. For example, the system performs syntax parsing on utility class code files in a cross-platform project, breaking them down into code units such as class definitions, member variables, and multiple function methods. For each function unit, an abstract syntax tree containing statement logic, parameter structure, and return value structure is generated.

[0043] Step S22: Extract function call relationships and module dependency relationships based on the abstract syntax tree, and establish the association relationships between each code unit; It should be noted that function call relationship refers to the execution call and callback relationship of the current function to other functions in the code unit; module dependency relationship refers to the import reference, inheritance implementation, and interface call relationship between different code files and different functional modules; and relationship refers to the structured correspondence used to represent the calling, dependency, and reference logic between code units.

[0044] The purpose of system execution relationship extraction is to clarify the interconnected logic between code segments and identify the scope of other code affected by changes to a single code unit. In one possible implementation, the system extracts function call relationships by traversing the call nodes of the abstract syntax tree; in another, it extracts module dependencies by parsing import and include declarations. Furthermore, the relationships include call direction and dependency strength identifiers for subsequent precise calculation of the affected code scope.

[0045] Specifically, the system performs a depth-first traversal of the abstract syntax tree corresponding to each code unit, identifies function call nodes and records the correspondence between callers and callees, forming function call relationships; it also identifies module import, class inheritance, and interface implementation nodes and records the dependency relationships between modules, forming module dependency relationships; these two types of relationships are then uniformly organized and bound to unique identifiers for each code unit, establishing complete associations between code units. For example, the system traverses the abstract syntax tree of the login function code unit, extracts the function call relationships between the login function and the encryption function and the network request function, as well as the module dependency relationships between the login module and the network module and the utility module, establishing corresponding associations between each code unit.

[0046] Step S23: Based on the association between the code units, construct a code dependency graph to represent structural dependencies.

[0047] It should be noted that structural dependencies refer to stable topological dependencies between code units formed by calls, references, and inheritance. In one possible implementation, the code dependency graph is constructed using a directed acyclic graph structure; in another, it is constructed using a hierarchical topological graph structure. Furthermore, the code dependency graph supports cross-module and cross-platform association display, and can uniformly represent global dependencies between shared code and platform-specific code.

[0048] Specifically, the system maps all code units to topological nodes, and maps function call relationships and module dependencies between code units to directed topological edges. It then combines and arranges nodes and directed edges according to preset topological graph construction rules, eliminates circular dependency anomalies, and performs structural optimization, ultimately generating a code dependency graph representing global structural dependencies. For example, the system uses shared code units, Android platform code units, and iOS platform code units in a cross-platform project as topological nodes, and function calls and module dependencies as directed edges, integrating them to construct a global code dependency graph covering the entire project and spanning multiple platforms.

[0049] This embodiment generates an abstract syntax tree by performing standardized syntax parsing on the code file, realizing the transformation of source code from text to structured data. Then, based on the abstract syntax tree, it accurately extracts two core relationships: function calls and module dependencies. Finally, it constructs a global code dependency graph with a topological structure, transforming complex and scattered cross-platform code logic into a clear and computable global dependency model. This model can accurately represent the linkage relationship between code units, providing solid structural support for subsequent structured code fingerprint generation, changed code identification, affected code range calculation, code trimming, and incremental compilation, effectively improving the accuracy of cross-platform code change identification and the efficiency of compilation processing.

[0050] Based on this, embodiments of this application provide a code update method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the code update method in this application.

[0051] In one feasible implementation, the step of identifying modified code units and affected code sets in the code file based on the abstract syntax tree and the code dependency graph, and obtaining an incremental code set through code trimming and code compression, includes: Step S31: Based on the abstract syntax tree and the code dependency graph, perform feature extraction processing to generate a structured code fingerprint corresponding to each code unit in the code file. The structured code fingerprint includes syntax structure features, function call chain features, and interface signature features. It should be noted that feature extraction processing refers to the quantitative processing operation of extracting the core semantic and structural information of code from the abstract syntax tree and code dependency graph; structured code fingerprint refers to the fixed-length feature code used to uniquely identify the logic and structure of code units, which can be used to accurately compare whether the code has been changed; syntax structure features refer to the structural features of statements, expressions, branches and loops within a code unit; function call chain features refer to the sequence and hierarchical features of functions called directly or indirectly by a code unit; and interface signature features refer to the interface identification features composed of function name, parameter type, and return value type.

[0052] The purpose of this step is to transform the semantics and structure of code units into fingerprint codes that can be quickly compared, thereby achieving accurate identification of code changes. In one possible implementation, the system hashes the three types of extracted features separately and then concatenates them to form the final fingerprint; in another possible implementation, the system combines the three types of features and performs a unified hash operation to generate a structured code fingerprint. Furthermore, the structured code fingerprint is unaffected by formatting changes such as code comments, spaces, and line breaks; it only focuses on changes in the actual logic and structure of the code.

[0053] Specifically, the system traverses the abstract syntax tree to extract statement type, branch level, and operation logic to obtain syntax structure features; traverses the code dependency graph to extract function call identifiers and call order to obtain function call chain features; extracts function parameter list, return value, and modifier information to obtain interface signature features; serializes and normalizes the three types of features, and generates a fixed-length structured code fingerprint through hash operation.

[0054] For example, the system parses the abstract syntax tree of the user login function, extracts if-else branches and parameter validation logic as syntax structure features, extracts calls to encryption functions and network request functions as function call chain features, and extracts function names, string parameters, and boolean return values ​​as interface signature features. The system then combines and hashes these three types of features to generate a unique structured code fingerprint for the function.

[0055] Step S32: Compare the current version's structured code fingerprint with the structured code fingerprint of the historical version to determine the changed code units, and calculate the set of affected code through the code dependency graph; It should be noted that the comparison process refers to the operation of matching and comparing the current version code fingerprint with the historical baseline version fingerprint bit by bit; the changed code unit refers to the code unit whose structured code fingerprint has changed and whose actual logic has been modified; the affected code set refers to the set of all code units that may be affected by the changes due to their call or dependency relationships and need to be recompiled.

[0056] The purpose of this step is to accurately locate the modification points and automatically identify all affected areas based on dependencies, avoiding omissions of related code. In one possible implementation, the system uses character-by-character string comparison to perform fingerprint comparison; in another, it uses direct hash value equality judgment. Furthermore, the affected code set is calculated using dependency transitive traversal, covering all related code from direct calls and multi-level indirect calls.

[0057] Specifically, the system reads the structured code fingerprints of each code unit in the historical version and the current version, performs an equivalence comparison operation, and marks the code unit as changed if the fingerprints are inconsistent. Starting from the changed code unit, the system performs directed traversal and dependency closure calculation in the code dependency graph, recursively collects all calling, dependent, and associated code units, and summarizes them to form the affected code set.

[0058] For example, the system compares and finds that the structured fingerprint of the password encryption function has changed, marking it as a changed code unit; then it traverses all login functions, registration functions, and password modification functions that call the encryption function in the code dependency graph, and includes all these functions in the affected code set.

[0059] Step S33: Perform path analysis, cuttable code identification, and code removal on the affected code set. Compress and optimize the structure of the processing results and the changed code units to form an incremental code set.

[0060] It should be noted that path analysis refers to topological traversal analysis based on the control flow graph to analyze the actual executable path of the program; tailorable code identification refers to the operation of identifying redundant code units that can never be executed by the program; code removal processing refers to the operation of removing tailorable code from the affected code set; compression and structure optimization refers to the process of removing invalid comments, blank lines, redundant fields and simplifying the code structure.

[0061] The purpose of this step is to eliminate unreachable redundant code, significantly reduce the size of the code to be compiled, and achieve lightweight incremental compilation. In one possible implementation, the system performs path analysis starting from the application startup entry point; in another possible implementation, the system performs path analysis starting from the business module entry point. Additionally, the code to be trimmed includes invalid code such as conditional branches not covered by any reachable paths, spare functions, and obsolete module code.

[0062] Specifically, the system performs syntax parsing on the affected code set and divides it into basic code blocks, constructing a global control flow graph. Starting from the program's entry point, it recursively traverses all reachable paths, marking uncovered code as eligible for trimming and removing it. The trimmed, valid code is merged with the modified code units, and compression optimizations are performed, including removing comments, simplifying formatting, and standardizing the structure, ultimately forming an incremental code set. For example, the system constructs a control flow graph for the login-related affected code set, identifies a deprecated third-party login branch that will never be executed after traversing reachable paths, identifies it as eligible for trimming and removes it, and then performs further compression and simplification on the remaining code to form the final incremental code set.

[0063] This embodiment generates a structured code fingerprint containing three types of information: syntax, calls, and interfaces, based on a syntax tree and dependency graph, achieving accurate code change identification unaffected by formatting. Then, it automatically calculates the full range of affected code through dependency graph traversal, ensuring no code related to the change is missed. Furthermore, it identifies and removes unreachable redundant code through control flow path analysis, ultimately forming a minimal incremental code set. Compared to traditional file-level change identification methods, this solution can refine the change granularity to the code unit level, significantly eliminating invalid and redundant code, significantly reducing the data volume and computational overhead of subsequent incremental compilation, while improving the accuracy and efficiency of cross-platform project compilation and updates.

[0064] In one feasible implementation, the path analysis, trimmable code identification, and code removal processing of the affected code set includes: Step S41: Perform syntax parsing on the affected code set, and divide the code into multiple basic blocks using conditional branches, loop relationships, jump relationships, and function call relationships as basic block boundaries; It should be noted that syntax parsing refers to lexical and syntactic analysis of the affected code set to identify the processing of internal statement structure and execution logic; conditional branching refers to logical branching statements such as if, else, and switch; loop relationships refer to loop execution statements such as for, while, and do-while; jump relationships refer to statements such as break, continue, return, and goto that change the program execution order; function call relationships refer to the jump logic of the current code block calling other functions; basic block boundaries refer to the segmentation nodes used to separate continuously executed statements; and a basic code block refers to the smallest unit of code execution in which internal statements are executed sequentially without branching or jumping.

[0065] The purpose of this step is to break down complex logic code into analyzable and traversable standard execution units, providing basic data units for subsequent control flow graph construction. In one possible implementation, the system uses jump instructions as the end boundary of the basic block; in another, it uses function call instructions as the dividing boundary. Furthermore, each basic code block contains only sequentially executed statements, without any branching, looping, jumping, or call-type interruption logic, ensuring a unique execution flow.

[0066] Specifically, the system re-parses the affected code set, identifying four types of statements line by line: conditional branches, loops, jumps, and function calls, and marking them as basic block boundaries. Based on these boundaries, the system segments the sequentially executed instruction sequences into multiple independent, structurally sound basic code blocks, assigning each basic code block a unique identifier for subsequent tracing. For example, when parsing the affected code of the login verification function, the system identifies if branch boundaries and return jump boundaries, dividing the function into parameter validation basic blocks, account determination basic blocks, exception return basic blocks, and successful execution basic blocks.

[0067] Step S42: Based on the program execution flow between each of the basic code blocks, establish a function-level control flow graph, and combine the function call relationships between each of the basic code blocks to integrate the function-level control flow graphs into a global control flow graph, which is used to completely represent the code execution path topology. It should be noted that program execution flow refers to the sequential relationship of jumps, execution, and progression between basic code blocks; function-level control flow graph refers to the local topology graph formed by connecting all basic code blocks within a single function according to the execution flow; function call relationship refers to the association relationship of mutual call jumps between basic code blocks of different functions; global control flow graph refers to the complete execution path topology graph that integrates all internal function flows and cross-function call relationships and covers the entire affected code set; code execution path topology refers to the structured topology model used to represent all possible execution routes, branch directions, and call chains of the program.

[0068] The purpose of this step is to construct a global, visual, and traversable execution path model, providing structural support for reachability path analysis and the identification of customizable code. In one possible implementation, the system uses a directed graph to construct the function-level control flow graph; in another possible implementation, the system uses a hierarchical graph to construct the function-level control flow graph. Furthermore, the global control flow graph includes execution jump relationships across functions and modules, fully covering the entire execution logic of the affected code set.

[0069] Specifically, the system uses basic code blocks as nodes and program execution flow as directed edges to construct a function-level control flow graph for each function. Then, based on the calling relationship between functions, the control flow graph of the called function is connected to the exit node of the calling function. All function-level control flow graphs are then assembled sequentially to complete topology integration and finally generate a global control flow graph that covers all affected code.

[0070] For example, the system constructs function-level control flow graphs for the login function, encryption function, and network request function respectively. Then, based on the relationship between the login function calling the encryption function and the encryption function calling the network request function, the three graphs are sequentially linked and integrated to form a complete global control flow graph for the login module.

[0071] Step S43: Starting from the basic code block at the program execution entry point, traverse the execution path along the global control flow graph, identify all reachable paths, determine the code units not covered by any reachable path as trimmable code, and remove the trimmable code.

[0072] It should be noted that the program execution entry point refers to the starting execution position of the program during actual runtime, such as the application startup entry point, business module entry point, and configuration-enabled module entry point; execution path traversal refers to the recursive traversal operation that starts from the starting node and visits all reachable nodes in sequence along the directed edges of the global control flow graph; reachable path refers to the path that can be triggered for execution during the actual program execution; code unit not covered by any reachable path refers to code logic that will never be executed regardless of the input parameters or the branch triggered; code removal processing refers to the processing operation of removing trimmed code from the affected code set and not participating in subsequent compilation.

[0073] The purpose of this step is to accurately identify and remove invalid and redundant code, minimizing incremental code size and improving compilation efficiency. In one possible implementation, the system uses a depth-first search algorithm to traverse the execution path; in another, it uses a breadth-first search algorithm. Furthermore, the code to be trimmed includes obsolete branches, disabled modules, dead code, and redundant commented blocks; removing these will not affect program functionality.

[0074] Specifically, the system locates the basic code block corresponding to the program execution entry point and adds it to the initial traversal set. It then recursively traverses all reachable nodes along the global control flow graph using a depth-first traversal method, marking all reachable code units. After the traversal is completed, unmarked code units are determined to be trimmed code, which are then directly removed from the affected code set and a trimming log is recorded, thus completing the code trimming process.

[0075] For example, the system traverses the global control flow graph starting from the login function entry point. None of the paths cover a piece of old, deprecated third-party login code. This piece of code is identified as code that can be trimmed and removed, further reducing the size of the affected code set.

[0076] This embodiment breaks down the affected code into standard code blocks, constructs a two-level control flow graph at the function level and the global level, and forms a complete and computable execution path topology model. Then, starting from the actual execution entry point, it traverses all reachable paths to accurately identify and remove redundant code that can never be executed. By pruning and eliminating invalid logic, the amount of incremental code data can be significantly reduced, useless code can be avoided from participating in compilation, and the computational overhead and time consumption of cross-platform compilation can be significantly reduced, while ensuring the conciseness and effectiveness of incremental code.

[0077] In one feasible implementation, the step of traversing the execution path along the global control flow graph, starting from the basic code block at the program execution entry point, identifying all reachable paths, and determining code units not covered by any reachable path as trimmable code includes: Step S51: Obtain the basic code block corresponding to the program execution entry point, and add the basic code block to the initial execution set of the path traversal. The program execution entry point includes the application startup entry point, the business entry point, and the configuration enabled module entry point. It should be noted that the program execution entry point refers to the starting position where the code logic begins to execute during the actual operation of the program; the basic code block refers to the smallest code unit that executes sequentially without branching or jumping; the initial execution set refers to the temporary data set used to store the starting node of the path traversal, serving as the starting point data for the global control flow graph traversal; the application startup entry point refers to the entry function executed when the application is initialized and started; the business entry point refers to the starting execution position when a single business module is triggered; and the configuration-enabled module entry point refers to the starting execution position of a module that is dynamically enabled based on the running configuration and environment parameters.

[0078] The purpose of this step is to determine the valid starting point of path traversal, ensuring that all reachable path analysis begins from a truly triggerable execution location, thus improving the accuracy of identifying customizable code. In one possible implementation, the system obtains the program execution entry point by parsing the project configuration file; in another, the system locates the execution entry point by retrieving the main function and startup function markers from the abstract syntax tree. Furthermore, the initial execution set can accommodate multiple entry points simultaneously, supporting parallel traversal of multiple entry points and modules.

[0079] Specifically, the system reads the application startup entry point, business entry point, and configuration-enabled module entry point from project configuration information, startup scripts, and function tags. Based on the entry function, it locates the corresponding basic code block in the global control flow graph and adds all located basic code blocks to the initial execution set for path traversal, completing the initialization of the starting point before traversal. For example, if the system locates the basic code blocks corresponding to the user center business entry function and the application initialization startup entry function, it adds both basic code blocks to the initial execution set simultaneously as the starting node for path traversal.

[0080] Step S52: Based on the initial execution set, perform recursive traversal processing of conditional branches, loop structures, jump logic and function calls along the global control flow graph until all reachable paths have been traversed. It should be noted that recursive traversal refers to an iterative traversal method that starts from the initial node, visits subsequent nodes layer by layer, and automatically tracks all branches, loops, jumps, and call paths; conditional branching refers to the branch execution logic generated by if / else / switch; loop structure refers to the loop execution logic composed of for / while; jump logic refers to the logic that changes the execution flow, such as return / break / continue; function call refers to the associated logic that jumps from the current code block to other functions for execution; and reachable path refers to the code path that can actually trigger execution when the program runs.

[0081] The purpose of this step is to fully cover all runnable logic and accurately mark all executable code units, providing a basis for subsequent filtering of unreachable code. In one possible implementation, the system uses a depth-first recursive traversal to perform path traversal; in another possible implementation, the system uses a breadth-first recursive traversal. Furthermore, recursive traversal automatically skips repeatedly visited nodes, avoiding infinite traversal caused by loop structures and ensuring execution efficiency.

[0082] Specifically, the system starts from the basic code blocks in the initial execution set and recursively traverses the directed edges of the global control flow graph, sequentially entering conditional branches, loop structures, jump logic, and the subsequent basic code blocks corresponding to function calls. Each node visited is marked as reachable, and the system recursively traces all branch links until no new nodes are accessible, ultimately completing the traversal and marking of all reachable paths. For example, the system recursively traverses from the login business entry point, sequentially entering the account verification branch, password encryption call, exception return jump, and loop retry logic, covering all triggerable execution paths and completing node marking.

[0083] Step S53: Perform multi-dimensional screening and judgment on code units that are not covered by any reachable path and determine them as cuttable code.

[0084] It's important to clarify that code units not covered by any reachable path refer to code logic that can never be executed regardless of changes in program input, branch triggers, or environment configuration. Multi-dimensional screening and judgment refers to the logic that comprehensively verifies code removability from multiple perspectives, including reachability, business validity, configuration status, and module activation status. Cuttable code refers to redundant code units that do not affect program functionality, have no execution significance, and can be safely removed. The purpose of this step is to avoid mistakenly deleting valid code and ensure that all removed code is absolutely invalid and redundant.

[0085] In one possible implementation, the multi-dimensional filtering judgment includes reachability verification, module activation status verification, business configuration status verification, and obsolescence flag verification. In another possible implementation, the multi-dimensional filtering judgment combines code comments, version history, and configuration files for comprehensive judgment. Furthermore, the code that can be trimmed after multi-dimensional filtering judgment will not have any negative impact on program functionality, stability, or operational logic when removed.

[0086] Specifically, the system traverses all code units, filters out those not marked with reachable paths, and sequentially performs multi-dimensional checks including reachability verification, enable status verification, business configuration verification, and obsolescence status verification. Code units that are confirmed to be useless across all dimensions are ultimately identified as code that can be trimmed. For example, the system identifies a piece of old third-party login code that is not covered by any path. After multi-dimensional checks, it is confirmed that the module has been configured to be disabled and the business is obsolete, and this piece of code is ultimately identified as code that can be trimmed.

[0087] This embodiment initializes the traversal set from the actual program execution entry point, recursively traverses all branches, loops, jumps, and call chains along the global control flow graph, accurately marks all reachable code, and then strictly confirms the validity of unreachable code through multi-dimensional screening and judgment, finally accurately locating the code that can be trimmed. This method can completely eliminate dead code, obsolete code, and code of unenabled modules that can never be executed, significantly reduce the incremental code size, reduce cross-platform compilation overhead, improve compilation speed and the lightweightness of update packages, while ensuring that the code trimming process is safe and reliable and will not affect core business functions.

[0088] In one feasible implementation, the step of combining the historical compilation results of the unaffected code with the incremental code set to generate an incremental update package adapted to the target platform includes: Step S61: Perform a range filtering process on the code units in the code file to determine the code that has not been affected by the changes; It should be noted that scope filtering refers to the process of classifying and dividing all code units based on the scope of code changes and dependency propagation relationships. A code unit refers to an independent logical unit within a project, defined at the smallest granularity as a function, class, interface, or method. Unaffected code refers to stable code units that are neither changed code units nor within the affected code set, and whose code structure, logic, and dependencies have remained unchanged. In one possible implementation, the system performs scope filtering based on the results of structured code fingerprint comparison; in another possible implementation, the system performs scope filtering in conjunction with the scope of change impact in the code dependency graph.

[0089] In addition, the code that is not affected by the changes includes cross-platform shared code and code specific to each target platform. Different types of code will be distinguished and marked during the screening process.

[0090] Specifically, the system retrieves the identified changed code unit identifiers and the list of affected code sets. It then matches each code unit in the entire code file against this range, excluding those already marked as changed or affected. The remaining unaffected code units are then marked and identified as unaffected. For example, in a cross-platform project where only login verification-related code units have been modified, the system uses comparison and filtering to identify unaffected code units such as the user information module, theme configuration module, and basic tools module as unaffected.

[0091] Step S62: Perform historical compilation result call processing on the code that has not been affected by the changes, and directly reuse the corresponding historical compilation artifacts; It should be noted that historical compilation result retrieval processing refers to the operation of reading and loading valid file data generated by historical versions from local or cloud compilation artifact repositories; historical compilation artifacts refer to the binary files, intermediate code, library files, resource mapping files, and other directly usable compilation output results generated after the code that has not been affected by changes has been compiled in historical stable versions; direct reuse means that existing stable compilation artifacts can be used directly without performing compilation, parsing, and optimization operations on the source code again.

[0092] The purpose of the system's historical compilation result retrieval process is to avoid repeatedly executing the compilation process on stable, unmodified code, thus significantly saving compilation computational resources and time. In one possible implementation, the system retrieves historical compilation artifacts from a local cache repository; in another, it retrieves the corresponding version's historical compilation artifacts from a cloud-based versioned repository. Furthermore, historical compilation artifacts are indexed and stored according to unique code unit identifiers, enabling precise matching and ensuring a one-to-one correspondence between reused artifacts and source code.

[0093] Specifically, the system uses the unique identifier and version information of the unaffected code to perform an index search and match in the compilation artifact repository, locates the historical compilation artifact of the corresponding code unit, and loads the artifact into the compilation workspace via a load instruction, completing the artifact reuse process that does not require code compilation. For example, for identified unaffected basic tool code, the system searches the repository using its unique identifier and directly calls the historical compilation artifacts in .class and .so formats generated by the previous version, without performing any compilation operations.

[0094] Step S63: Perform compilation processing on the incremental code set to generate incremental compilation artifacts, and perform integration processing on the incremental compilation artifacts and reused historical compilation artifacts to generate an incremental update package adapted to the target platform.

[0095] It should be noted that compilation processing refers to the process of calling the corresponding platform's compilation toolchain to perform syntax parsing, optimization, linking, and generating executable files for the incremental code set; incremental compilation artifacts refer to the new compiled files generated after compiling only the changed and affected incremental code; integration processing refers to the operation of merging, sorting, verifying, and encapsulating the incremental compilation artifacts and the reused historical compilation artifacts according to module structure and dependencies; target platform refers to the system platform that the incremental update package is ultimately adapted to run on, including Android and iOS platforms; incremental update package refers to a lightweight cross-platform update installation package that contains only the changed code artifacts and reused stable artifacts.

[0096] The purpose of this step is to compile only the necessary code, integrate the old and new artifacts to generate a minimal update package, and achieve efficient cross-platform updates. In one possible implementation, the Javac and D8 compilation toolchains are used to generate incremental compilation artifacts for the Android target platform; in another possible implementation, the Clang and Swiftc compilation toolchains are used to generate incremental compilation artifacts for the iOS target platform. Furthermore, the integration process performs dependency checks and format standardization to ensure seamless compatibility between the incremental and historical artifacts.

[0097] Specifically, the system calls the compilation toolchain corresponding to the target platform to perform compilation, optimization, and linking operations on the incremental code set to generate incremental compilation artifacts. The incremental compilation artifacts are then merged with the reused historical compilation artifacts according to the project directory structure and dependencies, deduplicated, and verified. The artifacts are then packaged according to the package format specifications of each target platform to finally generate a lightweight incremental update package adapted to the corresponding platform.

[0098] For example, the system only compiles the incremental code set related to login to generate new artifacts, which are then integrated with the reused historical artifacts and packaged into Android incremental APK packages and iOS incremental IPA packages respectively.

[0099] This embodiment uses range filtering to accurately locate code unaffected by changes, directly reusing its historical compilation artifacts to avoid recompiling the entire codebase. It only performs compilation processing on the streamlined incremental code set, and then efficiently integrates the incremental artifacts with the reused artifacts to generate lightweight incremental update packages adapted to different target platforms. Compared with the traditional full compilation method, it significantly reduces the amount of compilation computation, shortens cross-platform compilation time, and reduces the size of the update package, while ensuring the stability and compatibility of the artifacts, realizing an efficient, lightweight, and low-cost compilation and update process for cross-platform projects.

[0100] In one feasible implementation, the step of distributing the incremental update package to the target platform for merging verification and runtime verification to complete the incremental update of cross-platform code includes: Step S71: Transmit the incremental update package to the target platform and perform data integrity verification on the incremental update package; It should be noted that an incremental update package refers to a lightweight update file package containing only the compiled artifacts of the changed code and reused historical compiled artifacts; the target platform refers to the system platform such as Android or iOS where the incremental update package needs to be deployed and run; data integrity verification processing refers to the verification operation performed on the received update package to ensure data consistency, file integrity, and tamper-free operation. The purpose of this step is to ensure that the update package is not lost, damaged, or maliciously tampered with during network transmission, thus guaranteeing the security and reliability of subsequent update processes. In one possible implementation, the system uses the MD5 hash algorithm to perform data integrity verification processing; in another possible implementation, the system uses the SHA-256 hash algorithm to perform data integrity verification processing. Furthermore, the data integrity verification processing is completed offline on the target platform, without relying on the network for verification.

[0101] Specifically, the system sends the incremental update package for the corresponding platform to the target platform terminal via a network push channel. After receiving the update package, the terminal reads the built-in checksum, recalculates the checksum for the entire update package file using the same hash algorithm, and compares the calculated result with the original checksum. If they match, the verification is considered successful; otherwise, the update package is considered corrupted, and the update process is terminated. For example, the server sends the incremental update package to an Android mobile terminal. The terminal recalculates the file hash value locally using the MD5 algorithm. If the hash value matches exactly with the checksum sent by the server, the data integrity verification is considered successful.

[0102] Step S72: Merge and integrate the verified incremental update package with the existing local compilation artifacts to obtain an integrated update package; It should be noted that the local original compilation artifacts refer to the collection of historical compilation files, library files, and executable files of the currently running version on the target platform terminal; the merging and integration process refers to the operation of replacing, splicing, and completing the new compilation artifacts in the incremental update package with the local original artifacts according to the directory structure, dependency relationship, and module index; the integrated update package refers to the complete and directly runnable new version program package formed after the incremental artifacts and local artifacts are merged.

[0103] The purpose of this step is to restore the lightweight incremental update package to a complete program structure, ensuring that the updated code dependencies are intact and can run normally. In one possible implementation, the system uses an overwrite merging strategy to replace and integrate the change artifacts; in another possible implementation, the system uses an incremental append merging strategy to insert and integrate the newly added code. Furthermore, the merge and integration process automatically backs up the original artifact files, providing a recovery data source for subsequent rollbacks.

[0104] Specifically, the system reads the incremental compilation artifacts and version index information from the incremental update package, locates the files that need to be replaced in the local original compilation artifacts based on the index, performs overwrite replacement and writes the new files, re-establishes module dependency links and function index mappings according to the project structure, completes the integration of all files, and generates an executable integrated update package. For example, on the iOS terminal, the newly compiled artifact of the login module in the incremental update package will overwrite the local old artifact, while other unchanged modules will be directly retained. After merging, a complete and runnable new version integrated update package will be generated.

[0105] Step S73: Perform runtime verification on the integrated update package, and perform update completion processing or version rollback processing based on the verification results.

[0106] It should be noted that "run verification" refers to the operation of starting the integrated update package to perform initialization, module loading, and function call testing to verify whether the program runs normally; "update completion processing" refers to the operation of confirming the new version takes effect after successful verification, cleaning up temporary files and backups of the old version; "version rollback processing" refers to the safety fallback operation of restoring to the original version before the update and discarding the artifacts of this incremental update when verification fails. The purpose of the system performing this step is to ensure that the program functions normally after the update and to avoid problems such as application crashes and functional abnormalities caused by update anomalies.

[0107] In one possible implementation, runtime verification includes startup testing, module loading verification, and core interface call testing; in another possible implementation, runtime verification includes crash monitoring, log anomaly detection, and automatic dependency integrity checks. Additionally, version rollback processing automatically restores all existing local compilation artifacts, ensuring the terminal can immediately return to a stable and usable state.

[0108] Specifically, the system launches the integrated update package and performs automatic verification, checking the program startup status, module loading results, and core function execution logs. If no abnormalities are found, the update is marked as successful, and update completion processing is executed. If startup failure, crashes, or functional abnormalities occur, version rollback processing is immediately triggered, restoring the original local compilation artifacts and deleting the updated files. For example, after the Android terminal runs the integrated update package, it automatically verifies that the core functions are normal, with no crashes or abnormalities, executes update completion processing, and officially enables the new version; if module loading fails during verification, it automatically rolls back to the old version.

[0109] This embodiment securely distributes incremental update packages to the target platform and performs data integrity verification to prevent corrupted files from entering the update process. Then, it efficiently merges the incremental output with the existing local output to quickly form a complete new version package. Finally, through a dual guarantee mechanism of runtime verification and version rollback, it ensures that the update is enabled normally if successful and rolled back safely if the update fails. The entire process achieves lightweight, efficient, and stable cross-platform code updates, significantly reducing the size of the update package, saving traffic and storage space, while significantly improving the update success rate and terminal operation security.

[0110] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0111] This application also provides a code updating device, please refer to... Figure 3 The code update device includes: The acquisition module 31 is used to acquire the code files of the cross-platform project and generate the abstract syntax tree and code dependency graph corresponding to the code files; The trimming module 32 is used to identify the changed code units and the affected code set in the code file based on the abstract syntax tree and the code dependency graph, and to obtain the incremental code set through code trimming and code compression. The compilation module 33 is used to combine the historical compilation results of the code that has not been affected by the changes, perform compilation processing on the incremental code set, and generate an incremental update package adapted to the target platform; The update module 34 is used to send the incremental update package to the target platform for merging verification and running verification, thereby completing the incremental update of cross-platform code.

[0112] The code update apparatus provided in this application, employing the code update method described in the above embodiments, can solve the technical problems in the background art. Compared with the prior art, the beneficial effects of the code update apparatus provided in this application are the same as those of the code update method described in the above embodiments, and other technical features in the code update apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0113] This application provides a code update device, which includes: 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the code update method in Embodiment 1 above.

[0114] The following is for reference. Figure 4 The diagram illustrates a structural schematic of a code update device suitable for implementing embodiments of this application. The code update device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The code update device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0115] like Figure 4As shown, the code update device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the code update device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the code update device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows code update devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0116] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0117] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0118] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the code update methods provided by the methods described above.

[0119] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0121] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A code update method, characterized in that, include: Obtain the code files of a cross-platform project and generate the corresponding abstract syntax tree and code dependency graph for the code files; Based on the abstract syntax tree and the code dependency graph, the modified code units and the affected code set in the code file are identified, and the incremental code set is obtained through code trimming and code compression. Based on the historical compilation results of the code that has not been affected by the changes, the incremental code set is compiled to generate an incremental update package adapted to the target platform; The incremental update package is sent to the target platform for merging verification and runtime verification, thus completing the incremental update of the cross-platform code.

2. The code update method as described in claim 1, characterized in that, The generation of the abstract syntax tree and code dependency graph corresponding to the code file includes: Perform syntax parsing on the code file to generate an abstract syntax tree corresponding to each code unit in the code file; Based on the abstract syntax tree, function call relationships and module dependency relationships are extracted, and the association relationships between each code unit are established. Based on the relationships between the code units, a code dependency graph is constructed to represent structural dependencies.

3. The code update method as described in claim 1, characterized in that, The process of identifying modified code units and affected code sets in the code file based on the abstract syntax tree and the code dependency graph, and obtaining an incremental code set through code trimming and compression, includes: Based on the abstract syntax tree and the code dependency graph, feature extraction processing is performed to generate a structured code fingerprint corresponding to each code unit in the code file. The structured code fingerprint includes syntax structure features, function call chain features, and interface signature features. The current version's structured code fingerprint is compared with the structured code fingerprints of historical versions to identify the changed code units, and the set of affected code is calculated through the code dependency graph. The affected code set is subjected to path analysis, cuttable code identification, and code removal. The processing results are then compressed and structurally optimized with the changed code units to form an incremental code set.

4. The code update method as described in claim 3, characterized in that, The process of performing path analysis, identifying trimmable code, and removing code from the affected code set includes: Syntax parsing is performed on the affected code set, and multiple basic code blocks are divided using conditional branches, loop relationships, jump relationships, and function call relationships as basic block boundaries. Based on the program execution flow between the basic code blocks, a function-level control flow graph is established. Combined with the function call relationships between the basic code blocks, the function-level control flow graphs are integrated to form a global control flow graph, which is used to completely represent the code execution path topology. Starting from the basic code block at the program execution entry point, the execution path of the global control flow graph is traversed to identify all reachable paths. Code units not covered by any reachable path are identified as trimmable code, and the trimmable code is removed.

5. The code update method as described in claim 4, characterized in that, Starting from the basic code block at the program execution entry point, the process traverses the execution path along the global control flow graph, identifies all reachable paths, and determines code units not covered by any reachable path as trimmable code, including: Obtain the basic code block corresponding to the program execution entry point, and add the basic code block to the initial execution set of the path traversal. The program execution entry point includes the application startup entry point, the business entry point, and the configuration enabled module entry point. Based on the initial execution set, recursive traversal processing is performed along the global control flow graph for conditional branches, loop structures, jump logic and function calls until all reachable paths are traversed. Code units that are not covered by any reachable path are subjected to multi-dimensional screening and are identified as code that can be trimmed.

6. The code update method as described in claim 1, characterized in that, The process of combining historical compilation results of code unaffected by the changes with the incremental code set to generate an incremental update package adapted to the target platform includes: Perform a range filtering process on the code units in the code file to determine the code that has not been affected by the changes; For the code that has not been affected by the changes, the historical compilation results are called and the corresponding historical compilation artifacts are directly reused. The incremental code set is compiled to generate incremental compilation artifacts, and the incremental compilation artifacts are integrated with the reused historical compilation artifacts to generate an incremental update package adapted to the target platform.

7. The code update method as described in claim 1, characterized in that, The step of distributing the incremental update package to the target platform for merging verification and runtime verification to complete the incremental update of cross-platform code includes: The incremental update package is transmitted to the target platform, and data integrity verification is performed on the incremental update package. The verified incremental update package is merged and integrated with the local original compilation artifacts to obtain an integrated update package. Perform runtime verification on the integrated update package, and perform update completion processing or version rollback processing based on the verification results.

8. A code updating device, characterized in that, include: The acquisition module is used to acquire the code files of cross-platform projects and generate the abstract syntax tree and code dependency graph corresponding to the code files; The trimming module is used to identify the changed code units and the affected code set in the code file based on the abstract syntax tree and the code dependency graph, and to obtain the incremental code set through code trimming and code compression. The compilation module is used to combine the historical compilation results of the code that has not been affected by the changes, perform compilation processing on the incremental code set, and generate an incremental update package adapted to the target platform; The update module is used to distribute the incremental update package to the target platform for merging verification and runtime verification, thereby completing the incremental update of cross-platform code.

9. A code update device, characterized in that, The code update device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the code update method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the code update method as described in any one of claims 1 to 7.

Images