Cross-platform honkong application code conversion method and system based on feature analysis and large model

Abstract

This invention provides a cross-platform HarmonyOS application code conversion method and system based on feature parsing and a large model, including: constructing a skill constraint system for cross-platform code conversion; performing lexical and syntactic analysis on the source files to be converted to generate an abstract syntax tree, extracting semantic information and classifying and merging it; constructing a file dependency graph and detecting circular dependencies; forming a dynamic context information package; converting the source file information into an intermediate semantic representation independent of the programming language; generating preliminary HarmonyOS target code based on the intermediate semantic representation and the skill constraint system; performing automatic build detection; extracting error feature information from compilation failure logs; generating error correction prompts and inputting them into a large model to perform closed-loop repair; and setting retry counting and circuit breaker exit mechanisms. This invention achieves decoupled conversion between the source language and the target language through intermediate semantic representation, and combined with the self-healing loop and circuit breaker mechanism of compilation feedback, improves the automation level and compilation pass rate of cross-platform code conversion.

Description

Technical Field

[0001] This invention relates to the field of cross-platform migration technology for mobile applications, specifically to a method and system for cross-platform HarmonyOS application code conversion based on feature parsing and large models. Background Technology

[0002] With the rapid adoption of native HarmonyOS applications and terminal upgrades, HarmonyOS has become one of the major operating systems on the market. Major companies are accelerating the development of their own HarmonyOS apps, and adapting to HarmonyOS is a crucial channel for acquiring high-quality, localized user traffic.

[0003] Technical pain points: 1) Traditional code migration mainly relies on manual rewriting, which is inefficient and costly; 2) When directly using the conventional Large Language Model (LLM) for code translation, due to the huge differences in the underlying architecture and API of the two major platforms, the generated code often contains syntax errors or API illusions and cannot be directly compiled; 3) Relying on manual inspection of errors generated by large models is still time-consuming and labor-intensive; 4) If large models are allowed to correct errors on their own, they are prone to getting stuck in endless "dead loops" when encountering complex problems, which consumes a lot of computing power and blocks the automated process.

[0004] Patent application CN120578577A discloses an application adaptability optimization method and system for the HarmonyOS system. The method includes: acquiring application data and historical running records corresponding to the application to be optimized; determining the functional module architecture corresponding to the application to be optimized based on the application data and module function decoupling rules; predicting risk interface information corresponding to the application to be optimized based on the historical running records and the interface rules corresponding to the HarmonyOS system; and determining a module optimization strategy corresponding to the application to be optimized based on the risk interface information and the functional module architecture. The module optimization strategy is used to limit the code optimization scheme corresponding to any functional module in the application to be optimized. However, this patent cannot completely solve the existing technical problems, nor can it meet the needs of this invention. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this invention is to provide a cross-platform HarmonyOS application code conversion method and system based on feature parsing and large models.

[0006] The cross-platform HarmonyOS application code conversion method based on feature parsing and large models provided by the present invention includes: Step 1: Construct a skill constraint system for cross-platform code conversion. The skill constraint system includes a platform API mapping relationship library, a coding standard constraint library, a migration rule library, and a dependency replacement rule library. Step 2: Perform feature parsing on the source file to be converted, including: performing lexical and syntactic analysis on the source file to generate an abstract syntax tree, extracting semantic information from the abstract syntax tree, and classifying and merging the semantic information according to interface structure features, business logic features, lifecycle features, and external dependency features to form a structured feature set. Step 3: Construct a file dependency graph based on the structured feature set. The construction of the dependency graph includes: adding the current file to be converted as the root node to the dependency graph, traversing the import declaration nodes in the abstract syntax tree to extract candidate dependency nodes, recursively performing node initialization and import statement scanning on the candidate dependency nodes, establishing directed edges in the direction of the current file's dependency on the target file, recording the dependency type and reference symbol set, and detecting directed cycles and marking circular dependencies. Step 4: Retrieve associated files based on the current file to be converted, and extract interface signatures, global variable declarations, macro definition summaries, and context information from the associated files to form a dynamic context information package; Step 5: Convert the functional intent, structural features, dependency context and platform constraint information of the source file into an intermediate semantic representation that is independent of the specific programming language. The intermediate semantic representation includes page structure definition, state variable set, event triggering relationship, lifecycle binding, external interface call list and dependency graph. Step 6: Based on the intermediate semantic representation and combined with the skill constraint system, generate preliminary HarmonyOS target code; Step 7: Perform build checks on the initial HarmonyOS target code. The build checks include syntax checking, type checking, dependency resolution checking, compilation checking, and static rule checking. Step 8: When the build detection result is a failure, extract error features from the compilation failure log. The error feature information includes error line number, error column number, error type, missing symbol, unrecognized API, type mismatch information, syntax structure abnormal information, and dependency missing information. Step 9: Combine the error feature information, the current error code fragment, and the platform constraint information to generate error correction prompts. Input the error correction prompts into the large model to generate the repaired target code, and re-execute the build detection on the repaired code. Step 10: Set up a retry counter and circuit breaker exit mechanism. When the retry counter is greater than or equal to the maximum retry threshold, trigger the circuit breaker mechanism to terminate the large model repair process.

[0007] Preferably, the dependency types in the dependency graph include strong dependencies and weak dependencies; The strong dependency is: the compilation, type resolution or core semantic restoration of the current file must depend on the target file. Removing this dependency will result in unrecognizable type, missing method signature, missing inheritance relationship or compilation failure. The weak dependencies are: auxiliary information, optional capabilities, conditional compilation branches, resource identifiers, macro switches, logging tools, instrumentation tools, or downgraded implementations provided by the target file. Removing them will not affect the semantic parsing of the main process or can be replaced by the default strategy.

