A declarative ui automation cross-platform translation method

Abstract

This application relates to the field of automated migration technology for computer software, specifically a declarative method for automated cross-platform UI translation. The method includes: parsing a source UI file, extracting component types, attributes, modifiers, and child node information, and constructing a structured UI tree; mapping the component types, attributes, and modifiers in the UI tree to the basic structure of the target platform ArkUI based on a predefined cross-language component mapping table, generating an ArkUI code skeleton; constructing prompts, inputting the ArkUI code skeleton and prompts into a large language model, and using the large language model to generate preliminary ArkUI code; correcting syntax errors and incompatibilities in the generated preliminary ArkUI code using deterministic transformation rules, and outputting target code that can be directly compiled and run. This invention significantly improves the efficiency of engineering implementation of cross-platform UI translation while maintaining high-fidelity visual effects.

Description

Technical Field

[0001] This application relates to the field of computer software automated migration technology, and specifically to a declarative UI automated cross-platform translation method. Background Technology

[0002] Currently, with the booming development of multi-terminal operating systems, cross-platform migration of application ecosystems has become an important issue in the field of software engineering. In recent years, the rapid expansion of the HarmonyOS ecosystem has created an urgent need to migrate applications from mainstream declarative UI frameworks such as Android Jetpack Compose (KJC) and iOS SwiftUI to the HarmonyOS native platform (ArkUI framework).

[0003] Currently, UI development paradigms have fully shifted from the traditional imperative to the declarative. Declarative UI frameworks (such as KJC, SwiftUI, and ArkUI) significantly improve development efficiency by declaring the logical mapping between interface state and component layout. However, significant differences exist between different declarative frameworks in syntax, component systems, and state management mechanisms, posing a serious challenge to automated cross-platform translation.

[0004] In existing technologies, the following types of solutions are mainly used for code migration: Rule-based static transformation methods: These methods use predefined syntax maps and abstract syntax trees (ASTs) to perform mechanical transformations from the source language to the target language. For example, some tools can handle transformations within the same ecosystem (such as Java to Kotlin) or with highly similar syntax. However, when faced with frameworks like KJC, SwiftUI, and ArkUI, which are conceptually similar but differ significantly in syntactic details (such as decorators, modifier scope, and state management hooks), static rules struggle to cover all semantic gaps, leading to numerous compilation errors and visual distortions.

[0005] End-to-end translation methods based on Large Language Models (LLM): Recent research attempts to leverage the powerful code generation capabilities of LLM to directly translate UI code from a source platform into code for the target platform. However, such methods have inherent drawbacks. First, for emerging frameworks like ArkUI, high-quality code samples in the LLM pre-training corpus are scarce, leading to the model generating non-standard APIs or pseudocode that do not conform to the target platform's specifications. Second, declarative UIs have highly nested syntactic structures (such as closures and modifier chains), making LLM prone to issues like mismatched brackets and missing parameters when generating long code sequences. Finally, the compilation success rate of code generated by end-to-end methods is extremely low, often requiring significant manual intervention for syntax calibration and logic repair, severely limiting the practicality of automated tools.

[0006] Migration methods based on intermediate representations (IR): Some studies propose parsing the source UI into a platform-independent intermediate representation (such as a UI tree in JSON format) and then generating the target code from it. While this method can preserve the layout topology, it often loses key semantics when dealing with platform-specific design tokens, custom modifiers, and complex interaction logic due to the high abstraction level of the intermediate representation. This results in low visual fidelity of the generated code, and the generated code usually requires a lot of manual correction to meet compilation requirements.

[0007] In summary, existing automated translation technologies generally suffer from the following technical problems when dealing with the cross-platform migration of declarative UIs: semantic invalidation due to unfamiliarity with emerging target languages, syntactic chaos caused by nested declarative syntax, difficulties in semantic alignment of cross-platform components and property mappings, and high manual refactoring costs due to low compilability of translation results. Therefore, there is an urgent need for a hybrid translation method that integrates deterministic rule guidance with the flexible generation capabilities of LLM (Local Language Modeling) to achieve efficient, high-fidelity, and low-intervention-requirement automated cross-platform migration of declarative UIs.

[0008] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0009] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0010] This disclosure provides a declarative method for automated cross-platform UI translation, which significantly improves the efficiency of engineering implementation of cross-platform UI translation while maintaining high-fidelity visual effects.

[0011] In some embodiments, the method includes: Parse the source UI file, locate the UI entry point, identify UI components based on naming conventions and heuristics, filter non-UI logic code, extract component type, attributes, modifiers and child node information, and build a structured UI tree; Based on a predefined cross-language component mapping table, the component types, attributes and modifiers in the UI tree are mapped to the basic structure of the target platform ArkUI, generating the ArkUI code skeleton. Metadata that cannot be mapped is retained in the ArkUI code skeleton as comments. A prompt word containing system roles, context data, and explicit translation instructions is constructed. The ArkUI code skeleton and the prompt word are input into a large language model. The semantic understanding capabilities of the large language model are used to fill in placeholders, process unmapped elements, and generate preliminary ArkUI code. A pre-built single-sample example of skeleton-to-ArkUI code conversion is added to the large language model. This single-sample example demonstrates the conversion process from an ArkUI skeleton containing annotations of unmapped elements to complete executable ArkUI code. The generated initial ArkUI code is fixed with deterministic transformation rules to correct syntax errors and incompatibilities, and the output is target code that can be directly compiled and run. The deterministic transformation rules include constant inlining, lexical correction, layout attribute correction and structural integrity verification.

