Dynamic interface rendering method and apparatus, storage medium, and electronic device

Abstract

The application discloses a dynamic interface rendering method and device, a storage medium and an electronic device, wherein the dynamic interface rendering method comprises the following steps: sending a configuration request to a server, and receiving structured configuration data returned by the server; analyzing the structured configuration data, and generating a first component tree model; creating a native view instance and building a view tree according to the first component tree model, and mounting the view tree to a target container; obtaining a current environment context state, and controlling the display, hiding or deferred rendering of a corresponding component according to the current environment context state; when detecting a configuration update or a local data change, generating a second component tree model, comparing the second component tree model with the first component tree model, and performing incremental rendering on the part of the view tree that has changed according to the comparison result. The application can balance dynamic expansion capability, native performance, development efficiency and device compatibility.

Description

Technical Field

[0001] This application relates to the field of interface rendering technology, specifically to a dynamic interface rendering method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the rapid iteration of mobile internet services, Android application interfaces need frequent updates to adapt to market demands and changes in user behavior. In traditional development models, interface layout, styles, and interaction logic are typically fixed in the client-side code. Any interface adjustment requires rewriting the code, packaging and releasing it, and undergoing app store review, resulting in long update cycles and slow response times. To address this, various dynamic technical solutions have emerged, attempting to achieve dynamic deployment and real-time updates of the interface while maintaining native performance. However, existing solutions still have their limitations.

[0003] Currently, the mainstream dynamic interface implementation solutions mainly fall into three categories: First, traditional Android native development, which relies on XML static layout and Activity / Fragment hard coding, and interface updates must be released with the version release; second, WebView hybrid development solution, which achieves dynamics by loading remote H5 pages and uses JavaScript to bridge and interact with native functions; and third, cross-platform dynamic frameworks (such as Flutter), which package the rendering engine into the application and achieve cross-platform interface reuse through self-drawing.

[0004] However, while the current solutions have their own advantages in different scenarios, none of them can simultaneously achieve dynamic scalability, native performance, development efficiency, and device compatibility. Summary of the Invention

[0005] This application provides a dynamic interface rendering method, apparatus, storage medium, and electronic device that can balance dynamic scalability, native performance, development efficiency, and device compatibility.

[0006] In a first aspect, embodiments of this application provide a dynamic interface rendering method, including: Send a configuration request to the server and receive structured configuration data returned by the server; Parse the structured configuration data to generate a first component tree model; Based on the first component tree model, create native view instances and construct view trees, and mount the view trees to the target container; Obtain the current environment context state, and control the display, hiding, or delayed rendering of the corresponding components based on the current environment context state; When a configuration update or local data change is detected, a second component tree model is generated. The second component tree model is compared with the first component tree model, and incremental rendering is performed on the changed parts of the view tree based on the comparison results.

[0007] In the dynamic interface rendering method provided in this application embodiment, the step of parsing the structured configuration data and generating a first component tree model includes: The structured configuration data is validated to obtain the target configuration data that passes the validation. The target configuration data is parsed into intermediate entity class objects; The hierarchical structure of the intermediate entity class objects is recursively traversed to create the corresponding nodes; All the created nodes are assembled into a tree structure starting from the root node to obtain the first component tree model.

[0008] In the dynamic interface rendering method provided in this application embodiment, parsing the target configuration data into an intermediate entity class object includes: Identify the encoding format of the target configuration data and determine the corresponding parser; The parser is invoked to deserialize the target configuration data to obtain the original entity object; The original entity object is mapped to fields and converted to types to generate an intermediate entity class object with a standardized component attribute structure.

[0009] In the dynamic interface rendering method provided in this application embodiment, the step of creating a native view instance and constructing a view tree based on the first component tree model, and mounting the view tree to the target container, includes: Traverse the first component tree model to obtain the current node and its component type and style attributes; Based on the component type, the corresponding Android native view class is searched from the preset component mapping table to obtain the target view class; Instantiate the target view class to obtain the original view instance, and assign attribute values ​​to the original view instance according to the style attribute to obtain the target view instance; According to the parent-child hierarchy of the first component tree model, the target view instance is mounted onto the corresponding parent view instance to form a view tree; The current hard-coded root layout container is used as the target container, and the root view instance of the view tree is added to the target container.

[0010] In the dynamic interface rendering method provided in this application embodiment, controlling the display, hiding, or delayed rendering of the corresponding component according to the current environmental context state includes: Traverse the first component tree model and read the rendering condition expression carried in the current node; The current environment context state is substituted into the rendering condition expression as a variable for evaluation to obtain the rendering control instruction of the current node. The rendering control instruction is one of the following: a display instruction, a hide instruction, or a deferred rendering instruction. According to the rendering control instructions, perform corresponding operations on the view instance corresponding to the current node.

[0011] In the dynamic interface rendering method provided in this application embodiment, the comparison result includes a list of newly added nodes, a list of deleted nodes, a list of moved nodes, and a list of nodes with changed attributes; the step of performing incremental rendering on the changed parts of the view tree based on the comparison result includes: Traverse the list of deleted nodes, remove the view instance corresponding to each deleted node from the view tree, and recycle the removed view instances to the component cache pool to obtain an updated view tree; Traverse the list of attribute change nodes, and for each attribute change node in the first-updated view tree, only update the changed style attribute or content of the view instance, without recreating the view instance, to obtain the second-updated view tree; Traverse the list of moving nodes, adjust the position index of the view instance corresponding to each moving node in the parent layout in the second updated view tree, and obtain the third updated view tree; The list of newly added nodes is traversed, a corresponding view instance is created for each newly added node, and the newly added node is mounted to the view tree after the three updates according to its hierarchical position in the component tree to complete incremental rendering.

[0012] The dynamic interface rendering method provided in this application embodiment further includes the following steps before performing incremental rendering: Determine if the view instance corresponding to the changed part exists in the component cache pool. If it exists, reuse the view instance in the component cache pool; otherwise, create a new view instance.

[0013] Secondly, embodiments of this application provide a dynamic interface rendering apparatus, including: The sending unit is used to send a configuration request to the server and receive structured configuration data returned by the server. The parsing unit is used to parse the structured configuration data and generate a first component tree model; A creation unit is used to create native view instances and construct a view tree based on the first component tree model, and to mount the view tree to the target container; The control unit is used to obtain the current environmental context state and control the display, hiding or delayed rendering of the corresponding components according to the current environmental context state; The comparison unit is used to generate a second component tree model when a configuration update or local data change is detected, compare the second component tree model with the first component tree model, and perform incremental rendering on the changed parts of the view tree according to the comparison result.

