View rendering method and apparatus, computer device, and computer-readable storage medium

Abstract

This application provides a view rendering method, apparatus, computer device, and computer-readable storage medium for achieving view flattening, thereby improving view rendering efficiency. It includes: obtaining an Extensible Markup Language (XML) file of a target interface; instantiating and parsing the XML file to obtain a view tree corresponding to the XML file; parsing the view tree to obtain a view node structure, wherein each view node in the view node structure is used to store attribute data of each view of the target interface; and rendering the target interface based on the view node structure.

Description

Technical Field

[0001] This application relates to the field of computer vision, specifically to a view rendering method, apparatus, computer device, and computer-readable storage medium. Background Technology

[0002] Android UI rendering technology has evolved from early software rendering that relied entirely on the Central Processing Unit (CPU) to the current mainstream rendering pipeline that utilizes the Graphics Processing Unit (GPU) for hardware acceleration, greatly improving graphics processing capabilities.

[0003] Existing technologies mainly follow the process of "Extensible Markup Language (XML) parsing → View Tree construction → Rendering initialization". The system constructs the ViewTree by parsing the XML file, and then executes three core steps in sequence on the main thread: measurement (onMeasure), layout (onLayout), and drawing (onDraw) to determine the size and position of each UI element and record the drawing instructions.

[0004] However, this technology has significant drawbacks: First, the different coding habits of developers can easily lead to excessively deep view tree levels, which greatly increases the time required for measurement and layout traversal, severely affecting the smoothness of the application and the user experience. Summary of the Invention

[0005] This application provides a view rendering method, apparatus, computer device, and computer-readable storage medium for implementing view flattening, thereby improving view rendering efficiency.

[0006] The technical solution adopted by this invention to solve the problem is as follows: Firstly, this application provides a view rendering method, including: Obtain the Extensible Markup Language (XML) file of the target interface; The XML file is instantiated and parsed to obtain the view tree corresponding to the XML file; The view tree is parsed to obtain the view node structure, where each view node in the view node structure is used to store the attribute data of each view of the target interface. The target interface is rendered based on this view node structure.

[0007] In some embodiments of this application, the view tree is parsed to obtain the view node structure, including: Multithreading is invoked to pre-render the view tree in order to obtain its basic properties; Based on this fundamental attribute, the view tree is recursively parsed to obtain the view node structure. The view node structure is a tree structure, and the view node types in the view node structure include basic nodes, text nodes, image nodes, container nodes, center view nodes, and extended nodes.

[0008] In some implementations of this application, multi-threading is invoked to pre-render the view tree to obtain its basic attributes, including: Call the size calculation function to get the width and height of each view in the view tree; Call the position allocation function to obtain the position data of each view in the view tree; Call the pixel drawing function to obtain the pixel data of each view in the view tree; Among them, the width, the height, the position data, and the pixel data are used as the basic attributes.

[0009] In some embodiments of this application, before invoking a multi-threaded pre-rendering of the view tree to obtain its basic properties, the method further includes: Each view in the view tree is cached in memory. Views in the view tree with a reuse rate higher than a first threshold are cached using a persistent caching mechanism, while views in the view tree with a reuse rate lower than or equal to the first threshold are cached using a least recently used caching mechanism.

[0010] In some embodiments of this application, rendering of the target interface based on this view node structure includes: The initial drawing bitmap is asynchronously constructed based on the main rendering thread of the target interface; Traverse the view node structure and draw each view node of the view node structure on the initial drawing bitmap to obtain the target bitmap; The target bitmap is passed to the main rendering thread to trigger a redraw of the target interface; In response to the redraw, the target bitmap is drawn in the drawing area of ​​the target interface to complete the rendering of the target interface, wherein the drawing area of ​​the target interface is constructed based on the main rendering thread.

[0011] In some embodiments of this application, rendering of the target interface based on this view node structure includes: Traverse the view node structure to create its corresponding rendering node structure; The rendering main thread of the target interface constructs the drawing area of ​​the target interface; Traverse the rendering node structure and draw each view node of the view node structure on the drawing area to complete the rendering of the target interface.

[0012] In some embodiments of this application, rendering of the target interface based on this view node structure includes: The rendering main thread of the target interface constructs the drawing area of ​​the target interface; Traverse the view node structure and draw each view node of the view node structure on the drawing area to complete the rendering of the target interface.

[0013] In some embodiments of this application, the XML file is instantiated and parsed to obtain the view tree corresponding to the XML file, including: An asynchronous parsing component is built based on the main rendering thread of the target interface; The asynchronous parsing component is used to instantiate and parse the XML file to obtain the view tree corresponding to the XML file.

[0014] Secondly, this application provides a view rendering apparatus, comprising: The acquisition module is used to acquire the Extensible Markup Language (XML) layout file of the target interface; The processing module is used to instantiate and parse the XML file to obtain the view tree corresponding to the XML file; parse the view tree to obtain the view node structure, wherein each view node in the view node structure is used to store the attribute data of each view of the target interface; and render the target interface based on the view node structure.