[0012] Preferably, the specific method for locating the UI entry point is as follows: When the source UI file is a KJC framework: parse the source code into an abstract syntax tree, traverse the nodes of the abstract syntax tree, locate the top-level function with the @Composable annotation and no input parameters, and use it as the UI entry point; When the source UI file is a SwiftUI framework: the source code is parsed into an abstract syntax tree, the structure declarations that conform to the View protocol are identified, and the body property inside is used as the UI entry point.

[0013] Preferably, the UI component identification based on naming convention heuristic rules specifically includes: Determine whether an abstract syntax tree node is a function call or initialization call that follows the upper camelCase naming convention; If so, then identify it as a potential UI component; If not, determine whether it meets the component blacklist. If it is a non-UI functional entity in the component blacklist, perform pruning. The component blacklist includes: language-specific hook functions, SwiftUI property wrappers, and lifecycle modifiers.

[0014] Preferably, the specific methods for extracting component type, attributes, modifiers, and child node information are as follows: Iterate through the parameter list of the UI component, store the configuration in the form of chained calls into the modifier field, and store the configuration in the form of named parameters into the attribute field; If the parameters of a UI component are not literals or identifiers, then a sub-recursive call is made to extract its metadata; After extraction, the extracted attributes and modifiers are standardized by removing quotes, converting values, and parsing constants. The structured UI tree is represented by a quadruple that includes component type, attributes, modifiers, and child node information.

[0015] Preferably, the prompt words include system roles, context data, and explicit translation instructions; The system roles clearly define the task positioning of the large language model; The context data includes the ArkUI skeleton generated during the skeleton construction phase and the design tokens extracted from the metadata extraction phase, including a set of color constants and a set of size constants; The explicit translation instructions clearly inform the large language model of the requirements during the translation process, thus constraining the translation behavior of the large language model.

[0016] Preferably, the single-sample example demonstrates the transformation process from an ArkUI skeleton containing unmapped element annotations to complete executable ArkUI code, and includes the following syntax error types: attribute assignment error, modifier chaining error, layout attribute expansion error, component naming error, and state management error.

[0017] Preferably, the constant inline specifically includes: Construct a replacement mapping that replaces the design token identifiers defined outside all components in the code with their corresponding literal values; the replacement mapping is as follows: , in, This is the code after constant inlining. For translated code containing unresolved external constant references, For identifiers, For identifier Associated constant values, The function is used to determine the definition of the external static class in the source code. A set of design token identifiers defined outside all components; The conversion operator removes external static class definitions that are no longer referenced after inlining, thus eliminating the source language's static class dependency; the conversion operator is as follows: , in, For the transformation operator, This indicates the design token class definition to be removed. This indicates the translation of all class definitions in the code. For removal conditions: if No longer cited Then remove it from the code.

[0018] Preferably, the lexical correction utilizes a lexical token mapping table to replace the lexical tokens in the initial ArkUI code with the standard syntax elements corresponding to ArkUI; if the lexical token mapping table does not have a corresponding mapping relationship, the metalexical tokens are retained; The layout attribute modification specifically includes: Define layout attribute mappings to identify abbreviated layout attributes in the source language for horizontal, vertical, or all directions; Expand the abbreviated layout properties into a set of specific direction properties compatible with ArkUI, where the horizontal abbreviated properties are expanded into left and right properties, and the vertical abbreviated properties are expanded into top and bottom properties.

[0019] Preferably, the structural integrity verification includes two stages: Component placement validity check: Check whether the component node conforms to the valid parent-child pairing set of ArkUI. If there is an invalid parent-child pairing, use the repair function to replace it with a semantically neutral valid component. Separator balance check: Calculate the balance operator to characterize the imbalance of separators in the code, and append missing closing separators to the end of the code based on the imbalance. The specific formula is as follows: , in, The imbalance of separators is calculated by subtracting the number of right closing brackets from the number of left opening brackets. Corresponding type of closing delimiter, For the balancing operator, As an intermediate variable, This is the complete set of delimiters.

[0020] The declarative UI automated cross-platform translation method provided in this disclosure can achieve the following technical effects: This invention effectively solves the common grammatical confusion problem in large language models when processing declarative UIs through a dual mechanism of heuristic skeleton construction and post-processing repair. Furthermore, this invention does not rely entirely on the model's spontaneous generation; instead, it extracts source platform metadata through heuristic rules and constructs a deterministic code skeleton, effectively preventing logical illusions from arising in the model. A post-processing repair rule library based on experience has been established, which can automatically identify and repair typical grammatical errors using pattern matching technology, transforming the work that originally required a large amount of manual debugging into automated processing.

[0021] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0022] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the metadata extraction algorithm provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of the skeleton construction algorithm provided in the embodiments of this disclosure; Figure 4 This is a schematic diagram of the device structure provided in the embodiments of this disclosure. Detailed Implementation

[0023] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0024] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0025] Unless otherwise stated, the term "multiple" means two or more.

[0026] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0027] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0028] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0029] Example 1 like Figure 1As shown, a declarative, automated cross-platform UI translation method is designed with the core principle of "layered migration and semantic fidelity." It receives UI files in the source language (KJC or SwiftUI) as input, processes them through multiple stages, and outputs executable code that is semantically equivalent to the source file and conforms to the ArkUI specification. Overall, the ArkUI translator ArkTrans comprises four interconnected and progressively advancing main stages. Each stage has a clear division of labor and works collaboratively to ensure the integrity and accuracy of the migration process, including: S1: Parse the source UI file, locate the UI entry point, identify UI components based on naming conventions and heuristics, filter non-UI logic code, extract component type, attributes, modifiers and child node information, and build a structured UI tree; S2: Based on a predefined cross-language component mapping table, the component types, attributes and modifiers in the UI tree are mapped to the basic structure of the target platform ArkUI, generating the ArkUI code skeleton. Metadata that cannot be mapped is retained in the ArkUI code skeleton as comments. S3: Construct prompt words containing system roles, context data, and explicit translation instructions. Input the ArkUI code skeleton and prompt words into the large language model. Use the semantic understanding capabilities of the large language model to fill in placeholders, process unmapped elements, and generate preliminary ArkUI code. S4: The generated preliminary ArkUI code is fixed with deterministic transformation rules to correct syntax errors and incompatibilities, and the target code that can be directly compiled and run is output. The deterministic transformation rules include constant inlining, lexical correction, layout attribute correction and structural integrity verification.