[0008] Preferably, the cycle dependency detection uses the DFS three-color labeling method, which includes: marking unvisited nodes as white, marking nodes that are being visited and are located in the current recursion stack as gray, and marking nodes that have been visited as black; performing a depth-first search for each unvisited node, and if the target node is gray, it is determined that a directed cycle exists, the cycle is recorded and the path is interrupted from being expanded.

[0009] Preferably, the intermediate semantic representation is implemented using a structured data format, wherein: The page structure definition includes four fields: page unique identifier, page type, root container definition, and view hierarchy tree; The state variable set records the variable name, variable type, scope, access modifier, initial value, whether it is a UI state variable, the set of view identifiers it is bound to, and the variable update mechanism for each state variable; The event triggering relationship record includes the unique identifier of each event, event type, triggering source view, processing method name, processing method parameter list, and list of side effects generated after the event is triggered; The lifecycle binding establishes a mapping relationship between iOS lifecycle functions and corresponding HarmonyOS lifecycle callbacks, and records the logic types, target variables, and execution order to be executed in each lifecycle node; The external interface call list records the unique identifier, iOS-side interface name, interface category, method signature, parameter list, return type, and asynchronous mode of each external interface call; The dependency graph takes the current file as the root node and records its dependent file list, global variable declaration list, macro definition list, and enumeration type definition list.

[0010] Preferably, the generation of preliminary HarmonyOS target code based on intermediate semantic representation includes: The logic in iOS that achieves UI changes by directly modifying view properties and actively refreshing controls is transformed into state-driven data binding logic, and a component structure that conforms to the HarmonyOS ArkUI specification is generated. Map instance variables, control variables, and UI state variables on the iOS side to state decorator variables, ordinary member variables, or shared state variables in HarmonyOS. Map the logic related to initialization, request triggering, and resource loading in the iOS lifecycle to the corresponding lifecycle callbacks in HarmonyOS for execution; Transform the complex nested constraint layout relationships in iOS into composable linear layouts, cascading layouts, or grid layout structures in HarmonyOS. The original iOS interface is replaced with an equivalent interface for the target platform. When there is no one-to-one correspondence, it is completed into a replacement interface or a combination interface that can be implemented by HarmonyOS based on the functional semantics.

[0011] Preferably, the syntax check in the build detection is performed by the built-in syntax analyzer of the build toolchain, the type check is performed by calling the TypeScript or ArkTS type system, the dependency resolution check verifies the existence of the referenced package name, module path and exported symbols in the dependency repository of the HarmonyOS platform, the compilation check is performed by calling the compiler provided by the HarmonyOS SDK, and the static rule check is performed by performing static scanning of ESLint or HarmonyOS dedicated Lint tool according to the HarmonyOS platform coding specifications.

[0012] Preferably, the closed-loop repair adopts an incremental repair method, including: Based on the error line number and column number in the compilation failure log, accurately locate the error position in the row and column index structure of the current code and determine the smallest error unit; Centered on the error location, the number of preceding and following context lines is dynamically determined based on the compilation error type, the boundary of the smallest error unit in the abstract syntax tree, the symbol reference range, and the scope of the repair impact. The preceding and following contexts are then extracted to form a local repair context window. Error feature information, local repair context window and platform constraint information are combined into error correction prompt words and fed into the large model for repair; The repair code snippets output by the large model are updated to the complete code file using a minimized replacement method, based on the row and column range of the original error location.

[0013] Preferably, the maximum retry threshold Rmax is dynamically set based on the historical migration success rate, error type, code complexity, and upper limit of computing power cost. The maximum retry threshold is set to 3 times for ordinary syntax errors, 5 times for type and API replacement errors, and 8 times for complex dependency errors. When the number of errors does not decrease after two consecutive rounds of repair or the same error recurs, the circuit breaker is triggered in advance before Rmax is reached.

[0014] The cross-platform HarmonyOS application code conversion system based on feature parsing and large models provided by the present invention includes: Constraint System Construction Module: Used to build a skill constraint system for cross-platform code conversion. The skill constraint system includes a platform API mapping relationship library, a coding standard constraint library, a migration rule library, and a dependency replacement rule library. Feature parsing module: used to perform lexical and syntactic analysis on the source file to be converted to generate an abstract syntax tree, extract semantic information from the abstract syntax tree, and classify and merge the semantic information according to interface structure features, business logic features, life cycle features and external dependency features to form a structured feature set; Dependency graph construction module: It is used to add the current file to be converted as the root node to the dependency graph, traverse the import declaration nodes in the abstract syntax tree to extract candidate dependency nodes, recursively perform node initialization and import statement scanning on the candidate dependency nodes, establish directed edges in the direction of the current file's dependency on the target file, record the dependency type and reference symbol set, and detect directed cycles and mark circular dependencies. Context extraction module: used to retrieve associated files based on the current file to be converted, and extract interface signatures, global variable declarations, macro definition summaries and necessary context information from the associated files to form a dynamic context information package; Intermediate semantic representation module: used to uniformly convert the functional intent, structural features, dependency context and platform constraint information of the source file into an intermediate semantic representation that is independent of the specific programming language. The intermediate semantic representation includes page structure definition, state variable set, event triggering relationship, lifecycle binding, external interface call list and dependency graph. Code generation module: used to generate preliminary HarmonyOS target code based on the intermediate semantic representation and the skill constraint system, and output the preliminary HarmonyOS target code to the construction and detection module; Build detection module: used to perform build detection on the initial HarmonyOS target code. The build detection includes syntax checking, type checking, dependency resolution checking, compilation checking and static rule checking, and outputs compilation success information or compilation failure logs. Error feature extraction module: used to parse the compilation failure log when the build detection result is failure, and extract error feature information, including error line number, error column number, error type, missing symbol, unrecognized API, type mismatch information, syntax structure abnormal information, and dependency missing information; Closed-loop repair module: used to combine the error feature information, the current error code fragment and the platform constraint information to generate error correction prompts, input the error correction prompts into the large model, generate the repaired target code, and send the repaired code back to the construction and detection module; Retry and Circuit Breaker Module: Used to set the retry counter and the maximum retry threshold. When the retry counter is less than the maximum retry threshold, the closed-loop repair continues. When the retry counter is greater than or equal to the maximum retry threshold, the circuit breaker mechanism is triggered to terminate the large model repair process.

