A method, system, device, and computer storage medium for generating user interfaces

Abstract

This application discloses a user interface generation method, system, device, and computer storage medium, relating to the field of computer technology. The method involves: acquiring design draft data of a target UI; parsing the design draft data into a design node tree; performing code mapping on each node in the design node tree, converting the platform-native attributes of each node into DSL attribute parameters; compressing the design node tree to obtain a compression result; generating an executable DSL program for the target UI based on the DSL attribute parameters and the compression result; executing the executable DSL program to obtain a nested trie named using DSL attributes; and using deterministic transformation rules to restore the nested trie to the native design data corresponding to the target platform, thereby generating the target UI on the target platform using the native design data. This application eliminates information redundancy, reduces design scale, and improves the efficiency, reversibility, and convenience of UI representation, thus enabling efficient and convenient generation of user interfaces.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a user interface generation method, system, device, and computer storage medium. Background Technology

[0002] User interface (UI) design is a crucial part of software development. Currently, UI can be represented using data formats natively exported by design tools, such as raw JSON. This involves exporting the design draft as raw data using the application programming interface (API) provided by the design tool, recording all attribute information of each design node in a tree structure. Alternatively, web markup languages ​​such as HTML / CSS and style sheets can be used to represent the UI, which means representing the UI design as a combination of nested tags and style rules. Another approach is to use code generation methods based on the layer tree of the design draft to represent the UI, using the layer tree of the design draft as an intermediate representation to generate code for the target platform.

[0003] However, these representation methods suffer from information redundancy, and their size expands superlinearly with the design scale. For example, the data natively exported by design tools serializes all style attributes of each node independently. Even if hundreds of nodes use the exact same color scheme, font size, and rounded corner combination, these attributes still appear repeatedly in each node. Furthermore, these representation methods struggle to support accurate reverse reconstruction from representation to design tools. The structural models between different representation systems, such as the box model and automatic layout, are not isomorphic. While general data formats faithfully serialize the internal data structure of design tools, they do not impose semantic constraints from the design domain, making them unreliable intermediate layers for accurate reconstruction of design drafts. This results in poor efficiency and convenience in UI generation.

[0004] In conclusion, how to generate user interfaces efficiently and conveniently is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a user interface generation method, which can, to some extent, solve the technical problem of how to generate user interfaces efficiently and conveniently. This application also provides a user interface generation system, an electronic device, and a computer-readable storage medium.

[0006] To achieve the above objectives, this application provides the following technical solution: A user interface generation method, comprising: Obtain the design draft data of the target UI; The design draft data is parsed into a design node tree; Code mapping is performed on each node in the design node tree to convert the platform native attributes of each node into DSL attribute parameters; The designed node tree is compressed to obtain the compression result; Based on the DSL attribute parameters and the compression result, an executable DSL program for the target UI is generated; Executing the executable DSL program yields a nested trie named according to the DSL attributes. Using deterministic transformation rules, the nested trie is restored to native design data corresponding to the target platform, so as to generate the target UI on the target platform using the native design data.

[0007] Preferably, the compression process of the designed node tree to obtain the compression result includes: Traverse the design node tree and combine all style class attributes of each node into an immutable tuple; Use immutable tuples as keys; Count the number of times the key appears in the design node tree; Extract attribute bundles whose frequency of occurrence reaches a threshold and use them as named variables; Generate reference points for attribute bundles by replacing duplicate attributes of attribute bundles with variable references; Generate style extraction results based on the reference points of named variables and attribute bundles; The extracted style results are used as the compressed result.

[0008] Preferably, the compression process of the designed node tree to obtain the compression result includes: The design node tree is traversed, and a structural signature for each child node is generated based on the list of child nodes for each node. If at least two consecutive sibling child nodes have the same structural signature, they are marked as cyclic candidates; Extract the fields with different values ​​among the child nodes of the cyclic candidate as a data array; Replace the child nodes of the data array with a combination of template functions and list comprehensions to obtain the loop detection results; The results of the cyclic detection are used as the compression results.

[0009] Preferably, the compression process of the designed node tree to obtain the compression result includes: Perform a global scan on the designed node tree, generate the structural signatures of all subtrees, and establish a global index; Extract the subtrees corresponding to structural signatures that appear a threshold number of times and define them as independent functions; Replace duplicate subtrees with function calls to generate reference points for subtrees; Component detection results are generated based on the independent function definitions and the reference points of the subtree; The component detection results are used as the compression results.

[0010] Preferably, executing the executable DSL program to obtain a nested trie named using DSL attributes includes: Container nodes are constructed for the attribute parameters in the executable DSL program to generate dictionary nodes containing container attributes. The container attributes include node name, size, fill color, rounded corners, shadow, border, layout direction, child element spacing, alignment, padding, and child node list. The executable DSL program is text-constructed to generate dictionary nodes containing text attributes, including text content, font size, font family, font style, font color, line height ratio, character spacing, text alignment, and size. The executable DSL program is used to construct images and generate dictionary nodes containing image data. By nesting dictionary nodes layer by layer according to the sublist, a nested trie named according to the DSL attributes is generated.

