Interface rendering methods, apparatus, devices and storage media

Abstract

This application provides a method, apparatus, computer device, and computer-readable storage medium for interface rendering, aimed at improving the development efficiency and flexibility of UI development. The method includes: acquiring business data, which characterizes the rendering requirements of the user interface; calling an intelligent model to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data, which characterizes the rendering information of the user interface; traversing the DSL file to generate a view node tree, which characterizes the drawing data of the view corresponding to the user interface; and rendering the user interface based on the view node tree.

Description

Technical Field

[0001] This application relates to the field of image processing, specifically to an interface rendering method, apparatus, device, and storage medium. Background Technology

[0002] With the booming development of mobile internet and multi-terminal applications, the market has placed higher demands on the personalized customization, rapid iteration and intelligent presentation capabilities of user interfaces (UI).

[0003] In existing technologies, UI implementation solutions have evolved from hard-coding to declarative description. Early solutions relied on developers directly creating and configuring UI components in client-side code, resulting in high coupling and difficulty in maintenance. Subsequently, the industry generally adopted the method of manually writing layout resources. Although these solutions separated the UI structure from business logic to some extent, the UI definition was still fixed on the client side. Any visual adjustments or logical changes required a complete application compilation, release, and review process, resulting in long response cycles, poor flexibility, and difficulty in meeting the ever-changing business operation needs.

[0004] To address this issue, the industry has further developed dynamic UI solutions based on Domain-Specific Languages ​​(DSLs). These solutions involve the server distributing a DSL file, which the client then parses and renders to achieve dynamic UI updates. However, existing DSL generation processes still have significant drawbacks: they typically require backend developers to manually write or generate the corresponding DSL (such as JSON format) data based on business logic or using pre-defined rigid templates. This process is not only labor-intensive and error-prone, but also has a long response time. More importantly, it cannot intelligently adapt the interface expression based on the inherent semantics of the original business data, making it difficult to achieve truly personalized UI customization and limiting the level of intelligence in UI presentation. Summary of the Invention

[0005] This application provides an interface rendering method, apparatus, computer device, and computer-readable storage medium to improve the development efficiency and flexibility of UI development.

[0006] The technical solution adopted by this invention to solve the problem is as follows: Firstly, this application provides a method for rendering an interface, including: Acquire business data, which is used to characterize the rendering requirements of the user interface; The intelligent model is invoked to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. The DSL file is used to represent the rendering information of the user interface, including the layout information, data binding information, and interaction logic of the user interface. Traverse the DSL file to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface; The user interface is rendered based on this view node tree.

[0007] In some embodiments of this application, the acquisition of business data includes: Acquire text data, image data, video data, and / or audio data; The text data, image data, video data, and / or audio data are processed into structured data to obtain structured data, which serves as the business data.

[0008] In some embodiments of this application, the method further includes: Obtain training samples, an initial model, and user interface layout specifications. The training samples include historical business data and historical DSL files, and the user interface layout specifications include a flex layout model and / or custom layout rules. The initial model is trained based on the training samples and the user interface layout specifications to obtain the intelligent model.

[0009] In some embodiments of this application, traversing the DSL file to generate a view node tree includes: Traverse each node in the DSL file and objectify each node to obtain multiple node objects. Each node object includes a node identifier, node type, visual appearance information, and binding event information for each node. Based on the nesting relationships in the DSL file, the multiple node objects are used to generate the view node tree.

[0010] In some implementations of this application, each node in the DSL file is traversed, and each node is objectified to obtain multiple node objects, including: Iterate through each node in the DSL file and create a corresponding node object for each node; Obtain the node type of each node, and determine the corresponding processing component based on the node type; Based on this processing component, the corresponding visual appearance information and bound event information of each node are obtained; The visual appearance information and the bound event information are stored in the node objects corresponding to each node to obtain the multiple node objects.

[0011] In some embodiments of this application, the processing component includes a base view component, a layout component, and a custom component; Based on this processing component, the visual appearance information and bound event information of each node are obtained, including: The view element of the node is obtained based on this basic view component, and the view element is mapped to drawing information; The layout information of the nodes is obtained based on the layout component, and the layout information is mapped to the size information and position information of each node. The drawing information, the size information and the position information serve as the visual appearance information of each node. The custom component retrieves the event definition corresponding to the node and registers the event definition as the event identifier for each node, where the event identifier serves as the bound event information.

[0012] In some embodiments of this application, rendering the user interface based on the view node tree includes: Create a drawing canvas; Traverse the view node tree to obtain the view appearance information for each view node; Draw the user interface on the drawing canvas based on the view's appearance information.

[0013] In some embodiments of this application, the method further includes: Retrieve returned data based on native capability call syntax; Update the view appearance information and / or bound event information of the target view node in the view node tree based on the returned data; Redraw the view corresponding to the target view node to update the user interface.

[0014] Secondly, this application provides an interface rendering apparatus, comprising: The acquisition module is used to acquire business data, which is used to characterize the rendering requirements of the user interface. The processing module is used to call the intelligent model to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. The DSL file is used to represent the rendering information of the user interface, including the layout information, data binding information, and interaction logic of the user interface. The module traverses the DSL file to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface. The module then draws the user interface based on the view node tree.

[0015] Thirdly, this application also provides a computer device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the interface rendering method of any of the first aspects.

[0016] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps in the interface rendering method of any of the first aspects.