[0015] Preferably, it also includes an output module, which is used to output compileable HarmonyOS target code when the build detection passes, and to output a manual intervention result package containing the failure reason and context information when the circuit breaker mechanism is triggered. The manual intervention result package includes the latest code version, unresolved error logs, attempted repair records, and associated context information.

[0016] Compared with the prior art, the present invention has the following beneficial effects: (1) The present invention is based on the dynamic context construction technology of dependency graph. By extracting dependencies on demand, it not only ensures sufficient context support during conversion and avoids the fabrication of non-existent function calls in large models, but also greatly reduces token consumption and improves conversion speed and success rate. (2) Based on the state variable extraction and lifecycle mapping technology for cross-paradigm UI transformation, this invention solves the technical problem of different underlying paradigms of imperative and declarative UI, so that the generated ArkTS code can not only run, but also conforms to the reactive programming specifications recommended by HarmonyOS, greatly reducing the workload of manual refactoring. (3) The present invention is based on a dynamic self-healing loop method of compilation feedback, which solves the objective technical problems that will inevitably be encountered when large models are actually implemented, such as "illusions leading to failure to compile" and "getting stuck in an infinite loop and consuming computing power". Attached Figure Description

[0017] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart of the cross-platform HarmonyOS application code conversion method based on feature parsing and large models according to the present invention. Detailed Implementation

[0018] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0019] Example 1 This invention provides an automated code conversion method based on feature parsing and a large language model (LLM). It can not only efficiently translate iOS code to HarmonyOS code, but also innovatively introduces a closed-loop self-healing process with a circuit breaker mechanism of "compile-feedback-retry-circuit breaker", realizing automated code migration with high code compilation pass rate and low computing power consumption.

[0020] like Figure 1 The specific technical solution is as follows: Step S1: Construct a skill constraint system for cross-platform code conversion; Before performing code conversion, a skill constraint system for the iOS platform and HarmonyOS platform is pre-built. The skill constraint system includes at least a platform API mapping library, a coding standard constraint library, a migration rule library, and a dependency replacement rule library.

[0021] Platform API mapping database: { "ruleId": "API_UIKIT_001", "source": { "platform": "iOS", "symbol": "UILabel", }, "target": { "platform": "HarmonyOS", "symbol": "Text", }, "condition": "Used for static text display scenarios", } Coding Standard Constraint Library: { "ruleId": "ARKTS_STATE_001", "constraint": "UI display-related variables should be declared using decorators such as @State, @Prop, or @Link". "forbiddenPattern": "Directly modify state variables in build()", "repairHint": "Changes UI changes to updates of @State variables within the event function." } Migration rule base: { "ruleId": "UI_PARADIGM_001", "sourcePattern": "Command-based modification of control properties", "targetPattern": "Declarative state binding", "example": "button.enabled = false ->@State isEnabled=false; Button().enabled(this.isEnabled)" } Dependency replacement rule base: { "sourceDependency": "Masonry", "targetStrategy": "replace", "targetImplementation": "ArkUI Column / Row / Stack / Flex + width / height / margin / alignment", "condition": "iOS Auto Layout constraint dependency replaced with ArkUI declarative layout" } The platform API mapping library stores the mapping relationships between native iOS platform interfaces, UIKit components, system callback functions, and HarmonyOS ArkTS interfaces, ArkUI components, and lifecycle callbacks. The coding standard constraint library stores the target platform's syntax rules, state management rules, layout rules, component composition rules, and prohibited usage patterns. The migration rule library stores the rule constraints in cross-platform transformation, including rules for transforming from imperative UI to declarative UI, lifecycle function alignment rules, layout component mapping rules, and system capability call substitution rules. The dependency replacement rule library stores the equivalent replacement strategies or downgrade implementation strategies for iOS third-party libraries, system libraries, and tool libraries in the HarmonyOS platform.

[0022] By applying the aforementioned skill constraint system, platform-level boundary restrictions are imposed on the generation process of large models to improve the correctness and consistency of the conversion results.

[0023] Step S2: Perform feature parsing on the iOS source files and generate intermediate semantic representations; When the iOS source files to be migrated are received, the system first performs feature parsing on the source files, rather than directly translating them word by word. The specific process is as follows: (a) Lexical and Syntax Analysis: The system uses a lexical analyzer to scan the source file, identify lexical units such as keywords, identifiers, operators and delimiters, and convert the sequence of lexical units into an abstract syntax tree (AST) according to the grammar rules of the target language. The lexical analyzer is an existing tool. In the iOS development system, the lexical analyzer (Lexer) is the core component of the Clang compiler front end.

[0024] (b) Semantic information extraction: The system traverses each node of the AST, reads the type information, scope attribution and symbol reference relationship of each node, and obtains complete semantic information including type declaration, function definition, variable binding and call chain; (c) Feature classification and merging: The system classifies and merges the above semantic information according to four dimensions: interface structure features, business logic features, life cycle features and external dependency features, to form a structured feature set.