[0011] Preferably, the step of restoring the nested trie to native design data corresponding to the target platform through deterministic transformation rules includes: By using attribute conversion rules, the attributes in the nested trie are restored to the attribute data of the target platform; For the current node in the nested trie, based on the layout mode of the parent node of the current node, the alignment description in the current node that is not related to the layout direction is mapped to the alignment field related to the layout direction in the target platform, and the semantic transformation of the alignment field is completed to obtain the direction data; based on the layout direction of the parent node in the target platform, the size filling behavior of the current node is mapped to obtain the filling data; the associated attribute transformation result is generated based on the direction data and the filling data. Based on the attribute data and the transformation results of related attributes, native design data corresponding to the target platform is generated.

[0012] Preferably, the step of restoring the attributes in the nested trie to the attribute data of the target platform through attribute conversion rules includes: By using color conversion rules, the color representation in the nested trie is parsed into the native color data structure of the target platform, and the color representation includes an opacity suffix and gradient syntax; The color conversion rules are used to parse the border colors in the nested trie and generate the corresponding border attribute structure. The numerical size and adaptive semantics carried by a single attribute in the nested trie are split into multiple collaborative fields of the target platform; Expand the abbreviated padding attribute in the nested trie into an independent four-way padding field, and expand the shadow triplet and border doublet into a multi-field complete structure for the target platform. The independent font attributes in the nested trie are merged into a font nesting object for the target platform, and the line height ratio and character spacing values ​​are converted into a unit-based representation for the target platform. Each node in the nested trie is supplemented with the default fields required by the target platform to obtain attribute data corresponding to the target platform.

[0013] A user interface generation system, comprising: The design draft acquisition module is used to acquire the design draft data of the target UI. The parsing module is used to parse the design draft data into a design node tree; The code mapping module is used to perform code mapping on each node in the design node tree, converting the platform native attributes of each node into DSL attribute parameters; A compression module is used to compress the design node tree to obtain a compression result; A forward translation module is used to generate an executable DSL program for the target UI based on the DSL attribute parameters and the compression result; An execution module is used to execute the executable DSL program and obtain a nested trie named according to the DSL attributes. The reverse translation module is used to restore the nested trie to native design data corresponding to the target platform through deterministic transformation rules, so as to generate the target UI on the target platform using the native design data.

[0014] An electronic device, comprising: Memory, used to store computer programs; A processor for implementing the steps of any of the above-described user interface generation methods when executing the computer program.

[0015] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the user interface generation methods described above.

[0016] This application provides a user interface generation method that involves: acquiring design draft data of a target UI; parsing the design draft data into a design node tree; performing code mapping on each node in the design node tree to convert the platform-native attributes of each node into DSL attribute parameters; compressing the design node tree to obtain a compression result; generating an executable DSL program for the target UI based on the DSL attribute parameters and the compression result; executing the executable DSL program to obtain a nested trie named using the DSL attributes; and restoring the nested trie to the native design data corresponding to the target platform using deterministic transformation rules, thereby generating the target UI on the target platform using the native design data. In this application, by mapping and compressing design draft data into an executable DSL program, the semantic structure of the design system is carried by utilizing the inherent abstraction mechanism of the executable program. This embeds compression capabilities within the execution semantics of the representation, eliminating information redundancy and reducing the design scale. The DSL program is then expanded into a nested trie, and deterministic transformation rules are used to restore it to the target platform's native design data. Since the transformation rules are predefined and unambiguous, without involving any probabilistic inference or heuristic estimation, the same nested trie can always restore the exact same design draft data. This achieves a complete closed loop from design draft to executable program and back to design draft, improving the convenience, efficiency, reversibility, and cross-platform applicability of UI representation. This allows for the efficient and convenient generation of user interfaces using native design data on the target platform. The user interface generation system, electronic device, and computer-readable storage medium provided in this application also solve the corresponding technical problems. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating a user interface generation method provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of a user interface generation system provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0020] Please see Figure 1 , Figure 1 This is a flowchart of a user interface generation method provided in an embodiment of this application.

[0021] This application provides a user interface generation method, which may include the following steps: Step S101: Obtain the design draft data of the target UI.

[0022] In practical applications, the target UI refers to the user interface to be generated or processed. It can be a complete page-level design or a partial component design within a page. Design draft data refers to the raw data of the design files generated by UI design tools. Different design tools export design draft data in different formats. For example, the design draft data exported by the first design tool through its application programming interface is in JSON format, which records all attribute information of each design node in a tree structure. The design draft data exported by the second design tool is an archive file, such as ZIP format, which contains page data files, etc.

[0023] In an exemplary embodiment, during the process of acquiring design draft data, the currently open design file can be read directly through the plugin interface of the design tool; it can be acquired from the cloud through the web application programming interface provided by the design tool; or it can be obtained by parsing locally stored design files. Regardless of the acquisition method used, the acquired design draft data can include the hierarchical relationship of design nodes and the visual attributes of each design node. The hierarchical relationship can be a parent-child node tree structure, and the visual attributes of each design node can include position, size, color, font, rounded corners, shadow, border, etc.

[0024] It should be noted that the design node types described in the design draft data may include, but are not limited to: container type nodes, such as FRAME and GROUP in the first design tool, and artboard and group in the second design tool, used to hold and lay out child nodes; text type nodes, used to display text content; shape type nodes, used to draw geometric shapes; and image type nodes, used to display bitmaps or vector icons. Different design tools may have different naming and attribute systems for node types, but all are recorded in a structured form in the design draft data.