[0017] The beneficial effects of this invention are as follows: Introducing an intelligent model transforms the process of mapping development needs to the user interface—which previously required manual coding or relied on rigid rules—into an automated, intelligent adaptation process that understands business semantics. This dynamically generates a Domain-Specific Language (DSL) that best reflects business requirements, rather than simply filling in templates. This not only liberates developers from tedious UI adaptation work, greatly improving development efficiency and flexibility, but also, during the parsing of the DSL file, it generates a view node tree. This allows container components that exist only for layout to be optimized away during the rendering stage, thereby achieving a flattened view structure and significantly improving rendering efficiency. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of the system architecture provided in an embodiment of the present invention; Figure 2 This is a schematic flowchart of an embodiment of the interface rendering method provided by the present invention; Figure 3 This is a schematic diagram of the structure of a DSL file provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a process for parsing a DSL file into a view node tree according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the interface rendering method provided in an embodiment of the present invention; Figure 6 Specific embodiment principle block diagram of the interface rendering device provided in this invention; Figure 7 This is a schematic diagram of an embodiment of the computer device provided in this invention. Detailed Implementation

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

[0021] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more features.

[0022] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0023] It should be noted that since the method in this application embodiment is executed in a computer device, the processing objects of each computer device exist in the form of data or information, such as time, which is essentially time information. It is understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the computer device can process them. Specific details will not be elaborated here.

[0024] With the booming development of mobile internet and multi-terminal applications, the market has placed higher demands on the personalized customization, rapid iteration, and intelligent presentation capabilities of user interfaces (UI). In existing technologies, UI implementation solutions have evolved from hard-coding to declarative description. Early solutions relied on developers directly creating and configuring UI components in client-side code, resulting in high coupling and difficulty in maintenance. Subsequently, the industry commonly adopted hand-written layout resources. While these solutions separated UI structure from business logic to some extent, the UI definition remained fixed on the client side. Any visual adjustments or logical changes required a complete application compilation, release, and review process, leading to long response cycles, poor flexibility, and difficulty in meeting the ever-changing business operation needs. To address this issue, the industry further developed dynamic UI solutions based on Domain-Specific Languages ​​for UI (DSLs). These solutions involve the server distributing DSL files, which the client then parses and renders, enabling dynamic UI updates. However, the generation process of existing DSL solutions still has significant drawbacks: it typically requires backend developers to manually write or generate corresponding DSL (such as JSON format) data based on business logic or using pre-set rigid templates. This process is not only labor-intensive and error-prone, but also has a long response chain. More importantly, it cannot intelligently adapt the interface expression based on the inherent semantics of the original business data, making it difficult to achieve truly personalized UI customization and limiting the level of intelligence in UI presentation.

[0025] To address this technical challenge, this application provides the following technical solution: Acquiring business data, which characterizes the rendering requirements of the user interface; parsing the business data using an intelligent model to generate a Domain-Specific Language (DSL) file corresponding to the business data. This DSL file characterizes the rendering information of the user interface, including layout information, data binding information, and interaction logic; traversing the DSL file to generate a view node tree, which characterizes the drawing data of the view corresponding to the user interface; and rendering the user interface based on the view node tree. This introduction of an intelligent model transforms the process of mapping development needs to the user interface—which previously required manual coding or relied on rigid rules—into an automated, business-semantic, and intelligent adaptation process. This dynamically generates a Domain-Specific Language (DSL) that best reflects the business requirements, rather than simply filling in templates. This not only frees developers from tedious UI adaptation work, greatly improving development efficiency and flexibility, but also, during the parsing of the DSL file, generates a view node tree. This allows container components that exist only for layout to be optimized away during the rendering stage, achieving a flattened view structure and significantly improving rendering efficiency.

[0026] This application provides an interface rendering method, apparatus, computer device, and computer-readable storage medium to improve the development efficiency and flexibility of UI development. The electronic device provided in this application can be implemented as various types of user terminals or as a server.

[0027] Electronic devices can improve the efficiency and flexibility of UI development by running the interface rendering method provided in the embodiments of this application.

[0028] The above methods can be applied to many UI development fields, such as application user interface development, web page user interface development, and so on.

[0029] In one exemplary solution, this UI rendering method can be applied to the rendering of personalized recommendation cards on the homepage of an e-commerce application. In this scenario, when the server generates a promotional activity for a specific user, its original business data may only contain core fields such as activity type (e.g., "flash sale"), product information, discount level, and expiration time. After receiving this business data, the intelligent model deployed in the cloud parses and performs semantic understanding, and automatically generates a structured DSL file based on a pre-defined UI knowledge base and rules. For example, if the model identifies the "flash sale" type, it will construct a vertical layout container structure in the DSL containing a product image, a prominent discount label, a product title, and a dynamic countdown component. After the DSL file is sent to the client, the client's parsing engine immediately parses it, constructing a lightweight view node tree in memory that corresponds one-to-one with the DSL structure. Subsequently, the rendering engine traverses this view node tree and calls the corresponding native rendering capabilities according to the type (such as image, text, countdown timer) and style attributes of each node. Finally, it efficiently draws a promotional card interface containing complete visual elements and interactive logic on the user's screen. The entire process does not require manual writing of UI layout code, realizing the automated and intelligent generation from business data to the final interface.

[0030] It should be understood that the above is only an exemplary application scenario of the interface rendering method. There are many other possible application scenarios, which are not limited here.

[0031] The interface rendering method provided in this application embodiment is applied to, for example, Figure 1 The system architecture diagram shown is for your reference. Figure 1To support a user interface rendering method, the terminal device 100 connects to the server 300 via network 200, and the server 300 connects to the database 400. Network 200 can be a wide area network (WAN), a local area network (LAN), or a combination of both. The client used to implement the user interface rendering method is deployed on the terminal device 100, or it can run on the terminal device 100 as a standalone application. The specific display format of the client is not limited here.

[0032] The server 300 involved in this application can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms.