[0025] The interface structure features include view control types, layout container types, hierarchical nesting relationships, and interface update methods; the business logic features include state variables, function call relationships, data processing logic, and event response logic; the lifecycle features include view loading, display, destruction, and callback triggering logic; and the external dependency features include header file references, utility class references, model class references, macro definitions, and third-party library dependencies.

[0026] Furthermore, the system constructs a file dependency graph based on syntax tree analysis, symbolic reference analysis, or static dependency analysis. The specific process is as follows: (a) Node initialization: Add the current file to be converted as the root node to the dependency graph and assign it a unique node identifier; (b) Import statement scanning: Traverse the import declaration nodes (import / include / #import, etc.) in the abstract syntax tree, extract the path or module identifier of the referenced file as candidate dependency nodes; (c) Recursive dependency resolution: For each candidate dependency node, repeatedly execute node initialization and import statement scanning until all reachable nodes in the graph have been processed; (d) Directed edge construction: Construct a directed edge in the direction of "current file depends on target file", and record the dependency type (strong dependency / weak dependency) and the set of reference symbols; Strong dependency: The compilation, type resolution, or core semantic restoration of the current file depends on the target file. Removing this dependency will result in unrecognized types, missing method signatures, missing inheritance relationships, or compilation failure.

[0027] Weak dependencies: The target file only provides auxiliary information, optional capabilities, conditional compilation branches, resource identifiers, macro switches, logging tools, instrumentation tools, or fallback implementations. Removing them does not affect the semantic parsing of the main process, or they can be replaced by the default strategy.

[0028] (e) Circular dependency detection: During the construction of the graph, check for the existence of directed cycles. If a cycle exists, mark it as a circular dependency and interrupt the expansion of the path to prevent infinite recursion. Circular dependency detection can be performed using the DFS three-color labeling method: White: Not visited; Gray: Currently being visited, located in the current recursion stack; Black: Access complete.

[0029] Algorithm process: Perform DFS (Depth-First Search) on each unvisited node: 1. Mark the current node as gray; 2. Traverse all outgoing edges of the current node; 3. If the target node is white, then recursively visit it; 4. If the target node is gray, it means that a directed cycle has been found in the path from the current node back to the node in the recursion stack. 5. Record the loop and then interrupt the path expansion. 6. Once all dependencies of the current node have been processed, it will be marked in black.

[0030] Then, based on the current file to be converted, its associated files are automatically retrieved, and the interface signature, global variable declaration, macro definition summary and necessary context information are extracted from the associated files to form a dynamic context information package.

[0031] Based on this, the system uniformly converts the functional intent, structural features, dependency context and platform constraint information of the source file into an intermediate semantic representation that is independent of the specific programming language. The intermediate semantic representation is used to describe the interface composition relationship, event triggering relationship, data flow relationship, life cycle and business logic binding relationship, and external interface call intent.

[0032] Specifically, the intermediate semantic representation is implemented using a structured data format and includes the following core components: (1) Page Structure Definition: The page structure is fully described by four fields: "unique page identifier", "page type" (such as UIViewController or custom component), "root container definition" (including container type, layout direction and subview list) and "view hierarchy tree" (records the type, layout constraints and attribute set of each view node); (2) State Variables: Records the variable name, variable type, scope (instance level / local / global), access modifier, initial value, whether it is a UI state variable, the set of view identifiers bound to it, and the variable update mechanism (direct modification / delegation / notification) for each state variable. (3) Event Triggering Relationship (EventFlow): Record the unique identifier of each event, event type (click / scroll / pull-down / refresh / custom), triggering source view, processing method name, processing method parameter list, and the list of side effects generated after the event is triggered (including side effect type, target object and new value); (4) Lifecycle Binding: Establish the mapping relationship between iOS lifecycle functions (such as viewDidLoad, viewWillAppear, etc.) and corresponding HarmonyOS lifecycle callbacks (such as aboutToAppear, onPageShow, etc.), and record the logic type, target variable and execution order to be executed in each lifecycle node; (5) External API Call List: Records the unique identifier, iOS-side API name, API category (network / storage / device / third party), method signature, parameter list, return type and asynchronous mode (callback block / delegation / callback / Promise) for each external API call. (6) Dependency Graph: With the current file as the root node, it records the list of its dependent files (including the set of dependency types and reference symbols), the list of global variable declarations, the list of macro definitions, and the list of enumeration type definitions.

[0033] Through the aforementioned structured intermediate semantic representation, the system achieves decoupled transformation from the iOS source language to the HarmonyOS target language, enabling the large model to focus on equivalent transformations at the semantic level, rather than getting caught in the trap of word-for-word translation of grammatical details.

[0034] Step S3: Generate HarmonyOS target code based on intermediate semantic representation; The HarmonyOS target code generation stage receives the intermediate semantic representation output from step S2 instead of directly receiving the original iOS source code, thereby reducing the interference of source language syntax differences on the generation result.

[0035] During the generation process, the system incorporates the HarmonyOS platform's skill constraint system to generate the target code under constraints, specifically including: 1) Transform the logic in iOS that achieves UI changes by directly modifying view properties and actively refreshing controls into state-driven data binding logic, and generate a component structure that conforms to the HarmonyOS ArkUI specification; 2) Map instance variables, control variables, and UI state variables on the iOS side to state decorator variables, ordinary member variables, or shared state variables in HarmonyOS. 3) Map the logic related to initialization, request triggering, and resource loading in the iOS lifecycle to the corresponding lifecycle callbacks in HarmonyOS for execution; 4) Convert the complex nested constraint layout relationships in iOS into composable linear layout, cascading layout or grid layout structures in HarmonyOS. 5) Replace the original iOS interface with the equivalent interface for the target platform; when there is no one-to-one correspondence, automatically complete it with the alternative interface or combination interface that HarmonyOS can implement based on the functional semantics.

[0036] Through the above constraint generation, the initial HarmonyOS ArkTS code is output.

[0037] Step S4: Perform automatic build detection on the initial HarmonyOS ArkTS code; After obtaining the initial HarmonyOS ArkTS code, the system control module automatically calls the target platform's build toolchain to perform build checks on the code. The build checks include at least the following five types of checks: First, syntax checking: The built-in parser of the build toolchain performs lexical and syntactic compliance verification on the generated ArkTS code, detects syntax errors such as mismatched brackets, missing semicolons in statements, and illegal keyword usage, and outputs the corresponding error line number and error description; among them, the parser is an existing tool. In the iOS development system, the parser is the core component of the Clang compiler front-end. Secondly, type checking: The TypeScript / ArkTS type system is invoked to perform static type inference and compliance checks on variable declarations, function signatures, return values ​​and assignment operations in the code, and to identify type-level errors such as type incompatibility, implicit type conversion exceptions and generic constraint violations. Third, dependency resolution check: parse the import statements and module references in the code, verify whether the referenced package name, module path and exported symbols exist in the HarmonyOS platform's dependency repository, and detect problems such as missing dependencies, incorrect paths and namespace conflicts. Fourth, compilation check: The compiler provided by HarmonyOS SDK is called to perform a complete compilation chain verification of the code, generate intermediate bytecode and detect all errors in the compilation stage, including non-compliant API calls, incorrect component property assignment types and abnormal decorator usage, etc. Fifth, static rule check: Based on the HarmonyOS platform coding specifications and performance best practices, perform static scanning using ESLint or the HarmonyOS-specific Lint tool to detect potential logical errors, performance anti-patterns, and issues such as disabling API usage.

[0038] The output of the build test includes either a compilation success message or a compilation failure log.

[0039] Step S5: Extract error features from the compilation failure log; When the build test result is a failure, the system parses the compilation failure log and extracts error feature information.

[0040] The error characteristic information includes at least the error line number, error column number, error type, missing symbol, unrecognized API, type mismatch information, syntax structure exception information, and dependency missing information.

[0041] Furthermore, the system categorizes and aggregates error logs to form structured error summaries, which are used as targeted inputs in the subsequent large model repair process to reduce the interference of irrelevant information on the repair results.

[0042] Step S6: Generate error correction prompts based on error feature information and perform closed-loop repair; The system combines the current error characteristics, the current error code fragment, and the platform constraint information to generate error correction prompts, and inputs the error correction prompts into the large model to generate the repaired target code.

[0043] In one embodiment, the repair process employs an incremental repair method, the specific implementation of which is as follows: (a) Error location: Based on the error line number and column number in the compilation failure log, accurately locate the error location in the row and column index structure of the current code and determine the smallest error unit (single statement, single function body or single component definition block). (b) Context window extraction: Centered on the error location, extract no more than N lines of preceding context (including related variable declarations and import statements) and no more than M lines of following context (including the scope of the error's impact) to form a local repair context window; Here, N and M should not be written as fixed values. The system dynamically determines the number of preceding context lines N and the number of following context lines M based on the error type, the boundary of the AST node where the error occurs, the location of related symbol declarations, and the input length limit of the large model. The confirmation criteria include: Compilation error types: Syntax errors usually only require a smaller window; type errors, import errors, and component parameter errors require a larger window.

[0044] The smallest error unit in AST is to prioritize function bodies, component definition blocks, and class member declaration blocks as boundaries, rather than mechanically truncating line numbers.

[0045] Symbolic reference scope: If the error involves variables, methods, types, or imports, you need to include their declaration locations forward.

[0046] Scope of impact: If the error affects subsequent chained calls, component closures, or layout blocks, it needs to be extended to the end of the complete statement block.

[0047] (c) Incremental repair input construction: The error feature information, local repair context window and platform constraint information are combined into error correction prompt words, which only contain the local code snippets that need to be repaired, rather than the complete conversion file, and are sent into the large model for repair; (d) Local code replacement: The repair code snippets output by the large model are updated to the complete code file in a minimized replacement manner according to the row and column range of the original error location, keeping the correct code outside the repair area unchanged, so as to reduce the impact on the correct code part and improve the repair efficiency.

[0048] After the repair, the system re-executes step S4 to rebuild and inspect the repaired code, thus forming a closed-loop self-healing process of "generation-inspection-feedback-regeneration".

[0049] Step S7: Set the retry count and circuit breaker exit mechanism; The system sets a retry counter and a maximum retry threshold Rmax for the closed-loop repair process.

[0050] When the detection result is a failure and the system is ready to enter the next round of repair, the system determines whether the current retry counter is less than the maximum retry threshold Rmax. If it is less than Rmax, the closed-loop repair process continues. If it is greater than or equal to Rmax, the circuit breaker mechanism is triggered to terminate the automatic repair process of the large model.

[0051] The maximum retry threshold Rmax can be dynamically set based on historical migration success rate, error type, code complexity, and upper limit of computing power cost. In one embodiment, the retry threshold is set to 3 for ordinary syntax errors, 5 for type and API replacement errors, and 8 for complex dependency errors. If the number of errors does not decrease after two consecutive rounds of fixing, or if the same error recurs, the circuit breaker can be triggered early even if Rmax has not been reached.

[0052] After the circuit breaker mechanism is triggered, the system will output the latest code version, unresolved error logs, attempted repair records, and related context information to the developers so that they can intervene manually, thereby preventing the system from getting stuck in infinite retries and reducing the waste of computing resources.

[0053] Step S8: Output the conversion results and the abnormal intervention results; When the build test passes, the system outputs compileable HarmonyOS target code; when the circuit breaker mechanism is triggered, the system outputs a manual intervention result package containing the reason for failure and context information. This result package can be used for subsequent manual corrections, rule supplements, or skill constraint system updates to further improve the success rate of subsequent conversion tasks.

[0054] Example 2 This embodiment uses the source file Am of a certain business page on the iOS client as the object to be migrated, and the target platform is the HarmonyOS ArkTS environment. The system performs the following steps: 1) Initialization of the skill constraint system Preload the skill constraint systems of the iOS platform and HarmonyOS platform into the large model, including: Commonly used UIKit components, controller lifecycle functions, layout constraint schemes, and usage of third-party libraries in iOS; HarmonyOS ArkUI components, state management mechanism, page lifecycle functions, layout components, and command-line build rules; The API mapping relationship, lifecycle mapping relationship, layout replacement rules, and dependency replacement rules between iOS and HarmonyOS.

[0055] The system organizes the above constraint information into Skills and injects them as Skills for the large model in subsequent large model calls.

[0056] 2) Semantic analysis of iOS source files After receiving the Am file to be migrated, the system first performs static parsing to extract the interface structure, event handling logic, data flow relationships, and lifecycle-related logic from the file.