[0025] Step S102: Parse the design draft data into a design node tree.

[0026] In practical applications, design draft data needs to be parsed into a design node tree. The design node tree is the product of organizing the hierarchical relationships and attribute information of the nodes recorded in the design draft data according to a unified tree data structure. Since the design draft data exported from different design platforms has different formats, it is necessary to set up corresponding format parsers for different platforms to uniformly convert the platform-specific data formats into a universal design node tree representation.

[0027] Specifically, for the first design platform, the format parser reads the JSON file exported by its application interface, traverses the node tree structure, maps the type field of each node to the node type of the design node tree, and extracts fields such as node position, size, fill color array, stroke, rounded corners, shadow effect, font attributes, auto layout mode, child element spacing, padding, and child node array as node attributes of the design node tree. For platforms based on Web Markup Language and style sheets, the format parser directly parses the tag nesting structure of the source file, maps each tag to a node in the design node tree, and extracts the tag's identifier attributes and visual attributes from inline styles as node attributes; it also parses the associated style rule text, determines the style attributes corresponding to each element according to the selector's matching rules, and merges the parsed style attributes into the corresponding design nodes. For the second design platform, the format parser reads the page data in its archive file, traverses the layer list of each page, maps the type of each layer to the node type of the design node tree, and extracts the layer's position and size, style fields such as fill / border / shadow in the style object, and the sublayer list as node attributes of the design node tree. The output of the format parser is a unified design node tree representation, which is independent of the source platform of the input data. All subsequent processing steps are based on this unified design node tree. This unified representation design means that when the system adds support for other design platforms, only the corresponding format parser needs to be added, and no changes are required to the subsequent processing logic.

[0028] Step S103: Perform code mapping for each node in the design node tree to convert the platform native properties of each node into DSL property parameters.

[0029] In practical applications, code mapping needs to be performed on each node in the design node tree to convert the platform-native attributes of each node into DSL (Domain Specific Language) attribute parameters. Code mapping is the process of converting the platform-native attributes of each node in the design node tree into DSL attribute parameters. DSL attribute parameters adopt a unified naming system that is decoupled from any specific design platform and oriented towards the UI design domain. This naming system defines all the attribute parameters required by three types of primitives: container nodes, text nodes, and image nodes, including but not limited to: fill color, rounded corners, shadow, border, layout direction, child element spacing, alignment, padding abbreviation, size, font size, font family, font style, text content, line height ratio, character spacing, etc. The fill color can be represented by a hexadecimal string, such as 'FF3B30'; rounded corners can be represented by a single number or a quadruple; shadows can be represented by a triple, such as ('000000', 0.2, (0, 4)); borders can be represented by a binary, such as ('212121', 1.0); layout direction can be horizontal, vertical, none, line breaks, etc.; child element spacing can be a fixed value or set automatically; size can be a number or the string FILL or HUG, etc.

[0030] In the exemplary embodiment, during the code mapping process, for each node in the design node tree, the attribute value corresponding to the node in the platform's native format can be extracted according to its node type, which can be a container type, text type, or image type, etc. The platform's native attribute value is then converted into DSL attribute parameter values ​​according to predefined mapping rules. The mapping rules define the conversion method from the native attributes of each platform to the unified attributes of the DSL. Taking the first design platform as an example, the RGBA floating-point color values ​​in its fill color array can be converted into 6-digit hexadecimal strings, identical rounded corners can be merged into a single value, the shadow effect array can be compressed into triples, and layout mode and size-related fields can be comprehensively converted into FILL / HUG semantics for layout direction and size, etc. For Icon and image-type nodes, they can be converted into corresponding natural language descriptions through the "Icon, Image - Natural Language Description" submodule of the Icon, Image Retrieval and Generation module. Only one getImage(query='Natural Language Description, width W, height H') call is retained in the DSL code. Furthermore, during the code mapping process, only attributes that differ from their default values ​​are explicitly output as DSL attribute parameters. Unspecified attributes can automatically adopt default values, such as default horizontal auto-layout, default width and height auto-adjustment, and default no padding, no borders, and no rounded corners. This default value omission mechanism is itself a form of attribute-level compression, because when a large number of nodes use the same default attribute values, these attribute values ​​will not be output in the DSL code at all, achieving a high compression rate.

[0031] Step S104: Compress the designed node tree to obtain the compression result.

[0032] In practical applications, the design node tree needs to be compressed to obtain the compressed result. Compression is a multi-level semantic compression operation on the design node tree, aiming to eliminate information redundancy in the design representation and extract abstract patterns from the design. Compression includes three optional compression methods: style extraction, loop detection, and component detection. These three methods can be used independently or in combination, operating at the attribute level, sibling sequence level, and global subtree level, respectively.