[0014] Thirdly, this application provides a storage medium storing a plurality of instructions that are adapted for loading by a processor to execute the dynamic interface rendering method described in any of the preceding claims.

[0015] Fourthly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the dynamic interface rendering method described in any of the above claims.

[0016] In summary, the dynamic interface rendering method provided in this application includes: sending a configuration request to a server and receiving structured configuration data returned by the server; parsing the structured configuration data to generate a first component tree model; creating a native view instance and constructing a view tree based on the first component tree model, and mounting the view tree to a target container; obtaining the current environment context state, and controlling the display, hiding, or delayed rendering of corresponding components based on the current environment context state; when a configuration update or local data change is detected, generating a second component tree model, comparing the second component tree model with the first component tree model, and performing incremental rendering on the changed parts of the view tree based on the comparison result. This application's embodiments enable remote distribution of interface definitions by sending configuration requests to the server and receiving structured configuration data. Server-side configuration updates change the interface, thus achieving dynamic scalability. By parsing the configuration into a first component tree model and directly creating native view instances to construct the view tree, intermediate conversion overhead is avoided. Simultaneously, when configuration or data changes, a second component tree model is generated and compared with the first, performing incremental rendering only on the changed parts of the view tree, reducing redundant redrawing and ensuring native rendering performance. The component tree model structurally describes the interface, and the display, hiding, or delayed rendering of components is controlled based on context state, reducing the need for manually writing conditional logic and improving development efficiency. Built on a native view system, it naturally adapts to various Android system versions, ensuring device compatibility. Therefore, this application overcomes the shortcomings of existing technologies that cannot simultaneously satisfy dynamic scalability, native performance, development efficiency, and device compatibility. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of the dynamic interface rendering method provided in the embodiments of this application.

[0019] Figure 2 This is a flowchart illustrating the dynamic interface rendering method provided in the embodiments of this application.

[0020] Figure 3 This is a schematic diagram of the structure of the dynamic interface rendering device provided in the embodiments of this application.

[0021] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] It should be noted that, in this document, 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 that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

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

[0025] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0026] In the description of this application, it should be noted that the terms "upper," "lower," "left," "right," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. In addition, terms such as "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0027] Currently, the mainstream dynamic interface implementation solutions mainly fall into three categories: First, traditional Android native development, which relies on XML static layout and Activity / Fragment hard coding, and interface updates must be released with the version release; second, WebView hybrid development solution, which achieves dynamics by loading remote H5 pages and uses JavaScript to bridge and interact with native functions; and third, cross-platform dynamic frameworks (such as Flutter), which package the rendering engine into the application and achieve cross-platform interface reuse through self-drawing.

[0028] However, while the current solutions have their own advantages in different scenarios, none of them can simultaneously achieve dynamic scalability, native performance, development efficiency, and device compatibility.

[0029] Based on this, embodiments of this application provide a dynamic interface rendering method, apparatus, storage medium, and electronic device. Specifically, the dynamic interface rendering apparatus can be integrated into a client, which is an electronic device, such as a server or a terminal. The terminal can include mobile phones, wearable smart devices, tablets, laptops, and personal computers (PCs) and other computers and auxiliary devices. The server can be a single server or a server cluster composed of multiple servers, and can be a physical server or a virtual server.

[0030] For example, such as Figure 1As shown, the electronic device can send a configuration request to the server and receive structured configuration data returned by the server; parse the structured configuration data to generate a first component tree model; based on the first component tree model, create a native view instance and build a view tree, and mount the view tree to the target container; obtain the current environment context state, and control the display, hiding, or delayed rendering of the corresponding components according to the current environment context state; when a configuration update or local data change is detected, generate a second component tree model, compare the second component tree model with the first component tree model, and perform incremental rendering on the changed parts of the view tree according to the comparison result.

[0031] The technical solutions shown in this application will be described in detail below through specific embodiments. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0032] Please see Figure 2 , Figure 2 This is a flowchart illustrating the dynamic interface rendering method provided in this application embodiment. The specific flow of the dynamic interface rendering method can be as follows: 101. Send a configuration request to the server and receive the structured configuration data returned by the server.

[0033] Specifically, in this embodiment, when a user opens an interface on a client (i.e., an electronic device) that requires dynamically displayed content, such as the "Double Eleven activity homepage" in an e-commerce application or the "personalized recommendation channel" in a news application, the client can first send a configuration request to the server. This configuration request typically carries an interface identifier (such as the page ID "page_home"), user information (such as user ID and membership level), and device parameters (such as screen resolution and system version). Based on this configuration request, the server can generate personalized structured configuration data. In some embodiments, this structured configuration data can be in JSON format, containing the types of various components in the interface (such as "text", "image", "button"), layout hierarchy, style attributes (such as font size, color, width, and height), rendering conditions (such as "user.isVip == true"), and event logic (such as redirecting to a specific product details page after clicking). After receiving this structured configuration data, the client can store it in a local cache for faster loading next time.

[0034] For example, suppose a video app launches a "Member Exclusive Benefits" event over the weekend. The operations team doesn't need to release a new version; they only need to modify the structured configuration data of the event page in the backend configuration center. This involves changing the style of the "Activate Membership" button for non-members to highlight in red and adding a "Claim Benefits" floating component for members. When a regular user opens the event page, the client sends a configuration request to the server. The server then sends the corresponding structured configuration data based on this request, and the client can display the event interface in real time. The entire process requires no application update from the user.

[0035] This application embodiment achieves remote distribution and dynamic updating of interface definitions by sending configuration requests to the server and receiving structured configuration data. This breaks the limitation of interface updates relying on client releases in the traditional development model, greatly shortens the business iteration cycle, and improves market response speed.

[0036] 102. Parse the structured configuration data and generate the first component tree model.

[0037] In this embodiment of the application, after the client receives the structured configuration data returned by the server, in order to enable the subsequent rendering engine to efficiently traverse and operate on the structured configuration data, it needs to convert it into a tree structure in memory, namely the first component tree model.

[0038] In some embodiments, step 102 may specifically include the following steps: 1021. Perform a validity check on the structured configuration data to obtain the target configuration data that has passed the check.

[0039] Understandably, the purpose of the client performing validity checks on the structured configuration data is to ensure the integrity and correctness of the structured configuration data, avoid application crashes or interface abnormalities due to configuration errors, and thus improve fault tolerance.

[0040] In this embodiment of the application, the validity check may include format check, required field check, and field value range check.