[0057] For example, if Am contains button click events, network request callbacks, and automatic refresh operations after page load, the system will identify these as: interface interaction events, business network logic, lifecycle triggering logic, etc.

[0058] At the same time, based on the syntax tree and symbol reference relationships, the system retrieves the related files such as Bh and Ch that Am depends on, and extracts only their interface declarations, enumeration definitions, global variable declarations and necessary macro definitions, instead of inputting the whole text into the model indiscriminately, so as to reduce context redundancy and improve transfer accuracy.

[0059] 3) Constructing intermediate semantic representations The system organizes the parsed interface structure, behavioral logic, state information, and external dependency information into an intermediate semantic representation. This intermediate semantic representation may include: Page component tree; Event triggering node; Set of state variables; List of external interface calls; Lifecycle binding relationship.

[0060] Intermediate semantic representation serves as the sole input for subsequent target platform code generation and does not directly expose the original iOS syntax details.

[0061] The following is a specific example: Example 1: Explanation of iOS source file (LoginViewController.m) This example file is a typical iOS login page controller, and its main structure is as follows: In the property declaration section, five view control properties are defined (titleLabel, usernameField, passwordField, loginButton, loadingIndicator), and three business status properties (string types for username and password, and boolean type for isLoading). During the view loading phase, the setupUI method is called sequentially in the viewDidLoad lifecycle method to complete the initialization of controls and the addition of layers, and the setupConstraints method completes the layout constraint configuration of each control through the Masonry constraint library; In the interaction logic section, the loginTapped method responds to the login button click event, reads the content of the input box, validates the non-empty condition, and sets isLoading to true and disables the login button after the validation passes. Then, it calls the loginRequest method to initiate a simulated network request. The loginRequest method uses dispatch_after to implement a 1-second delayed callback. In the callback, it determines whether the login is successful or failed based on whether the username and password match the preset value (admin / 123456). If it fails, it displays an error message pop-up through UIAlertController.