[0030] As a refinement of the above embodiments, step S1 serves as the foundation of the entire method. Its core task is to parse the syntactic structure and logical relationships of the source UI file, accurately extract the component hierarchy, component attributes, modifier configurations, and nesting relationships between components, and finally construct a structured UI tree in JSON format. The key to this step is to filter out non-UI-related logic code, retain all the core elements required for subsequent semantic translation, and provide clear and standardized data support for subsequent skeleton construction.

[0031] The core objective of metadata extraction is to extract metadata hierarchically and accurately from the source UI file, construct a structured UI tree, and fully retain the necessary elements (such as component types, component attributes, modifiers, and nesting relationships) and UI layout logic required for subsequent semantic translation, providing standardized data input for later stages. Each node in the UI tree uses a four-tuple. Component type (comp), properties (props), modifiers (mod), child nodes (children) The specific meanings and specifications of each field are defined as follows: comp (component type): Used to identify the category of UI component corresponding to the current node, such as button component (Button), text component (Text), layout container component. It is the core identifier that distinguishes different UI elements and directly determines the basic functions and rendering method of the component.

[0032] props (properties): These exist in the form of key-value pairs and are used to describe the core configuration parameters of a component, that is, the named parameters passed to the component, such as the display text of a button, the font size of a text component, etc., which directly affect the appearance and functionality of the component.

[0033] mod (modifier): Also exists in the form of key-value pairs, used to describe the style decoration and behavior configuration of a component, that is, chained modifier calls, such as the alignment of the component, click events, etc., used to refine the display effect and interaction logic of the component.

[0034] children (child nodes): Exists as an ordered list, used to store all child components of the current component. It strictly preserves the nesting level and order of the original UI, ensuring that the structure of the UI layout is completely consistent with the source file, and is the key to restoring the visual effect of the UI.

[0035] To achieve accurate extraction of the aforementioned metadata, a recursive extraction process was designed and implemented (as shown in the metadata extraction algorithm). This algorithm uses an Abstract Syntax Tree (AST) to perform deep parsing of the source UI file, accurately identify UI-related code patterns, and filter out non-UI logic (such as data requests, core logic of state management, utility functions, etc.) to ensure that the extracted metadata is pure and efficient, containing only the core information required for UI migration.

[0036] Specifically, such as Figure 2 As shown, the metadata extraction algorithm includes: S101: Parse source UI files of type KJC or SwiftUI. In KJC code, locate the top-level function with the @Composable annotation and no input parameters. In SwiftUI code, locate the struct that conforms to the View protocol and its internal body property. Set the location result as the root node of the UI tree.

[0037] S102: Using the root node as a reference, traverse the remaining code areas in the source file, collect the declarations and implementations of all user-defined UI components, and store the collection results into the custom component collection.

[0038] S103: Load the preset component blacklist, starting from the determined root node, and call and execute the Extract recursive function.

[0039] S104: Perform type determination on the currently traversed node, retain only nodes with function call and initialization call types, and return null values ​​for other types of nodes.

[0040] S105: Extract the name of the current node, compare the node name with the blacklist, and determine whether it conforms to the big camelCase naming format. If the node does not meet the conditions, return an empty value directly.

[0041] S106: When the node name belongs to the collection of custom components, read the complete definition of the component, replace the current node with the component definition, and re-enter the recursive parsing process.

[0042] S107: For a valid UI component node, create a four-tuple structure consisting of component type, attribute set, modifier set, and child node list to complete node initialization.

[0043] S108: Iterate through all input parameters of the current component, identify and separate modifier type parameters and property type parameters, and store the parameters into the modifier set mod and the property set props respectively.

[0044] S109: Perform recursive extraction operations on nested components in the parameters, and perform standardized processing such as dequoting, numerical conversion, and constant resolution on literals and identifiers in the parameters.

[0045] S1010: Completes recursive parsing and data filling of all nodes, generating a JSON-formatted UI tree containing a complete hierarchical structure.

[0046] This algorithm defines the complete metadata extraction process in detail, from entry point location, custom component collection, blacklist loading, to recursive extraction of component information and standardization processing. Each step revolves around the goal of "accurate extraction and semantic preservation," ensuring that the generated UI tree can completely and accurately reflect the structure and configuration of the source UI file. Furthermore, auxiliary functions further guarantee the standardization and efficiency of the extraction process.

[0047] (1) The specific method for locating the UI entry point is as follows: In declarative UI frameworks (KJC, SwiftUI), when a mobile application's UI page launches, a specific template configuration code is needed as the compiler's execution entry point. This code is also the root node of the entire UI tree, determining the initial rendering logic of the UI page. Due to significant differences in the syntax of UI frameworks across different platforms, the declaration methods of entry points also vary. If the entry point cannot be accurately located, metadata extraction will start from the wrong level, leading to problems such as missing components and structural errors. To solve this problem, the algorithm implements the `LocateEntryPoint` function, specifically designed to locate the UI entry point of the source UI file. The specific logic is as follows: The KJC framework parses the source code into an abstract syntax tree (API). It traverses the API tree nodes to locate the top-level function annotated with `@Composable` and without input parameters, using this as the UI entry point. These functions in the KJC framework are typically used to define the main UI entry point; they do not contain complex business logic and are only responsible for declaring and laying out UI components, serving as the root node of the UI tree. For example, the `MainScreen` function annotated with `@Composable` is a typical KJC UI entry point.