[0033] Terminal equipment 100, also known as user equipment (UE), mobile station (MS), mobile terminal (MT), customer premises equipment (CPE), etc., can be a device that includes both receiving and transmitting hardware, that is, a device with receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. Such equipment can include cellular or other communication devices with single-line displays, multi-line displays, or no multi-line displays. Examples include handheld devices with wireless connectivity, vehicle-mounted devices, machine-type communication (MTC) terminals, etc. Currently, terminal devices 100 can include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, etc. For example, wireless terminals in self-driving vehicles can be drones, helicopters, or airplanes. For example, wireless terminals in vehicle-to-everything (V2X) systems can be in-vehicle equipment, vehicle-mounted equipment, in-vehicle modules, vehicles, or ships, etc. Wireless terminals in industrial control can be cameras, robots, or robotic arms, etc. Wireless terminals in smart homes can be televisions, air conditioners, robot vacuums, speakers, or set-top boxes, etc.

[0034] It should be noted that the terminal device 100 may be a device or apparatus with a chip, or a device or apparatus with integrated circuitry, or a chip, module, or control unit in the device or apparatus shown above; this application does not impose any specific limitations. The solution provided in this application can be implemented by the terminal device 100 and the server 300 working together.

[0035] In short, a database can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of application programs. A Database Management System (DBMS) is a computer software system designed to manage databases, generally possessing basic functions such as storage, retrieval, security, and backup. DBMSs can be classified according to the database model they support, such as relational or Extensible Markup Language (XML); or according to the type of computer they support, such as server clusters or mobile phones; or according to the query language used, such as Structured Query Language (SQL) or XQuery; or according to performance priorities, such as maximum scale or maximum operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, supporting multiple query languages ​​simultaneously. In this application, database 400 can be used to store data such as DSL files, intelligent models, UI knowledge bases and rules, and business data.

[0036] Those skilled in the art will understand that Figure 1 The system architecture diagram shown is one possible system architecture for this application and does not constitute a limitation on the system architecture of this application. Other system architectures may include more advanced architectures. Figure 1 The number of more or fewer terminal devices or servers shown, for example Figure 1 The diagram shows one server. It is understood that the system architecture may also include one or more other terminal devices or servers, which are not limited here.

[0037] It should be noted that, Figure 1 The system architecture shown is an example. The servers and scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of servers and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0038] like Figure 2 The diagram shown is a flowchart of an embodiment of the interface rendering method in this application. The following description, using a terminal device as the execution subject, illustrates the interface rendering method, which may include the following steps 201 to 204, as detailed below: 201. Obtain business data, which is used to characterize the rendering requirements of the user interface.

[0039] In user interface development or user interface rendering scenarios, the terminal device can obtain corresponding business data, which is used to characterize the rendering requirements of the user interface of the client deployed on the terminal device.

[0040] In this embodiment, the terminal device can acquire text data, image data, video data, and / or audio data; then perform structuring processing on the text data, image data, video data, and / or audio data to obtain structured data, which serves as the business data.

[0041] When this terminal device acquires business data, it can use different acquisition methods for different application scenarios.

[0042] In one exemplary scenario, during the user interface development process, the terminal device can obtain development requirements (also known as business requirements) provided by a third party (such as developers) and generate business data based on these requirements. For example, in an application under development, developers provide corresponding development requirements for the user interface. After receiving these requirements, the terminal device performs structured processing to obtain the business data. It should be understood that when developers submit development requirements, they can use standardized requirement documents or other forms of documents, such as text data, image data, audio data, or video data, etc., without specific limitations here.

[0043] In another exemplary solution, the terminal device responds to a user interface rendering request by obtaining the rendering requirements of the corresponding user interface, and then retrieves the corresponding business data from the server based on these rendering requirements. The implementation process can be as follows: The client deployed on this terminal device (such as an app installed on a mobile phone) needs to update its interface due to user actions (such as opening the homepage) or system events (such as receiving a push notification). At this time, the client on the terminal device constructs a business request based on the current context (such as user ID, device information, and target page ID). The client sends this request to a pre-configured server over the network. After receiving the business request, the server performs authentication and permission verification, and then queries and aggregates relevant raw business data from its backend database, cache, or microservices according to the request parameters. The server encapsulates the retrieved raw data into a preset structured business data format (usually JSON). The server places the encapsulated business data in a response frame and returns it to the client. The client receives and parses the response frame, extracting the clean business data object from it.

[0044] In this embodiment, the process by which the server queries and aggregates relevant raw business data from its backend database, cache, or microservices can be as follows: 1. The server queries the main database to obtain the business data. For example, the server retrieves basic data from a core relational database (such as MySQL, PostgreSQL) or a NoSQL database (such as MongoDB).

[0045] 2. The server accesses the caching system to obtain the business data. For example, the server prioritizes checking whether there is hot data in the cache (such as Redis, Memcached) to avoid repeated database queries.

[0046] 3. The server calls internal microservices to retrieve the business data. In modern network architectures, a single piece of business data may be provided by multiple independent microservices. For example, to retrieve product details, the server might need to separately call the "Product Service" to obtain basic information, the "Inventory Service" to obtain real-time inventory, and the "Review Service" to obtain user reviews. The server is responsible for coordinating these calls and aggregating the results.

[0047] 4. The server calls a third-party application programming interface (API) to obtain the business data. For example, sometimes the business data comes from external sources; for instance, obtaining weather information requires calling a weather application programming interface (API), and obtaining map data requires calling a map service application programming interface (API).

[0048] In an exemplary application scenario, a user enters flight number "XXXXX" in an airline's mini-program and clicks "Search." At this point, the "Retrieve Business Data" step is triggered. The airline's mini-program sends a request to the server containing {"Flight Number": "XXXXX"}. Upon receiving the request, the server queries the real-time information of the flight from the flight management system and returns corresponding business data. This business data may include flight number, airline, departure city, departure airport, arrival city, arrival airport, departure time, and arrival time. Once the terminal device obtains this data, this step is complete. This data represents all the core information that the interface needs to display: flight number, airline, departure and arrival cities, time, status, and gate.