[0062] 4) HarmonyOS code generation The system inputs the intermediate semantic representation into the HarmonyOS generation module and, in conjunction with the HarmonyOS platform skill constraint system, generates the target ArkTS code.

[0063] During the generation process, the system transforms imperative UI update logic into declarative state-driven logic. For example: The code that changes the interface by directly modifying view properties in the original iOS is converted into the rendering logic driven by state decorators such as @State and @Prop in HarmonyOS. Map the initialization request logic executed in viewDidLoad to the aboutToAppear lifecycle of the HarmonyOS page; Transform complex constraint layouts into a combined structure of layout containers such as Column, Row, and Stack.

[0064] Output the initial HarmonyOS ArkTS code.

[0065] Example 2: Explanation of the generated HarmonyOS target code (LoginPage.ets) The main structure of the HarmonyOS ArkTS login page component generated after code conversion is as follows: In the state variable section, the original iOS instance variables username, password, and isLoading are all declared as @State state decorator variables, and a new loginButtonEnabled boolean state variable is added to control the availability of the login button; In the lifecycle section, the aboutToAppear method corresponds to viewDidLoad in iOS, preserving the execution entry point for the initialization logic; In the UI construction section, a Column linear layout container is used to replace the UIView constraint layout. It contains a Text component (corresponding to UILabel), two TextInput components (corresponding to UITextField, where the password field implements encrypted input through type(InputType.Password)), a Button component (corresponding to UIButton, which controls availability by binding state through enabled(this.loginButtonEnabled)), and a conditionally rendered LoadingProgress component (corresponding to UIActivityIndicatorView, which controls visibility through if(this.isLoading)). In the event handling section, the loginTapped method uses promptAction.showToast instead of UIAlertController to display the prompt message, and the loginRequest method uses setTimeout instead of dispatch_after to implement asynchronous delay logic. Overall, the iOS imperative UI update mode is transformed into a declarative data-driven rendering mode based on @State.