[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 view 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 view rendering method of any of the first aspects.

[0017] The beneficial effects of this invention are as follows: The XML file of the target interface is parsed to obtain the native view tree; then, by parsing the view tree, the basic attributes of each view element in the view tree are mapped to generate a view node structure; finally, the target interface is rendered based on this view node structure. In this way, during the rendering process, the view tree with a high rendering hierarchy is mapped to a flattened view node structure, which can improve rendering efficiency and thus enhance the smoothness of the application. 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 an application scenario of the view rendering method provided in an embodiment of the present invention; Figure 2 This is a schematic flowchart of an embodiment of the view rendering method provided by the present invention; Figure 3 This is a schematic diagram of the asynchronous architecture of the view rendering method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the drawing principle of view nodes provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the drawing process of a view node provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of a drawing interface for a view rendering method provided in an embodiment of the present invention; Figure 7 This is a flowchart illustrating a view rendering method provided in an embodiment of the present invention; Figure 8 This is another flowchart illustrating the view rendering method provided in this embodiment of the invention; Figure 9 This is a timing diagram of the view rendering method provided in an embodiment of the present invention; Figure 10 This is another timing diagram of the view rendering method provided in this embodiment of the invention; Figure 11 This is a schematic diagram of a specific embodiment of the view rendering device provided in this invention. Figure 12 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, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application 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] Android UI rendering technology has evolved from early software-based rendering that relied entirely on the Central Processing Unit (CPU) to the current mainstream hardware-accelerated rendering pipeline utilizing the Graphics Processing Unit (GPU), significantly improving graphics processing capabilities. Existing technologies primarily follow the process of "Extensible Markup Language (XML) parsing → View Tree construction → Rendering initialization." The system constructs the ViewTree by parsing XML files, and then sequentially executes three core steps on the main thread: measurement (onMeasure), layout (onLayout), and drawing (onDraw) to determine the size and position of each UI element and record drawing instructions. However, this technology has significant drawbacks: First, inconsistent coding habits among developers can easily lead to excessively deep view tree hierarchies, drastically increasing the time consumed by measurement and layout traversal, which severely impacts application smoothness and user experience.

[0025] To address this technical problem, this application provides the following technical solution: obtaining the Extensible Markup Language (XML) file of the target interface; instantiating and parsing the XML file to obtain the corresponding view tree; parsing the view tree to obtain a view node structure, wherein each view node in the view node structure stores the attribute data of each view of the target interface; and rendering the target interface based on the view node structure. This process parses the XML file of the target interface to obtain the native view tree; then, through parsing the view tree, the basic attributes of each view element in the view tree are mapped to generate a view node structure; finally, the target interface is rendered based on this view node structure. In this way, during the rendering process, the view tree with a high rendering hierarchy is mapped to a flattened view node structure, which improves rendering efficiency and thus enhances the smoothness of the application.

[0026] This application provides a view rendering method, apparatus, computer device, and computer-readable storage medium for implementing view flattening, thereby improving view rendering efficiency. The electronic device provided in this application can be implemented as various types of user terminals or as a server.

[0027] Electronic devices can implement view flattening by running the view rendering method provided in the embodiments of this application, thereby improving the efficiency of view rendering.

[0028] The above method can be applied to user interface rendering for many smart TVs, smart screens, display terminals and other terminal devices.

[0029] In one exemplary solution, this view rendering method can be applied to the user interface rendering of a smart TV. For example, when the smart TV starts up and displays its user interface, the rendering process can be as follows: Upon system startup, the rendering engine obtains the XML file of the smart TV's initial interface; then, it parses the XML file to obtain a view tree (ViewTree), and then recursively parses the view tree to construct its corresponding view node structure (ViewNode) in memory. Each node contains necessary rendering information such as text, color, and image links; finally, it performs flattening based on the view node structure to obtain the initial interface. During this process, when drawing the initial interface, the system only needs to traverse the ViewNodes and, based on the pre-calculated layout information of each node, efficiently draw the entire interface directly on the drawing area (such as a canvas).

[0030] It should be understood that the above is only an example of a scenario for view rendering, and there are many other possible scenarios, which are not limited here.

[0031] The view rendering method provided in this application embodiment is applied to, for example, Figure 1 The system architecture diagram shown is for your reference. Figure 1 To support a view 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 view rendering scheme 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, 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. Examples include handheld devices with wireless connectivity, vehicle-mounted devices, and machine-type communication (MTC) terminals. Currently, terminal devices 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, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, and wireless terminals in smart homes. For example, wireless terminals in self-driving can be drones, helicopters, or airplanes. For example, wireless terminals in vehicle-to-everything (V2X) can be in-vehicle equipment, vehicle-mounted equipment, in-vehicle modules, vehicles, or ships. Wireless terminals in industrial control can be cameras, robots, or robotic arms. Wireless terminals in smart homes can be televisions, air conditioners, robot vacuums, speakers, or set-top boxes.

[0034] It should be noted that the terminal device 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 limit the specific device.

[0035] The solution provided in this application can be completed by the cooperation of terminal device 100 and server 300.

[0036] In short, Database 400 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 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 view trees, view nodes, and view elements.

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

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

[0039] like Figure 2 The diagram shown is a flowchart of an embodiment of the view rendering method in this application. The view rendering method is described below, taking a terminal device as the execution subject. It may include the following steps 201-204, as detailed below: 201. Obtain the Extensible Markup Language (XML) file of the target interface.

[0040] When an application runs on a terminal device, the screen typically needs to display the application's user interface (UI). Before displaying the UI, the terminal device needs to render the UI based on its description. Therefore, the terminal device needs to obtain a precise, structured description of the UI layout on the current screen. This description usually exists in the form of an XML file. It is not the application's original layout XML, but a snapshot dynamically generated by the system at runtime based on the actual view tree of the current screen.

[0041] The user interface refers to the medium through which users interact and exchange information with machines (such as mobile applications, websites, and software). It includes all visual elements that users see and all interactive controls, such as visual elements like buttons, icons, text, images, colors, fonts, and layouts; as well as interactive controls like input boxes, drop-down menus, sliders, and switches.

[0042] During the user interface rendering process in the Android system, the content of this XML file originates from the view tree maintained in memory by the target application. This view tree is a real-time, dynamic tree-like data structure composed of view and view group objects.

[0043] When retrieving the XML file, the terminal device can perform a real-time depth-first traversal in response to a dump request, starting from the root view (DecorView) of the current window and recursively accessing every visible View object on the screen. During the traversal, for each View object, the terminal device extracts the key attributes of the View (identifier (ID), text, class name, coordinates, whether it is clickable, etc.) and encapsulates this information to generate a target object. Finally, the target objects are organized according to their parent-child relationships in the original view tree, and this node tree is then serialized to generate a standard XML file.