[0033] In the exemplary embodiment, during the compression process of the design node tree to obtain the compression result, the design node tree can be traversed, for example, by performing a depth-first traversal. All style-type properties of each node are combined into an immutable tuple, such as combining fill color, rounded corners, shadow, layout direction, child element spacing, horizontal padding, vertical padding, font family, font size, font style, text alignment, and line height into an immutable tuple. This immutable tuple is used as the key. The occurrence count of the key in the design node tree is counted. Attribute bundles whose occurrence count reaches a threshold are extracted as named variables. Assuming the threshold is 2, when the occurrence count of an attribute bundle reaches 2, the attribute bundle is extracted as a named dictionary variable, such as frameStyle1, textStyle1, etc. Repeated attributes of the attribute bundle are replaced by variable references to generate reference points for the attribute bundle. That is, at all nodes referencing the attribute bundle, the originally declared repeated attributes are replaced using dictionary unpacking syntax. Based on the named variables and the reference points of the attribute bundles, the style extraction result is generated. The style extraction result is used as the compression result. In this way, the input for style extraction is only the design node tree itself, without relying on the designer's predefined style specifications, naming conventions, or any external annotation information. It achieves automatic discovery and global extraction of design tokens entirely through statistical analysis of the frequency of attribute values. Style extraction eliminates duplication at the attribute value level, consolidating the same style bundles scattered across hundreds of nodes into a single variable definition. Compared with the solution that requires the designer to pre-set design tokens and manually reference them, the method in this application is entirely data-driven and requires no manual annotation or predefined specifications. This method is not only suitable for new design drafts but also for a large number of existing design drafts that lack specification annotations, and has wide applicability.

[0034] In an exemplary embodiment, during the compression process of the design node tree to obtain the compression result, the design node tree can be traversed. Based on the child node list of each node, the child node list of each node is checked to generate a structural signature for each child node. The calculation rule for the structural signature is: for leaf nodes, signature = (node ​​type, frozen set of attribute key sets); for container nodes, signature = (node ​​type, frozen set of attribute key sets, tuple of child node signature sequence), that is, recursively including the structural information of all subtrees while ignoring actual attribute values. If at least two consecutive sibling child nodes have the same structural signature, they are marked as cycle candidates. Fields with different values ​​between the child nodes of the cycle candidates are extracted as a data array. The child nodes of the data array are replaced with a combination of template functions and list comprehensions. The list comprehension calls the template function based on each element in the data array to generate a corresponding child node instance, which is used as the cycle detection result. The cycle detection result is used as the compression result. In this way, by identifying consecutive sibling node sequences with the same structure but different data in the design node tree through structural signature, and using the list comprehension of the host language, the instantiation code of these repeated nodes is folded into a compact loop structure. Compared with the strategy of first generating a complete redundant representation and then extracting the reuse pattern in post-processing, the loop detection in this application completes the identification and folding of the repeating pattern in the representation generation stage, and compresses it into the representation structure without the need for additional post-processing steps.

[0035] In an exemplary embodiment, during the compression process of the design node tree to obtain the compression result, a global scan of the design node tree can be performed to detect subtrees with the same structure appearing in non-contiguous positions (under different parent nodes or across pages). Specifically, the structural signature of each subtree in the design node tree is calculated, generating structural signatures for all subtrees and establishing a global index, recording all positions where each structural signature appears in the entire tree; the subtrees corresponding to structural signatures that have appeared twice are extracted as independent function definitions. Assuming the threshold is 2, when a structural signature appears twice globally, the subtree corresponding to that signature is marked as a reusable component candidate. Subsequently, the DSL construction code corresponding to that subtree is extracted as an independent function definition, the function body being the complete DSL construction logic of that subtree, and the function parameters being all variable data fields in the subtree; duplicate subtrees are replaced by function calls to generate reference points for the subtrees, that is, at all reference points where the subtree structure appears, the original duplicate subtree code is replaced by function calls; based on the independent function definition and the reference points of the subtrees, component detection results are generated; and the component detection results are used as the compression result. In this way, by using the global structural signature index, the subtrees with the same structure that appear under different parent nodes or across pages in the design node tree are identified. These repeated subtrees are then encapsulated into reusable components using the function definition of the host language. Compared with style extraction and loop detection, component detection works at the global subtree structure level. The three work together at different abstract dimensions to achieve multi-level compression.

[0036] The code mapping and the three compression methods mentioned above are all driven by predefined attribute mapping tables, frequency statistics algorithms and structure signature matching algorithms, without involving any machine learning models or probabilistic inferences. The same design input will always produce the exact same compressed output.

[0037] Step S105: Based on the DSL attribute parameters and compression results, generate an executable DSL program for the target UI.

[0038] In practical applications, an executable DSL program for the target UI needs to be generated based on the DSL attribute parameters and compression results. An executable DSL program refers to program code written in a host language that supports programming abstraction mechanisms such as variable assignment, function definition and parameterized calls, loops or list comprehensions, and can be directly executed by a standard interpreter. The host language can be Python, etc.

[0039] In an exemplary embodiment, the core of the executable DSL program can be composed of three primitive constructors: a container constructor, a text constructor, and an image constructor. The container constructor receives DSL attribute parameters and returns a dictionary node containing container attributes, including node name, size, fill color, rounded corners, shadow, border, layout direction, child element spacing, alignment, padding abbreviation, whether to crop content, and a list of child nodes. The text constructor returns a dictionary node containing text attributes, including text content, font size, font family, font style, font color, line height ratio, character spacing, text alignment, and size. The image constructor receives a query parameter containing a natural language description and size information of the image. In the DSL code, the image constructor does not directly contain the image binary data; instead, it only retains the natural language description text as the query parameter. This design compresses a large amount of binary image data into a concise natural language description text.