[0041] The format validation function checks whether the structured configuration data is in a valid JSON format and whether there are any syntax errors. For example, if a JSON parser attempts to read a string and throws an exception, it indicates that the format is invalid.

[0042] Required field validation checks whether the structured configuration data contains necessary fields, such as the "type" field for the root component and the unique identifier "id" for each component. For example, a button component must contain a "type" field with the value "button".

[0043] Field value range validation is used to check whether the field values ​​of structured configuration data are within the allowed range. For example, the value of the "width" field should be a positive integer or a predefined constant such as "match_parent"; the value of the "textSize" field should be a positive number and the unit should conform to the specification (such as "14sp").

[0044] In some embodiments, if the validation fails, the client can trigger an exception handling mechanism, such as displaying a pre-built default interface (e.g., "Page failed to load, please try again later"), or logging an error and reporting it to the server. If the validation passes, the target configuration data is obtained.

[0045] For example, in the configuration of an e-commerce application's activity page, the operations staff mistakenly wrote "buton" as the "type" field for a button (a spelling error). When the client received this structured configuration data, it found that the component type was not within the preset mapping table during validity validation, thus determining that the validation failed. The client displayed the default error message and reported the error log. Upon receiving the alert, the operations staff promptly corrected the structured configuration data, preventing a widespread white screen issue online.

[0046] 1022. Parse the target configuration data into intermediate entity class objects.

[0047] After successful verification, the client needs to convert the target configuration data (usually a JSON string or byte stream) into an intermediate entity class object that is easy to manipulate in a programming language. Since the server may use different data organization methods (data formats) and character encoding methods (encoding formats), this embodiment of the application can achieve compatibility and conversion through the following steps: First, the encoding format of the target configuration data can be identified to determine the corresponding parser.

[0048] Specifically, the client first identifies two pieces of information from the source of the target configuration data (e.g., the Content-Type field in the HTTP response header) or the characteristics of the target configuration data itself: data format and encoding format. Data format refers to the way structured data is organized, such as JSON, Protocol Buffers, and XML; encoding format refers to the byte representation of character data, such as UTF-8, UTF-16, and GBK. Then, based on the identified data format, the client determines the corresponding parser (e.g., using the Gson library for JSON parsing and the protobuf library for Protocol Buffers parsing); based on the identified encoding format, the client determines the byte-to-character decoding method (e.g., a UTF-8 decoder).

[0049] Next, the parser is invoked to deserialize the target configuration data to obtain the original entity object.

[0050] Specifically, the client can call the parser determined in the previous step and correctly decode the byte stream of the target configuration data into a string according to the identified encoding format (if the data format is text-based, such as JSON). Then, it performs a deserialization operation to obtain a raw entity object. This raw entity object can be a general Map structure or a JsonObject, containing all the key-value pairs in the configuration, but without yet undergoing type conversion and field mapping.

[0051] Finally, field mapping and type conversion are performed on the original entity object to generate an intermediate entity class object with a standardized component attribute structure.

[0052] It should be noted that the field names and data types in the original entity object may not be consistent with the component model defined internally by the client. For example, the value of the "textColor" field in the server configuration may be the string "#FF0000", while the client requires a color integer value (such as 0xFFFF0000); the value of the "layout_width" field may be "match_parent", which the client needs to recognize as the ViewGroup.LayoutParams.MATCH_PARENT constant.

[0053] Therefore, the client can convert the fields of the original entity object into the standard attribute structure expected by the client component model according to the preset mapping rules, and finally generate an intermediate entity class object. This intermediate entity class object has a tree-like hierarchical structure, containing a root entity object and its child entity objects. Each entity object stores information such as the standardized component type, style attributes, child component list, rendering condition expression, and event configuration.

[0054] For example, the HTTP response header returned by the server contains "application / json; charset=utf-8" in the Content-Type field. The client recognizes the data format as JSON and the encoding as UTF-8, thus determining to use the Gson parser and decode it using UTF-8. After deserialization, a raw JsonObject object is obtained, containing fields such as "type":"button" and "textColor":"#FF0000". The client, according to the mapping rules, converts the "textColor" field value "#FF0000" to the color integer value 0xFFFF0000 and stores it in the style attribute of the intermediate entity class object. Simultaneously, the server-side configuration's "visibleCondition" field value of "user.isLogin&&user.age>18" is preserved verbatim by the client as a string expression.

[0055] In this embodiment, by identifying data formats and encoding formats, the client can correctly parse diverse configuration data returned by different servers (such as JSON or Protocol Buffers, UTF-8 or GBK encoding), enhancing the versatility and robustness of the solution. Through field mapping and type conversion, the semi-structured target configuration data is converted into standardized intermediate entity class objects within the client, isolating the impact of server configuration format changes on the client's core logic and improving the maintainability and scalability of the system.

[0056] 1023. Recursively traverse the hierarchical structure of intermediate entity class objects to create the corresponding nodes.

[0057] Specifically, the process can start from the root entity object of the intermediate entity class and sequentially access each entity object and its child entity objects. For each entity object encountered, the client can create a corresponding node. Each node records at least the component type, style attributes, a list of child nodes, a rendering condition expression, and event configuration information.

[0058] 1024. Assemble all the created nodes into a tree structure starting from the root node to obtain the first component tree model.

[0059] It is understandable that the parent-child relationship between nodes is implicitly included in the node creation process. Therefore, starting from the root node, all nodes can be assembled into a complete tree structure according to the original hierarchical relationship of the intermediate entity class objects, which is the first component tree model.

[0060] For example, in a product details page, the root node of the first component tree model is a vertical linear layout, and its child nodes are, in order, the product image component, the product title component, the product price component, and the buy button component. Each node carries its own style attributes and event configurations, completely describing the structure of the entire interface.

[0061] This application embodiment can completely transform semi-structured target configuration data into a component tree model that can be directly manipulated by the client through recursive traversal and tree assembly, laying the data structure foundation for subsequent view construction, conditional rendering and incremental updates.

[0062] 103. Based on the first component tree model, create native view instances and construct the view tree, then mount the view tree to the target container.

[0063] Understandably, once the first component tree model is obtained, the rendering engine can begin converting the tree structure in memory into a user-visible native Android interface. The specific conversion process may include steps such as traversing the component tree to obtain node information, finding the native view class, creating and assigning view instances, constructing the parent-child hierarchical view tree, and mounting it to the root container. Step 103 may specifically include the following steps: 1031. Traverse the first component tree model to obtain the current node and its component type and style attributes.