[0048] The SwiftUI framework parses the source code into an abstract syntax tree, identifies struct declarations that conform to the View protocol, and uses their internal `body` property as the UI entry point. These structs are the core carriers of UI pages in SwiftUI, and their internal `body` property is used to declare the layout and structure of UI components. Therefore, the algorithm uses this `body` property as the starting point for recursive traversal, ensuring that metadata is extracted starting from the root node of the UI layout.

[0049] It should be noted that the core value of the entry point location process lies in separating pure UI declaration code from template configuration and business logic code, establishing clear scanning boundaries for subsequent metadata extraction, avoiding interference from non-UI logic with the extraction results, and ensuring that the extracted metadata focuses only on UI-related structures and configurations.

[0050] (2) After locating the UI entry point, the algorithm enters the component identification stage. Based on the naming convention heuristic, it recursively traverses the AST to identify all UI components. The core logic of this heuristic is: if AST node n is a function call or initialization call that follows PascalCase, it is considered a potential UI component. This rule is applicable in both the KJC and SwiftUI frameworks.

[0051] The UI component identification based on naming convention heuristic rules specifically includes: Determine if an abstract syntax tree node is a function call or initialization call that follows upper camelCase naming convention: In the KJC framework, UI components are usually declared as functions annotated with @Composable. For example, the button component (Button), the layout container component (Column), and the text component (Text) are all @Composable functions named in upper camelCase. They are instantiated in the UI layout by calling functions in upper camelCase, so they can be quickly identified by the naming rules.

[0052] In the SwiftUI framework, UI components are defined as structs that conform to the View protocol. These components are instantiated within the body property using a large camelCase initialization call, and therefore can also be identified by the large camelCase naming convention.

[0053] If so, it will be identified as a potential UI component.

[0054] If not, determine whether it meets the component blacklist. If it is a non-UI functional entity in the component blacklist, then perform pruning.

[0055] To eliminate non-visual interference and ensure that all extracted components are UI (user interface) related elements, the algorithm introduces a component blacklist and performs pruning operations on non-UI functional entities. The blacklist contains three core elements: first, language-specific hook functions (such as KJC's LaunchedEffect and SideEffect functions, used to handle lifecycle logic, not UI components); second, SwiftUI property wrappers (such as local state @State, two-way binding @Binding, and observables @ObservedObject, used for state management, not UI entity components); and third, lifecycle modifiers (such as SwiftUI's .onAppear and .onDisappear callbacks, used to listen to component lifecycles, only adding decorative logic to components, not independent UI components).

[0056] Complete blacklist identifier: KJC source language: State storage (remember), mutable state creation (mutableStateOf), mutable list state (mutableStateListOf), derived state (derivedStateOf), produced state (produceState), color class (Color), color companion object (Color.Companion), side effect (SideEffect), launch side effect (LaunchedEffect), disposable side effect (DisposableEffect), format, string resource (stringResource), dimension resource (dimensionResource), local context (LocalContext), local pixel density (LocalDensity), local lifecycle owner (LocalLifecycleOwner).

[0057] SwiftUI source language: Color, Divider, EmptyView, AnyView, someView, opacity, font, foregroundColor, frame, padding, fill, overlay, stroke, lineWidth, onSurface, Colors, Binding, CGVector, State, ObservedObject, Environment, and GeometryReader are used to ensure complete coverage of pruning logic.

[0058] Furthermore, in actual UI development, developers often define custom UI components (such as custom buttons and custom layout containers). These components are defined outside the entry point. Without special handling, their internal structure cannot be identified during metadata extraction, resulting in missing components. Therefore, the algorithm uses the `CollectCusCompDefs` function to collect all custom component definitions outside the entry point and construct a custom component set. If the identified component points to a locally defined component in the custom component set, the algorithm uses the `FetchCompDef` function to obtain the complete definition of that custom component, parses its internal UI structure, and fully expands it into basic UI elements. This ensures that the metadata of the custom component is completely extracted, and the UI tree structure is completely consistent with the source file.

[0059] (3) After confirming that the current node is a valid UI component, the algorithm enters the attribute extraction and recursion stage, collects the associated attributes of the component and establishes the subordinate relationship, and recursively processes child nodes to ensure the hierarchical integrity of the UI tree. The specific process is as follows: First, by traversing the component's parameter list, the configuration in the form of chained calls is stored in the mod field, and the configuration in the form of named parameters is stored in the props field, clearly distinguishing the component's properties and modifiers to avoid confusion.

[0060] If the parameter of a component is not a literal (such as a string or number) or an identifier (such as a constant reference), then the parameter is likely to be a nested UI component (for example, the child node of a Button component is a Text component). In this case, the Extract sub-recursive call will be triggered to extract the metadata of the nested component, ensuring that the parent-child nesting relationship in the source code is faithfully reconstructed into branches of the hierarchical UI tree, and there will be no problem of lost component nesting or disordered hierarchy.

[0061] The algorithm's auxiliary function, Normalize, standardizes the extracted attribute and modifier values, eliminating interference from syntactic differences between source languages ​​and providing data in a unified format for subsequent cross-language mapping. The core logic of the standardization process includes three aspects: First, remove the quotes from string type values ​​(e.g., convert "Confirm" to Confirm for easier subsequent mapping).