[0040] In DSL programs, named variables generated by style extraction are defined as dictionary variables, and style attributes are injected in batches during the construction of container nodes or text nodes using dictionary unpacking syntax. Template functions generated by loop detection are defined as functions, and are called in list comprehensions to generate a group of child nodes with the same structure but different data. Independent function definitions generated by component detection are defined as functions, and corresponding component subtrees are generated through function calls at reference points. Executable DSL programs have the following key characteristics: their compression capability directly stems from the execution semantics of the host language, such as the centralized declaration of design tokens corresponding to variable definitions, the encapsulation and reuse of components corresponding to function definitions, and the folding of repeating modules corresponding to list comprehensions; the program structure itself is a compressed form, rather than applying independent compression processing after the data format is generated.

[0041] Step S106: Execute the executable DSL program to obtain a nested trie named according to the DSL attributes.

[0042] In practical applications, an executable DSL program needs to be executed to obtain a nested trie named using DSL attributes. Executing the executable DSL program means dynamically executing the DSL program code through a standard interpreter. Style dictionary variables in the DSL program are evaluated to dictionary objects, list comprehensions are expanded into multiple node instances, and template functions and component functions are called to generate reusable component subtrees.

[0043] In an exemplary embodiment, during the execution of an executable DSL program to obtain a nested trie named using DSL attributes, container nodes can be constructed for the attribute parameters in the executable DSL program to generate dictionary nodes containing container attributes. Container attributes include node name, size, fill color, rounded corners, shadow, border, layout direction, child element spacing, alignment, padding, and a list of child nodes. Text can also be constructed for the executable DSL program to generate dictionary nodes containing text attributes. Text attributes include text content, font size, font family, font style, font color, line height ratio, character spacing, text alignment, and size. The L program constructs images, generating dictionary nodes containing image data. Specifically, the image constructor function calls the image generation module in real time to generate corresponding image data based on the natural language description in the query parameters, returning a dictionary node containing complete image data. The dictionary nodes are nested layer by layer according to the sublist, generating a nested trie named according to DSL attributes. Each node in this nested trie is a dictionary, with the dictionary keys named according to the attribute parameters designed by DSL, such as fill color, layout mode, rounded corners, etc., and the dictionary values ​​are the corresponding attribute values. The image nodes in the nested trie already contain complete image data and do not require subsequent additional recovery. For example, a container containing a search bar and icons will produce a trie with the following structure after execution: The root node is a dictionary returned by the container node constructor, which contains DSL properties such as name='AAA', width='FILL', height=36, cornerRadius=8, fill='F2F2F2', itemSpacing=8, alignVertical='CENTER', and paddingHorizontal=12. The children list contains a nested icon node, whose children are an image dictionary returned by the image node constructor and a text node returned by the text node constructor, which contains properties such as characters='search contract / strategy', fontSize=14, and fill='00000066'.

[0044] Step S107: Using deterministic transformation rules, the nested trie is restored to the native design data corresponding to the target platform, so as to generate the target UI on the target platform by applying the native design data.

[0045] In practical applications, the attribute system of nested trie uses parameter naming based on the DSL design, which differs systematically from the native attributes of various design platforms. For example, the DSL uses hexadecimal strings to represent colors, while the first design platform natively uses a color array structure; the DSL uses a single size attribute to simultaneously carry numerical size and adaptive semantics, while the first design platform natively requires multiple fields such as size, layout size, layout growth, and layout alignment to express the same meaning. These differences determine that nested trie cannot be directly used as the native format of any platform. It must undergo reverse translation, performing restoration operations such as color parsing, size expansion, alignment direction mapping, and default attribute completion node by node, before it can be converted into the native format of the target platform. In other words, deterministic conversion rules are needed to restore the nested trie to the native design data corresponding to the target platform, so that the native design data can be used to generate the target UI on the target platform.

[0046] It should be noted that deterministic transformation rules refer to transformation specifications consisting of predefined, unambiguous attribute mapping relationships. These specifications uniquely map each DSL attribute parameter in the nested trie to the target platform's native attribute format, without involving probabilistic inference or heuristic estimation throughout the process. The reverse translation process consists of two stages: attribute format conversion and associated attribute calculation.

[0047] In the attribute format conversion stage, the nested trie is traversed, and the DSL abbreviation attribute of each node is expanded into the complete attribute format of the target platform. Specifically, it covers the following five types of operations: (1) Color encoding conversion: The hexadecimal string color representation of the DSL (including opacity suffix and gradient syntax) is parsed into the native color data structure of the target platform; the border color adopts the same parsing rules and generates the corresponding border attribute structure. (2) Size semantic expansion: The numerical size and adaptive semantics (FILL / HUG) carried by the DSL with a single size attribute are split into multiple collaborative fields required by the target platform. For example, the FILL semantics need to set the layout size level and layout growth attribute in the first design platform, the elastic growth attribute in the web page style sheet, and the size constraint in the second design platform. (3) Abbreviation parameter splitting: The inner margin abbreviation of the DSL is expanded into an independent four-way inner margin field; the shadow triple is expanded into a multi-field complete structure of the target platform; the border double is expanded into multiple fields such as border array, border width, and border alignment of the target platform. (4) Text attribute reorganization: merge the independent font attributes of DSL into the target platform's nested font object; convert the line height ratio value to the target platform's unit representation; convert the character spacing value to the target platform's unit representation. (5) Default attribute completion: supplement each node with all default fields required by the target platform but omitted by DSL, such as visibility, opacity, blending mode, export settings, constraints, etc., to ensure that the output data meets the integrity constraints of the target platform's application programming interface.