[0064] In practice, the rendering engine can start from the root node of the first component tree model and traverse each node in a depth-first or breadth-first manner. For the current node, the rendering engine reads the component type (e.g., "text", "button", "image", "layout") and style attribute set (e.g., width, height, margin, background color, font size, text color, etc.) information stored in the current node.

[0065] For example, in the homepage configuration of an e-commerce application, the first component tree model contains a root layout node (of type "layout"), under which there is a product title node (of type "text"). When traversing to the product title node, the rendering engine obtains the component type as "text", and the style attributes include "textSize=18sp", "textColor=#333333", and "layout_marginLeft=16dp".

[0066] 1032. Based on the component type, find the corresponding Android native view class from the preset component mapping table to obtain the target view class.

[0067] In this embodiment of the application, a component type mapping table is pre-built inside the client. This component type mapping table has a correspondence between component types in string form (such as "text") and specific view classes in the Android SDK (such as "android.widget.TextView").

[0068] The rendering engine can look up the component type in the component type mapping table based on the component type obtained in step 1031. If the corresponding view class is found, it is used as the target view class; if it is not found (for example, an unregistered component type appears in the configuration), a fallback process can be triggered (for example, using a default TextView to display an error message or ignoring the component).

[0069] For example, in this component mapping table, "text" can be mapped to "TextView.class", "button" can be mapped to "Button.class", "image" can be mapped to "ImageView.class", and "layout" can be mapped to "LinearLayout.class". When processing the product title node, the component type is "text", and the rendering engine finds the target view class to be "TextView.class".

[0070] It is understandable that this embodiment achieves flexible binding between component types and native view classes through a component mapping table, allowing developers to easily extend new custom components (e.g., mapping "ratingbar" to "RatingBar.class"), thus enhancing the system's scalability.

[0071] 1033. Instantiate the target view class to obtain the original view instance, and assign property values ​​to the original view instance according to the style attributes to obtain the target view instance.

[0072] Specifically, the rendering engine can instantiate the target view class through reflection or by directly calling the constructor, creating a primitive view instance (e.g., calling "new TextView(context)"). Then, the rendering engine iterates through all the style properties of that node and applies each property to the primitive view instance.

[0073] For example: For the "textSize" property, call the "setTextSize()" method and convert the unit (sp to pixels).

[0074] For the "textColor" property, parse the color string (such as "#333333") and call "setTextColor()".

[0075] For the "layout_width" and "layout_height" attributes, generate the corresponding "LayoutParams" objects and set the width and height modes (such as "MATCH_PARENT" or specific pixel values).

[0076] For the "background" property, parse the color value or Drawable resource and call "setBackgroundColor()" or "setBackground()".

[0077] The "margin" and "padding" properties are set to either the layout parameters or the view itself, respectively.

[0078] After all style attributes are assigned values, you will get a fully configured target view instance.

[0079] In a practical application example, for the product title node, the rendering engine creates a "TextView" instance, then sets the text size to 18sp, the text color to #333333, and the left margin to 16dp based on style attributes. Simultaneously, it retrieves the title text content (e.g., "2024 New Sneakers") from the component map and calls "setText()" to set it. The resulting target view instance has the correct style and content.

[0080] It should be noted that this embodiment achieves a precise mapping from the visual styles described in the structured configuration data to the native view by applying style attributes one by one, ensuring the controllability and consistency of the interface effect. At the same time, directly using the native view's application programming interface for attribute settings avoids additional intermediate layer overhead and improves rendering performance.

[0081] 1034. According to the parent-child hierarchy of the first component tree model, the target view instance is mounted onto the corresponding parent view instance to form a view tree.

[0082] During the construction of the view tree, the rendering engine needs to maintain a stack or recursive calls to handle parent-child relationships. Specifically, when processing a container-type node (such as "layout"), the rendering engine first creates the parent view instance corresponding to the container (e.g., "LinearLayout"), and then recursively processes its child nodes. For each target view instance created by a child node, the "addView()" method of the parent view instance is called to add it as a child view. Simultaneously, layout parameters (LayoutParams) need to be set for the child views, which are typically generated from the layout rules of the parent container and the width and height style attributes of the child view itself. Following the hierarchical structure of the first component tree model, all views are mounted from top to bottom, ultimately forming a complete Android native view tree.

[0083] For example, in the first component tree model, the root node is a "LinearLayout" (vertical linear layout), whose child nodes include an "ImageView" (product image) and a "TextView" (product title). The rendering engine first creates an instance of the "LinearLayout," then creates an instance of the "ImageView" and adds it to the LinearLayout, and then creates an instance of the "TextView" and adds it to the LinearLayout. At this point, the view tree structure is: the LinearLayout (root) contains two child views: ImageView and TextView.

[0084] 1035. Use the currently hard-coded root layout container as the target container, and add the root view instance of the view tree to the target container.

[0085] Understandably, once the view tree is built, it needs to be displayed on the screen. The rendering engine obtains the root layout container of the current hard-coded (e.g., Activity or Fragment) and uses it as the target container. This target container is typically a "ViewGroup," such as the content layout (i.e., a "FrameLayout" type content area) obtained through "findViewById(android.R.id.content)." Then, the rendering engine adds the root view instance of the view tree (e.g., the "LinearLayout" instance mentioned above) to this target container. During addition, the layout parameters of the root view instance can be set (usually "MATCH_PARENT, MATCH_PARENT") to fill the entire screen. After addition, the system triggers the measurement, layout, and drawing process, and the interface is then displayed to the user.

[0086] For example, in a news details page, the root layout container of the Activity is a "FrameLayout" (identified as "content"). The rendering engine adds the constructed view tree root view (a vertical "LinearLayout" containing the news title, publication time, body image, and text, etc.) to this "FrameLayout" and sets the root view's width and height to "MATCH_PARENT". When the user opens the page, they immediately see the complete news content.

[0087] In this embodiment, by mounting the view tree to the standard root container of Activity or Fragment, seamless integration of the dynamically generated interface with the native Activity or Fragment lifecycle is achieved, eliminating the need for additional window management or view overlay issues and ensuring system stability and compatibility.

[0088] 104. Obtain the current environment context state, and control the display, hiding, or delayed rendering of the corresponding components based on the current environment context state.

[0089] Specifically, after the initial mounting of the view tree, or when the current environmental context, such as user status or network status, changes, the visibility or loading timing of certain components in the interface can be dynamically adjusted according to the current environment. In this embodiment, this function can be implemented through a conditional rendering module. Specifically, it can be as follows: First, traverse the first component tree model and read the rendering condition expression carried in the current node.