[0049] In this embodiment, when the terminal device triggers the operation of acquiring service data, it may have the following triggering events: In one possible implementation, the triggering event is a user-initiated action. For example, a user launching an application, clicking a button, switching pages, swiping up to load more information in a list, or entering search keywords. These actions clearly express the user's intention to see new information or update the current information.

[0050] In another possible implementation, the triggering event can be an automatic system action. For example, the application might silently refresh background data at preset intervals, the application might need to display details when the operating system pushes a notification message, or the application might need to refresh its status when a countdown ends.

[0051] When an event is triggered, the terminal device needs to determine the context required for this business data acquisition, such as which page or module the data is for, as well as the key parameters required for acquiring the business data (such as user identifier, product identifier, etc.).

[0052] Optionally, the process by which the server or the terminal device performs structured processing on the business data can be as follows: Field filtering: Only retain fields necessary for displaying the client user interface.

[0053] Restructuring: Organizing flat data into a more logical nested structure.

[0054] Data calculation: Perform some server-side calculations, such as calculating the final selling price based on the original price and discount, or formatting date strings.

[0055] Ultimately, the server or terminal device outputs structured business data that accurately represents the UI rendering requirements.

[0056] 202. Call the intelligent model to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. This DSL file is used to represent the rendering information of the user interface.

[0057] After acquiring the service data, the terminal device can use the service data as input data for the intelligent model. The intelligent model then performs semantic understanding and reasoning processing on the service data to generate a DSL file corresponding to the service data. The DSL file is used to represent the rendering information of the user interface.

[0058] The DSL file, or Domain-Specific Language file, is a computer-readable file used for description and expression within a specific problem domain. Unlike general-purpose programming languages ​​(such as Java and C++) designed to solve general computing problems, DSL files employ a restricted but highly expressive syntax, aiming to provide a highly abstract and declarative way of describing a specific domain (such as database queries, UI layouts, and build processes). Its core purpose is to enable systems or developers to focus on describing business intent rather than specific implementation steps. In this embodiment, the DSL file serves as an intermediate data carrier for a structured description of the user interface (UI). It defines the types, hierarchical relationships, style attributes, and bindable interactive events of the various view components that constitute the interface in a way that is independent of specific rendering platforms (such as Android, iOS, and Web). This file serves as the output of the intelligent model after parsing business data and the input of the client-side rendering engine, acting as a standardized protocol or blueprint between abstract business semantics and the final visual presentation.

[0059] This DSL file typically uses a data exchange format with good readability and machine parsing capabilities, such as JSON (JavaScript Object Notation) or Extensible Markup Language (XML). Its content is organized into a tree structure, where each node represents a UI element. For example, the structure definition of this DSL file could be as follows: Figure 3 As shown: Each node contains at least a "type" field to identify its component type (such as 'text', 'image', 'container'), a "direction" field to describe its appearance and behavior, and can nest other child nodes through the "children" field, thus fully representing the layout, content and interaction logic of the entire interface.

[0060] This intelligent model, also known as an intelligent agent, is a computational entity or mathematical representation constructed through algorithms that can process input data and generate outputs with specific semantics. Its core characteristic is that it does not operate based on fixed, hard-coded rules, but rather performs tasks such as reasoning, prediction, classification, or generation by learning patterns, associations, or rules from large amounts of data, thereby simulating or realizing human intelligent behavior in a specific domain. In this embodiment, the intelligent model can refer to a functional module trained to understand the semantics of business data and automatically convert it into a DSL file. The core task of this model is to act as a converter from "business semantics to interface structure." It receives business data representing user interface development requirements as input, and through built-in semantic analysis, feature extraction, and mapping logic, intelligently maps non-visual business information into a DSL file containing specific view components, layout structures, and style definitions, thereby achieving automated generation of UI definitions.

[0061] It should be understood that this intelligent model can be built through various technical paths. For example, it can be a deep learning-based neural network model, such as using recurrent neural networks or Transformer architectures to process serialized business data and generate corresponding DSL structure sequences. Alternatively, it can be a hybrid system combining a rule engine and a knowledge graph, where the rule engine handles deterministic mapping logic (e.g., "flash sale" business data always maps to a DSL component containing a countdown timer), while the knowledge graph stores the association knowledge between UI components and business concepts. After supervised learning training with a large number of "business data to DSL file" paired samples, the model's internal parameters (such as network weights) are solidified, forming a deployable inference engine capable of performing fast inference.

[0062] In one exemplary scheme, the training process of the intelligent model can be as follows: obtain training samples, an initial model, and a user interface layout specification, wherein the training samples include historical business data and historical DSL files, and the user interface layout specification includes a flex layout model and / or custom layout rules; train the initial model based on the training samples and the user interface layout specification to obtain the intelligent model.

[0063] The user interface layout specification is a set of rules and algorithms used to determine the spatial relationships between view elements in a user interface. This specification defines a set of formal constraints and models, enabling the system to automatically calculate the precise position and size of each view element on the two-dimensional display plane based on these preset rules. Its purpose is to abstract layout logic from specific coordinate encoding, achieving a declarative description and reusability of the layout method. In this embodiment, the user interface layout specification is the core principle followed by the rendering engine when parsing the view node tree and performing layout calculations. When the rendering engine traverses the view node tree, it checks the layout attributes specified for each node (e.g., the layout or style attributes defined in the DSL file) and applies the corresponding layout model or rules in the specification to calculate the geometric framework of the node and its child nodes. This specification is a crucial bridge connecting the structured view description (view node tree) and the final visual presentation (the position and size of elements on the screen).

[0064] This user interface layout specification includes at least one or more of the following specific layout models: Flexbox layout model: This is a one-dimensional layout model that provides powerful spatial distribution and alignment capabilities for items within a container. When a view node's layout mode is specified as Flex, the rendering engine will automatically calculate the size and position of its child nodes based on its main axis direction (row or column), main axis alignment, and cross axis alignment, etc., to efficiently adapt to different screen sizes and dynamic content.