[0048] During the attribute calculation phase, attribute values ​​that depend on the parent-child node context need to be processed. For example, the DSL uses alignment descriptions independent of layout direction, while target platforms typically distinguish between main axis and cross axis alignment based on layout direction. Therefore, it is necessary to map the DSL alignment value to a direction-related alignment field based on the current node's parent node layout mode and complete the semantic conversion of the alignment value. Furthermore, the fill size behavior of child nodes depends on the layout direction of the parent node. For instance, in a horizontal layout, when the child node's width is fill, a main axis stretch attribute needs to be set; in a vertical layout, the same stretch operation is performed on the height. Fill in the cross axis direction requires setting a cross axis stretch attribute. This calculation needs to maintain the parent-child relationship context during the traversal of the nested trie and dynamically determine it node by node. The automatic spacing semantics of the DSL also fall under the scope of attribute calculation and need to be converted accordingly based on the target platform's equal-spacing layout mechanism.

[0049] Based on this, in the process of restoring the nested trie to native design data corresponding to the target platform through deterministic transformation rules, attribute transformation rules can be used to restore the attributes in the nested trie to attribute data of the target platform. For the current node in the nested trie, according to the layout mode of the parent node of the current node, the alignment description in the current node that is not related to the layout direction is mapped to the alignment field related to the layout direction in the target platform, and the semantic transformation of the alignment field is completed to obtain the direction data. According to the layout direction of the parent node in the target platform, the size filling behavior of the current node is mapped to obtain the filling data. The associated attribute transformation results are generated based on the direction data and the filling data. The native design data corresponding to the target platform is generated based on the attribute data and the associated attribute transformation results. Furthermore, in the process of restoring the attributes in the nested trie to the attribute data of the target platform through attribute conversion rules, color conversion rules can be used to parse the color representation in the nested trie into the native color data structure of the target platform. The color representation includes opacity suffixes and gradient syntax. Color conversion rules can also be used to parse the border color in the nested trie and generate the corresponding border attribute structure. The numerical size and adaptive semantics carried by a single attribute in the nested trie can be split into multiple collaborative fields of the target platform. The abbreviated padding attribute in the nested trie can be expanded into an independent four-way padding field, and the shadow triples and border doubles can be expanded into a multi-field complete structure of the target platform. The independent font attributes in the nested trie can be merged into a font nesting object of the target platform, and the line height ratio and character spacing values ​​can be converted into the unit-based representation of the target platform. Finally, the default fields required by the target platform can be added to each node in the nested trie to obtain attribute data corresponding to the target platform.

[0050] It should also be noted that the specific mapping rules for the above two-stage transformation differ for different target platforms. For the first design platform, colors are converted to a `fills` array structure, and dimensions are expressed collaboratively through fields such as `layoutSizingHorizontal`, `layoutGrow`, and `layoutAlign`. Alignment is distinguished by `primaryAxisAlignItems` and `counterAxisAlignItems`, and default properties require the completion of fields such as `visible`, `opacity`, `blendMode`, `effects`, and `constraints`. For HTML / CSS, colors are converted to `#hex` format or the `rgba()` function, and layout is expressed through `display:flex` in conjunction with CSS properties such as `flex-direction`, `flex-grow`, and `align-items`. Dimensions use unit systems such as `px`, `em`, and `rem`. For the second design platform, colors are converted to RGBA color object format, layout is expressed through `SmartLayout` and `Resizing Constraints`, and font properties are converted to Sketch-specific font property objects. All platform format generators follow the above two-stage general transformation framework; the differences lie only in the specific property names and data structures. In other words, after the two-stage transformation described above, the output native design data is visually equivalent to the original design draft, and all attribute values ​​are accurately reproduced. A single DSL program can perform reverse translation for multiple different target platforms, outputting their respective native formats, achieving one-time representation and multi-platform output.

[0051] This application provides a user interface generation method that involves: acquiring design draft data of a target UI; parsing the design draft data into a design node tree; performing code mapping on each node in the design node tree to convert the platform-native attributes of each node into DSL attribute parameters; compressing the design node tree to obtain a compression result; generating an executable DSL program for the target UI based on the DSL attribute parameters and the compression result; executing the executable DSL program to obtain a nested trie named using the DSL attributes; and restoring the nested trie to the native design data corresponding to the target platform using deterministic transformation rules, thereby generating the target UI on the target platform using the native design data. In this application, by mapping and compressing design draft data into an executable DSL program, the semantic structure of the design system is carried by the inherent abstraction mechanism of the executable program. The compression capability is embedded in the execution semantics of the representation, eliminating information redundancy and reducing the design scale. By executing the DSL program and expanding it into a nested trie, and then restoring it to the native design data of the target platform through deterministic transformation rules, since the transformation rules are predefined and unambiguous and do not involve any probability inference or heuristic estimation, the same nested trie can always restore the exact same design draft data. This realizes a complete closed loop from design draft to executable program and back to design draft, improving the convenience, efficiency, reversibility and cross-platform applicability of UI representation. Thus, native design data can be used on the target platform to generate user interfaces efficiently and conveniently.

[0052] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a user interface generation system provided in an embodiment of this application.