[0066] The above example clearly shows that: (1) The view controls in the iOS source files are mapped to HarmonyOS components such as Column, Text, TextInput, Button, LoadingProgress; (2) Instance variables (username, password, isLoading) in iOS are converted to HarmonyOS's @State state variables; (3) The iOS lifecycle method viewDidLoad is mapped to HarmonyOS's aboutToAppear; (4) iOS’s imperative UI updates (directly modifying control properties) have been converted to declarative state-driven (@State + data binding). (5) The asynchronous call of dispatch_after in iOS is converted to setTimeout in HarmonyOS; (6) iOS’s UIAlertController is replaced by HarmonyOS’s promptAction.showToast.

[0067] 5) Automatic compilation and detection The system automatically calls the HarmonyOS build tool to perform compilation checks on the initial code. If compilation is successful, the final migration result is output; if compilation fails, a closed-loop error correction process is initiated.

[0068] 6) Error Feature Extraction and Loop Closure Repair When compilation fails, the system parses the error log, extracts the error line number, error type, missing symbol, error call chain and related context, and uses them together with the current code snippet to construct an error correction prompt. The large model is then input again to generate the repair code.

[0069] The system repeatedly executes the "build-compile-feedback-repair" cycle and maintains a retry counter.

[0070] 7) Circuit breaker and manual intervention When the number of retries reaches the preset threshold N, the system stops automatically repairing and outputs the current code version, error logs, and retry history for developers to manually check and correct.

[0071] Through the above process, this embodiment realizes the automated migration of iOS applications to HarmonyOS applications, reduces the cost of manual rewriting, and improves migration efficiency and code compilability.

[0072] Those skilled in the art will understand that, in addition to implementing the system, apparatus, and their modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and their modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0073] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A cross-platform HarmonyOS application code conversion method based on feature parsing and large models, characterized in that, include: Step 1: Construct a skill constraint system for cross-platform code conversion. The skill constraint system includes a platform API mapping relationship library, a coding standard constraint library, a migration rule library, and a dependency replacement rule library. Step 2: Perform feature parsing on the source file to be converted, including: performing lexical and syntactic analysis on the source file to generate an abstract syntax tree, extracting semantic information from the abstract syntax tree, and classifying and merging the semantic information according to interface structure features, business logic features, lifecycle features, and external dependency features to form a structured feature set. Step 3: Construct a file dependency graph based on the structured feature set. The construction of the dependency graph includes: adding the current file to be converted as the root node to the dependency graph, traversing the import declaration nodes in the abstract syntax tree to extract candidate dependency nodes, recursively performing node initialization and import statement scanning on the candidate dependency nodes, establishing directed edges in the direction of the current file's dependency on the target file, recording the dependency type and reference symbol set, and detecting directed cycles and marking circular dependencies. Step 4: Retrieve associated files based on the current file to be converted, and extract interface signatures, global variable declarations, macro definition summaries, and context information from the associated files to form a dynamic context information package; Step 5: Convert the functional intent, structural features, dependency context and platform constraint information of the source file into an intermediate semantic representation that is independent of the specific programming language. The intermediate semantic representation includes page structure definition, state variable set, event triggering relationship, lifecycle binding, external interface call list and dependency graph. Step 6: Based on the intermediate semantic representation and combined with the skill constraint system, generate preliminary HarmonyOS target code; Step 7: Perform build checks on the initial HarmonyOS target code. The build checks include syntax checking, type checking, dependency resolution checking, compilation checking, and static rule checking. Step 8: When the build detection result is a failure, extract error features from the compilation failure log. The error feature information includes error line number, error column number, error type, missing symbol, unrecognized API, type mismatch information, syntax structure abnormal information, and dependency missing information. Step 9: Combine the error feature information, the current error code fragment, and the platform constraint information to generate error correction prompts. Input the error correction prompts into the large model to generate the repaired target code, and re-execute the build detection on the repaired code. Step 10: Set up a retry counter and circuit breaker exit mechanism. When the retry counter is greater than or equal to the maximum retry threshold, trigger the circuit breaker mechanism to terminate the large model repair process.

2. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The dependency types in the dependency graph include strong dependencies and weak dependencies; The strong dependency is: the compilation, type resolution or core semantic restoration of the current file must depend on the target file. Removing this dependency will result in unrecognizable type, missing method signature, missing inheritance relationship or compilation failure. The weak dependencies are: auxiliary information, optional capabilities, conditional compilation branches, resource identifiers, macro switches, logging tools, instrumentation tools, or downgraded implementations provided by the target file. Removing them will not affect the semantic parsing of the main process or can be replaced by the default strategy.

3. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The circular dependency detection uses the DFS three-color labeling method, which includes: marking unvisited nodes as white, marking nodes that are being visited and are located in the current recursion stack as gray, and marking nodes that have been visited as black; performing a depth-first search for each unvisited node, and if the target node is gray, it is determined that a directed cycle exists, the cycle is recorded and the path is interrupted from being expanded.

4. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The intermediate semantic representation is implemented using a structured data format, wherein: The page structure definition includes four fields: page unique identifier, page type, root container definition, and view hierarchy tree; The state variable set records the variable name, variable type, scope, access modifier, initial value, whether it is a UI state variable, the set of view identifiers it is bound to, and the variable update mechanism for each state variable; The event triggering relationship record includes the unique identifier of each event, event type, triggering source view, processing method name, processing method parameter list, and list of side effects generated after the event is triggered; The lifecycle binding establishes a mapping relationship between iOS lifecycle functions and corresponding HarmonyOS lifecycle callbacks, and records the logic types, target variables, and execution order to be executed in each lifecycle node; The external interface call list records the unique identifier, iOS-side interface name, interface category, method signature, parameter list, return type, and asynchronous mode of each external interface call; The dependency graph takes the current file as the root node and records its dependent file list, global variable declaration list, macro definition list, and enumeration type definition list.

5. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The process of generating preliminary HarmonyOS target code based on intermediate semantic representation includes: The logic in iOS that achieves UI changes by directly modifying view properties and actively refreshing controls is transformed into state-driven data binding logic, and a component structure that conforms to the HarmonyOS ArkUI specification is generated. Map instance variables, control variables, and UI state variables on the iOS side to state decorator variables, ordinary member variables, or shared state variables in HarmonyOS. Map the logic related to initialization, request triggering, and resource loading in the iOS lifecycle to the corresponding lifecycle callbacks in HarmonyOS for execution; Transform the complex nested constraint layout relationships in iOS into composable linear layouts, cascading layouts, or grid layout structures in HarmonyOS. The original iOS interface is replaced with an equivalent interface for the target platform. When there is no one-to-one correspondence, it is completed into a replacement interface or a combination interface that can be implemented by HarmonyOS based on the functional semantics.

6. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The syntax check in the build detection is performed by the built-in parser of the build toolchain, the type check is performed by calling the TypeScript or ArkTS type system, the dependency resolution check verifies the existence of the referenced package name, module path and exported symbols in the dependency repository of the HarmonyOS platform, the compilation check is performed by calling the compiler provided by the HarmonyOS SDK, and the static rule check is performed by ESLint or HarmonyOS dedicated Lint tool static scanning according to the HarmonyOS platform coding specifications.

7. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The closed-loop repair adopts an incremental repair method, including: Based on the error line number and column number in the compilation failure log, accurately locate the error position in the row and column index structure of the current code and determine the smallest error unit; Centered on the error location, the number of preceding and following context lines is dynamically determined based on the compilation error type, the boundary of the smallest error unit in the abstract syntax tree, the symbol reference range, and the scope of the repair impact. The preceding and following contexts are then extracted to form a local repair context window. Error feature information, local repair context window and platform constraint information are combined into error correction prompt words and fed into the large model for repair; The repair code snippets output by the large model are updated to the complete code file using a minimized replacement method, based on the row and column range of the original error location.

8. The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models according to claim 1, characterized in that, The maximum retry threshold Rmax is dynamically set based on historical migration success rate, error type, code complexity, and upper limit of computing power cost. The maximum retry threshold is set to 3 times for ordinary syntax errors, 5 times for type and API replacement errors, and 8 times for complex dependency errors. If the number of errors does not decrease after two consecutive rounds of repair or the same error occurs repeatedly, the circuit breaker will be triggered in advance before Rmax is reached.

9. A cross-platform HarmonyOS application code conversion system based on feature parsing and large models, characterized in that, The method for cross-platform HarmonyOS application code conversion based on feature parsing and large models, as described in any one of claims 1 to 8, includes: Constraint System Construction Module: Used to build a skill constraint system for cross-platform code conversion. The skill constraint system includes a platform API mapping relationship library, a coding standard constraint library, a migration rule library, and a dependency replacement rule library. Feature parsing module: used to perform lexical and syntactic analysis on the source file to be converted to generate an abstract syntax tree, extract semantic information from the abstract syntax tree, and classify and merge the semantic information according to interface structure features, business logic features, life cycle features and external dependency features to form a structured feature set; Dependency graph construction module: It is used to add the current file to be converted as the root node to the dependency graph, traverse the import declaration nodes in the abstract syntax tree to extract candidate dependency nodes, recursively perform node initialization and import statement scanning on the candidate dependency nodes, establish directed edges in the direction of the current file's dependency on the target file, record the dependency type and reference symbol set, and detect directed cycles and mark circular dependencies. Context extraction module: used to retrieve associated files based on the current file to be converted, and extract interface signatures, global variable declarations, macro definition summaries and necessary context information from the associated files to form a dynamic context information package; Intermediate semantic representation module: used to uniformly convert the functional intent, structural features, dependency context and platform constraint information of the source file into an intermediate semantic representation that is independent of the specific programming language. The intermediate semantic representation includes page structure definition, state variable set, event triggering relationship, lifecycle binding, external interface call list and dependency graph. Code generation module: used to generate preliminary HarmonyOS target code based on the intermediate semantic representation and the skill constraint system, and output the preliminary HarmonyOS target code to the construction and detection module; Build detection module: used to perform build detection on the initial HarmonyOS target code. The build detection includes syntax checking, type checking, dependency resolution checking, compilation checking and static rule checking, and outputs compilation success information or compilation failure logs. Error feature extraction module: used to parse the compilation failure log when the build detection result is failure, and extract error feature information, including error line number, error column number, error type, missing symbol, unrecognized API, type mismatch information, syntax structure abnormal information, and dependency missing information; Closed-loop repair module: used to combine the error feature information, the current error code fragment and the platform constraint information to generate error correction prompts, input the error correction prompts into the large model, generate the repaired target code, and send the repaired code back to the construction and detection module; Retry and Circuit Breaker Module: Used to set the retry counter and the maximum retry threshold. When the retry counter is less than the maximum retry threshold, the closed-loop repair continues. When the retry counter is greater than or equal to the maximum retry threshold, the circuit breaker mechanism is triggered to terminate the large model repair process.

10. The cross-platform HarmonyOS application code conversion system based on feature parsing and large models according to claim 9, characterized in that, It also includes an output module, which is used to output compileable HarmonyOS target code when the build detection passes, and to output a manual intervention result package containing the failure reason and context information when the circuit breaker mechanism is triggered. The manual intervention result package includes the latest code version, unresolved error logs, attempted repair records, and associated context information.

Images