[0044] Based on the above description, the XML file is a static, structured text file that is easy for external programs to parse. It is used to describe a complex, object-oriented, real-time view tree in the application's memory.

[0045] 202. Instantiate and parse the XML file to obtain the view tree corresponding to the XML file.

[0046] After the terminal device obtains the XML file of the target interface, it instantiates and parses the XML file to construct the view tree corresponding to the XML file.

[0047] It should be understood that the view tree obtained by parsing the XML file is not the original view tree in the Android application's memory. It is a model tree defined by external tools to simulate the structure of the original view tree, which can be used to render the target interface corresponding to the original view tree.

[0048] In current rendering schemes, heavyweight tasks such as view tree construction, complex layout calculations, and even XML file parsing are tightly bound to the main rendering thread of the target interface. This makes the main rendering thread prone to stuttering due to computational intensity or I / O blocking, severely impacting application smoothness. Therefore, this embodiment also provides the following technical solution: An asynchronous parsing component is built based on the main rendering thread of the target interface; then, the XML file is instantiated and parsed based on the asynchronous parsing component to obtain the view tree corresponding to the XML file.

[0049] The asynchronous parsing component can be a custom layout loader (such as LayoutInflater). It should be understood that it should be distinguished from the native layout loader in the Android system. This custom layout loader is a thread that is asynchronous with the main rendering thread of the target interface.

[0050] In one exemplary solution, when the terminal device constructs the asynchronous parsing component, the drawing thread mechanism in this embodiment can be as follows: Figure 3 As shown: exist Figure 3 In the drawing thread mechanism shown, time-consuming logic such as size calculation (measure) and position allocation (layout) is executed asynchronously (i.e., through an asynchronous thread). Then, in response to a synchronization signal, the final drawing is performed through the main rendering thread. Compared to the native view drawing thread, this asynchronous execution of all time-consuming logic in the view drawing process does not occupy the main thread, thus reducing lag on the main thread and improving the smoothness of the application.

[0051] The following example illustrates the process of parsing an XML file to obtain a view tree: First, when a target interface of an application enters the initialization phase of its lifecycle, the terminal device receives an interface rendering instruction. Then, it obtains a resource identifier pointing to a layout description file (such as the XML file) from the interface setting instruction. Based on the resource identifier, it retrieves and locates the corresponding layout description file in memory.