[0053] This application provides a user interface generation system, which may include: Design draft acquisition module 101 is used to acquire design draft data of the target UI; Parsing module 102 is used to parse the design draft data into a design node tree; Code mapping module 103 is used to perform code mapping on each node in the design node tree, converting the platform native properties of each node into DSL property parameters; Compression module 104 is used to compress the design node tree to obtain the compression result; Forward translation module 105 is used to generate an executable DSL program for the target UI based on DSL attribute parameters and compression results; Execution module 106 is used to execute an executable DSL program and obtain a nested trie named according to the DSL attributes. The reverse translation module 107 is used to restore the nested trie to the native design data corresponding to the target platform through deterministic transformation rules, so as to generate the target UI on the target platform by applying the native design data.

[0054] This application provides a user interface generation system, in which the compression module may include: The style extraction unit traverses the design node tree, combines all style class attributes of each node into immutable tuples, uses these immutable tuples as keys, counts the occurrences of keys in the design node tree, extracts attribute bundles whose occurrence counts reach a threshold as named variables, replaces duplicate attributes of attribute bundles with variable references to generate reference points for attribute bundles, generates style extraction results based on named variables and attribute bundle reference points, and uses the style extraction results as compression results.

[0055] This application provides a user interface generation system, in which the compression module may include: The loop detection unit traverses the designed node tree and generates a structural signature for each child node based on its list of child nodes. If at least two consecutive sibling child nodes have the same structural signature, they are marked as loop candidates. The unit extracts the fields with different values ​​between the child nodes of the loop candidates as a data array. The child nodes of the data array are replaced with a combination of template functions and list comprehensions to obtain the loop detection result. The loop detection result is then used as the compression result.

[0056] This application provides a user interface generation system, in which the compression module may include: The component detection unit performs a global scan of the design node tree, generates structural signatures for all subtrees, and establishes a global index; extracts subtrees corresponding to structural signatures that have appeared a certain number of times as independent function definitions; replaces duplicate subtrees with function calls to generate reference points for subtrees; generates component detection results based on independent function definitions and subtree reference points; and compresses the component detection results.

[0057] This application provides a user interface generation system, the execution module of which may include: The container construction unit is used to construct container nodes for attribute parameters in the executable DSL program, generating dictionary nodes containing container attributes, including node name, size, fill color, rounded corners, shadow, border, layout direction, child element spacing, alignment, padding, and child node list. The text construction unit is used to construct the text of the executable DSL program and generate dictionary nodes containing text attributes, including text content, font size, font family, font style, font color, line height ratio, character spacing, text alignment and size. The image construction unit is used to construct images for the executable DSL program and generate dictionary nodes containing image data. Nested units are used to nest dictionary nodes layer by layer according to sublists, generating a nested trie named according to the DSL attributes.

[0058] This application provides a user interface generation system, in which a reverse translation module may include: The attribute format conversion unit is used to restore the attributes in the nested trie to the attribute data of the target platform according to the attribute conversion rules; The related attribute calculation unit is used to, for the current node in the nested trie, map the alignment description in the current node that is unrelated to the layout direction to the alignment field in the target platform that is related to the layout direction, according to the layout mode of the parent node of the current node, and complete the semantic transformation of the alignment field to obtain the direction data; according to the layout direction of the parent node in the target platform, map the size filling behavior of the current node to obtain the filling data; and generate the related attribute transformation result based on the direction data and the filling data. The design generation unit is used to generate native design data corresponding to the target platform based on attribute data and the transformation results of associated attributes.

[0059] This application provides a user interface generation system, in which an attribute format conversion unit is used to: parse the color representation in a nested trie into the native color data structure of the target platform using color conversion rules, wherein the color representation includes an opacity suffix and gradient syntax; parse the border color in the nested trie and generate a corresponding border attribute structure using color conversion rules; split the numerical size and adaptive semantics carried by a single attribute in the nested trie into multiple collaborative fields of the target platform; expand the padding abbreviation attribute in the nested trie into an independent four-way padding field, and expand the shadow triples and border doubles into a multi-field complete structure of the target platform; merge the independent font attributes in the nested trie into a font nesting object of the target platform, and convert the line height ratio value and character spacing value into a unit-based representation of the target platform; and supplement each node in the nested trie with the default fields required by the target platform to obtain attribute data corresponding to the target platform.

[0060] This application also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the user interface generation method provided in the embodiments of this application. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0061] An electronic device provided in this application includes a memory 201 and a processor 202. The memory 201 stores a computer program, and the processor 202 executes the computer program to implement the steps of the user interface generation method described in any of the above embodiments.

[0062] Please see Figure 4 Another electronic device provided in this application embodiment may further include: an input port 203 connected to the processor 202 for transmitting commands input from the outside to the processor 202; a display unit 204 connected to the processor 202 for displaying the processing results of the processor 202 to the outside; and a communication module 205 connected to the processor 202 for enabling communication between the electronic device and the outside. The display unit 204 may be a display panel, a laser scanning display, etc.; the communication method adopted by the communication module 205 includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connection: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.

[0063] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the user interface generation method described in any of the above embodiments.

[0064] The computer-readable storage media involved in this application include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.

[0065] This application provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the user interface generation method described in any of the above embodiments.