[0090] The conditional rendering module first obtains the first component tree model, then traverses each node starting from the root node. For the current node encountered, the conditional rendering module reads the pre-stored "rendering condition expression" within that node. This rendering condition expression is typically a string-based logical condition statement, such as "user.isVip == true", "network.type == 'wifi' && data.isLoaded == true", or "device.screenWidth > 600". If a node does not have a configured rendering condition expression (i.e., the field is empty or does not exist), that node is always displayed by default.

[0091] For example, on the homepage of a video application, the first component tree model contains a "VIP Exclusive Recommendation" node, whose rendering condition expression is "user.vipLevel>= 3". Another "Ad Slot" node has a rendering condition expression of "network.type == 'wifi'". When traversing these two nodes, the conditional rendering module reads the corresponding expression strings respectively.

[0092] Next, the current environment context state is substituted as a variable into the rendering condition expression for evaluation, thus obtaining the rendering control instructions for the current node.

[0093] The rendering control instruction is one of the following: a display instruction, a hide instruction, or a deferred rendering instruction.

[0094] Specifically, the conditional rendering module can first obtain the current environment context state from the client's local machine. This current environment context state can include user status (e.g., whether logged in, membership level, user ID), network status (e.g., Wi-Fi, 4G, 5G, no network), data status (e.g., whether data has been loaded, whether data is empty), permission status (e.g., whether location permission, camera permission), and device status (e.g., screen width, whether it is a tablet, system version). These current environment context states are usually managed uniformly by the client and updated in real time through listeners.

[0095] Next, the conditional rendering module can replace the variables in the rendering conditional expression with the state values ​​of the current environment context, and then evaluate the rendering conditional expression. The evaluation result is a Boolean value (true or false). Based on the evaluation result and the component's own configuration strategy, the conditional rendering module can generate corresponding rendering control instructions.

[0096] Specifically, if the evaluation result is true, a "display instruction" is generated, indicating that the node should be displayed normally. If the evaluation result is false, and the node has not yet been created or displayed, a "hide instruction" is generated, indicating that the node should be hidden (not occupying layout space). If the evaluation result is false, but the node is marked as "deferred rendering" (e.g., a complex component located off-screen), a "deferred rendering instruction" is generated, indicating that the node will not be created or displayed temporarily, and will be rendered when the subsequent triggering conditions are met.

[0097] For example, the current user is a regular member (vipLevel=1) and the network status is Wi-Fi. For the "VIP Exclusive Recommendations" component, the rendering conditional expression "user.vipLevel>= 3" evaluates to false, generating a hidden instruction. For the "Ad Slot" component, the rendering conditional expression "network.type == 'wifi'" evaluates to true, generating a display instruction. Additionally, there is a "You May Like" waterfall layout node at the bottom of the page. Due to its high rendering overhead and its current absence from the visible area, even if its conditional expression is true, a deferred rendering instruction is generated based on the deferred rendering strategy.

[0098] This application's embodiments achieve dynamic rendering control based on multi-dimensional conditions by substituting the state value of the current environment context into the rendering condition expression for evaluation. This allows the interface to automatically adjust according to real-time changes in factors such as user, network, and device, improving interface personalization and resource utilization efficiency. Simultaneously, the deferred rendering instruction provides a foundation for subsequent performance optimization.

[0099] Finally, based on the rendering control instructions, perform the corresponding operations on the view instance corresponding to the current node.

[0100] Specifically, based on the instruction type, the rendering engine performs the following operations on the view instance corresponding to the current node: Display instructions: If the view instance already exists, call the view instance's "setVisibility(View.VISIBLE)" method to make it visible; if the view instance has not yet been created (e.g., it was skipped during the first render), immediately create the view instance according to the process in step 103 and mount it to the view tree.

[0101] Hide instruction: If the view instance already exists, call the "setVisibility(View.GONE)" method to hide it and release the layout space it occupies; if the view instance has not yet been created, skip the creation process, as if the node never existed.

[0102] Deferred rendering directive: Adds the node to a deferred rendering queue, temporarily refraining from creating a view instance. Simultaneously, sets trigger conditions for this queue, such as listening for scroll events; when the component enters the visible area, it is removed from the queue and creation and display operations are performed; or listening for data loading completion events; when the dependent data is ready, it is re-evaluated and may be converted into a display directive.

[0103] For example, for the "VIP Exclusive Recommendations" node, because a hide instruction was generated, the rendering engine checked and found that the view instance corresponding to this node had not yet been created, so it skipped it directly, and the component area would not appear on the user interface. For the "Ad Slot" node, a show instruction was generated, the rendering engine created an ImageView instance and loaded the ad image, and the user saw the ad content. For the "You May Like" node at the bottom of the page, a deferred rendering instruction was generated, and the rendering engine did not create this complex view yet; when the user scrolled down the page and the component area was about to enter the screen, the scroll listener was triggered, the rendering engine immediately created and rendered the node, and the user saw the content loading without realizing it.

[0104] In this embodiment, by executing precise view operations according to instructions, nodes can be displayed, hidden, or deferred-loaded on demand, avoiding unnecessary view creation and rendering overhead, and reducing memory usage and CPU consumption. The deferred rendering mechanism is particularly beneficial for improving first-screen loading speed and scrolling smoothness, thus enhancing the user experience.

[0105] 105. When a configuration update or local data change is detected, a second component tree model is generated. The second component tree model is compared with the first component tree model, and incremental rendering is performed on the changed parts in the view tree based on the comparison results.

[0106] During application operation, the server may proactively push new structured configuration data (e.g., operations personnel modify the activity page layout in real time), or the client's local data may change (e.g., the style of the like button needs to be updated after a user likes an image, or a higher-resolution image needs to be loaded after switching from mobile data to Wi-Fi). In such cases, rebuilding the entire interface would waste resources and time. Therefore, this embodiment uses a Diff incremental update mechanism to minimize the rendering of only the changed parts.

[0107] Specifically, it can be shown as follows: First, generate the second component tree model.

[0108] Specifically, when a configuration update or local data change is detected, the client can re-execute the parsing process in step 102. Specifically, based on the new structured configuration data (incremental or full configuration issued by the server) or the changed local data, the client re-performs validity checks, parses the data into intermediate entity objects, recursively creates nodes, and assembles a tree structure to obtain the second component tree model. This second component tree model reflects the updated interface structure, style, conditions, and event configurations. Simultaneously, the client saves the "first component tree model" used in the previous rendering as a comparison benchmark.