[0062] Second, convert numeric strings to numbers (e.g., convert "16" to 16).

[0063] Third, parse simple constant references (such as converting the design token text size DesignTokens.textSize to its corresponding specific value) to ensure that the extracted values ​​can be directly used for subsequent skeleton construction and code generation.

[0064] As a refinement of the above embodiments, step S2, based on the structured UI tree generated in the metadata extraction stage, has the core task of synthesizing a deterministic ArkUI code skeleton, with two core objectives: First, determine the topology of the UI layout to ensure that the layout of the ArkUI skeleton is completely consistent with the source UI file.

[0065] Secondly, it preserves as much metadata as possible that cannot be heuristically migrated (such as unknown attributes and custom modifiers), and annotates it with comments to provide clear guidance for subsequent LLM-driven translation. The detailed process of skeleton construction is shown in the skeleton construction algorithm. This algorithm uses a predefined mapping dictionary to achieve an initial mapping from source language components and attributes to ArkUI, generating a complete and clearly annotated ArkUI skeleton.

[0066] Specifically, such as Figure 3 As shown, the skeleton construction algorithm is as follows: S201: Load the component mapping dictionary, property mapping dictionary, and modifier mapping dictionary from the source language to ArkUI, and start the skeleton constructor (BuildSkeleton) from the UI tree root node.

[0067] S202: Based on the component type of the current node, match and retrieve the corresponding ArkUI component template from the mapping dictionary.

[0068] S203: Iterate through all properties of the current component. Properties with corresponding mapping relationships directly replace the placeholders in the template. Properties without mapping relationships are written to the template as comments.

[0069] S204: Traverse all modifiers of the current component. Modifiers with corresponding mapping relationships are concatenated into the ArkUI chained call format, and modifiers without mapping relationships are written into the template as comments.

[0070] S205: Traverse all child nodes of the current component, recursively generate the ArkUI skeleton corresponding to each child node, and fill it into the specified position of the parent component template after splicing it in the original order.

[0071] S206: Complete the skeleton transformation of the entire UI tree and output a complete ArkUI code skeleton with annotations.

[0072] The algorithm clearly defines the complete skeleton construction process. Its core relies on a predefined cross-language mapping dictionary D, which is crucial for mapping the source language to ArkUI. Its contents will be explained further later. The entire process starts from the root node of the UI tree, recursively processing each node to gradually generate the ArkUI skeleton. This ensures the skeleton's structure is completely consistent with the UI tree, while also marking unmappable elements to provide clear guidance for subsequent LLM translation.

[0073] First, the algorithm retrieves the component template for the current node n from the mapping dictionary D. The mapping dictionary D is a predefined cross-language mapping table based on the syntax specifications of KJC, SwiftUI, and ArkUI, and its core content includes three parts: First, there is the component mapping from the source language (KJC / SwiftUI) to ArkUI (e.g., the KJC button component Button is mapped to the ArkUI button component Button, and the SwiftUI layout container component VStack is mapped to the ArkUI layout container component Column).

[0074] Second, attribute mapping (e.g., KJC's value is mapped to ArkUI's text label, and SwiftUI's font is mapped to ArkUI's font size fontSize()).