[0065] Custom layout rules: This is an extensible layout mechanism that allows the system to define and register specific layout algorithms beyond the standard model. For example, a custom layout rule named "Waterfall" can be implemented to create a waterfall layout. When the layout mode of a container node is specified as "Waterfall," the rendering engine calls the pre-registered waterfall layout algorithm to dynamically and non-linearly arrange the child nodes according to their sizes for efficient space utilization. Essentially, this custom layout rule is a function or algorithm module that takes a list of nodes and their attributes as input and outputs the calculated geometric framework of each node.

[0066] 203. Traverse the DSL file to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface.

[0067] After the terminal device obtains the DSL file, it parses the DSL file to obtain a view node tree, which is used to represent the drawing data of the view corresponding to the user interface.

[0068] In this embodiment, the view node tree (NodeTree) is a tree-like data structure built in computer memory to represent the logical structure of the user interface. This structure consists of multiple view nodes, each corresponding to a visible or non-visual element in the interface (such as text, images, containers, etc.), and the parent-child relationships between nodes accurately reflect the nesting and hierarchical relationships of interface elements. It is an abstract and programmatic memory mapping of the user interface layout and content. In this embodiment, the view node tree is an intermediate data representation generated by the rendering engine after parsing the DSL file. It transforms the declarative, textual interface description in the DSL file into a programmatic object model that can be directly traversed and manipulated. The view node tree is the direct object for subsequent layout calculations, style applications, and final rendering to the screen, and is a crucial link connecting static description and dynamic rendering.

[0069] In one exemplary scheme, each view node in the view node tree is typically an instance of a data object or class. This node object contains at least the following information: Component type identifier: A field used to identify the type of its corresponding UI component (e.g., 'text', 'image', 'container').

[0070] Attribute collection: An object that stores its content, style, and behavior attributes (e.g., text content, color, font size, and bound click events).

[0071] Child node list: A list or array used to store all its child view nodes. The empty or non-empty state of the list determines whether the node is a leaf node or a non-leaf node, thus defining the hierarchical structure of the tree.

[0072] Parent node reference: A reference to its parent node to facilitate upward traversal in the tree and access to context information.

[0073] Based on the above description, the process by which the terminal device traverses the DSL file to generate the view node tree can be as follows: traverse each node in the DSL file and perform node objectification processing on each node to obtain multiple node objects, wherein each node object includes a node identifier, node type, visual appearance information and binding event information for each node; generate the view node tree based on the nesting relationship in the DSL file from the multiple node objects.

[0074] In one exemplary scheme, the terminal device may adopt the following approach when generating node objects: traverse each node in the DSL file and create a corresponding node object for each node; obtain the node type of each node and determine the processing component corresponding to each node based on the node type; obtain the visual appearance information and binding event information corresponding to each node based on the processing component; and store the visual appearance information and binding event information in the node object corresponding to each node to obtain the multiple node objects.

[0075] The processing component can be understood as a modular software entity with specific functions. It is designed to receive input data, perform a series of predefined calculations or transformations, and generate corresponding output results. This processing component encapsulates the algorithms, rules, or operation sequences required to implement a specific task. By providing explicit input / output interfaces, it achieves functional cohesion and isolation, thereby improving the system's maintainability, reusability, and scalability. In this embodiment, the processing component can be a pluggable functional unit constituting the entire rendering pipeline. It is responsible for executing a specific stage in the rendering process. For example, it can be a "parsing and building component" responsible for converting a DSL file into a view node tree, a "layout calculation component" responsible for calculating the layout of each node in the view node tree, or a "drawing component" responsible for converting a view node tree with layout information into platform-native drawing instructions.

[0076] In this embodiment, the processing component may include multiple components, such as a basic view component, a layout component, and a custom component.

[0077] This basic view component parses the attribute data of view nodes in the DSL file and converts it into drawing information that the view node tree can store. For example, the basic view component parses the style object of each node into a style attribute map. Then, it converts the style attribute map into standardized drawing information according to preset rules. For example, CSS-like style values ​​in the protocol (such as "10px", "#RRGGBB") are converted into standardized units used internally by the Android system (such as pixel values, ColorInt). Finally, the style attributes (such as padding, margin, color, fontSize, backgroundColor, borderRadius, etc.) are stored as drawing instruction parameters (drawing information) in the node object, waiting to be used in the rendering stage.

[0078] This layout component parses the container nodes in the DSL file, primarily handling the layout calculations for child nodes. It may not render any content itself, but rather maps the layout information of each node in the DSL file to the size and position information of each node during the layout process. This drawing, size, and position information will serve as the visual appearance information for each node. For example, for nodes of type flex or their child nodes, the layout component converts the Flex layout-related properties (such as flexDirection (main axis direction), justifyContent (main axis alignment), alignItems (secondary axis alignment), flexWrap (line wrapping), and gap (space)) from the style object in the DSL file into parameters recognizable by the layout component. Then, starting from the Flex container node, the layout component recursively performs layout calculations on its child nodes: calculating the expected size of each child node based on its style (width, height, flexGrow, flexShrink, etc.), content, and container constraints. According to Flex rules, it calculates the exact coordinates (x, y) of each child node within the container.

[0079] Finally, the calculated absolute coordinates and final width and height of each node are stored as geometric attributes in the corresponding node object. At this point, the position and size of each node are determined.