[0109] For example, in a live streaming application, when a host starts a "gift draw," the server pushes an incremental configuration to all viewers' clients: adding a "Participate in the Giveaway" button next to the gift panel (new node), moving the existing "Share" button from the toolbar to the "More" menu (moved node), and changing the color of the "Online Users" text from gray to red (attribute change). After receiving this incremental configuration, the client merges it with the locally cached base configuration, then re-executes the parsing process to generate the second component tree model.

[0110] Next, the second component tree model is compared with the first component tree model to obtain the comparison results. These results include lists of newly added nodes, deleted nodes, moved nodes, and nodes with changed attributes.

[0111] Specifically, the client can invoke the Diff update engine to perform a depth-first traversal comparison of the second and first component tree models. The Diff update engine compares the unique identifier (e.g., component ID), component type, style attribute set, order and number of child components, rendering conditional expression content, and event configuration information of each node in the two component tree models. Based on the comparison results, four change types can be identified, and corresponding lists can be generated for each. New Node List: Records nodes that exist in the second component tree model but not in the first component tree model.

[0112] Deleted Node List: Records nodes that exist in the first component tree model but not in the second component tree model.

[0113] Mobile Node List: Records nodes with the same node ID but whose parent node or sibling position has changed.

[0114] Attribute Change Node List: Records nodes with the same node ID and unchanged position, but whose style attributes, content, rendering conditions, or event configurations have changed.

[0115] For example, after comparing the second component tree model and the first component tree model of a live streaming application, the Diff update engine generates the following list: the list of newly added nodes includes the "Participate in the lottery" button node; the list of deleted nodes is empty (no original components were deleted); the list of moved nodes includes the "Share" button node (moved from the toolbar to the more menu); and the list of nodes with changed attributes includes the "Online Users" text node (the color attribute changes from gray to red).

[0116] Then, incremental rendering can be performed on the parts of the view tree that have changed based on the comparison results.

[0117] In some embodiments, the rendering engine performs incremental rendering operations in a specific order (delete first, then update attributes, then move, and finally add) to ensure the consistency and correctness of the view tree.

[0118] First, iterate through the list of deleted nodes, remove the View instance corresponding to each deleted node from the view tree, and recycle the removed view instances to the component cache pool to obtain an updated view tree.

[0119] The rendering engine iterates through each node in the deletion list. For each node, the rendering engine finds the corresponding view instance in the current view tree and calls the parent ViewGroup's "removeView()" method to remove it from the view tree. The removed view instance is no longer displayed on the screen. For later reuse, the rendering engine does not immediately destroy the view instance but instead puts it into the component cache pool. The component cache pool stores idle view instances categorized by component type (such as "text", "button", "image"). After removal is complete, an "updated view tree" is obtained (at this point, unnecessary components have been removed), which is the updated view tree.

[0120] For example, suppose an expired "banner" ad component is deleted during a configuration update. The rendering engine finds the BannerView in the view tree, calls the parent layout's "removeView(bannerView)" to remove it, and then stores the BannerView object in the "image" type queue of the component cache pool for reuse when creating new image components later.

[0121] In this embodiment, by recycling deleted View instances to the component cache pool, the overhead of frequent view creation and destruction can be avoided, the frequency of memory allocation and garbage collection can be reduced, and the smoothness of interface updates can be improved.

[0122] Next, the list of attribute change nodes is traversed. For each attribute change node in the updated view tree, the view instance is updated only with its changed style attributes or content, without recreating the view instance, to obtain the updated view tree.