[0075] Thirdly, there is the mapping of modifiers (such as KJC's alignment mapping to ArkUI's alignment mapping, and SwiftUI's component appearance mapping to ArkUI's component appearance mapping to ArkUI's onAppear).

[0076] The algorithm then iterates through all properties of the current component: if a property has a corresponding entry in the property mapping table of the mapping dictionary D, it is directly injected into the ArkUI component template, replacing the placeholder in the template (e.g., replacing the value placeholder {{value}} with the specific property value); if the property is not defined in the mapping table (i.e., cannot be migrated through heuristic rules), it is preserved in the skeleton as an annotation, marked "unmapped property," reminding the LLM to handle it specifically and avoid property loss. The processing logic for modifiers is similar to that for properties: known modifiers are converted into the chained call form supported by ArkUI, while unknown modifiers are preserved as annotations to ensure that all modifier information is not lost.

[0077] After processing the attributes and modifiers of the current node, the algorithm recursively builds a skeleton for all child nodes, injects the skeleton content of the child nodes into the template of the current node, replaces the child node placeholders {children} in the template, and finally generates a complete ArkUI skeleton. The characteristics of this skeleton are: all components, attributes, and modifiers that can be heuristically mapped have undergone preliminary translation; unknown elements have been annotated; and the layout topology is completely consistent with the source UI file, providing clear structural constraints and complete metadata support for subsequent LLM-driven translation.

[0078] As a refinement of the above embodiment, step S3 invokes a Large Language Model (LLM) to translate the ArkUI skeleton generated during the skeleton construction phase into executable ArkUI code. Since the ArkUI skeleton contains unmapped attributes, modifiers, and complex semantic logic, a complete translation cannot be achieved solely through heuristic rules. LLM, however, possesses powerful natural language understanding and code generation capabilities, enabling it to perform complex semantic transfer and grammatical correction based on contextual information. To improve the accuracy and standardization of LLM translation, a structured prompting strategy and a corresponding skeleton-to-ArkUI single-sample learning example are designed to provide precise guidance for LLM and ensure that the generated code conforms to the ArkUI specification.

[0079] (1) Prompt structure To guide the LLM to accurately translate the skeleton into ArkUI code, the prompts are divided into three clearly defined parts. These parts work together to ensure that the LLM can clearly understand the task objectives, obtain the necessary contextual information, and follow clear translation rules, as follows: System Role: Clarify the LLM's task positioning, informing them that "as an ArkUI code translation expert, you need to translate the ArkUI skeleton into executable ArkUI code, strictly follow the ArkUI syntax specifications, ensure that the code semantics are consistent with the source UI, and fix unmapped elements marked in the comments in the skeleton," helping the LLM to establish a correct role awareness and focus on the core tasks.

[0080] Contextual data: This includes two core components. The first is the ArkUI skeleton generated during the skeleton construction phase (providing basic structure and annotation information). The second is design tokens (such as #FF0000, 16dp, etc.) extracted from the metadata extraction phase, including color constant sets and size constant sets. This ensures that the LLM can accurately use these design tokens during the translation process, preserving the visual style of the source UI and avoiding style deviations.

[0081] Explicit translation instructions: Clearly inform the LLM of the core requirements in the translation process, such as "prioritize the use of mapping rules in the mapping dictionary for translation", "unmapped elements need to be combined with the source UI semantics to generate alternative solutions that conform to the ArkUI specification", "ensure that the code syntax is correct and can be directly compiled and run", "preserve the layout structure and interaction logic of the source UI", etc., to constrain the LLM's translation behavior and improve translation quality. Specifically, the following constraints apply: Only Stack, Column, Row, Grid, List, Text, Button, Image, Progress, Slider, Blank, Divider, and TextInput components should be used; the constructors for Column and Row layouts should use the {space:N} format to pass spacing parameters, and chained modifier methods should be called after curly braces; child elements of List must be wrapped with ListItem, and child elements of Grid must be wrapped with GridItem; state variables must be referenced using the this. prefix; all / / comments should be replaced with actual implementation code based on the comment metadata in the skeleton; only compileable ArkTS code should be output, without any additional explanatory text.

[0082] This includes tooltip templates for different scenarios (KJC to ArkUI, SwiftUI to ArkUI), adapting to the syntax features of different source languages. Notably, the addition of explicit color and size metadata is crucial for ensuring visual style consistency. By adding explicit metadata, the accuracy of style migration is improved, significantly reducing visual discrepancies.

[0083] (2) Example of single-sample learning Although the ArkUI skeleton has completed the mapping and annotation of some elements through heuristics, there are still many source language-specific annotation elements and complex semantic logic that need to be translated (such as custom modifiers, special layout constraints, state management logic, etc.). To enable LLMs to quickly learn to write ArkUI code that conforms to the specifications based on the skeleton, a single-sample learning example has been created for LLMs to learn the context and help them master the translation logic and ArkUI syntax specifications.

[0084] This single-sample example covers most of the syntax error types revealed by empirical studies, ensuring that LLM can specifically avoid these errors, including: property assignment errors (such as the correct assignment format of ArkUI properties), modifier chaining errors (such as the calling order and syntax of ArkUI modifiers), layout property expansion errors, component naming errors (such as the correct naming conventions for ArkUI components), and state management errors (such as the declaration and usage of state variables in ArkUI).

[0085] The example is designed following the "skeleton-correct code" correspondence pattern, that is, it provides a complete ArkUI skeleton (including unmapped elements and comments) and the corresponding complete executable ArkUI code, clearly demonstrating the handling of unmapped elements and the adaptation logic of syntax rules, so that LLMs can quickly learn from the example, master the conversion rules from skeleton to code, and improve the accuracy and efficiency of translation.

[0086] As a refinement of the above embodiment, step S4 is the repair phase. Even if the LLM is provided with the ArkUI skeleton and single-sample learning examples to help it become familiar with the ArkUI programming specifications, the code generated by the LLM may still have a large number of syntax errors, layout incompatibilities, and incomplete structures. This is because the LLM may be interfered with by the source language syntax or may not have a thorough understanding of some ArkUI specifications when generating the code. To solve this problem, the post-repair phase uses a set of deterministic transformation rules based on empirical research to execute the post-repair module, systematically repairing these common errors and ensuring that the final output code conforms to the requirements of the HarmonyOS compiler and the ArkUI specifications, and can be directly compiled and run. These transformation rules cover the four most common types of errors in LLM-generated code, and are formally defined as follows: (1) Constant Inlining (CI) In source language frameworks (KJC, SwiftUI), design tokens (including color, spacing, typography, layout margins, etc.) are usually stored centrally in static classes for easy unified management and maintenance. In KJC, these constants are typically managed using object declarations.

[0087] In SwiftUI, enums with static properties are typically used to manage constants.

[0088] During the migration process, LLMs often directly copy language-specific class references into the translated ArkUI code, mixing in component instantiation logic. However, these source language static classes do not exist in the ArkUI environment, causing the code to fail to compile.

[0089] To address this issue, a constant inlining rule was designed. By replacing constant references with concrete literals, the dependency on static classes in the source language is eliminated. The formal definition of the specific rule is as follows: set up For translated code containing unresolved external constant references, This is a set of design token identifiers (i.e., constant names in static classes of the source language) defined outside all components. Build the replacement map: , in, The function is used to return an identifier based on the definition of the external static class in the source code. Associated constant values . This is the code after constant inlining, where All occurrences are replaced with the matching literal. Eliminate the dependency on the DesignTokens class.

[0090] After constants are inlined, the static classes originally used to manage these constants become unreferenced and invalid code. This code cannot be compiled in the ArkUI environment and also increases code redundancy. Therefore, a conversion operator was designed. This is used to remove all such unused class definitions, formally defined as follows: , in, This indicates the translation of all class definitions in the code. This indicates the design token class definition to be removed. For removal conditions: if No longer cited If the reference count is 0, then remove it from the code. Operator By pruning these obsolete classes, clean and concise ArkUI code is output, avoiding compilation errors caused by invalid code.

[0091] (2) Lexical Repair (LR) When generating ArkUI code, LLM is often interfered with by the syntax of the source language, directly copying the lexical structure of the source language into the ArkUI code, leading to syntax errors. For example, the `toInt` method (used for type conversion in KJC) is directly copied into the ArkUI code (the corresponding method in ArkUI is for converting numbers); the string concatenation symbol `+` from SwiftUI is directly used for string concatenation in ArkUI (string concatenation in ArkUI requires template interpolation). To solve these lexical errors, a lexical correction function was designed based on lexical conversion rules. The specific logic is as follows: , in, For lexical tokens in the source language, This represents the lexical token corresponding to the mapped ArkTS. It is a lexical token mapping table that contains the correspondence between the source language (KJC / SwiftUI) and ArkUI in terms of basic APIs, operators, style tokens, etc., to ensure lexical compatibility.

[0092] For each lexical token in the translation code (Including API methods, operators, constant formats, etc.), if the lexical token mapping table There is a corresponding mapping relationship. Then Replace with the lexical token corresponding to ArkUI If no corresponding mapping relationship exists, then retain it. Unchanged. Besides the examples above, common lexical mappings include: KJC's `println` mapping to ArkUI's `console.log`, SwiftUI's `.count` mapping to ArkUI's `length`, and KJC's `==` mapping to ArkUI's `===`. Lexical correction ensures that the code conforms to ArkUI's syntax specifications at the lexical level, eliminating compilation errors caused by lexical differences.

[0093] (3) Layout Property Repair (LPR) In the original language framework, layout properties support abbreviations such as horizontal and vertical, which simplify code writing. However, ArkUI does not support these abbreviations, only supporting property configurations specific to a given direction. During the translation process, it's easy to directly copy the abbreviations from the original language into the ArkUI code, leading to syntax errors and affecting layout rendering.

[0094] To solve this problem, layout property mapping was defined. The abbreviated layout properties for each source language Expand into a specific set of directional attributes compatible with ArkUI, where The property name that represents the source language layout property. The corresponding attribute value is formally defined as follows: , in, To the source language layout attributes The correction function, To show the traversal of the set Each of them Construct property pairs Then, the union of all constructed attribute pairs is taken to form a set of expanded ArkUI layout attributes. It is a collection of source language abbreviation attributes with defined expansion rules. It is a simplified attribute. The corresponding set of ArkUI layout attribute names. For example, Then, horizontal:16 in the source language will be expanded to {left:16,right:16}; Then vertical:8 will be expanded to {top:8,bottom:8}; Then all:12 will be expanded to {left:12,right:12,top:12,bottom:12}. This transformation rule will be applied to all layout properties in the code to ensure that the generated ArkUI component has correct syntax, while maintaining a visual layout consistent with the source UI as much as possible.

[0095] (4) Structural Integrity Verification (SIV) After constant inlining, lexical correction, and layout attribute correction, the generated ArkUI code is basically syntactically compliant. However, structural errors such as violations of ArkUI component placement rules or mismatched separators may still exist, leading to compilation failures or layout errors. Typical structural errors fall into two main categories: first, incorrect component placement, such as Blank components (blank placeholder components) which are only valid within linear layout containers (Row / Column), but LLM may incorrectly place them in non-linear containers such as stacked layouts, list layouts, or grid layouts; second, mismatched separators, such as missing closing braces, parentheses, or square brackets, resulting in incomplete code syntax.

[0096] To address these structural errors, a two-stage structural verification process is defined. This process, using a structural validator and a balancing operator, ensures the integrity of the code structure and the legal placement of components, as detailed below: Phase 1: Component Placement Validation. Let H be the component hierarchy of the generated code, and define a structure validator. Used to validate each component node Does it conform to the valid parent-child pairing set of ArkUI? ( It contains all legal parent-child component pairings in ArkUI, and its formal definition is as follows: , in, Represents a node The parent node, This is a fix function used to replace invalid component nodes with semantically neutral but syntactically valid alternatives. For example, it can replace a Blank component placed in a Stack with an empty Column component, which does not affect the overall layout, but ensures that the component is placed legally and avoids compilation errors.

[0097] Phase Two: Delimiter Balance Check. A balance operator B is defined to ensure that all delimiters {}, (), and [] in the code are correctly matched, avoiding issues of missing or redundant delimiters. In practical applications, the code generated by LLM usually only lacks closing delimiters at the end (such as curly braces and parentheses). Therefore, the core logic of the balance operator B is to calculate the imbalance of delimiters in the code and then append the necessary closing delimiters to the end of the code. The formal definition is as follows: , in, The unbalance of separators is calculated by subtracting the number of right closing brackets (}, ]) from the number of left opening brackets ({, (, [).). For the corresponding type of closing separator (e.g., the left opening bracket is {, then...) for}); This indicates that the delimiter will be closed. repeat Then, append it to the end of the code S after the above steps. For example, if the code is missing two closing curly braces, then... =2, =}, operator B will append}} to the end of the code to ensure that the delimiters match and the code structure is complete.