[0080] The custom component can be defined as any parsing and rendering logic that needs to be added, such as `custom_card`. In this embodiment, the business side can pre-register the parsing and rendering logic of the custom component. Then, during DSL file parsing, the corresponding custom component can be determined according to the node type, and the corresponding parsing and rendering logic can be called to achieve the reuse and dynamic updating of the business UI module. In this embodiment, the implementation of the custom component can be as follows: In the DSL file, an event field can be defined for each node, such as `{"onClick": "fetchUserInfo", "onVisible": "trackExposure"}`. Then, during the parsing process, the custom component reads the event definition indicated by the event field and registers it to a central event handler. When user interaction (such as a click) is triggered, the underlying input event is captured and passed to the corresponding node in the view node tree. The central event handler executes the corresponding action of the event definition indicated by the event field. The UI layer only emits event identifiers; the specific business logic is defined by the backend protocol, achieving complete decoupling from the frontend code.

[0081] Optionally, in this embodiment, the DSL file may also introduce native capability call syntax (e.g., @native{capability_key}), and implement the target capability based on this native capability call syntax. During the construction of the view node tree, this native capability call syntax can be directly bound to the target node. During the drawing process, when the runtime encounters this native capability call syntax, it can obtain the returned data based on this syntax; then, based on the returned data, it can update the view appearance information and / or bound event information of the target view node in the view node tree; and then, during the drawing process, the updated target view node can be drawn directly.

[0082] The implementation can be as follows: The terminal device maintains a dynamically expandable capability registry. Businesses can implement specific capabilities (such as obtaining user information, calling QR code scanning, and cross-process data querying) by following the unified interface (INativeCapability) and register them in the table. When an event is triggered by parsing the DSL file or calling the native capability call syntax, if the @native{} syntax is encountered, the terminal device intercepts the capability_key (such as userinfo), searches for the corresponding capability implementation in the registry based on the event indicated by the capability_key, calls the capability, obtains the native return result (such as a UserInfo object), and dynamically populates / updates the result to the node attributes or status specified in the DSL protocol, thereby triggering a UI update.

[0083] Based on the above description, the following will be used as... Figure 4 The flowchart shown illustrates the process of traversing and parsing the DSL to generate the view node tree: Receive the DSL file and use a standard parser (such as a JSON parser or XML parser) to parse the complete text content of the DSL file into a general, programmable tree data structure (e.g., a JavaScript object consisting of nested objects and arrays).

[0084] Define a recursive function, such as createNode(genericNode, parentNode). This function takes two arguments: a node in the tree data structure (genericNode) and a reference to the future parent node of the node in the tree data structure (parentNode).

[0085] Inside the recursive function, first, based on the type field of the node in the tree data structure, an empty view node object of the corresponding type (newViewNode) is instantiated, and a node object is created. At this time, the node object has no view elements.

[0086] Then, node dispatching is performed, which routes nodes to different processing components based on their node type in the tree data structure. When the node type is a non-container node, the attribute data (such as content and styles in attribute objects) carried by the node in the tree data structure is copied or mapped to the corresponding attributes of the node object based on the base view component; or the event definitions carried by the node in the tree data structure are registered based on the custom component. When the node type is a container node, child nodes are processed recursively to complete the node layout calculation.

[0087] The recursive processing of child nodes can be as follows: Based on the nesting relationships in the DSL file, determine the reference relationships of the nodes in the tree data structure. For example, assign the passed-in parent node reference to the parent node pointer of the node object (e.g., newViewNode.parent = parentNode), thus establishing an upward tracing link. Check if the nodes in the tree data structure contain a child node (children) field and if it is a non-empty list. If so, traverse the child node list. For each child node in the list, recursively call createNode(childGenericNode, newViewNode), and add the returned child view node object to a temporary list. Assign the generated temporary child view node list to the child node list property of newViewNode (e.g., newViewNode.children = [...]).

[0088] After the recursive function that recursively processes child nodes completes execution, it returns the constructed node object. The entire process begins by calling `createNode(rootGenericNode, null)`, where `rootGenericNode` is the root node of the tree data structure, and its parent node reference is initially null. Ultimately, this initial call returns the root node of the entire view node tree.

[0089] After completing the overall recursive function, the view node tree is generated.

[0090] 204. Render the user interface based on the view node tree.

[0091] After the terminal device parses the DSL file to obtain the view node tree, it can trigger the user interface rendering operation. At this time, the terminal device can first create a drawing canvas; then traverse the view node tree to obtain the view appearance information of each view node; finally, based on the view appearance information, call the corresponding drawing tool to render the user interface on the drawing canvas.

[0092] Optionally, after introducing native capability call syntax (e.g., `@native{capability_key}`), the target capability can be implemented based on this syntax. For example, during the construction of the view node tree, the native capability call syntax can be directly bound to the target node. Then, during the rendering process, when the runtime encounters this native capability call syntax, it can retrieve the returned data based on this syntax; then, based on the returned data, it can update the view appearance information and / or bound event information of the target view node in the view node tree; and then, during the rendering process, the updated target view node can be directly drawn.

[0093] Based on this native capability call syntax, dynamic refresh can be achieved during the user interface rendering process. For example, when the DSL protocol is updated or new data is called back by the @native{} capability, it is only necessary to update the attribute data of the corresponding node object, mark the dirty area, and trigger a targeted redraw of the layout.

[0094] Based on the above, the following will be based on... Figure 5 The rendering framework shown illustrates the interface rendering method of this application embodiment: like Figure 5 As shown, the rendering framework includes a front-end interface, an intelligent model, a back-end gateway, a client (deployed on the terminal device), and a DSL parsing engine. Within this framework, the user inputs / uploads business data through the front-end interface; the front-end interface calls the application programming interface to send a request and inputs the business data into the intelligent model; the intelligent model performs semantic parsing and model inference on the DSL file to obtain the corresponding DSL file for the business data; then, the DSL file is sent to the client through the back-end gateway; the client recursively parses the DSL file based on the DSL parsing engine to obtain the visual appearance information and bound event information of each node; finally, a view node tree is generated based on the visual appearance information and bound event information, and the user interface is rendered based on this view node tree.