[0052] The terminal device then calls a layout loader (such as LayoutInflater) to parse the layout description file. For example, LayoutInflater will read the XML tags in the XML file one by one (such as linear layout tags). <linearlayout>) and text view ( <textview>For each XML tag, the layout loader uses Java's reflection mechanism to construct the view object. For example, it finds the corresponding fully qualified class name (e.g., "android.widget.TextView") based on the tag name (e.g., "TextView"); then it calls the constructor of that class through reflection to create a corresponding View object instance in memory (new TextView(...)).

[0053] The layout loader then continues to parse the tag's attributes (such as android:layout_width="wrap_content") and calls the corresponding setting methods of the View object (such as setWidth(...)) to set these attributes.

[0054] When the layout loader encounters a ViewGroup tag (such as...) <linearlayout>When a child View object is created, the layout loader can create a LinearLayout object and then recursively parse the child elements within that ViewGroup. Each time a child View object is created, the layout loader calls the parent ViewGroup's addView() method to add the child View to the parent container.

[0055] This process is repeated until all XML tags have been parsed.

[0056] Finally, an object tree that corresponds perfectly to the XML file and exists in memory is constructed. The top-level node of this object tree will be added to the window of the target interface, ready to be displayed to the user.

[0057] 203. Parse the view tree to obtain the view node structure, wherein each view node in the view node structure is used to store the attribute data of each view of the target interface.

[0058] After parsing the XML file to obtain the corresponding view tree, the terminal device can parse the view tree again to reduce the rendering layers and obtain the view node structure corresponding to the view tree.

[0059] In one exemplary solution, when parsing the view tree, the terminal device needs to obtain the basic attributes of each view in the view tree; then, based on these basic attributes, it generates the view node structure corresponding to the view tree. The process can be as follows: The terminal device calls multiple threads to pre-render the view tree to obtain its basic attributes; based on these basic attributes, it recursively parses the view tree to obtain its view node structure, which is a tree structure. The view node types in this structure include basic nodes, text nodes, image nodes, container nodes, center view nodes, and extended nodes.

[0060] Optionally, this multithreading can be understood as follows: Call the size calculation function to get the width and height of each view in the view tree; Call the position allocation function to obtain the position data of each view in the view tree; Call the pixel drawing function to obtain the pixel data of each view in the view tree; Among them, the width, the height, the position data, and the pixel data are used as the basic attributes.

[0061] In this embodiment, each view node contains basic attributes of the view in the native view tree. For example, the base node contains basic attributes such as width and height. The text node contains attributes such as text and paint. The image node contains attributes such as image source (e.g., web image address (url) or local resource ID), scaling type, or placeholder and error image. The container node includes attributes such as a list of child nodes and layout definition attributes. The center view node contains attributes such as layout attributes (e.g., width and height), style attributes (e.g., background color, transparency), interaction attributes (e.g., click indicators), general identifiers (e.g., resource identifiers), and calculation results (e.g., the calculated rectangular area). The extension node is used for custom extensions.

[0062] In this embodiment, the pre-rendering of the view tree by the terminal device can be divided into two stages: The data binding phase is used to apply abstract user interface data to concrete view objects that exist in memory.

[0063] At this stage, the terminal device can create and configure a complete ViewTree. At this point, the View object can access its content (such as text content and background color), but it cannot obtain the View object's position on the target screen or the View object's size. Then, the terminal device calls a layout loader (such as LayoutInflater) to parse the View object's data source (such as a layout description file). For example, LayoutInflater will read the XML tags in the XML file one by one (such as linear layout tags...). <linearlayout>) and text view ( <textview>For each XML tag, the layout loader uses Java's reflection mechanism to construct the view object. For example, it finds the corresponding fully qualified class name (e.g., "android.widget.TextView") based on the tag name (e.g., "TextView"); then it calls the constructor of that class through reflection to create a corresponding View object instance in memory (new TextView(...)).

[0064] The layout loader then parses the tag's attributes (such as android:layout_width="wrap_content") and calls the corresponding setter methods of the View object (such as setWidth(...)) to set these attributes. This binds the data corresponding to the View object to the View object itself.

[0065] When the layout loader encounters a ViewGroup tag (such as...) <linearlayout>When a child View object is created, the layout loader can create a LinearLayout object and then recursively parse the child elements within that ViewGroup. Each time a child View object is created, the layout loader calls the parent ViewGroup's addView() method to add the child View to the parent container.

[0066] This process is repeated until all XML tags have been parsed, thus completing the entire process of applying abstract user interface data to concrete, in-memory view objects.

[0067] Rendering initialization phase: The terminal device's system takes over to complete the data binding of the View objects, and calculates the size and position of each View object through the process of size calculation (onMeasure), position allocation (onLayout), and pixel drawing (onDraw).

[0068] The system initiates a depth-first traversal starting from the root node of the ViewTree, calling the `measure()` method of each View. This `measure()` method calls back `onMeasure`, triggering the size calculation (`onMeasure`) for each View object. Based on this size calculation (`onMeasure`), the width and height of each View object are determined. For example, the parent ViewGroup generates a measurement specification based on its available space and the LayoutParams (match_parent, wrap_content, 80dp, etc.) set during the data binding phase for its child Views. This measurement specification is passed to the `onMeasure` method of the child Views. The child Views determine their desired size based on this measurement specification and the content bound during the data binding phase (e.g., a TextView calculates the required size based on its text content and textSize). Finally, each View calls `setMeasuredDimension()` to save its measurement results. At this point, the size calculation (`onMeasure`) completes the initialization of the width and height of each View object.

[0069] After the size calculation process is complete, the terminal device's system traverses the view tree again starting from the root node, calling the position allocation (onLayout) method of each ViewGroup. This method calls back onLayout to determine the specific position of each child View within its parent container (i.e., the four coordinates of left, top, right, and bottom). For example, onLayout() is only meaningful within ViewGroup. The parent ViewGroup obtains the dimensions of all child Views calculated during the onMeasure phase. Then, based on its own layout logic (e.g., the orientation of LinearLayout) and the dimensions of the child Views, the parent ViewGroup calls the child.layout(left, top, right, bottom) method of each child View to allocate a rectangular area for them. After onLayout, the initialization of the position data (mLeft, mTop, mRight, mBottom) of each View is complete.

[0070] After the onLayout process is complete, the view tree is ready to be drawn. The terminal device's system initiates a drawing traversal, calling the draw() method of each View that needs to be drawn. This method calls back onDraw(), which is used to actually draw the View's content onto the canvas corresponding to the terminal device's screen. For example, the system provides a Canvas object whose coordinate system has been translated to the top-left corner of the View. In the onDraw() method, the View uses the data bound during the data binding phase (such as textColor, backgroundColor, Bitmap, etc.) and a Paint object to draw on the Canvas. For example, TextView will call canvas.drawText(...), and ImageView will call canvas.drawBitmap(...). During this process, onDraw uses the data initialized in all previous phases to generate the pixel data for each View object.

[0071] In this embodiment, in order to reduce computation and time consumption (time consumption refers to re-performing IO read and write operations), after the view tree is constructed, the terminal device can also cache each view of the view tree in memory. Among them, the views in the view tree with a reuse rate higher than the first threshold are cached according to the persistent caching mechanism, and the views in the view tree with a reuse rate lower than or equal to the first threshold are cached according to the least recently used caching mechanism.

[0072] Optionally, the terminal device can invoke a custom cache manager (such as FlattenInflater) to cache the individual views.

[0073] The Least Recently Used Cache (LruCache) is a fixed-size memory cache. When the cache is full, it automatically removes "least recently used" objects when storing new objects. It is used to cache UI layouts that may not be the most frequently used, but may be reused in the near future. In this embodiment, the terminal device can use the following working mechanism when adopting the Least Recently Used Cache mechanism: Cache Key: Usually the resource ID of the layout file, such as R.layout.user_profile_header. Cache Value: The root View object (i.e., the top-level node of the ViewTree) obtained after complete parsing and instantiation by FlattenInflater. Cache Size: A reasonable cache size is preset, such as caching 10 or 20 different layouts to prevent unlimited memory consumption. For example, if a user opens "Product Details Page A" (R.layout.item_detail), the ViewTree of this page is created and put into LruCache. Then the user returns and opens "Product Details Page B" (also using R.layout.item_detail). On the second opening, FlattenInflater will directly hit and return the cached ViewTree from LruCache. If the user then visits 20 other different pages, causing LruCache to fill up, the cache for "Product Details Page A" may be evicted.

[0074] Persistent caching refers to a strong reference cache that resides in memory throughout the entire lifecycle of an application and never expires. It is used to cache core user interface styles that are highly reusable and crucial to application smoothness. In this embodiment, the terminal device can employ the following mechanism when using persistent caching: Cache Key: Typically the resource ID of the layout file, such as R.layout.chat_list_item. Cache Value: The corresponding root View object. Population Timing: This can be done when the application starts, by pre-specifying a list containing the corresponding view objects, and pre-loading and pre-caching the view objects in this list.

[0075] 204. Render the target interface based on the view node structure.

[0076] After obtaining the view node structure, the terminal device calls the `invalidate` method of the container View. Within the `onDraw` method of the container ViewGroup, the ViewNodes are dispatched to the corresponding Node objects' `draw` methods. Through different Nodes, bitmaps, text, etc., are drawn on the container's Canvas using different drawing methods. The execution flow can be as follows: Figure 4 As shown, the `onDraw` method of the `ViewGroup` container dispatches the `ViewNode`s to each `Node` element for drawing. During this process, the `ViewNode` consumes little memory, avoids the intermediate time-consuming processes found in view objects, and is a structured object containing basic properties.

[0077] Based on the above description, the following will be used as... Figure 5 The diagram shown illustrates the node drawing process in this embodiment.

[0078] like Figure 5 As shown, after the root node triggers drawing, it iterates through the view nodes; it checks if a node is a container node; if it is a container node, it iterates through the child nodes of that container node and draws each child node on the canvas; if it is not a container node, it checks the node type and then dispatches the corresponding Node object's draw method according to the node type, so that different nodes draw themselves on the canvas in different ways. Figure 5 As shown, for text nodes, text is drawn in a canvas; for image nodes, images are drawn in a canvas; and for center view nodes, a canvas is provided for custom drawing.

[0079] Based on the above drawing scheme, the view hierarchy of the target interface can be as follows: Figure 6 As shown, in the native view rendering, there are 6 views (one dashed box corresponds to one view), and the layer arrangement can be four levels (for example, image 1, image 2, and image 3 each correspond to one rendering level, and the other text parts are divided into another rendering level). However, in the view rendering scheme provided in this embodiment, the number of views is 1 (all text and images are asynchronously merged into a bitmap, and only one bitmap needs to be drawn in the main rendering thread), and the layer arrangement is one level. Figure 6 As can be seen, the solution provided in this embodiment can significantly reduce the number of views and the hierarchical arrangement during drawing compared to the original view.

[0080] In practical applications, the terminal device can render the target interface based on the view node structure according to the actual application scenario.

[0081] In one exemplary solution, for non-4K devices in ordinary scenarios, the image dimensions are not very large when loading, so the rendering pressure on the entire GPU is not high. Therefore, all nodes are drawn on the canvas of the same view, and the process can be as follows: In one possible implementation, the terminal device could employ a recursive ViewTree, using RenderNode to draw onto the Canvas. That is, the terminal device traverses the view node structure to create its corresponding rendering node structure; the main rendering thread of the target interface constructs the drawing area of ​​the target interface; and iterates through the rendering node structure, drawing each view node of the view node structure on the drawing area to complete the rendering of the target interface.

[0082] In this scheme, a RenderNode is a node in a parallel tree that corresponds one-to-one with a View. Each View internally holds a RenderNode. The role of the RenderNode is to record the drawing operations that a View needs to perform (such as drawRect, drawText), as well as the View's attributes (such as alpha, translationX, rotation). It transforms the View's drawing content from a "pixelated" description to a "vectorized" and "attribute-based" description. Its drawing process can be as follows: When the terminal device's system receives the synchronization signal and begins rendering a new frame, it checks each child view in the ViewTree and records the drawing content of each child view in its respective RenderNode. During this process, the terminal device's system performs a "fake drawing" of the ViewTree; that is, it doesn't draw any pixels, but successfully updates the entire RenderNode tree, with each RenderNode containing the latest list of drawing instructions. The terminal device's system then passes the updated RenderNode tree to the main rendering thread. The main rendering thread receives the RenderNode tree and traverses it. For each RenderNode, the main rendering thread re-executes the instructions in its drawing instruction list. The main rendering thread translates the instructions in the drawing instruction list into low-level instruction calls and applies the attributes stored on the RenderNode. The main rendering thread then passes the instructions to the GPU, enabling the GPU to execute these instructions in parallel and at extremely high speed, completing all graphics calculations, compositing, and shading, ultimately rendering the complete image to the back buffer. When the GPU completes rendering a frame, the system swaps the back buffer with the foreground buffer (the image currently displayed on the screen), so that the user finally sees a new frame on the screen. In this process, if only some view objects in the view tree are modified, this solution can draw only the modified parts without redrawing all view objects in the view tree. This reduces the amount of drawing work, improves drawing efficiency, and thus enhances the smoothness of the application.

[0083] In another possible implementation, the terminal device can use a recursive ViewTree to directly draw using the Canvas application programming interface. That is, the terminal device constructs the drawing area of ​​the target interface based on the main rendering thread of the target interface; it traverses the view node structure and draws each view node of the view node structure on the drawing area to complete the rendering of the target interface.

[0084] In this solution, the drawing process can execute the traditional view drawing process, and the process can be as follows: When the system of the terminal device receives a synchronization signal and starts rendering a new frame, the system of the terminal device prepares a bitmap (Bitmap) in memory for the window or View layer to be drawn. This Bitmap is the canvas carrier. The system creates a Canvas object and associates this Canvas object with the Bitmap. In this way, all operations on this Canvas will be directly reflected on this Bitmap. The system of the terminal device starts from the root node of the ViewTree and calls its draw(Canvas canvas) method, and the passed-in Canvas is the one associated with the Bitmap prepared above. The following takes a TextView as an example to illustrate the drawing process: Call drawBackground() to check this TextView to determine whether this TextView has a background. If so, call backgroundDrawable.draw(canvas). The CPU will immediately draw the pixels of the background onto the Bitmap. Next, the onDraw method of the TextView is called, and the text color, size, font, etc. are set using a Paint object. Then call canvas.drawText(...). At this time, the CPU starts to draw. For example, the CPU will perform font rasterization, calculate the color of each pixel of the words "Hello", and then write these pixel data one by one to the specified position of the Bitmap. Finally, call drawForeground() to draw the foreground (such as a scroll bar). When the drawing process reaches a ViewGroup (such as a LinearLayout), its corresponding draw() method will first complete the background drawing of the ViewGroup. Then, call dispatchDraw(Canvas canvas) to be responsible for drawing all child Views of the ViewGroup. Inside dispatchDraw, the ViewGroup will perform a loop: a. Obtain the child view: Get the first child view.

[0085] b. Coordinate transformation: Before calling the draw method of the child view, the ViewGroup will perform a transformation on the Canvas. It translates the origin (0, 0) of the canvas to the upper left corner of the current child view. In this way, when the child view is drawn, it can consider its upper left corner as (0, 0), greatly simplifying the drawing logic of the child view. Usually, this operation will be wrapped between canvas.save() and canvas.restore() to ensure that the transformation of one child view will not affect the next sibling view.

[0086] c. Recursive call: Call child.draw(canvas) to pass the already "translated" Canvas down. The drawing process then enters this child View.

[0087] d. Continue the loop until all child views have been drawn.

[0088] Once the root node's `draw()` method finishes executing, the Bitmap associated with the Canvas contains the complete visual content of the entire ViewTree. Finally, the terminal device's system passes the content of this final Bitmap to the screen's framebuffer, allowing the user to see that frame of the image.

[0089] For 4K UI devices, the image size is double that of a normal non-4K image. For example, a non-4K image might be 200*200 pixels wide and long, while a 4K image is 400*400 pixels. On devices with such doubled overall UI size, the rendering load on the GPU is also doubled. For these 4K UI devices, the terminal device can employ a scheme where the CPU asynchronously synthesizes bitmaps and then passes them to the GPU for bitmap rendering. Specifically, the terminal device asynchronously constructs an initial rendering bitmap based on the main rendering thread of the target interface; it traverses the view node structure, drawing each view node on the initial rendering bitmap to obtain the target bitmap; it passes the target bitmap to the main rendering thread to trigger a redraw of the target interface; in response to the redraw, the target bitmap is drawn in the drawing area of ​​the target interface to complete the rendering of the target interface. The drawing area of ​​the target interface is constructed based on the main rendering thread.

[0090] The following is based on Figure 7 The drawing process shown illustrates the above scheme: The code retrieves the width and height of each View from the XML file; calls View.measure() to measure the View; calls View.layout() to lay out the View; recursively triggers textView.draw() to initialize the paint; recursively generates its own nodeTree for each View; asynchronously creates a bitmap; iterates through the nodeTree and draws each node onto the bitmap; after drawing, passes the bitmap to the main rendering thread; triggers view.invalidate() to refresh; and finally, draws the bitmap onto the View.

[0091] Based on the above description, it can be seen that the view rendering scheme provided in this embodiment can perform the following: Figure 8 The process shown: 1. Obtain the XML file.

[0092] 2. Construct a custom asynchronous parsing component (e.g., LayoutInflater) to convert the XML file into an in-memory data structure, namely the native view tree (ViewTree).

[0093] 3. Use a custom cache manager (e.g., a FlattenInflater singleton object) to cache the native view tree in memory. Caching strategies include persistent caching and LruCache.

[0094] 4. When you need to add a View to the window (such as setContentView or addView), construct a new container object using newViewGroup() to provide the Canvas.

[0095] 5. Employ a multi-threaded approach to pre-render the View cache. Pre-rendering refers to binding data (such as setText, setBackground, etc.) to the corresponding UI elements displayed on the View (e.g., JsonObject format), and initializing the width, height, position, and other data of each View element on the UI through the View's onMeasure, onLayout, and onDraw methods.

[0096] 6. After pre-rendering is complete, the ViewTree object with initialized data is recursively parsed to generate new ViewNode objects. The ViewNode object adopts a tree structure, consisting of baseNode, textNode, imageNode, GroupNode, viewNode, and extensionNode. The extensionNode is used for custom extensions. Each Node contains basic properties of the native View. For example, baseNode is the base class and contains basic properties such as width and height, while textNode contains properties such as text and paint.

[0097] 7. Call the invalidate refresh method of the container View, and dispatch the ViewNode in the onDraw method of the container ViewGroup. Dispatch the ViewNode to the draw method of the corresponding Node object. Through different Nodes, draw bitmap, text, etc. on the container's Canvas according to different drawing methods.

[0098] In this application, the asynchronous processing flow can also be built into a software toolkit (SDK), and this SDK can be combined with the native rendering main thread to implement the view rendering scheme of this application. The following is an example... Figure 9 The sequence diagram shown illustrates the view rendering scheme that combines the software toolkit (SDK) with the main rendering thread: like Figure 9 As shown, the target interface's rendering lifecycle manager (Activity) serves as the entry point, which can invoke the layout transformation functionality provided by asynchronous processing packages (such as the Flatten SDK). The SDK uses native instantiation parsing methods (such as `inflate(layoutId)`) to asynchronously convert the specified XML layout resource into the corresponding View object. This asynchronous operation is achieved through view callbacks (such as `callback`). <view>The method callback returns the generated View, ensuring that the main thread is not blocked, while also supporting View caching and reuse mechanisms to improve rendering efficiency.

[0099] After successfully obtaining the View object, the system enters the data preparation phase, preparing the data that needs to be dynamically bound. It's worth noting that the container's width and height are known during this process to ensure layout stability and subsequent rendering accuracy. Next, using data binding methods (such as `bindData(FlattenParams)`), the prepared data is dynamically bound to the View, updating its displayed content.

[0100] After data binding is complete, the system triggers the canvas draw process to draw the updated view elements on the canvas. Finally, a redraw is requested by calling the invalidate method, ensuring that the changed content is displayed on the screen in a timely manner.

[0101] The view rendering scheme of this application is illustrated below with a complete sequence diagram, such as... Figure 10 As shown: An asynchronous parsing component (such as LayoutInflater) is built based on the main rendering thread to parse the XML file and obtain the View. The sequence of events can be as follows: the width and height of the View are set based on the XML file; measure(widthSpec, heightSpec) is called, then the View calls onMeasure() to complete the measurement and returns the corresponding value; finally, onLayout() is called to complete the layout. After the layout is complete, the `draw(canvas)` method of each View that needs to be drawn is called. This method calls back `onDraw()` to initialize the View's content based on the TextView. After the paint initialization is complete, a nodeTree is recursively generated. In this nodeTree builder, the basic properties of the view are traversed to create node nodes. After the nodeTree is generated, an asynchronous rendering thread is triggered to start asynchronous rendering. This asynchronous rendering thread creates a bitmap. After the bitmap is created, a canvas is created. Then, the nodeTree is traversed, and each node is drawn to the bitmap, i.e., written to pixels. After the bitmap is drawn, it is passed to the native rendering thread, triggering the view to be redrawn (invalidated). During the redraw, the `onDraw()` function is called to complete the bitmap drawing. After the bitmap is drawn, the target interface is refreshed and displayed.

[0102] To better implement the view rendering method in the embodiments of this application, a view rendering apparatus is also provided in the embodiments of this application, such as... Figure 11 As shown, the view rendering device 1100 includes: Module 1101 is used to obtain the Extensible Markup Language (XML) layout file of the target interface; The processing module 1102 is used to instantiate and parse the XML file to obtain the view tree corresponding to the XML file; parse the view tree to obtain the view node structure, wherein each view node in the view node structure is used to store the attribute data of each view of the target interface; and render the target interface based on the view node structure.

[0103] In this embodiment, the XML file of the target interface is parsed to obtain the native view tree; then, by parsing the view tree, the basic attributes of each view element in the view tree are mapped to generate a view node structure; finally, the target interface is rendered based on this view node structure. In this way, during the rendering process, the view tree with a high rendering level is mapped to a flattened view node structure, which can improve rendering efficiency and thus improve the smoothness of the application.

[0104] In some embodiments of this application, the processing module 1102 is specifically used for: Multithreading is invoked to pre-render the view tree in order to obtain its basic properties; Based on this fundamental attribute, the view tree is recursively parsed to obtain the view node structure. The view node structure is a tree structure, and the view node types in the view node structure include basic nodes, text nodes, image nodes, container nodes, center view nodes, and extended nodes.

[0105] In this embodiment, the native view tree is pre-rendered to initialize the basic attributes of each view, and view nodes are constructed based on the initialized basic attributes. This allows the view node structure to store only lightweight data, thereby reducing memory usage. When drawing the view based on the view node structure, flat drawing can be achieved, avoiding frequent reflow and redrawing of the view tree, thereby reducing rendering layers, improving drawing efficiency, and thus improving the smoothness of the application.

[0106] In some embodiments of this application, the processing module 1102 is specifically used for: Call the size calculation function to get the width and height of each view in the view tree; Call the position allocation function to obtain the position data of each view in the view tree; Call the pixel drawing function to obtain the pixel data of each view in the view tree; Among them, the width, the height, the position data, and the pixel data are used as the basic attributes.

[0107] In this embodiment, the corresponding functions are called to initialize each basic attribute, thereby obtaining the specific attributes of each view in the view tree, ensuring the accuracy of the view node data, and making the subsequent flattening drawing correct.

[0108] In some embodiments of this application, the processing module 1102 is further configured to cache each view of the view tree in memory, wherein views in the view tree with a reuse rate higher than a first threshold are cached according to a persistent caching mechanism, and views in the view tree with a reuse rate lower than or equal to the first threshold are cached according to a least recently used caching mechanism.

[0109] In this embodiment, highly reusable views are persistently cached, while less reusable views are cached using a least recently used caching mechanism. This reduces redundant calculations and time-consuming processing of highly reusable views and balances memory usage.

[0110] In some embodiments of this application, the processing module 1102 is specifically used for: The initial drawing bitmap is asynchronously constructed based on the main rendering thread of the target interface; Traverse the view node structure and draw each view node of the view node structure on the initial drawing bitmap to obtain the target bitmap; The target bitmap is passed to the main rendering thread to trigger a redraw of the target interface; In response to the redraw, the target bitmap is drawn in the drawing area of ​​the target interface to complete the rendering of the target interface, wherein the drawing area of ​​the target interface is constructed based on the main rendering thread.

[0111] In this embodiment of the application, an asynchronous rendering scheme is provided, that is, bitmap rendering is implemented through an asynchronous rendering thread, and then only the bitmap is rendered in the main rendering thread. This reduces the number of drawing elements in the main rendering thread, thereby reducing the computation. Multiple elements are converted into a bitmap, which reduces the number of GPU drawing calls and reduces the drawing pressure on the GPU.

[0112] In some embodiments of this application, the processing module 1102 is specifically used for: Traverse the view node structure to create its corresponding rendering node structure; The rendering main thread of the target interface constructs the drawing area of ​​the target interface; Traverse the rendering node structure and draw each view node of the view node structure on the drawing area to complete the rendering of the target interface.

[0113] In this embodiment of the application, a rendering node of the view node structure is provided, and view rendering is performed based on the rendering node. This allows only the views that have changed to be rendered during the rendering process, avoiding the overall redrawing of the view node, thereby reducing the amount of drawing calculations and improving drawing efficiency and application smoothness.

[0114] In some embodiments of this application, the processing module 1102 is specifically used for: The rendering main thread of the target interface constructs the drawing area of ​​the target interface; Traverse the view node structure and draw each view node of the view node structure on the drawing area to complete the rendering of the target interface.

[0115] In this embodiment, a native rendering scheme is adopted based on the view node, which enables the view rendering scheme to be applied to a variety of devices and improves the applicability of the scheme.

[0116] In some embodiments of this application, the processing module 1102 is specifically used for: An asynchronous parsing component is built based on the main rendering thread of the target interface; The asynchronous parsing component is used to instantiate and parse the XML file to obtain the view tree corresponding to the XML file.

[0117] In this embodiment, an asynchronous parsing component is constructed to parse the XML file, thereby enabling the subsequent asynchronous construction of the view node structure. This separates time-consuming logic from the main rendering thread, preventing it from occupying the main rendering thread and improving smoothness.

[0118] This application also provides a computer device that integrates any of the view rendering 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 view rendering method in any of the above-described view rendering method embodiments.

[0119] This application also provides a computer device that integrates any of the view rendering setups provided in this application. For example... Figure 12 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 1201 with one or more processing cores, a memory 1202 with one or more computer-readable storage media, a power supply 1203, and an input unit 1204. Those skilled in the art will understand that... Figure 12 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 1201 is the control center of the computer device. It connects various parts of the computer device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1202, and by calling data stored in the memory 1202, thereby providing overall monitoring of the computer device. Optionally, the processor 1201 may include one or more processing cores; preferably, the processor 1201 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 1201.

[0120] The memory 1202 can be used to store software programs and modules. The processor 1201 executes various functional applications and data processing by running the software programs and modules stored in the memory 1202. The memory 1202 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 1202 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 1202 may also include a memory controller to provide the processor 1201 with access to the memory 1202.

[0121] The computer device also includes a power supply 1203 that supplies power to various components. Preferably, the power supply 1203 can be logically connected to the processor 1201 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 1203 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.

[0122] The computer device may also include an input unit 1204, 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.

[0123] 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 1201 in the computer device loads the executable files corresponding to the processes of one or more application programs into the memory 1202 according to the following instructions, and the processor 1201 runs the application programs stored in the memory 1202 to realize various functions, as follows: Obtain the Extensible Markup Language (XML) file of the target interface; The XML file is instantiated and parsed to obtain the view tree corresponding to the XML file; The view tree is parsed to obtain the view node structure, where each view node in the view node structure is used to store the attribute data of each view of the target interface. The target interface is rendered based on this view node structure.

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

[0125] 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 view rendering methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Obtain the Extensible Markup Language (XML) file of the target interface; The XML file is instantiated and parsed to obtain the view tree corresponding to the XML file; The view tree is parsed to obtain the view node structure, where each view node in the view node structure is used to store the attribute data of each view of the target interface. The target interface is rendered based on this view node structure.

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

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

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

[0129] The foregoing has provided a detailed description of a view 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.< / view> < / linearlayout> < / textview> < / linearlayout> < / linearlayout> < / textview> < / linearlayout>

Claims

1. A view rendering method, characterized in that, include: Obtain the Extensible Markup Language (XML) file of the target interface; The XML file is instantiated and parsed to obtain the view tree corresponding to the XML file; The view tree is parsed to obtain a view node structure, wherein each view node in the view node structure is used to store the attribute data of each view of the target interface; The target interface is rendered based on the view node structure.

2. The method according to claim 1, characterized in that, The view tree is parsed to obtain the view node structure, which includes: Multithreading is invoked to pre-render the view tree in order to obtain the basic attributes of the view tree; The view tree is recursively parsed based on the aforementioned basic attributes to obtain the view node structure, which is a tree structure. The view node types in the view node structure include basic nodes, text nodes, image nodes, container nodes, center view nodes, and extended nodes.

3. The method according to claim 2, characterized in that, Multi-threaded pre-rendering of the view tree is invoked to obtain its basic attributes, including: Call the size calculation function to obtain the width and height of each view in the view tree; Call the position allocation function to obtain the position data of each view in the view tree; Call the pixel drawing function to obtain the pixel data of each view in the view tree; The width, height, position data, and pixel data are the basic attributes.

4. The method according to any one of claims 1 to 3, characterized in that, Before invoking multiple threads to pre-render the view tree to obtain its basic properties, the method further includes: Each view in the view tree is cached in memory. Views in the view tree with a reuse rate higher than a first threshold are cached according to a persistent caching mechanism, while views in the view tree with a reuse rate lower than or equal to the first threshold are cached according to a least recently used caching mechanism.

5. The method according to any one of claims 1 to 3, characterized in that, Rendering the target interface based on the view node structure includes: The initial drawing bitmap is asynchronously constructed based on the main rendering thread of the target interface; Traverse the view node structure and draw each view node of the view node structure on the initial drawing bitmap to obtain the target bitmap; The target bitmap is passed to the main rendering thread to trigger a redraw of the target interface; In response to the redraw, the target bitmap is drawn in the drawing area of ​​the target interface to complete the rendering of the target interface, wherein the drawing area of ​​the target interface is constructed based on the main rendering thread.

6. The method according to any one of claims 1 to 3, characterized in that, Rendering the target interface based on the view node structure includes: Traverse the view node structure to create its corresponding rendering node structure; The rendering main thread of the target interface constructs the drawing area of ​​the target interface; The rendering node structure is traversed, and each view node of the view node structure is drawn on the drawing area to complete the rendering of the target interface.

7. The method according to any one of claims 1 to 3, characterized in that, Rendering the target interface based on the view node structure includes: The rendering main thread of the target interface constructs the drawing area of ​​the target interface; The view node structure is traversed, and each view node of the view node structure is drawn on the drawing area to complete the rendering of the target interface.

8. The method according to any one of claims 1 to 3, characterized in that, The XML file is instantiated and parsed to obtain the view tree corresponding to the XML file, including: An asynchronous parsing component is constructed based on the main rendering thread of the target interface; The XML file is instantiated and parsed based on the asynchronous parsing component to obtain the view tree corresponding to the XML file.

9. A view rendering apparatus, characterized in that, include: The acquisition module is used to acquire the Extensible Markup Language (XML) layout file of the target interface; The processing module is used to instantiate and parse the XML file to obtain the view tree corresponding to the XML file; The view tree is parsed to obtain a view node structure, wherein each view node in the view node structure is used to store the attribute data of each view of the target interface; The target interface is rendered based on the view node structure.

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