[0098] Example 2 Combination Figure 4 As shown, this disclosure provides a declarative UI automated cross-platform translation device 300, including a processor 304 and a memory 301. Optionally, the device may further include a communication interface 302 and a bus 303. The processor 304, communication interface 302, and memory 301 can communicate with each other via the bus 303. The communication interface 302 can be used for information transmission. The processor 304 can call logical instructions in the memory 301 to execute the declarative UI automated cross-platform translation method of the above embodiment.

[0099] Furthermore, the logic instructions in the aforementioned memory 301 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0100] The memory 301, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 304 executes functional applications and data processing by running the program instructions / modules stored in the memory 301, thereby realizing the declarative UI automated cross-platform translation method in the above embodiments.

[0101] The memory 301 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 301 may include high-speed random access memory and may also include non-volatile memory.

[0102] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a disk, or an optical disk, and other media capable of storing program code. It can also be a transient storage medium.

[0103] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the claims. As used in the description of embodiments and claims, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used in this application means including one or more of the associated listed items and all possible combinations thereof. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0104] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0105] The methods and products (including but not limited to devices and equipment) disclosed in the embodiments herein can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection shown or discussed between each other may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms. 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 units may be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A declarative UI automated cross-platform translation method, characterized in that, The method includes the following steps: Parse the source UI file, locate the UI entry point, identify UI components based on naming conventions and heuristics, filter non-UI logic code, extract component type, attributes, modifiers and child node information, and build a structured UI tree; Based on a predefined cross-language component mapping table, the component types, attributes and modifiers in the UI tree are mapped to the basic structure of the target platform ArkUI, generating the ArkUI code skeleton. Metadata that cannot be mapped is retained in the ArkUI code skeleton as comments. Construct prompt words containing system roles, context data, and explicit translation instructions; input the ArkUI code skeleton and prompt words into a large language model, utilize the semantic understanding capabilities of the large language model to fill in placeholders, process unmapped elements, and generate preliminary ArkUI code; add a pre-built skeleton-to-ArkUI code single-sample example to the large language model; the single-sample example demonstrates the conversion process from an ArkUI skeleton containing unmapped element annotations to complete executable ArkUI code; The generated initial ArkUI code is fixed with deterministic transformation rules to correct syntax errors and incompatibilities, and the output is target code that can be directly compiled and run. The deterministic transformation rules include constant inlining, lexical correction, layout attribute correction and structural integrity verification.