[0095] As described above, the UI rendering method provided in this implementation introduces an intelligent model, transforming the mapping process from manually written or rigidly rule-based development requirements to the user interface into an automated, business-semantic, and intelligent adaptation process. This dynamically generates a Domain-Specific Language (DSL) that best reflects business needs, rather than simply filling in templates. This not only frees developers from tedious UI adaptation work, greatly improving development efficiency and flexibility, but also, during the parsing of the DSL file, it generates a view node tree. This allows container components that exist only for layout to be optimized away during the rendering stage, achieving a flattened view structure and significantly improving rendering efficiency. Furthermore, the introduction of native capability call syntax and custom components enables pluggable and extensible UI components and dynamic data binding, greatly expanding the breadth of business support.

[0096] To better implement the interface rendering method in the embodiments of this application, an interface rendering device is also provided in the embodiments of this application, such as... Figure 6 As shown, the interface rendering device 600 includes: The acquisition module 601 is used to acquire business data, which is used to characterize the rendering requirements of the user interface. The processing module 602 is used to call the intelligent model to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. The DSL file is used to represent the rendering information of the user interface. The DSL file is traversed to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface. The user interface is drawn based on the view node tree.

[0097] In this embodiment, the introduction of an intelligent model transforms the process of mapping development needs to the user interface—which previously required manual coding or relied on rigid rules—into an automated, business-semantic-understanding intelligent adaptation process. This dynamically generates a Domain-Specific Language (DSL) that best reflects business requirements, rather than simply filling in templates. This not only frees developers from tedious UI adaptation work, greatly improving development efficiency and flexibility, but also, during the parsing of the DSL file, it generates a view node tree. This allows container components that exist only for layout to be optimized away during the rendering stage, thereby achieving a flattened view structure and significantly improving rendering efficiency.

[0098] In some embodiments of this application, the acquisition module 601 is specifically used for: Acquire text data, image data, video data, and / or audio data; The text data, image data, video data, and / or audio data are processed into structured data to obtain structured data, which serves as the business data.

[0099] In this embodiment, multiple types of business data are provided to enhance the feasibility of the solution. Vague and variable business requirements are transformed into clear, unified structured data, enabling machines to understand and process these requirements. This significantly reduces communication costs and development ambiguities, and lays the foundation for subsequent automated generation, testing, and even interface rendering, thereby significantly improving end-to-end delivery efficiency.

[0100] In some embodiments of this application, the acquisition module 601 is further configured to: Obtain training samples, an initial model, and user interface layout specifications. The training samples include historical business data and historical DSL files, and the user interface layout specifications include a flex layout model and / or custom layout rules. The processing module 602 is also used to train the initial model based on the training samples and the user interface layout specifications to obtain the intelligent model.

[0101] In this embodiment, the introduction of an intelligent model transforms the process of mapping development needs to the user interface—which previously required manual coding or relied on rigid rules—into an automated, intelligent adaptation process that understands business semantics. This dynamically generates a Domain-Specific Language (DSL) that best reflects business requirements, rather than simply filling in templates. This not only frees developers from tedious UI adaptation work but also greatly improves development efficiency and flexibility.

[0102] In some embodiments of this application, the processing module 602 is specifically used to traverse each node in the DSL file and perform node objectification processing on each node to obtain multiple node objects, wherein each node object includes a node identifier, a node type, visual appearance information and binding event information for each node. Based on the nesting relationships in the DSL file, the multiple node objects are used to generate the view node tree.

[0103] In this embodiment of the application, during the parsing of the DSL file, the DSL file is parsed into a view node tree. This allows container components that exist only for layout to be optimized away during the rendering stage, thereby achieving a flattened view structure and significantly improving rendering efficiency.

[0104] In some embodiments of this application, the processing module 602 is specifically used to traverse each node in the DSL file and create a corresponding node object for each node. Obtain the node type of each node, and determine the corresponding processing component based on the node type; Based on this processing component, the corresponding visual appearance information and bound event information of each node are obtained; The visual appearance information and the bound event information are stored in the node objects corresponding to each node to obtain the multiple node objects.

[0105] In this embodiment, node type-based distribution establishes a clear and orderly routing mechanism for the UI processing flow. It breaks down the large and complex problem of "how to handle any node" into a series of independent and simple sub-problems of "how to handle specific types of nodes." This gives the system extremely high scalability, maintainability, and code clarity. Thus, the potentially chaotic UI parsing and event binding process is transformed into a structured, predictable, and easily manageable standardized process.

[0106] In some embodiments of this application, the processing component includes a basic view component, a layout component, and a custom component; The processing module 602 is specifically used to obtain the view element of the node based on the basic view component and map the view element into drawing information; The layout information of the nodes is obtained based on the layout component, and the layout information is mapped to the size information and position information of each node. The drawing information, the size information and the position information serve as the visual appearance information of each node. The custom component retrieves the event definition corresponding to the node and registers the event definition as the event identifier for each node, where the event identifier serves as the bound event information.

[0107] In this embodiment, the processing schemes of each processing component are described in detail, and the abstract node extension rules are concretized into a clear and reusable development template. This enables the rapid and correct access to new node types through imitation, which greatly reduces the development threshold, unifies the implementation paradigm, and thus significantly improves the collaborative development efficiency and stability of the system.

[0108] In some embodiments of this application, the processing module 602 is specifically used to create a drawing canvas; Traverse the view node tree to obtain the view appearance information for each view node; Draw the user interface on the drawing canvas based on the view's appearance information.

[0109] In this embodiment, the view node tree is a lightweight, data-driven, platform-independent object. It is merely a description or blueprint of the actual view, and the view hierarchy no longer needs to be considered during the rendering process, thereby achieving a flattened view structure and significantly improving rendering efficiency.