[0123] Specifically, the rendering engine can iterate through each node in the list of attribute change nodes. For each node, the rendering engine finds the corresponding view instance (which already exists because the node ID hasn't changed) in the current view tree (i.e., the view tree after one update). Then, the rendering engine only updates the changed parts: if the text content changes, it calls "setText()"; if the text color changes, it calls "setTextColor()"; if the width, height, or margins change, it updates LayoutParams; if the background changes, it calls "setBackground()". The entire process does not recreate the view instance or change its position in the view tree. After all attributes are updated, the second-updated view tree is obtained.

[0124] For example, for the "Online Users" text node, the color changes from gray to red. The rendering engine finds the corresponding TextView instance and directly calls "setTextColor(Color.RED)", leaving other properties unchanged. Users see the color of the online user number change instantly without needing to refresh the entire area.

[0125] This application embodiment avoids the layout calculation and drawing overhead caused by rebuilding view instances by only updating the changed attributes, and realizes fine-grained interface refresh, which is particularly suitable for high-frequency data change scenarios (such as real-time stock quotes, game scores).

[0126] Next, the list of moving nodes is traversed, and the position index of the view instance corresponding to each moving node in the parent layout is adjusted to obtain the view tree after the third update.

[0127] Specifically, the rendering engine can iterate through each node in the list of moved nodes. For each node, the rendering engine finds the corresponding View instance from the current view tree (the second-updated view tree), removes the view instance from its current parent ViewGroup (temporarily unloads it), and then re-inserts the view instance into the new parent ViewGroup or a new position within the same parent ViewGroup based on the node's new position index in the second component tree model. After the movement is complete, a third-updated view tree is obtained.

[0128] For example, the "Share" button node, which was originally in the third position of the toolbar layout, has now been moved to the first position of the More menu layout. The rendering engine first removes the share button view from the toolbar layout, then adds it to the More menu layout and sets it as the first child view. The user then sees the share button moved to its new position.

[0129] This application's embodiments achieve dynamic rearrangement of component order by adjusting position indexes rather than rebuilding the view, which is far more efficient than deleting and then adding again. It is suitable for scenarios such as list sorting and menu item adjustment.

[0130] Finally, the list of newly added nodes is traversed, a corresponding view instance is created for each newly added node, and the newly added node is mounted to the view tree after three updates according to its hierarchical position in the component tree, thus completing the incremental rendering.

[0131] Specifically, the rendering engine can iterate through each node in the list of newly added nodes. For each node, the rendering engine creates a corresponding view instance according to the component type and style attributes of that node, following the process in step 103. During creation, the rendering engine first checks the component cache pool to see if a reusable view instance of the same type exists (see the component cache pool reuse judgment in the next section for details). After creation, the rendering engine mounts the new view instance to the three-updated view tree obtained in the previous step according to the node's hierarchical position (parent node and index) in the second component tree model. After all newly added nodes have been processed, the final view tree is completely consistent with the second component tree model, and incremental rendering is complete.

[0132] For example, for the "Participate in the lottery" button node, the rendering engine checks the component cache pool for an idle "button" type view instance. If found, the instance is reused and its text, color, and other properties are updated; if not found, a new Button instance is created. Then, the button is added to the specified position in the gift panel layout (e.g., next to the "Send a Gift" button), and the user sees the new lottery button appear.

[0133] This application embodiment ensures the integrity of the interface structure by precisely mounting new nodes according to their hierarchical positions; in conjunction with component cache pool reuse, it further reduces creation overhead, making the overall performance of incremental rendering approach or even surpass that of traditional manual code updates.

[0134] In some embodiments, before performing incremental rendering, it can be determined whether the view instance corresponding to the changed part exists in the component cache pool. If it exists, the view instance in the component cache pool is reused; otherwise, a new view instance is created.

[0135] It's important to note that the rendering engine interacts with the component cache pool at various stages of incremental rendering (especially when handling newly added nodes and reuse after deleting nodes). The component cache pool is a view instance storage structure categorized by component type, such as "Map". <String, Queue <view>The key is the component type ("text", "button", "image", etc.), and the value is a queue (usually managed using an LRU strategy). Before performing incremental rendering, when a view instance needs to be created for a new node, the rendering engine first checks whether there is a free view instance in the component cache pool based on the component type of the node. If it exists, a view instance is retrieved from the component cache pool, and then the instance's style properties, content, event listeners, etc. are reset to meet the requirements of the newly added node, thereby avoiding calling "new" or using reflection to create a new instance.

[0136] If it does not exist, a new view instance will be created according to the normal process (reflection or factory pattern).

[0137] In addition, when iterating through the list of deleted nodes, the removed view instances are recycled into the component cache pool for later reuse. The component cache pool can be set to a maximum capacity (e.g., a maximum of 5 instances per type). When the capacity is exceeded, the least recently used instance is evicted and destroyed according to the LRU (Least Recently Used) strategy.

[0138] For example, in a news app, users repeatedly navigate between different channels. Each time a channel is switched, the component tree of the old channel is destroyed, and its view instances are recycled to the component cache pool. When the component tree of the new channel is generated, the rendering engine prioritizes retrieving view instances of the same type (such as a title TextView and an image ImageView) from the component cache pool, updating only the text and image URLs without recreating them. This significantly reduces object allocation and layout calculation time.

[0139] This embodiment significantly reduces memory allocation frequency and garbage collection pressure by reusing view instances through a component cache pool, making it particularly suitable for high-frequency scenarios such as list scrolling and page switching. Simultaneously, the LRU eviction policy of the component cache pool prevents unlimited memory growth, ensuring the long-term stability of the application.

[0140] In summary, the dynamic interface rendering method provided in this application includes: sending a configuration request to a server and receiving structured configuration data returned by the server; parsing the structured configuration data to generate a first component tree model; creating a native view instance and constructing a view tree based on the first component tree model, and mounting the view tree to a target container; obtaining the current environment context state, and controlling the display, hiding, or delayed rendering of the corresponding components based on the current environment context state; when a configuration update or local data change is detected, generating a second component tree model, comparing the second component tree model with the first component tree model, and performing incremental rendering on the changed parts of the view tree based on the comparison result. This application's embodiments decouple the interface definition from the client code by requesting and receiving structured configuration data from the server. Server-side configuration updates allow for real-time interface changes, thus achieving dynamic scalability. By parsing the configuration into a component tree model and directly creating Android native view instances for rendering, the additional overhead of WebView and Flutter compatibility issues are avoided. Furthermore, the Diff algorithm is used to incrementally render only the changed parts of the view tree, reducing redundant redraws and ensuring native rendering performance. The component tree model abstracts the UI structure, the conditional rendering module automatically handles display logic, and unified event and lifecycle management reduces repetitive coding and manual resource management, improving development efficiency. Based on the Android native view system and supplemented by a component caching pool, lazy loading, and degradation strategies, it naturally adapts to various system versions and low-to-mid-range devices, ensuring device compatibility. Therefore, this application's embodiments overcome the shortcomings of existing technologies that cannot simultaneously satisfy dynamic scalability, native performance, development efficiency, and device compatibility.

[0141] To facilitate better implementation of the dynamic interface rendering method provided in this application, this application also provides a dynamic interface rendering apparatus. The meanings of the terms used are the same as in the dynamic interface rendering method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0142] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of the dynamic interface rendering apparatus provided in an embodiment of this application. The dynamic interface rendering apparatus may include a sending unit 201, a parsing unit 202, a creation unit 203, a control unit 204, and a comparison unit 205. The sending unit 201 is used to send a configuration request to the server and receive structured configuration data returned by the server. Parsing unit 202 is used to parse structured configuration data and generate the first component tree model; Create unit 203, which is used to create native view instances and build view trees based on the first component tree model, and mount the view trees to the target container; The control unit 204 is used to obtain the current environmental context state and control the display, hiding or delayed rendering of the corresponding components according to the current environmental context state; The comparison unit 205 is used to generate a second component tree model when a configuration update or local data change is detected, compare the second component tree model with the first component tree model, and perform incremental rendering on the changed parts in the view tree based on the comparison result.

[0143] For specific implementation methods of each of the above units, please refer to the embodiments of the dynamic interface rendering method described above, which will not be repeated here.

[0144] In summary, the dynamic interface rendering apparatus provided in this application embodiment can send a configuration request to the server via the sending unit 201 and receive structured configuration data returned by the server; the parsing unit 202 parses the structured configuration data to generate a first component tree model; the creation unit 203 creates native view instances and constructs a view tree based on the first component tree model, and mounts the view tree to the target container; the control unit 204 obtains the current environment context state and controls the display, hiding, or delayed rendering of corresponding components based on the current environment context state; when the comparison unit 205 detects a configuration update or a change in local data, it generates a second component tree model, compares the second component tree model with the first component tree model, and performs incremental rendering on the changed parts of the view tree based on the comparison result. This application embodiment can overcome the shortcomings of existing technologies that cannot simultaneously satisfy dynamic expansion, native performance, development efficiency, and device compatibility.

[0145] This application also provides an electronic device that may integrate the dynamic interface rendering device of this application embodiment, such as... Figure 4 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores and a memory 302 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs stored in the memory 302 and / or the methods provided in this application, and by calling data stored in the memory 302, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 301 may include one or more processing cores; preferably, the processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operation of the storage medium, user interface, and application programs, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 301.