2. The declarative UI automated cross-platform translation method according to claim 1, characterized in that, The specific method for locating the UI entry point is as follows: When the source UI file is a KJC framework: parse the source code into an abstract syntax tree, traverse the nodes of the abstract syntax tree, locate the top-level function with the @Composable annotation and no input parameters, and use it as the UI entry point; When the source UI file is a SwiftUI framework: the source code is parsed into an abstract syntax tree, the structure declarations that conform to the View protocol are identified, and the body property inside is used as the UI entry point.

3. The declarative UI automated cross-platform translation method according to claim 1, characterized in that, The UI component identification based on naming convention heuristic rules specifically includes: Determine whether an abstract syntax tree node is a function call or initialization call that follows the upper camelCase naming convention; If so, then identify it as a potential UI component; If not, determine whether it meets the component blacklist. If it is a non-UI functional entity in the component blacklist, perform pruning. The component blacklist includes: language-specific hook functions, SwiftUI property wrappers, and lifecycle modifiers.

4. The declarative UI automated cross-platform translation method according to claim 3, characterized in that, The specific methods for extracting component type, attributes, modifiers, and child node information are as follows: Iterate through the parameter list of the UI component, store the configuration in the form of chained calls into the modifier field, and store the configuration in the form of named parameters into the attribute field; If the parameters of a UI component are not literals or identifiers, a sub-recursive call is made to extract its metadata; After extraction, the extracted attributes and modifiers are standardized by removing quotes, converting values, and parsing constants. The structured UI tree is represented by a quadruple that includes component type, attributes, modifiers, and child node information.

5. The declarative UI automated cross-platform translation method according to claim 1, characterized in that, The prompts include system roles, context data, and explicit translation instructions; The system roles clearly define the task positioning of the large language model; The context data includes the ArkUI skeleton generated during the skeleton construction phase and the design tokens extracted from the metadata extraction phase, including a set of color constants and a set of size constants; The explicit translation instructions clearly inform the large language model of the requirements during the translation process, thus constraining the translation behavior of the large language model.

6. The declarative UI automated cross-platform translation method according to claim 5, characterized in that, The single-sample example demonstrates the transformation process from an ArkUI skeleton containing unmapped element annotations to complete executable ArkUI code, and includes the following syntax error types: attribute assignment errors, modifier chaining errors, layout attribute expansion errors, component naming errors, and state management errors.

7. The declarative UI automated cross-platform translation method according to claim 1, characterized in that, The constant inline specifically includes: Build a replacement mapping to replace the design token identifiers defined in the code outside all components with their corresponding literal values; The application conversion operator removes external static class definitions that are no longer referenced after inlining, thus eliminating the source language's static class dependency.

8. The declarative UI automated cross-platform translation method according to claim 1, characterized in that, The lexical correction utilizes a lexical token mapping table to replace the lexical tokens in the initial ArkUI code with the standard syntax elements corresponding to ArkUI; If the lexical token mapping table does not have a corresponding mapping relationship, the metalexical token is retained. The layout attribute modification specifically includes: Define layout attribute mappings to identify abbreviated layout attributes in the source language for horizontal, vertical, or all directions; Expand the abbreviated layout properties into a set of specific direction properties compatible with ArkUI, where the horizontal abbreviated properties are expanded into left and right properties, and the vertical abbreviated properties are expanded into top and bottom properties.

9. The declarative UI automated cross-platform translation method according to claim 1, characterized in that, The structural integrity verification includes two stages: Component placement validity check: Check whether the component node conforms to the valid parent-child pairing set of ArkUI. If there is an invalid parent-child pairing, use the repair function to replace it with a semantically neutral valid component. Separator balance check: Calculate the balance operator to characterize the imbalance of separators in the code, and append missing closing separators to the end of the code based on the imbalance.

10. A declarative UI automated cross-platform translation device, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to execute the declarative UI automation cross-platform translation method as described in any one of claims 1 to 9 when running the program instructions.

Images