[0110] In some embodiments of this application, the processing module 602 is further configured to obtain returned data based on the native capability call syntax; Update the view appearance information and / or bound event information of the target view node in the view node tree based on the returned data; Redraw the view corresponding to the target view node to update the user interface.

[0111] In this embodiment, the syntax decouples native data acquisition from UI rendering, achieving non-blocking loading of the interface. It encapsulates the complexity of asynchronous callbacks and partial redraws, and when native data is returned, it can automatically and accurately update the target node without redrawing the entire interface, thereby greatly improving page responsiveness and user experience.

[0112] This application also provides a computer device that integrates any of the interface rendering method apparatuses provided in this application. The computer device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor from the steps of the interface rendering method in any of the above-described embodiments of the interface rendering method.

[0113] This application also provides a computer device that integrates any of the interface rendering devices provided in this application. For example... Figure 7 As shown, it illustrates a structural schematic diagram of the computer device involved in the embodiments of this application, specifically: The computer device may include components such as a processor 701 with one or more processing cores, a memory 702 with one or more computer-readable storage media, a power supply 703, and an input unit 704. Those skilled in the art will understand that... Figure 7 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 701 is the control center of the computer device. It connects various parts of the computer device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 702, and by calling data stored in the memory 702, it performs various functions of the computer device and processes data, thereby providing overall monitoring of the computer device. Optionally, the processor 701 may include one or more processing cores; preferably, the processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 701.

[0114] The memory 702 can be used to store software programs and modules. The processor 701 executes various functional applications and data processing by running the software programs and modules stored in the memory 702. The memory 702 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 702 may also include a memory controller to provide the processor 701 with access to the memory 702.

[0115] The computer device also includes a power supply 703 that supplies power to the various components. Preferably, the power supply 703 can be logically connected to the processor 701 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 703 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0116] The computer device may also include an input unit 704, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0117] Although not shown, the computer device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 701 in the computer device loads the executable files corresponding to the processes of one or more application programs into the memory 702 according to the following instructions, and the processor 701 runs the application programs stored in the memory 702 to realize various functions, as follows: Acquire business data, which is used to characterize the rendering requirements of the user interface; The intelligent model is invoked to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. This DSL file is used to represent the rendering information of the user interface. Traverse the DSL file to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface; The user interface is rendered based on this view node tree.

[0118] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0119] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the interface rendering methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Acquire business data, which is used to characterize the rendering requirements of the user interface; The intelligent model is invoked to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. This DSL file is used to represent the rendering information of the user interface. Traverse the DSL file to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface; The user interface is rendered based on this view node tree.

[0120] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0121] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0122] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0123] The foregoing has provided a detailed description of an interface rendering method, apparatus, computer device, and computer-readable storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An interface rendering method, characterized by, include: Acquire business data, which is used to characterize the rendering requirements of the user interface; The intelligent model is invoked to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. The DSL file is used to represent the rendering information of the user interface. The DSL file is traversed to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface; The user interface is rendered based on the view node tree.

2. The method of claim 1, wherein, The acquired business data includes: Acquire text data, image data, video data, and / or audio data; The text data, image data, video data, and / or audio data are subjected to structuring processing to obtain structured data, which serves as the business data.

3. The method of claim 1, wherein, The method further includes: Obtain training samples, an initial model, and user interface layout specifications, wherein the training samples include historical business data and historical DSL files, and the user interface layout specifications include a flex layout model and / or custom layout rules; The initial model is trained based on the training samples and the user interface layout specifications to obtain the intelligent model.

4. The method according to any one of claims 1 to 3, characterized in that, Traversing the DSL file to generate a view node tree includes: Traverse each node in the DSL file and perform node objectification on each node to obtain multiple node objects, wherein each node object includes a node identifier, node type, visual appearance information and binding event information for each node; The view node tree is generated from the multiple node objects based on the nesting relationships in the DSL file.

5. The method of claim 4, wherein, Traverse each node in the DSL file and objectify each node to obtain multiple node objects, including: Traverse each node in the DSL file and create a corresponding node object for each node; Obtain the node type of each node, and determine the processing component corresponding to each node based on the node type; Based on the processing component, the corresponding visual appearance information and bound event information of each node are obtained; The visual appearance information and the binding event information are stored in the node objects corresponding to each node to obtain the multiple node objects.

6. The method of claim 5, wherein, The processing components include basic view components, layout components, and custom components; The processing component obtains the corresponding visual appearance information and bound event information for each node, including: The view elements of the nodes are obtained based on the basic view components, and the view elements are mapped to drawing information; The layout information of the nodes is obtained based on the layout component, and the layout information is mapped to the size information and position information of each node, wherein the drawing information, the size information and the position information serve as the visual appearance information of each node; The custom component obtains the event definition corresponding to the node and registers the event definition as the event identifier of each node, wherein the event identifier serves as the bound event information.

7. The method according to any one of claims 1 to 3, 5 to 6, characterized in that, Rendering the user interface based on the view node tree includes: Create a drawing canvas; Traverse the view node tree to obtain the view appearance information of each view node; The user interface is drawn on the drawing canvas based on the view appearance information.

8. The method according to claim 7, characterized in that, The method further includes: Retrieve returned data based on native capability call syntax; Update the view appearance information and / or bound event information of the target view node in the view node tree based on the returned data; Draw the view corresponding to the target view node to obtain the user interface.

9. An interface rendering device, characterized in that, include: The acquisition module is used to acquire business data, which is used to characterize the rendering requirements of the user interface. The processing module is used to call the intelligent model to parse and process the business data to generate a domain-specific language (DSL) file corresponding to the business data. The DSL file is used to represent the rendering information of the user interface. The DSL file is traversed to generate a view node tree, which is used to represent the drawing data of the view corresponding to the user interface; The user interface is drawn based on the view node tree.

10. A computer device, characterized in that, The computer device includes: One or more processors; Memory; and One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the method according to any one of claims 1 to 8.

Images