[0146] The memory 302 can be used to store software programs and the methods provided in this application. The processor 301 executes various functional applications and data processing by running the software programs stored in the memory 302 and the methods provided in this application. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store applications required for operating the storage medium and at least one function; the data storage area may store data created based on the use of the electronic device. In addition, the memory 302 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 302 may also include a memory controller to provide the processor 301 with access to the memory 302.

[0147] Although not shown, the electronic device may also include a display unit, an input unit, and a power supply, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 301 in the electronic device loads the executable files corresponding to the processes of one or more application programs into the memory 302 according to the following instructions, and the processor 301 runs the application programs stored in the memory 302 to realize various functions, as follows: Send a configuration request to the server and receive structured configuration data returned by the server; Parse the structured configuration data to generate the first component tree model; Based on the first component tree model, create native view instances and build a view tree, then mount the view tree to the target container; Get the current environment context state, and control the display, hiding, or delayed rendering of the corresponding components based on the current environment context state; When a configuration update or local data change is detected, a second component tree model is generated. The second component tree model is compared with the first component tree model, and incremental rendering is performed on the changed parts in the view tree based on the comparison results.

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

[0149] Therefore, embodiments of this application provide a storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the methods provided in embodiments of this application. For example, the instructions can execute the following steps: Send a configuration request to the server and receive structured configuration data returned by the server; Parse the structured configuration data to generate the first component tree model; Based on the first component tree model, create native view instances and build a view tree, then mount the view tree to the target container; Get the current environment context state, and control the display, hiding, or delayed rendering of the corresponding components based on the current environment context state; When a configuration update or local data change is detected, a second component tree model is generated. The second component tree model is compared with the first component tree model, and incremental rendering is performed on the changed parts in the view tree based on the comparison results.

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

[0151] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0152] Since the instructions stored in the storage medium can execute the steps of any method provided in the embodiments of this application, the beneficial effects that any method provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0153] The above provides a detailed description of the dynamic interface rendering method, apparatus, storage medium, and electronic device provided in 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 core ideas of this application. At the same time, those skilled in the art will recognize that 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.< / view>

Claims

1. A dynamic interface rendering method, characterized in that, include: Send a configuration request to the server and receive structured configuration data returned by the server; Parse the structured configuration data to generate a first component tree model; Based on the first component tree model, create native view instances and construct view trees, and mount the view trees to the target container; Obtain the current environment context state, and control the display, hiding, or delayed rendering of the corresponding components based on the current environment context state; When a configuration update or local data change is detected, a second component tree model is generated. The second component tree model is compared with the first component tree model, and incremental rendering is performed on the changed parts of the view tree based on the comparison results.

2. The dynamic interface rendering method as described in claim 1, characterized in that, The step of parsing the structured configuration data to generate the first component tree model includes: The structured configuration data is validated to obtain the target configuration data that passes the validation. The target configuration data is parsed into intermediate entity class objects; The hierarchical structure of the intermediate entity class objects is recursively traversed to create the corresponding nodes; All the created nodes are assembled into a tree structure starting from the root node to obtain the first component tree model.

3. The dynamic interface rendering method as described in claim 2, characterized in that, The step of parsing the target configuration data into an intermediate entity class object includes: Identify the encoding format of the target configuration data and determine the corresponding parser; The parser is invoked to deserialize the target configuration data to obtain the original entity object; The original entity object is mapped to fields and converted to types to generate an intermediate entity class object with a standardized component attribute structure.

4. The dynamic interface rendering method as described in claim 1, characterized in that, The step of creating a native view instance and constructing a view tree based on the first component tree model, and then mounting the view tree to the target container, includes: Traverse the first component tree model to obtain the current node and its component type and style attributes; Based on the component type, the corresponding Android native view class is searched from the preset component mapping table to obtain the target view class; Instantiate the target view class to obtain the original view instance, and assign attribute values ​​to the original view instance according to the style attribute to obtain the target view instance; According to the parent-child hierarchy of the first component tree model, the target view instance is mounted onto the corresponding parent view instance to form a view tree; The current hard-coded root layout container is used as the target container, and the root view instance of the view tree is added to the target container.

5. The dynamic interface rendering method as described in claim 4, characterized in that, The step of controlling the display, hiding, or delayed rendering of the corresponding component based on the current environmental context state includes: Traverse the first component tree model and read the rendering condition expression carried in the current node; The current environment context state is substituted into the rendering condition expression as a variable for evaluation to obtain the rendering control instruction of the current node. The rendering control instruction is one of the following: a display instruction, a hide instruction, or a deferred rendering instruction. According to the rendering control instructions, perform corresponding operations on the view instance corresponding to the current node.

6. The dynamic interface rendering method as described in claim 1, characterized in that, The comparison results include a list of newly added nodes, a list of deleted nodes, a list of moved nodes, and a list of nodes with changed attributes. The step of performing incremental rendering on the changed portions of the view tree based on the comparison results includes: Traverse the list of deleted nodes, remove the view instance corresponding to each deleted node from the view tree, and recycle the removed view instances to the component cache pool to obtain an updated view tree; Traverse the list of attribute change nodes, and for each attribute change node in the first-updated view tree, only update the changed style attribute or content of the view instance, without recreating the view instance, to obtain the second-updated view tree; Traverse the list of moving nodes, adjust the position index of the view instance corresponding to each moving node in the parent layout in the second updated view tree, and obtain the third updated view tree; The list of newly added nodes is traversed, a corresponding view instance is created for each newly added node, and the newly added node is mounted to the view tree after the three updates according to its hierarchical position in the component tree to complete incremental rendering.

7. The dynamic interface rendering method as described in claim 6, characterized in that, Before performing incremental rendering, the following is also included: Determine if the view instance corresponding to the changed part exists in the component cache pool. If it exists, reuse the view instance in the component cache pool; otherwise, create a new view instance.

8. A dynamic interface rendering device, characterized in that, include: The sending unit is used to send a configuration request to the server and receive structured configuration data returned by the server. The parsing unit is used to parse the structured configuration data and generate a first component tree model; A creation unit is used to create native view instances and construct a view tree based on the first component tree model, and to mount the view tree to the target container; The control unit is used to obtain the current environmental context state and control the display, hiding or delayed rendering of the corresponding components according to the current environmental context state; The comparison unit is used to generate a second component tree model when a configuration update or local data change is detected, compare the second component tree model with the first component tree model, and perform incremental rendering on the changed parts of the view tree according to the comparison result.

9. A storage medium, characterized in that, The storage medium stores multiple instructions, which are applicable to the processor for loading to execute the dynamic interface rendering method according to any one of claims 1-7.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the dynamic interface rendering method as described in any one of claims 1-7.

Images