[0066] For descriptions of relevant parts in the user interface generation system, electronic device, and computer-readable storage medium provided in the embodiments of this application, please refer to the detailed descriptions of the corresponding parts in the user interface generation method provided in the embodiments of this application, and they will not be repeated here. Furthermore, parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

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

[0068] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for generating a user interface, characterized in that, include: Obtain the design draft data of the target UI; The design draft data is parsed into a design node tree; Code mapping is performed on each node in the design node tree to convert the platform native attributes of each node into DSL attribute parameters; The designed node tree is compressed to obtain the compression result; Based on the DSL attribute parameters and the compression result, an executable DSL program for the target UI is generated; Executing the executable DSL program yields a nested trie named according to the DSL attributes. Using deterministic transformation rules, the nested trie is restored to native design data corresponding to the target platform, so as to generate the target UI on the target platform using the native design data.

2. The method according to claim 1, characterized in that, The compression process of the designed node tree to obtain the compression result includes: Traverse the design node tree and combine all style class attributes of each node into an immutable tuple; Use immutable tuples as keys; Count the number of times the key appears in the design node tree; Extract attribute bundles whose frequency of occurrence reaches a threshold and use them as named variables; Generate reference points for attribute bundles by replacing duplicate attributes of attribute bundles with variable references; Generate style extraction results based on the reference points of named variables and attribute bundles; The extracted style results are used as the compressed result.

3. The method according to claim 1, characterized in that, The compression process of the designed node tree to obtain the compression result includes: The design node tree is traversed, and a structural signature for each child node is generated based on the list of child nodes for each node. If at least two consecutive sibling child nodes have the same structural signature, they are marked as cyclic candidates; Extract the fields with different values ​​among the child nodes of the cyclic candidate as a data array; Replace the child nodes of the data array with a combination of template functions and list comprehensions to obtain the loop detection results; The results of the cyclic detection are used as the compression results.

4. The method according to claim 1, characterized in that, The compression process of the designed node tree to obtain the compression result includes: Perform a global scan on the designed node tree, generate the structural signatures of all subtrees, and establish a global index; Extract the subtrees corresponding to structural signatures that appear a threshold number of times and define them as independent functions; Replace duplicate subtrees with function calls to generate reference points for subtrees; Component detection results are generated based on the independent function definitions and the reference points of the subtree; The component detection results are used as the compression results.

5. The method according to claim 1, characterized in that, The execution of the executable DSL program yields a nested trie named using DSL attributes, including: Container nodes are constructed for the attribute parameters in the executable DSL program to generate dictionary nodes containing container attributes. The container attributes include node name, size, fill color, rounded corners, shadow, border, layout direction, child element spacing, alignment, padding, and child node list. The executable DSL program is text-constructed to generate dictionary nodes containing text attributes, including text content, font size, font family, font style, font color, line height ratio, character spacing, text alignment, and size. The executable DSL program is used to construct images and generate dictionary nodes containing image data. By nesting dictionary nodes layer by layer according to the sublist, a nested trie named according to the DSL attributes is generated.

6. The method according to claim 1, characterized in that, The step of restoring the nested trie to native design data corresponding to the target platform using deterministic transformation rules includes: By using attribute conversion rules, the attributes in the nested trie are restored to the attribute data of the target platform; For the current node in the nested trie, based on the layout mode of the parent node of the current node, the alignment description in the current node that is not related to the layout direction is mapped to the alignment field related to the layout direction in the target platform, and the semantic transformation of the alignment field is completed to obtain the direction data; based on the layout direction of the parent node in the target platform, the size filling behavior of the current node is mapped to obtain the filling data; the associated attribute transformation result is generated based on the direction data and the filling data. Based on the attribute data and the transformation results of related attributes, native design data corresponding to the target platform is generated.

7. The method according to claim 6, characterized in that, The step of restoring the attributes in the nested trie to the attribute data of the target platform through attribute conversion rules includes: By using color conversion rules, the color representation in the nested trie is parsed into the native color data structure of the target platform, and the color representation includes an opacity suffix and gradient syntax; The color conversion rules are used to parse the border colors in the nested trie and generate the corresponding border attribute structure. The numerical size and adaptive semantics carried by a single attribute in the nested trie are split into multiple collaborative fields of the target platform; Expand the abbreviated padding attribute in the nested trie into an independent four-way padding field, and expand the shadow triplet and border doublet into a multi-field complete structure for the target platform. The independent font attributes in the nested trie are merged into a font nesting object for the target platform, and the line height ratio and character spacing values ​​are converted into a unit-based representation for the target platform. Each node in the nested trie is supplemented with the default fields required by the target platform to obtain attribute data corresponding to the target platform.

8. A user interface generation system, characterized in that, include: The design draft acquisition module is used to acquire the design draft data of the target UI. The parsing module is used to parse the design draft data into a design node tree; The code mapping module is used to perform code mapping on each node in the design node tree, converting the platform native attributes of each node into DSL attribute parameters; A compression module is used to compress the design node tree to obtain a compression result; A forward translation module is used to generate an executable DSL program for the target UI based on the DSL attribute parameters and the compression result; An execution module is used to execute the executable DSL program and obtain a nested trie named according to the DSL attributes. The reverse translation module is used to restore the nested trie to native design data corresponding to the target platform through deterministic transformation rules, so as to generate the target UI on the target platform using the native design data.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the user interface generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the user interface generation method as described in any one of claims 1 to 7.

Images