List rendering method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The application provides a list rendering method and device, electronic equipment, computer readable storage medium and computer program product; the method comprises the following steps: in response to a first operation for a to-be-rendered list, determining a first target object to be displayed in a viewport area of an electronic device and a second target object to be loaded outside the viewport area; calling a first coordinator located in a main execution thread, generating a first rendering instruction based on the first target object and a third target object currently displayed in the viewport area; calling a second coordinator, generating a second rendering instruction based on the second target object and a fourth target object; calling a rendering engine to obtain a current to-be-displayed view in the viewport area in response to the first rendering instruction, and calling the rendering engine to obtain a to-be-loaded view including the current to-be-displayed view in response to the second rendering instruction. Through the application, the rendering efficiency and smoothness of the list in the continuous interaction process can be improved.

Description

Technical Field

[0001] This application relates to computer technology, and more particularly to a list rendering method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the widespread adoption of mobile internet technology, application development frameworks are commonly used to manage the state and view updates of application user interfaces (UI). While these frameworks perform well when handling regular web pages, they face significant performance challenges when dealing with long lists (such as complex tables or real-time news feeds). Specifically, when users scroll quickly through lists on mobile devices, they may experience blank screens or screen stuttering, severely degrading the user experience. Summary of the Invention

[0003] This application provides a list rendering method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the rendering efficiency and smoothness of lists during continuous interaction.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a list rendering method, the method comprising: in response to a first operation on a list to be rendered, determining a first target object to be displayed within a viewport area of ​​an electronic device and a second target object to be loaded outside the viewport area; both the first target object and the second target object are list items in the list to be rendered; invoking a first coordinator located in the main execution thread to generate a first rendering instruction based on the first target object and a third target object currently displayed within the viewport area; invoking a second coordinator to generate a second rendering instruction based on the second target object and a fourth target object; the fourth target object is a loading object when the third target object is the object to be displayed; invoking a rendering engine in response to the first rendering instruction to obtain a currently displayed view within the viewport area, and invoking the rendering engine in response to the second rendering instruction to obtain a loading view including the currently displayed view; the loading view is used to determine a target view to be displayed within the viewport area upon receiving a second operation, the second operation being an adjacent operation following the first operation.

[0006] This application provides a list rendering apparatus, comprising: a determining module, configured to, in response to a first operation on a list to be rendered, determine a first target object to be displayed within a viewport area of ​​an electronic device and a second target object to be loaded outside the viewport area; both the first target object and the second target object are list items in the list to be rendered; a first generating module, configured to invoke a first coordinator located in the main execution thread to generate a first rendering instruction based on the first target object and a third target object currently displayed within the viewport area; a second generating module, configured to invoke a second coordinator to generate a second rendering instruction based on the second target object and a fourth target object; the fourth target object is a loading object when the third target object is the object to be displayed; and a rendering module, configured to invoke a rendering engine in response to the first rendering instruction to obtain a currently displayed view within the viewport area, and to invoke the rendering engine in response to the second rendering instruction to obtain a loading view including the currently displayed view; the loading view is used to determine a target view to be displayed within the viewport area upon receiving a second operation, the second operation being an adjacent operation following the first operation.

[0007] In the above scheme, the determining module is further configured to, in response to a first operation on the list to be rendered, obtain a pixel offset generated by the first operation; the pixel offset is a pixel value representing the offset of the currently displayed view in the viewport area in the movement direction corresponding to the first operation; calculate the number of list items based on the pixel offset and the table parameters of the list items to obtain a target number; and determine the first target object to be displayed and the second target object to be loaded from the list to be rendered according to the target number and the index identifier of the list items.

[0008] In the above scheme, the determining module is further configured to: when the table parameters of each list item in the list to be rendered are the same, divide the pixel offset by the table parameters to obtain the target quantity; when the table parameters of at least one list item in the list to be rendered are different from the table parameters of other list items, obtain the first index identifier of the last list item in the current display view located in the movement direction corresponding to the first operation; using the first index identifier as the starting identifier, obtain the table parameters of each list item in the movement direction one by one according to the preset index identifier order and accumulate them to obtain the accumulated value; when the accumulated value matches the pixel offset, determine the number of accumulated list items as the target quantity.

[0009] In the above scheme, the determining module is further configured to determine the first index identifier of the last list item and the second index identifier of the first list item in the current display view; determine the removed list items and moved-in list items from the list to be rendered according to the index identifier order, the target quantity, the first index identifier, and the second index identifier; determine the remaining list items after the removed list items are removed from the viewport area and the moved-in list items as the first target object; determine the target position of the first target object in the list to be rendered according to the index identifier order and the index identifier of the first target object; and determine the second target object as a preset number of list items in the list to be rendered located in at least one target direction at the target position.

[0010] In the above scheme, the first generation module is further configured to call the first coordinator located in the main execution thread to generate a first virtual node tree based on the attribute parameters of the first target object; obtain the first historical virtual node tree of the third target object currently displayed in the viewport area; compare the first virtual node tree with the first historical virtual node tree to obtain first difference data; and generate the first rendering instruction based on the first difference data.

[0011] In the above scheme, the second generation module is further configured to, when the main execution thread has idle time after calling the first coordinator, call the second coordinator located in the main execution thread during the idle time to obtain the task to be processed corresponding to the first operation from the preset queue; parse the task to be processed to obtain the attribute parameters of the second target object; generate a second virtual node tree according to the attribute parameters of the second target object; obtain the second historical virtual node tree of the fourth target object; compare the second virtual node tree with the second historical virtual node tree to obtain second difference data; and generate the second rendering instruction according to the second difference data.

[0012] In the above scheme, the second generation module is further used to encapsulate the attribute parameters of the second target object to obtain the task to be processed; and to add the task to be processed to the preset queue located in the main execution thread.

[0013] In the above scheme, the second generation module is further configured to configure the second coordinator in the background execution thread when the main execution thread has no idle time after calling the first coordinator; send the attribute parameters of the second target object and the list identifier of the list to be rendered to the second coordinator in the background execution thread through the main execution thread; and call the second coordinator located in the background execution thread to generate the second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object.

[0014] In the above scheme, the second generation module is further configured to call the second coordinator to generate a second virtual node tree based on the attribute parameters of the second target object; obtain the second historical virtual node tree of the fourth target object; compare the second virtual node tree with the second historical virtual node tree to obtain second difference data; generate the second rendering instruction based on the second difference data; the second rendering instruction carries the list identifier.

[0015] In the above scheme, the first rendering instruction carries a list identifier of the list to be rendered. The rendering module is further used to call the rendering engine to parse the first rendering instruction to obtain the list identifier, the index identifier of the first target object, and the first rendering parameters; in the rendering node tree of the current display view, to find the first list node corresponding to the list identifier; to generate a first subview rendering object of the first target object according to the first rendering parameters; to determine the first insertion position of the first subview rendering object in the first list node according to the index identifier of the first target object; to insert the first subview rendering object into the first insertion position to obtain a second list node located in the rendering node tree; and to refresh the layout of the rendering node tree according to the second list node to obtain the current view to be displayed in the viewport area.

[0016] In the above scheme, the first rendering instruction also includes a template type identifier of the first target object; the rendering module is further configured to update the attribute data of the idle view object according to the first rendering parameters when there is an idle view object matching the template type identifier in the preset view reuse pool, thereby obtaining the first sub-view rendering object; when there is no idle view object matching the template type identifier in the view reuse pool, create a view object corresponding to the template type identifier; and initialize the attribute data of the created view object according to the first rendering parameters, thereby obtaining the first sub-view rendering object.

[0017] In the above scheme, the rendering module is further configured to determine the first subview rendering object as a new idle view object when it is determined that the list item corresponding to the first subview rendering object is located outside the viewport area; and to map the new idle view object to the template type identifier of the first subview rendering object and store it in the view reuse pool.

[0018] In the above scheme, the rendering module is further configured to call the rendering engine to parse the second rendering instruction to obtain the list identifier, the index identifier of the second target object, and the second rendering parameters; search for the second list node corresponding to the list identifier in the rendering node tree of the currently displayed view; generate a second subview rendering object of the second target object according to the second rendering parameters; determine the second insertion position of the second subview rendering object in the second list node according to the index identifier of the second target object; insert the second subview rendering object into the second insertion position to obtain a third list node; and refresh the layout of the rendering node tree according to the third list node to obtain the view to be loaded.

[0019] In the above scheme, the determining module is further configured to, in response to the second operation on the list to be rendered, determine a fifth target object to be displayed within the viewport area of ​​the electronic device; if the fifth target object is the same object as the second target object being processed by the second coordinator, when the view to be loaded has been obtained, determine the current view to be displayed corresponding to the second operation from the view to be loaded; when the view to be loaded has not been obtained, prohibit the first coordinator from processing the fifth target object, and wait for the view to be loaded containing the fifth target object to be obtained through the second coordinator; when the view to be loaded containing the fifth target object is obtained, determine the current view to be displayed corresponding to the second operation from the view to be loaded.

[0020] This application provides an electronic device, which includes: a memory for storing computer-executable instructions or computer programs; and a processor for executing the computer-executable instructions or computer programs stored in the memory to implement the list rendering method provided in this application.

[0021] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the list rendering method provided in this application when executed by a processor.

[0022] This application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the list rendering method provided in this application.

[0023] The embodiments of this application have the following beneficial effects:

[0024] In this embodiment, in response to a first operation on the list to be rendered, a first target object to be displayed within the viewport area and a second target object to be loaded outside the viewport area are determined from the list. On one hand, a first rendering instruction is generated based on the first and third target objects by calling a first coordinator located in the main execution thread. On the other hand, a second rendering instruction is generated based on the second and fourth target objects by calling a second coordinator. Then, the rendering engine is invoked in response to the first rendering instruction to obtain the current view to be displayed within the viewport area, and then the rendering engine is invoked again in response to the second rendering instruction to obtain the view to be loaded, which includes the current view to be displayed. Thus, this embodiment of the application utilizes the division of labor and cooperation between the first coordinator and the second coordinator, enabling the main execution thread to focus on updating the core visible content within the viewport area. This reduces the computational load on the main thread, improves the rendering efficiency of the current viewport view, and ensures the immediacy and accuracy of the response in the user's visible area. Furthermore, by combining the rendering engine's responses to the first and second rendering instructions to obtain the current view to be displayed and the view to be loaded, the electronic device can promptly present the current view to be displayed corresponding to the first operation to the user. When receiving the second operation, it can also quickly determine the new target display content using the view to be loaded. This significantly improves the rendering efficiency and smoothness of the list during continuous interaction, enhancing the user's human-computer interaction experience. Attached Figure Description

[0025] Figure 1 This is an optional architecture diagram of the list rendering system provided in the embodiments of this application;

[0026] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0027] Figure 3 This is a schematic diagram illustrating an application scenario of the list rendering method provided in the embodiments of this application;

[0028] Figure 4 This is an optional flowchart illustrating the list rendering method provided in an embodiment of this application;

[0029] Figure 5 This is a schematic diagram of the implementation process for determining the first target object and the second target object provided in the embodiments of this application;

[0030] Figure 6 This is a schematic diagram of an optional implementation scenario for list rendering provided in the embodiments of this application;

[0031] Figure 7This is a schematic diagram of another optional implementation scenario of list rendering provided in the embodiments of this application;

[0032] Figure 8 This is a schematic diagram of the implementation process for generating the first rendering instruction provided in an embodiment of this application;

[0033] Figure 9 This is a schematic diagram illustrating an optional implementation principle for generating a second rendering instruction provided in an embodiment of this application;

[0034] Figure 10 This is a schematic diagram illustrating another optional implementation principle for generating the second rendering instruction provided in an embodiment of this application;

[0035] Figure 11 This is a schematic diagram illustrating the implementation process of obtaining the current view to be displayed, provided in an embodiment of this application.

[0036] Figure 12 This is a schematic diagram illustrating the implementation process of obtaining the view to be loaded, provided in an embodiment of this application.

[0037] Figure 13 This is a schematic diagram of the card view list architecture provided in an embodiment of this application;

[0038] Figure 14 This is a schematic diagram of the architecture of the table view list provided in the embodiments of this application;

[0039] Figure 15 This is a schematic diagram of the dual coordinator architecture provided in an embodiment of this application;

[0040] Figure 16 This is a flowchart illustrating the single-threaded concurrent scheduling provided in an embodiment of this application;

[0041] Figure 17 This is a flowchart illustrating multi-threaded parallel computing provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0043] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0044] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0045] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0046] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0047] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0048] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0049] 1) Responding to: used to indicate the conditions or states on which the operation is performed depends. When the conditions or states on which it depends are met, one or more operations can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0050] 2) React-Flutter framework: refers to a cross-platform application development architecture based on cross-language bridging technology. The React-Flutter framework hosts React applications based on a JavaScript execution environment (such as JSCore, V8, or WebView), and communicates with the native Flutter layer through a communication bridge.

[0051] 3) Bridge: refers to the data transmission channel established between the JavaScript execution environment and the Flutter native rendering layer. The bridge is responsible for transmitting the rendering instructions generated by the JavaScript side to the native layer and sending back the user interaction events captured by the native layer to the JavaScript side.

[0052] 4) Reconciler: This is the core logic processing unit in the React architecture, used to construct a new virtual node tree based on attribute parameters and execute the diff algorithm. The diff algorithm traverses and compares the new virtual node tree with the old virtual node tree, calculates the changed and differing nodes, and generates a minimal set of update operations, i.e., rendering instructions, based on the differing nodes.

[0053] 5) Main Coordinator: Refers to the coordinator instance residing in the main execution thread of the application (e.g., the main JS thread). In this embodiment, the main coordinator is configured with a high-priority response mechanism, specifically for handling the rendering logic of the first target object (i.e., the visible list items within the current viewport / visible area). The main coordinator is used to immediately perform synchronous calculations on the view within the visible area upon detecting a state update or scroll event, to ensure the immediate responsiveness of the user interface.

[0054] 6) List Item Coordinator: Also known as the secondary coordinator, it refers to another coordinator instance separate from the primary coordinator. The secondary coordinator is executed asynchronously, and the execution environment is a background execution thread or the idle time slice of the main execution thread. In the embodiments of this application, the list item coordinator is specifically used to handle the rendering logic of the second target object (i.e., the item to be rendered located outside the current viewport but within the preload range). The preload range is defined as: the spatial range extending vertically and horizontally along the list scrolling direction and / or vertically and horizontally perpendicular to the scrolling direction from the boundary of the visible area of ​​the current viewport to a preset distance; the value of the preset distance can be set to be equal to the display size of the current viewport in the scrolling direction (i.e., one screen height), or equal to the sum of the layout heights corresponding to the maximum number of list items that the current viewport can accommodate.

[0055] The role of the list item coordinator is to generate rendering instructions for preloaded items in parallel without blocking the main coordinator, thus sharing the computational load of the main thread.

[0056] 7) WebWorker / Background JS Thread: Refers to a parallel execution environment independent of the main JavaScript execution thread (main JS thread). This execution environment has its own memory space and event loop, used to execute computationally intensive or time-consuming tasks. In this application, WebWorker is configured to host the operation of the secondary coordinator, enabling the generation of the preloaded virtual document object model (DOM) and the Diff calculation process to be processed in parallel in the background, thereby avoiding the main JS thread being suspended or blocked.

[0057] 8) Rendering instructions: These are structured data generated by the coordinator based on the difference comparison results, used to indicate user interface updates. This structured data can be encapsulated in JSON format and passed to the native layer via a communication bridge, where the rendering engine parses it and executes the corresponding UI change operations.

[0058] Before explaining the list rendering method provided in the embodiments of this application, the methods in related technologies will be described first.

[0059] In current cross-platform application development frameworks, the rendering process typically involves generating a new Virtual Document Object Model (DOM) tree based on updated state data when the application's user interface state changes. A coordinator then immediately intervenes. The coordinator compares (diffs) the newly generated DOM tree with the old one to calculate the differences. Finally, the coordinator generates a minimal set of rendering update instructions based on these comparisons. To cross runtime environment boundaries, these instructions are usually serialized and transmitted to the native rendering layer via a communication bridge, where they are parsed and the final layer rendering is performed.

[0060] While the above architecture performs well on regular pages, it faces significant performance challenges when handling long lists with complex structures and massive amounts of data (such as large tables and social media feeds). In particular, it becomes sluggish when users perform rapid scrolling on mobile devices, severely impacting the user experience.

[0061] Based on at least one of the aforementioned problems with methods in related technologies, the list rendering method provided in this application can determine, in response to a first operation on the list to be rendered, a first target object to be displayed within the viewport area and a second target object to be loaded outside the viewport area. On one hand, a first rendering instruction is generated based on the first and third target objects by calling a first coordinator located in the main execution thread; on the other hand, a second rendering instruction is generated based on the second and fourth target objects by calling a second coordinator. Then, the rendering engine is invoked in response to the first rendering instruction to obtain the current view to be displayed within the viewport area, and then the rendering engine is invoked again in response to the second rendering instruction to obtain the view to be loaded, which includes the current view to be displayed. Thus, this embodiment of the application utilizes the division of labor and cooperation between the first coordinator and the second coordinator, enabling the main execution thread to focus on updating the core visible content within the viewport area. This reduces the computational load on the main thread, improves the rendering efficiency of the current viewport view, and ensures the immediacy and accuracy of the response in the user's visible area. Furthermore, by combining the rendering engine's responses to the first and second rendering instructions to obtain the current view to be displayed and the view to be loaded, the electronic device can promptly present the current view to be displayed corresponding to the first operation to the user. When receiving the second operation, it can also quickly determine the new target display content using the view to be loaded. This significantly improves the rendering efficiency and smoothness of the list during continuous interaction, enhancing the user's human-computer interaction experience.

[0062] Here, we first describe an exemplary application of the list rendering device in this application embodiment. This list rendering device is an electronic device used to implement the list rendering method. In one implementation, the list rendering device (i.e., electronic device) provided in this application embodiment can be implemented as a terminal or as a server. In one implementation, the list rendering device provided in this application embodiment can be implemented as any terminal with data processing and list rendering functions, such as a laptop, tablet, desktop computer, mobile phone, portable music player, personal digital assistant, dedicated messaging device, portable gaming device, or intelligent robot. In another implementation, the list rendering device provided in this application embodiment can also be implemented as a server. The server 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 (CDN), and big data and artificial intelligence platforms. The terminal and the server can be directly or indirectly connected through wired or wireless communication, which is not limited in this application embodiment. Below, we will describe an exemplary application when the list rendering device is implemented as a server.

[0063] See Figure 1 , Figure 1 This is an optional architecture diagram of the list rendering system provided in the embodiments of this application. The list rendering system 10 in the embodiments of this application includes at least a terminal 100, a network 200 and a server 300. The terminal 100 has an application that provides list rendering function.

[0064] The following description uses an application on a terminal that provides list rendering functionality as an example. In this embodiment, server 300 can be a server that stores the list to be rendered. Terminal 100 connects to server 300 via network 200, which can be a wide area network (WAN), a local area network (LAN), or a combination of both.

[0065] See Figure 1When a user views the list to be rendered, terminal 100 sends a list retrieval request to server 300, and server 300 sends the list to be rendered to terminal 100 via network 200. Subsequently, in response to the first operation on the list to be rendered, terminal 100 determines a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area; both the first and second target objects are list items in the list to be rendered. Then, terminal 100 calls a first coordinator located in the main execution thread to generate a first rendering instruction based on the first target object and a third target object currently displayed within the viewport area. Next, terminal 100 calls a second coordinator to generate a second rendering instruction based on the second target object and a fourth target object; the fourth target object is the object to be loaded when the third target object is the object to be displayed. Finally, terminal 100 calls the rendering engine in response to the first rendering instruction to obtain the current view to be displayed within the viewport area, and calls the rendering engine in response to the second rendering instruction to obtain a view to be loaded including the current view to be displayed. The view to be loaded is used to determine the target view to be displayed within the viewport area upon receiving the second operation, which is an adjacent operation following the first operation. After generating the current view to be displayed, terminal 100 can display the current view to be displayed on the current interface of the list rendering application.

[0066] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Figure 2 The illustrated electronic device 400 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the electronic device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0067] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc. User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls. Memory 450 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. Memory 450 may optionally include one or more storage devices physically located away from processor 410. Memory 450 includes volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), and volatile memory can be random access memory (RAM). The memory 450 described in the embodiments of this application is intended to include any suitable type of memory.

[0068] In some embodiments, memory 450 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, as illustrated below. Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as a framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks; network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including Bluetooth, WiFi, and Universal Serial Bus (USB); presentation module 453 is used to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.); input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0069] In some embodiments, the list rendering apparatus provided in this application can be implemented in software. Figure 2A list rendering apparatus 455 stored in memory 450 is shown. This apparatus can be software in the form of programs and plugins, and includes the following software modules: a determination module 4551, a first generation module 4552, a second generation module 4553, and a rendering module 4554. These modules are logically linked and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0070] In other embodiments, the list rendering apparatus provided in this application can be implemented in hardware. As an example, the list rendering apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the list rendering method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0071] In some embodiments, the terminal or server can implement the list rendering method provided in this application by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run, such as collaborative office APPs or instant messaging APPs; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0072] The following describes the application scenarios of the list rendering method provided in the embodiments of this application.

[0073] In collaborative work scenarios, when users browse smart spreadsheets containing tens of thousands of rows of data on low-configuration office terminals via a client, rapid scrolling can easily cause the main rendering thread to be blocked, resulting in large areas of blank space or stuttering due to insufficient rendering of the spreadsheet content. To address this issue, in this embodiment, the office computer or tablet (i.e., electronic device) responds to a large sliding signal or scroll bar drag signal for the smart spreadsheet interface (i.e., the first operation for the list to be rendered) by first calculating and determining locally the data rows that should be displayed in the current screen's visible window (i.e., the first target object) and the data rows in the prepared cache area below the visible window (i.e., the second target object to be loaded outside the viewport area). Subsequently, the terminal calls the view logic controller (i.e., the first coordinator) located in the main execution thread to perform a difference comparison based on the first target object to be displayed and the data rows currently displayed on the terminal screen (i.e., the third target object), generating a parameter for real-time display. The terminal executes the rendering instructions shown (i.e., the first rendering instruction); the terminal calls the preloading controller (i.e., the second coordinator) running in the background to generate a pre-rendering instruction (i.e., the second rendering instruction) based on the second target object outside the viewport and the object to be processed as a reference (i.e., the fourth target object); finally, the terminal calls the local rendering engine to respond to the first rendering instruction, constructs a table layout view of the current visible area (i.e., obtains the current view to be displayed in the viewport area), and calls the rendering engine to respond to the second rendering instruction to generate a long table view snapshot containing the visible area and the expanded buffer data (i.e., obtains the view to be loaded including the current view to be displayed), so that when the terminal user continues to perform continuous scrolling operations (i.e., receives the second operation), the terminal can directly use the pre-generated view to be loaded to determine the target view to be displayed in the viewport area, thereby effectively solving the performance bottleneck of rendering large-scale table data on the terminal side and ensuring the smoothness of data verification and browsing in office scenarios.

[0074] like Figure 3 As shown, Figure 3 This is a schematic diagram illustrating an application scenario of the list rendering method provided in this application embodiment. In a collaborative office scenario, when a user browses a large-scale table on the visible area 302 of device 301, device 301 captures the user's first operation in real time, then determines the first target object (the object to be displayed in the visible area 302) and the second target object (the object to be loaded in the pre-loading area 303). A first rendering instruction is generated for the first target object through a first coordinator, and a second rendering instruction is generated for the second target object through a second coordinator. The cloud-based table rendering engine then synchronously generates the current view to be displayed and the view to be loaded containing the current view to be displayed. The first coordinator resides in the main thread, while the second coordinator can reside in either the main thread or a background thread.

[0075] Figure 4This is an optional flowchart illustrating the list rendering method provided in this application embodiment. The following will combine... Figure 3 The application scenarios shown and Figure 4 The steps shown are explained as follows: Figure 4 As shown, the method of rendering a list is illustrated using an electronic device as the execution subject. The method includes the following steps S101 to S104:

[0076] Step S101, in response to the first operation on the list to be rendered, determines a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area.

[0077] Here, both the first target object and the second target object are list items in the list to be rendered.

[0078] In this embodiment of the application, an electronic device (such as a terminal) responds to a first operation on a list to be rendered by determining a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area of ​​the electronic device; and both the first target object and the second target object are list items in the list to be rendered.

[0079] Here, the viewport area refers to the rectangular physical pixel set allocated on the screen display panel of an electronic device for actually displaying the visible content of tables in the graphical user interface (GUI). The size of the viewport area is defined by the layout constraints of the current application window and the screen resolution. The viewport area constitutes the user's visible range at the current moment. The list to be rendered refers to an ordered collection of data to be displayed, maintained in the application's memory. The data volume often far exceeds the visible range of a single screen. The first target object refers to the list item whose geometric coordinates intersect with the physical viewport area of ​​the electronic device at the current time, i.e., the content that the user can currently "see". The second target object refers to the list item that is logically adjacent to the first target object and located outside the viewport area, i.e., the preloaded content that the user will soon "see", including the four directions of up, down, left, and right.

[0080] In some embodiments, the list to be rendered can be constructed as follows: In response to a user's instruction to open a spreadsheet file, an electronic device downloads structured data from a server, database, or cloud database, containing, but not limited to, financial statements, project schedules, or personnel files; subsequently, the structured data is deserialized by a data parsing engine, and the original data is mapped into a table structure containing row height attributes and cell content through a traversal algorithm, which constitutes the list to be rendered for subsequent rendering calculations.

[0081] In some embodiments, determining the first target object to be displayed within the viewport area of ​​the electronic device and the second target object to be loaded outside the viewport area can be achieved as follows: The terminal receives a first operation generated by an input device (such as mouse wheel scrolling, touchpad dragging, or finger sliding on a touchscreen), and obtains the total displacement distance generated by the first operation in the list scrolling direction. A correspondence is established between this total displacement distance and the geometric dimension parameters of the list items. Based on the correspondence and the arrangement order of the list items, the starting list item currently within the screen display range is located, and the ending list item is calculated in conjunction with the physical height of the viewport area. The list content located between the starting and ending list items is determined as the first target object to be displayed within the viewport area. A buffer area is defined by extending in at least one of the directions (up, down, left, right) of the first target object, using it as a reference. Data rows located within this buffer area, which are not yet displayed but are adjacent to the first target object, are determined as the second target object to be loaded outside the viewport area.

[0082] In some embodiments, determining the first target object to be displayed within the viewport area of ​​the electronic device and the second target object to be loaded outside the viewport area can also be achieved by: in response to detecting a first operation on the list to be rendered, obtaining the coordinate parameters of the list items to be displayed within the viewport area of ​​the electronic device; comparing the coordinate parameters of the list items to be displayed with the coordinate parameters of each list item in the list to be rendered, and selecting list items with the same coordinate parameters from the list to be rendered as the first target object; simultaneously, selecting list items located outside the viewport area and whose coordinate parameters are adjacent to the coordinate parameters of the first target object from the list to be rendered as the second target object.

[0083] In some embodiments, see Figure 5 , Figure 5 This is a schematic diagram of the implementation process for determining the first target object and the second target object provided in the embodiments of this application; Figure 5 Step S101 can be achieved through the following steps S1011 to S1013:

[0084] Step S1011: In response to the first operation on the list to be rendered, obtain the pixel offset generated by the first operation.

[0085] Here, the pixel offset is the pixel value of the offset of the currently displayed view within the viewport area in the movement direction corresponding to the first operation.

[0086] As an example, the terminal can receive event data reported by the input module and calculate the pixel offset generated by the first operation using the coordinate data provided in the event data. Specifically, when the terminal device's operating system detects a displacement signal from a touchscreen, mouse, or other pointing device, it generates an event object containing a timestamp and coordinate information. The rendering control module receives this event object and reads the anchor point coordinates at the start of the first operation and the real-time coordinates at the current sampling time. By performing vector subtraction, the anchor point coordinates are subtracted from the real-time coordinates to obtain the displacement vector. Subsequently, the component of the displacement vector in the list scrolling direction (such as the Y-axis) is extracted, and this component is defined as the original offset value.

[0087] For ease of explanation, assume the electronic device's screen viewport height is fixed, accommodating the height of four list items, and that the list item's table parameters are set to a fixed height, such as 100 pixels per item. The list is a single-column list, and users can scroll up and down to view the table content. See also... Figure 6 , Figure 6 This is a schematic diagram of an optional implementation scenario of list rendering provided in the embodiments of this application, such as... Figure 6 As shown, the screen of electronic device 601 displays data with indices [10, 11, 12, 13] within the viewport area 602. Data with indices [06, 07, 08, 09] is located outside the viewport area 6031, and data with indices [14, 15, 16, 17] is located outside the viewport area 6032. Next, see... Figure 7 , Figure 7 This is a schematic diagram of another optional implementation scenario of list rendering provided in this application embodiment. The terminal receives a first operation generated by the input device, such as the user's finger scrolling down on the mouse. The list moves upward, indicating the user's intention to view the content below. The electronic device calculates the scroll offset increment generated by the first operation based on the scroll signal, which is a distance of 100 pixels. The new offset (100 pixels) is divided by the list item height (100 pixels) to determine that one list item has moved upward, and the new starting index of the current viewport is calculated to be 11. Then, based on the parameter that the viewport height can accommodate 4 items, the new ending index is calculated to be 14. Thus, the range of new list items to be displayed in the viewport area 702 of the electronic device 701 is determined to be data with indices [11, 12, 13, 14]. Suppose that four list items in the forward and reverse scrolling directions are pre-defined as the second target objects to be loaded, namely the data with index [15, 16, 17, 18] located outside the viewport area 7032 and the data with index [07, 08, 09, 10] located outside the viewport area 7031.

[0088] Step S1012: Calculate the number of list items based on the pixel offset and the table parameters of the list items to obtain the target number.

[0089] As an example, the terminal reads pre-configured table parameters, which include the height and width of the list items, and may also include the spacing between the list items.

[0090] In some embodiments, when there is no spacing between list items, step S1012 can be implemented as follows: when the table parameters of each list item in the list to be rendered are the same, the target quantity is obtained by dividing the pixel offset by the table parameters. Alternatively, when the table parameters of at least one list item in the list to be rendered are different from the table parameters of other list items, the first index identifier of the last list item in the movement direction corresponding to the first operation in the current display view is obtained; using the first index identifier as the starting identifier, the table parameters of each list item in the movement direction are obtained one by one according to the preset index identifier order and accumulated to obtain the accumulated value; when the accumulated value matches the pixel offset, the number of accumulated list items is determined as the target quantity.

[0091] As an example, for a compact list layout where there is no spacing between list items (i.e., the spacing value in the table parameters is 0), when the table parameters of each list item in the list to be rendered are the same, the pixel offset is divided by the table parameters to obtain the target quantity. The terminal reads a preset uniform height parameter. The rendering control module calls the division operation instruction to divide the obtained pixel offset by this uniform height parameter. The integer part of the calculation result is the target quantity.

[0092] When at least one list item in the list to be rendered has a table parameter different from the table parameters of other list items (i.e., an irregular height list), the quantity cannot be determined by a single division. In this case, the terminal can execute an accumulation traversal logic. The following section combines... Figure 6 and Figure 7 To further explain, firstly, the terminal obtains the first index identifier (index 13) of the last list item in the current display view located in the movement direction corresponding to the first operation. This first index identifier can serve as the reference anchor point for calculating the content to be loaded outside the viewport. If the first operation is to swipe upwards (view the content below), the movement direction points to the end of the list, and this first index identifier is the index of the most visible list item at the bottom of the current viewport. Starting with the first index identifier, the table parameters of each list item in the movement direction are obtained one by one according to the preset index identifier order and accumulated to obtain the accumulated value. Specifically, an accumulator and a counter can be initialized. The height of the list item corresponding to the next index (index 14) is read from the data source, and the accumulated value of the accumulator is updated. If the accumulated value is less than the pixel offset at this time, the height of the list item corresponding to the next index (index 15) is read and accumulated, while the counter is incremented. Finally, when the accumulated value matches the pixel offset, the number of accumulated list items is determined as the target number. Here, "matching" refers to the critical state where the accumulated value first reaches or exceeds the pixel offset.

[0093] Through the above implementation, for rendering scenarios where list items have no spacing, a differentiated calculation method is adopted by determining whether the table parameters of each list item in the list to be rendered are consistent. When the table parameters are consistent, the target quantity is quickly obtained by dividing the pixel offset by the table parameter. When the parameters are inconsistent, the target quantity is determined by sequentially accumulating the table parameters of the list items starting from the last list item in the current display view's corresponding movement direction and matching them with the pixel offset. This effectively achieves accurate and efficient calculation of the target quantity under different table parameter scenarios, adapts to various actual rendering needs with both unified and non-unified list item parameters, improves the adaptability and accuracy of target quantity calculation during list rendering, and provides accurate quantity basis for subsequent list rendering operations.

[0094] In some embodiments, when there is spacing between list items, step S1012 can also be implemented as follows: when the table parameters of each list item in the list to be rendered are the same, the target quantity is obtained by dividing the pixel offset by the unit height, wherein the unit height is obtained by adding the table parameters and the spacing parameters. Alternatively, when at least one list item in the list to be rendered has a table parameter different from the table parameters of other list items, the first index identifier of the last list item in the movement direction corresponding to the first operation in the current display view is obtained; with the first index identifier as the starting identifier, the table parameters of each list item in the movement direction are obtained one by one according to the preset index identifier order, and the table parameters and the spacing parameters are summed and accumulated to obtain the accumulated value; when the accumulated value matches the pixel offset, the number of accumulated list items is determined as the target quantity.

[0095] Through the above implementation, for rendering scenarios with spacing between list items, a differentiated target quantity calculation method is adopted by determining whether the table parameters of each list item in the list to be rendered are consistent. When the parameters are all the same, the target quantity is quickly obtained by dividing the pixel offset by the unit height of the sum of the table parameters and the spacing parameters. When the parameters are different, starting from the last list item in the current display view's corresponding movement direction, the sum of the table parameters and the spacing parameters of each list item is accumulated sequentially and matched with the pixel offset to determine the target quantity. This effectively achieves accurate and efficient calculation of the target quantity under different table parameter states in scenarios with spacing, adapts to various actual rendering needs with uniform and non-uniform list item parameters, improves the adaptability and accuracy of target quantity calculation in list rendering with spacing, provides accurate quantity basis for subsequent list rendering operations, and ensures the smoothness and rationality of list rendering.

[0096] Step S1013: Based on the number of targets and the index identifier of the list items, determine the first target object to be displayed and the second target object to be loaded from the list to be rendered.

[0097] As an example, first, determine the index of the last list item currently displayed in the movement direction. Using the index of the last list item as the starting point, determine the index of the subsequent list items corresponding to the target quantity. The list item corresponding to the index of the subsequent list item is the first target object.

[0098] Furthermore, to determine the second target object, using the index range of the first target object as the center, if the list to be rendered is a single-list cell, a preset preloading threshold is applied to the upper and lower directions of the index range of the first target object to calculate the forward buffer space and the backward buffer space. List items corresponding to indices within these two extended ranges are determined as the second target objects to be loaded. If the list to be rendered is a multi-list cell, a preset preloading threshold is applied to the upper, lower, left, and right directions of the index range of the first target object to calculate the forward buffer space, the backward buffer space, the left-forward buffer space, and the right buffer space. List items corresponding to indices within these four extended ranges are determined as the second target objects to be loaded.

[0099] In some embodiments, step S1013 can also be implemented as follows: First, determine the first index identifier of the last list item and the second index identifier of the first list item in the current display view; then, determine the removed list items and moved-in list items from the list to be rendered according to the index identifier order, target quantity, first index identifier and second index identifier; then, determine the remaining list items after the removed list items and the moved-in list items in the viewport area as the first target object; then, determine the target position of the first target object in the list to be rendered according to the index identifier order and the index identifier of the first target object; finally, determine the second target object as the second target object by at least a preset number of list items in the list to be rendered located in at least one target direction at the target position.

[0100] As an example, still using Figure 6 and Figure 7Taking this as an example, firstly, the terminal determines the first index identifier (index 13) of the last list item and the second index identifier (index 10) of the first list item in the currently displayed view within the viewport area. At the end of the previous frame's rendering or the moment the first operation occurs, the rendering control module reads the metadata of the rendered list items within the current viewport. It locks the list item displayed at the bottom of the viewport's physical location and extracts its unique number from the data source as the first index identifier. Simultaneously, it locks the list item displayed at the top of the viewport's physical location and extracts its unique number as the second index identifier. These two index identifiers determine the logically closed interval of the currently visible area within the data source. Then, based on the index identifier order, target quantity, first index identifier, and second index identifier, it determines the list items to be moved out and moved in from the list to be rendered. The data movement logic is determined according to the movement direction indicated by the first operation. If the first operation indicates that the list scrolls upwards (i.e., the user browses the content below), the data logically shifts upwards. The top area of ​​the viewport can be designated as the move-out area, and the bottom area as the move-in area. The target number (e.g., 1) is used as the displacement step size. For the removed list item, starting from the second index of the first list item, the target number of objects are selected in the direction of decreasing index. For example, the selected target number of objects can be the list item corresponding to the index set

[10] . For the moved-in list item, starting from the first index of the last list item, the target number of subsequent objects are selected in the direction of increasing index. For example, the selected target number of subsequent objects can be the list item corresponding to the index set

[14] . If the operation direction is reversed, the reference bases for the removed and moved-in items are reversed accordingly. Then, the remaining list items after the removed list items in the viewport area, with the index set [11, 12, 13] and the index set of the moved-in list item

[14] , are determined as the first target object.

[0101] When determining the second target object, the third index identifier of the last list item and the fourth index identifier of the first list item are obtained. If the list to be rendered is a single-list cell, at both ends of the target position along the movement direction, a predetermined number of list items adjacent to the third index identifier and a predetermined number of list items adjacent to the fourth index identifier are obtained from the data source of the list to be rendered. If the list to be rendered is a multi-list cell, at both ends of the target position along the movement direction, a predetermined number of list items adjacent to the third index identifier and a predetermined number of list items adjacent to the fourth index identifier are obtained from the data source of the list to be rendered. Then, based on the index set formed by the third and fourth index identifiers, at both ends of the target position along the movement direction, a predetermined number of list items adjacent to the left side of the index set and a predetermined number of list items adjacent to the right side of the index set are obtained from the data source of the list to be rendered. These list items, which have not yet entered the current view area but are logically about to enter, are the second target objects.

[0102] By implementing the above method, the first and last indexes of the list items in the current display view are determined. The list items to be removed and the list items to be moved in are accurately filtered by combining the index order and the target quantity. Then, the remaining list items in the viewport area and the moved list items are integrated to obtain the first target object. The target position of the first target object in the list to be rendered is determined. Finally, based on the target position, a preset number of second target objects in the target direction are determined. This achieves accurate filtering, positioning and range expansion of the list items to be rendered, which clarifies the precise processing objects and range for subsequent list rendering operations, and improves the targeting and efficiency of list rendering.

[0103] Through steps S1011 to S1013, the pixel offset of the corresponding viewport area is obtained in response to the first operation of the list to be rendered. Then, the target quantity is calculated by combining the table parameters of the list items. Finally, the first target object to be displayed and the second target object to be loaded are determined based on the target quantity and the index identifier of the list item. This achieves an efficient closed loop from operation response to target object selection, accurately and quickly locking the display and loading objects required for list rendering, providing reliable support for the smooth rendering of the subsequent list, and improving the targeting and efficiency of list interaction and data loading.

[0104] Step S102: Invoke the first coordinator located in the main execution thread to generate the first rendering instruction based on the first target object and the third target object currently displayed in the viewport area.

[0105] In this embodiment, the terminal invokes a first coordinator located in the main execution thread to generate a first rendering instruction based on the difference data between a first target object to be displayed within the viewport area and a third target object currently displayed within the viewport area. After generating the first rendering instruction, the first coordinator in the main execution thread sends the first rendering instruction to the rendering engine through a communication bridge.

[0106] The main execution thread refers to the core thread in the operating system or application runtime environment responsible for handling user interface rendering, event dispatching, and user interaction. The first coordinator is a logical control module or object instance running within the main execution thread, responsible for scheduling, prioritizing, and calculating differences in rendering tasks. The first coordinator can be an algorithm engine with virtual DOM comparison capabilities or a layout manager responsible for managing the view reuse pool. The third target object refers to the collection of list items that have already been rendered and exist within the viewport area before the first operation occurs. The first rendering instruction refers to a sequence of commands output by the first coordinator to guide the graphics rendering engine in performing specific operations on view elements. The first rendering instruction is not limited to a full refresh but includes a set of atomic operations such as node creation, node removal, node attribute updates, and node position transformations.

[0107] Regarding the specific implementation of calling the first coordinator located in the main execution thread: When the terminal determines the first target object to be displayed within the viewport area of ​​the electronic device and the second target object to be loaded outside the viewport area, it can synchronously obtain the index identifier corresponding to the first target object, trigger the execution entry function of the first coordinator, and then call the first coordinator.

[0108] Regarding the specific implementation of generating the first rendering instruction based on the first target object and the third target object currently displayed within the viewport area: First, the first coordinator extracts the index set of the first target object and the index set of the third target object. The first coordinator can calculate the intersection of these two index sets: for list items that exist in both sets, a hold instruction or an update instruction is generated (if the data content remains unchanged, it is held; if the content changes, the attributes are updated). For list items that exist in the third target object but not in the first target object, the first coordinator generates a remove instruction or a recycle instruction, which instructs the corresponding view component to be unbound from the rendering node tree. For list items that exist in the first target object but not in the third target object, the first coordinator generates a create instruction or a reuse instruction, which instructs the first coordinator to retrieve an idle view component from the reuse cache pool and populate it with new data; if no cache is available, a new component is created and mounted to the specified coordinate position.

[0109] In some embodiments, the process of generating the first rendering instruction also includes position correction logic. When it is detected that a list item has only shifted (e.g., the user is slowly swiping) and has not moved out of the viewport area, the first rendering instruction only contains parameters to modify the transformation matrix of the view component. This shift can be completed using GPU hardware acceleration without triggering expensive layout reflow operations. Furthermore, the first rendering instruction can also be packaged into a transaction to ensure that these changes are committed within the same vertical synchronization cycle.

[0110] For example, suppose the currently displayed (third target object) area contains four list items with indices [10, 11, 12, 13]. The user scrolls down, and the new visible area (first target object) determined in step S101 has indices [11, 12, 13, 14]. The first coordinator performs a comparison: it finds that indices 11, 12, and 13 exist in both, and only their position coordinates have shifted upwards, therefore a move instruction is generated; it finds that index 10 belongs to the third target object but not the first target object, generating a recycling instruction to move the view component corresponding to index 10 into the cache pool; it finds that index 14 belongs to the first target object but not the third target object, generating a reuse and display instruction. This series of move, recycling, and reuse command sequences constitutes the first rendering instruction.

[0111] In some embodiments, see Figure 8 , Figure 8 This is a schematic diagram of the implementation process for generating the first rendering instruction provided in an embodiment of this application; Figure 8 Step S102 can be achieved through the following steps S1021 to S1024:

[0112] Step S1021: Invoke the first coordinator located in the main execution thread to generate the first virtual node tree based on the attribute parameters of the first target object.

[0113] As an example, the terminal invokes a first coordinator located in the main execution thread to generate a first virtual node tree based on the attribute parameters of the first target object. The attribute parameters contain all metadata that determines the final display form of the list items, such as the list item's index identifier, layout information (e.g., component type identifier, size constraint values, padding configuration, and coordinate position), and content information (e.g., text character sequences, image resource addresses, and dynamic status markers). The first coordinator uses preset component mapping rules to instantiate the aforementioned attribute parameters into corresponding lightweight data objects and recursively constructs a first virtual node tree describing the UI structure of the current frame according to the list layout hierarchy. The first virtual node tree exists in memory as data, serving as an abstract description of the content expected to be displayed in the current frame, and has not yet been converted into the underlying native view controls.

[0114] Step S1022: Obtain the first historical virtual node tree of the third target object currently displayed in the viewport area.

[0115] As an example, the terminal invokes the first coordinator located in the main execution thread to retrieve the first historical virtual node tree of the third target object currently displayed in the viewport area. The third target object refers to the set of list items already displayed in the viewport area before the first operation occurred. The terminal retrieves the virtual node tree generated for the third target object during the previous operation from memory, i.e., the first historical virtual node tree.

[0116] Step S1023: Compare the first virtual node tree with the first historical virtual node tree to obtain the first difference data.

[0117] As an example, the terminal calls the first coordinator located in the main execution thread, which uses a tree-structured differential algorithm to perform level-wise or same-level node traversal of the first virtual node tree and the first historical virtual node tree to determine the node changes between the two virtual node trees, including node additions, deletions, moves, and changes to node attributes (such as text color and background image). These identified changes are encapsulated as the first difference data.

[0118] Step S1024: Generate a first rendering instruction based on the first difference data.

[0119] As an example, the terminal invokes the first coordinator located in the main execution thread to transform the initial difference data into atomic operation commands that the rendering engine can recognize. For instance, if the difference data indicates a change in text at a certain index position, the first coordinator generates a corresponding update text instruction; if it indicates a translation of a node position, the first coordinator generates an update coordinate instruction. This series of atomic operations combines to form the first rendering instruction.

[0120] Through steps S1021 to S1024, the first coordinator of the main execution thread is invoked to generate a first virtual node tree based on the attribute parameters of the first target object. This tree is then compared with the first historical virtual node tree of the third target object to obtain the first difference data. Finally, a first rendering instruction is generated based on this first difference data. This achieves the generation of rendering instructions only for the difference parts of the list rendering, avoiding meaningless full rendering, improving the efficiency and performance of list rendering, and ensuring the accuracy of the rendering results. This provides technical support for smooth list interaction.

[0121] Step S103: Invoke the second coordinator to generate a second rendering instruction based on the second target object and the fourth target object.

[0122] Here, the fourth target object is the object to be loaded when the third target object is the object to be displayed.

[0123] In this embodiment, a second coordinator is invoked to generate a second rendering instruction based on a second target object to be loaded outside the viewport area and a fourth target object, where the fourth target object is the object to be loaded when the third target object is the object to be displayed. After generating the second rendering instruction, the second coordinator sends the second rendering instruction to the rendering engine through a communication bridge.

[0124] The second coordinator refers to the logic control module that runs on the main execution thread or in a background thread (such as WebWorker) independent of the main execution thread. The second coordinator has the same function as the first coordinator, and can also schedule rendering tasks, prioritize them, and perform difference calculations. The second coordinator and the first coordinator form a master-slave dual-pipeline architecture. The fourth target object is the second target object corresponding to the previous operation or the previous moment (or the previous frame) of the first operation. Specifically, when responding to the previous operation of the first operation, the set of list items located within the buffer area calculated based on the current visible range is the fourth target object, which is the pre-loaded data set from the previous operation. The second rendering instruction refers to a sequence of commands output by the second coordinator to guide the graphics rendering engine to perform specific operations on view elements. The second rendering instruction is not limited to a full refresh, but includes node creation, node removal, node attribute updates, and node position changes, etc.

[0125] Regarding the specific implementation of calling the second coordinator to generate the second rendering instruction based on the second and fourth target objects: First, the second coordinator extracts the index set of the second target object and the index set of the fourth target object. The second coordinator can calculate the intersection of these two index sets: for list items that exist in both sets, a hold instruction or an update instruction is generated (hold if the data content remains unchanged, update the attribute if the content changes). For list items that exist in the fourth target object but not in the second target object, the second coordinator generates a remove instruction or a recycle instruction, which instructs the corresponding view component to be unbound from the rendering node tree. For list items that exist in the second target object but not in the fourth target object, the second coordinator generates a create instruction or a reuse instruction, which instructs the user to first obtain an idle view component from the reuse cache pool and populate it with new data; if no cache is available, a new component is created and mounted to the specified coordinate position.

[0126] In some embodiments, the process of generating the second rendering instruction also includes position correction logic. When it is detected that a list item has only shifted (e.g., the user is slowly swiping) and has not moved out of the viewport area, the second rendering instruction only includes parameters for modifying the view component's transformation matrix, utilizing GPU hardware acceleration to complete the shift without triggering expensive layout reflow operations. Furthermore, the second rendering instruction can also be packaged into a transaction to ensure that these changes are committed within the same vertical synchronization cycle.

[0127] For example, assuming the currently displayed (third target object) within the viewport area consists of four list items with indices [10, 11, 12, 13], then the list items outside the viewport area (fourth target object) have indices [14, 15, 16, 17] and [06, 07, 08, 09]. The user scrolls down, and according to step S101, the indices of the second target object to be loaded are [15, 16, 17, 18] and [07, 08, 09, 10]. The second coordinator performs a comparison: it finds that indices 15, 16, 17 and 07, 08, 09 exist in both, and only their position coordinates have shifted upwards, therefore a move instruction is generated; it finds that indices 14 and 06 belong to the fourth target object but not to the second target object, generating a recycling instruction to move the view components corresponding to indices 14 and 06 into the cache pool; it finds that indices 18 and 10 belong to the second target object but not to the fourth target object, generating a reuse and display instruction. This series of move, recycling, and reuse command sequences constitutes the second rendering instruction.

[0128] In some embodiments, step S103 can be implemented as follows: when the main execution thread has idle time after calling the first coordinator, during the idle time, the second coordinator located in the main execution thread is called to obtain the task to be processed corresponding to the first operation from the preset queue; the task to be processed is parsed to obtain the attribute parameters of the second target object; a second virtual node tree is generated according to the attribute parameters of the second target object; the second historical virtual node tree of the fourth target object is obtained; the second virtual node tree is compared with the second historical virtual node tree to obtain the second difference data; and a second rendering instruction is generated according to the second difference data.

[0129] As an example, firstly, the terminal detects the state of the main execution thread after calling the first coordinator. After the first coordinator completes the high-priority rendering tasks of the current frame (i.e., steps S1021 to S1024), the terminal detects the remaining time window of the current frame, or detects whether the message queue of the main execution thread is in a momentarily empty state, thereby determining whether the main execution thread has idle time. For example, if the total time taken for the first coordinator to complete all high-priority rendering tasks of the current frame is less than the duration of the device screen refresh cycle (e.g., less than 16.6ms), it can be considered that there is idle time. During this idle time, the terminal calls the second coordinator located in the main execution thread. The second coordinator accesses the preset queue and extracts the task to be processed at the head of the queue according to the first-in-first-out principle or a priority algorithm based on viewport distance.

[0130] The terminal reads the encapsulated data packet of the task object, performs deserialization on the encapsulated data packet, extracts the internal business data payload, and obtains the attribute parameters of the second target object. The terminal calls the second coordinator located in the main execution thread to generate a second virtual node tree based on the attribute parameters of the second target object. The attribute parameters contain all metadata that determines the final display form of the list items, such as the list item's index identifier, layout information (e.g., component type identifier, size constraint value, padding configuration, and coordinate position), and content information (e.g., text character sequence, image resource address, and dynamic status flags). The second coordinator uses preset component mapping rules to instantiate the above attribute parameters into corresponding lightweight data objects, and recursively constructs a second virtual node tree describing the UI structure of the current frame according to the list layout hierarchy. The second virtual node tree exists in memory as data.

[0131] The terminal invokes the second coordinator to obtain the second historical virtual node tree of the fourth target object. The fourth target object refers to the object to be loaded when the third target object is used as the object to be displayed. The terminal retrieves the virtual node tree generated for the fourth target object during the rendering of the previous frame, i.e., the second historical virtual node tree, from memory.

[0132] The terminal invokes the second coordinator, employing a tree-structured differential algorithm to perform hierarchical or same-level node traversal of the second virtual node tree and the second historical virtual node tree. This determines the node changes between the two virtual node trees, including node additions, deletions, moves, and changes to node attributes (such as text color and background image). These identified changes are encapsulated as second difference data.

[0133] The terminal invokes the second coordinator to convert the second difference data into atomic operation commands that the rendering engine can recognize. For example, if the difference data indicates that the text at a certain index position has changed, the second coordinator generates a corresponding update text command; if it indicates that a node position has shifted, the second coordinator generates an update coordinate command. This series of atomic operations combines to form the second rendering command.

[0134] By utilizing the idle time after the main execution thread calls the first coordinator, the second coordinator retrieves and parses the corresponding task to be processed from the preset queue, generates a new virtual node tree based on the attribute parameters of the second target object, compares it with the historical virtual node tree to obtain the difference data, and finally generates the second rendering instruction. This achieves asynchronous processing of the second target object during idle time, which not only makes full use of the idle resources of the main execution thread and avoids resource waste, but also does not block the core rendering process of the main execution thread, effectively improving the overall rendering performance and interaction smoothness of the list.

[0135] See Figure 9 , Figure 9 This is a schematic diagram of an optional implementation principle for generating a second rendering instruction provided in an embodiment of this application. During the idle time of the main execution thread, incremental preprocessing is performed on the rendering task. Specifically, the task to be processed is obtained from a preset queue, and then the attribute parameters of the second target object are parsed and generated through the second coordinator, and a second virtual node tree is constructed. Then, the second virtual node tree is compared with the second historical virtual node tree stored in memory using tree structure difference to obtain second difference data containing information such as node addition and node attribute changes. Finally, a second rendering instruction that can be directly used in the subsequent rendering process is generated.

[0136] In some embodiments, a preset queue can be obtained by encapsulating the attribute parameters of the second target object to obtain the task to be processed, and adding the task to be processed to a preset queue located in the main execution thread.

[0137] As an example, the terminal reads the attribute parameters of the second target object and encapsulates them. For instance, based on a predefined task template, the terminal creates a task container containing an execution context. The terminal fills the parsed attribute parameters into the data payload area of ​​the task container and sets the operation type identifier of the task container to obtain the task to be processed. The terminal identifies a preset queue located in the main execution thread. The main execution thread maintains a message queue for managing event distribution, which is responsible for storing UI update requests, input events, and callback tasks to be processed in sequence. The terminal adds the task to be processed to the preset queue.

[0138] By encapsulating the attribute parameters of the second target object into a task to be processed in the above manner, and adding the task to be processed to the preset queue of the main execution thread, the standardized storage and orderly scheduling of the processing tasks related to the second target object are realized. This avoids the pressure on the main execution thread caused by chaotic task execution and lays a solid foundation for the efficient and stable processing of subsequent tasks.

[0139] In some embodiments, step S103 above can also be implemented in the following way: when the main execution thread has no idle time after calling the first coordinator, the second coordinator is configured in the background execution thread; the main execution thread sends the attribute parameters of the second target object and the list identifier of the list to be rendered to the second coordinator in the background execution thread; the second coordinator located in the background execution thread is called to generate a second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object.

[0140] As an example, after completing the task of the first coordinator in the main execution thread, the terminal checks the remaining time slice of the current frame. Assume the preset rendering budget per frame is 16ms, and the main execution thread has already consumed 15ms. The remaining time is insufficient to support the subsequent calculation of the second coordinator (i.e., there is no idle time). To avoid blocking the main thread and causing frame drops, the terminal decides not to call the second coordinator in the main execution thread. The terminal creates a background execution thread and configures the second coordinator in the background execution thread. The terminal utilizes a multi-threaded concurrency mechanism to obtain an independent background execution thread from the thread pool. The terminal performs a task scheduling operation, encapsulating the second coordinator into an executable task unit and binding or assigning the second coordinator to the runtime environment of that background execution thread.

[0141] The terminal uses the cross-thread communication mechanism of the main execution thread (such as a message passing interface or a shared memory channel) to encapsulate the attribute parameters of the second target object and the list identifier of the list to be rendered, and obtains a message object. The main thread calls the sending interface to asynchronously send the message object to the message queue of the background execution thread for the second coordinator in the background to read.

[0142] The terminal invokes the second coordinator to parse the received message object, obtaining the attribute parameters and list identifier. Based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object, the second coordinator generates a second rendering instruction.

[0143] In some embodiments, the above-mentioned "calling the second coordinator located in the background execution thread to generate a second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object" can be implemented in the following way: calling the second coordinator to generate a second virtual node tree according to the attribute parameters of the second target object; obtaining the second historical virtual node tree of the fourth target object; comparing the second virtual node tree with the second historical virtual node tree to obtain second difference data; generating a second rendering instruction based on the second difference data; the second rendering instruction carries the list identifier.

[0144] As an example, the second coordinator, running in a background thread, instantiates the attribute parameters of the second target object into corresponding lightweight data objects using preset component mapping rules. Following the list layout hierarchy, it recursively constructs a second virtual node tree describing the UI structure of the current frame. The terminal retrieves the second historical virtual node tree generated for the fourth target object during the previous frame's rendering from memory and uses a tree-structured differential algorithm to perform hierarchical traversal or same-level node traversal of the second virtual node tree and the second historical virtual node tree, determining the node changes between the two virtual node trees. These identified node changes are encapsulated as second difference data. The terminal calls the second coordinator to convert the second difference data into atomic operation commands recognizable by the rendering engine. These atomic operation commands combine to form the second rendering instructions.

[0145] The second coordinator in the background execution thread first generates a second virtual node tree based on the attribute parameters of the second target object. Then, it compares the second virtual node tree of the fourth target object with the second historical virtual node tree to obtain the second difference data. Combined with the list identifier of the list to be rendered, it generates a second rendering instruction. This continues the efficient rendering logic of virtual node tree difference comparison, and only generates rendering instructions for the difference parts, ensuring the efficiency of the second rendering instruction generation.

[0146] By employing the above method, when the main execution thread has no idle time after calling the first coordinator, the second coordinator is configured to the background execution thread. The main execution thread passes the second target object attribute parameters and the list identifier to be rendered to the second coordinator in the background execution thread. Then, the second coordinator in the background execution thread combines the above parameters and the fourth target object to generate the second rendering instruction. This achieves precise cross-thread scheduling and efficient parameter transmission for the second coordinator task. It avoids the background task occupying the core resources of the main execution thread and blocking the core rendering process of the list. At the same time, it relies on the background execution thread to independently complete the generation of the second rendering instruction, ensuring the parallel progress of the core rendering and background instruction generation tasks. This effectively improves resource utilization and scheduling rationality, ensures the smoothness of the core rendering process of the list and the efficiency of subsequent loading of related instruction generation, and further optimizes the overall interactive experience of the list.

[0147] See Figure 10 , Figure 10 This is a schematic diagram of another optional implementation principle for generating the second rendering instruction provided in the embodiments of this application. The main execution thread first performs an idle time detection. If there is no idle time, it sends a message object containing the attribute parameters of the second target object and the identifier of the list to be rendered to the message queue. The background execution thread obtains the task from the message queue, combines it with the fourth target object in memory, and processes it through the second coordinator to finally generate the second rendering instruction (e.g., a JSON instruction package).

[0148] In some embodiments, if the second coordinator is configured in advance in the background execution thread, step S103 can also be implemented as follows: The main execution thread sends the attribute parameters of the second target object and the list identifier of the list to be rendered to the second coordinator in the background execution thread. The second coordinator in the background execution thread is invoked to generate a second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object.

[0149] By using the above method, a second coordinator is pre-configured in the background execution thread. The main execution thread passes the attribute parameters of the second target object and the list identifier of the list to be rendered to the second coordinator in the background execution thread. The second coordinator in the background then combines the above parameters and the fourth target object to generate the second rendering instruction. This achieves the pre-configuration of the second coordinator and the precise cross-thread transmission of core parameters, allowing the generation of the second rendering instruction to be completed independently in the background execution thread.

[0150] Step S104: Call the rendering engine to respond to the first rendering instruction to obtain the current view to be displayed in the viewport area, and call the rendering engine to respond to the second rendering instruction to obtain the view to be loaded, including the current view to be displayed.

[0151] Here, the view to be loaded is used to determine the target view to be displayed within the viewport area when the second operation is received. The second operation is an adjacent operation following the first operation.

[0152] In this embodiment of the application, the first rendering instruction has a higher priority than the second rendering instruction. The rendering engine is invoked to respond to the first rendering instruction with higher priority to obtain the current view to be displayed in the viewport area. The rendering engine is also invoked to respond to the second rendering instruction with lower priority to obtain the view to be loaded, which includes the current view to be displayed.

[0153] A rendering engine refers to the core graphics processing module in an electronic device's operating system or application framework. The rendering engine is responsible for parsing the rendering node tree, performing rasterization (converting abstract graphical descriptions into concrete screen pixels), and compositing graphical layers into pixel data in the framebuffer. The rendering engine can be a browser kernel based on Web technologies or the rendering pipeline of a native mobile UI framework. The currently displayed view refers to the pixel matrix or view hierarchy structure rendered by the GPU and about to be projected onto the screen viewport area; it is also the part that the user directly perceives at the current moment. The view to be loaded refers to a logical superset view, which, in its data structure, contains the currently displayed view and preparatory view elements located outside the viewport area. Although the non-visible parts of the view to be loaded have not yet completed final pixel rendering onto the screen, data binding, layout measurement, or resource decoding have been completed in memory. The second operation refers to the next user interaction event on the timeline immediately following the first operation.

[0154] As an example, for the first rendering instruction, the rendering engine performs the on-screen drawing normally. For the second rendering instruction, the rendering engine draws the list items in the buffer on independent off-screen or invisible hardware and stores them in GPU memory. When constructing the view to be loaded, a virtual large canvas coordinate system is established, and the real-time rendering results in the viewport are concatenated with the pre-rendered textures outside the viewport according to logical coordinates or index identifiers. At this time, the view to be loaded is not simply a collection of data, but a mixed layer tree that is partially rasterized and partially in texture state. When the second operation is received (such as the user continuing to swipe down), the layout and drawing process is not retried, but the transformation matrix of the compositing layer is directly modified to translate the pre-generated texture to the viewport area.

[0155] For example, the rendering engine receives a sequence of instructions for the first target object (indexes 11-14). The rendering engine first executes a move command, directly modifying the coordinate parameters of the layers corresponding to indices 11, 12, and 13 in video memory, shifting the Y-axis position on the screen upwards by 100 pixels respectively. The rendering engine then executes a reuse and display command for index 14, retrieving the node from the cache pool, binding the data (such as text and images) for index 14, and initiating rasterization to calculate the pixel color values ​​within the index 14 area. Index 14 is then drawn at the bottom of the screen viewport (i.e., below the original index 13). In other words, the screen (viewport area) now displays an image with indices [11, 12, 13, 14], which constitutes the "current view to be displayed." The rendering engine continues processing the sequence of instructions for the second target object (indexes 15-18 and 07-10). For indices 15, 16, 17 and 07, 08, 09, the rendering engine executes the movement logic, updating the coordinate information of indices 15, 16, 17 and 07, 08, 09 in the virtual layout structure in memory (although the user cannot see them immediately, the position logic has already aligned with the slide). For indices 18 (newly appearing in the lower buffer) and 10 (just slid out of the viewport and into the upper buffer), the rendering engine executes the "reuse and display" instruction. In particular, for index 18, the rendering engine performs layout calculations and texture rendering in off-screen memory in advance, generating bitmap data for index 18. At this point, the "indices currently displayed on the screen [11-14]" plus the "buffer indices [07-10] and [15-18] already prepared in memory" together form a broader "view to be loaded".

[0156] In some embodiments, see Figure 11 , Figure 11 This is a schematic diagram illustrating the implementation process of obtaining the current view to be displayed, provided in an embodiment of this application. Figure 11 The step S104, "calling the rendering engine to respond to the first rendering command and obtaining the current view to be displayed within the viewport area," can be achieved through the following steps S1041A to S1046A:

[0157] Step S1041A: Call the rendering engine to parse the first rendering instruction and obtain the list identifier, the index identifier of the first target object, and the first rendering parameters.

[0158] As an example, the terminal calls the rendering engine to parse the first rendering instruction. The first rendering instruction is deserialized, converting the binary or JSON format instruction into a memory-readable object structure, yielding a list identifier, an index identifier for the first target object, and first rendering parameters. The list identifier uniquely identifies the UI container to which the current operation belongs; the first rendering parameters contain the actual business data to be displayed for the list item, such as text content, image URLs, background color values, and font style configurations.

[0159] Step S1042A: In the rendering node tree of the currently displayed view, find the first list node corresponding to the list identifier.

[0160] As an example, the terminal invokes the rendering engine to search for the first list node corresponding to the list identifier in the rendering node tree of the currently displayed view. The rendering engine traverses the rendering node tree maintained in memory or searches through a pre-built hash index table. When a container node object with the list identifier is located, that container node object is identified as the first list node. The rendering node tree is a core data structure in the graphical user interface rendering process, used to describe the hierarchical relationship and drawing information of visual elements on the interface.

[0161] Step S1043A: Generate the first subview rendering object of the first target object according to the first rendering parameters.

[0162] As an example, the terminal invokes the rendering engine to generate a first subview rendering object of the first target object based on the first rendering parameters. Specifically, the rendering engine uses the style configuration, layout constraints, and business data contained in the first rendering parameters to assign attribute values ​​and instantiate the target view component. This transforms the abstract data description into a concrete, drawing-capable rendering node instance in memory (i.e., the first subview rendering object), which encapsulates the geometric position information and layer drawing instructions required for the final display.

[0163] In some embodiments, the first rendering instruction further includes a template type identifier for the first target object; step S1043 can also be implemented in the following ways: when there is an idle view object matching the template type identifier in the preset view reuse pool, the attribute data of the idle view object is updated according to the first rendering parameters to obtain the first subview rendering object. Alternatively, when there is no idle view object matching the template type identifier in the view reuse pool, a view object corresponding to the template type identifier is created; the attribute data of the created view object is initialized according to the first rendering parameters to obtain the first subview rendering object.

[0164] As an example, when generating the first subview rendering object of the first target object, if the first rendering instruction also includes a template type identifier for the first target object, the terminal calls the rendering engine to first check the preset view reuse pool. When there is an idle view object in the preset view reuse pool that matches the template type identifier, the rendering engine retrieves the idle object from the view reuse pool. The rendering engine updates the attribute data of the idle view object according to the first rendering parameters, replacing the display content of the old view with the new data, thereby obtaining the first subview rendering object. When there is no idle view object in the view reuse pool that matches the template type identifier (for example, the view reuse pool is empty, or the view of the corresponding type has not been created), the rendering engine reads the layout file corresponding to the template type identifier through the layout loader or executes the code construction logic to create a view object corresponding to the template type identifier. The rendering engine initializes the attribute data of the created view object according to the first rendering parameters, completes the initial binding of the view, and obtains the first subview rendering object.

[0165] Through the above implementation, when the first rendering instruction carries the template type identifier of the first target object, it prioritizes matching and reusing idle view objects from the preset view reuse pool. If no matching idle object is found, it creates a new view object and initializes the attribute data to obtain the first subview rendering object. This achieves view object reuse optimization and significantly reduces the performance overhead and resource consumption caused by frequently creating or destroying view objects.

[0166] In some embodiments, after initializing the attribute data of the created view object according to the first rendering parameters to obtain the first subview rendering object, the following can also be performed: when it is determined that the list item corresponding to the first subview rendering object is located outside the viewport area, the first subview rendering object is determined as a new idle view object; the new idle view object is mapped to the template type identifier of the first subview rendering object and then stored in the view reuse pool.

[0167] As an example, after the terminal calls the rendering engine to initialize the attribute data of the created view object according to the first rendering parameters and obtains the first subview rendering object, it can verify the position and state of the first subview rendering object. When it is determined that the list item corresponding to the first subview rendering object is outside the viewport area (for example, the first subview rendering object belongs to a pre-rendering task, or the user has quickly swiped past it during the generation process), it can be determined that the first subview rendering object does not need to be displayed at present. At this time, the rendering engine identifies the first subview rendering object as a new idle view object and resets its state. The rendering engine maps the new idle view object to the template type identifier of the first subview rendering object and stores it in the view reuse pool.

[0168] Through the above implementation, after creating a new view object and initializing the first subview rendering object, if the list item is located outside the viewport area, the first subview rendering object is identified as a new idle view object, and its template type identifier is mapped and stored in the view reuse pool. This achieves effective recycling and classified storage of idle view objects outside the viewport, continuously enriches the available resources of the view reuse pool, further improves the reuse rate of subsequent view objects, reduces unnecessary view creation operations, reduces performance overhead, and ensures the efficiency and smoothness of the list rendering process.

[0169] Step S1044A: Determine the first insertion position of the first subview rendering object in the first list node based on the index identifier of the first target object.

[0170] As an example, the terminal calls the rendering engine to obtain the set of indices of the currently mounted child view rendering objects in the first list node. The rendering engine sorts and compares the index of the first target object with the index set. According to the preset list sorting rules (such as sorting by index in ascending order), it finds the empty index that conforms to the logical order in the first child node list of the rendering node tree, or locates the sibling node with adjacent values ​​as a reference anchor point, thereby determining the relative position of the empty index or reference anchor point as the first insertion position.

[0171] Step S1045A: Insert the first subview rendering object into the first insertion position to obtain the second list node in the rendering node tree.

[0172] As an example, the terminal calls the rendering engine to insert the first subview rendering object into the first insertion position. The rendering engine calls the mutation interface of the first list node to mount the first subview rendering object onto the corresponding branch of the rendering node tree, resulting in the second list node in the rendering node tree. At this point, the rendering node tree structure has been updated, and the second list node is the updated state of the parent container node containing the newly inserted subview.

[0173] Step S1046A: Refresh the layout of the rendering node tree based on the second list node to obtain the current view to be displayed within the viewport area.

[0174] As an example, the terminal invokes the rendering engine to refresh the rendering node tree layout based on the second list node. Because the rendering node tree structure has changed, the rendering engine marks the second list node and its affected child nodes as "dirty." This can trigger a local or global layout traversal, remeasure the size of each node, and determine its final position in the screen coordinate system. The rendering engine submits the updated layout data to the graphics processing unit (GPU) for rasterization and compositing to obtain the current view to be displayed within the viewport area, allowing the user to see a seamlessly updated list interface on the screen.

[0175] Through steps S1041A to S1046A, the rendering engine is invoked to parse the first rendering instruction to obtain the list identifier, the first target object index identifier, and the first rendering parameters. First, the corresponding first list node is matched in the rendering node tree. Then, the first subview rendering object is generated based on the first rendering parameters. The insertion position in the first list node is determined by combining the index identifier and the insertion is completed to obtain the second list node. Finally, the rendering node tree layout is refreshed based on the second list node to generate the current view to be displayed in the viewport area. This realizes the positioning and insertion of the first target object subview in the rendering node tree, ensures the accuracy and orderliness of the list view layout refresh, improves the rendering efficiency and display effect of the list view in the viewport area, and provides users with a smooth list visual interaction experience.

[0176] In some embodiments, see Figure 12 , Figure 12 This is a schematic diagram illustrating the implementation process of obtaining the view to be loaded, provided in an embodiment of this application. Figure 12 Step S104 can be achieved through the following steps S1041B to S1046B:

[0177] Step S1041B: Call the rendering engine to parse the second rendering instruction and obtain the list identifier, the index identifier of the second target object, and the second rendering parameters.

[0178] Step S1042B: In the rendering node tree of the currently displayed view, find the second list node corresponding to the list identifier.

[0179] Step S1043B: Generate a second subview rendering object of the second target object based on the second rendering parameters.

[0180] Step S1044B: Determine the second insertion position of the second subview rendering object in the second list node based on the index identifier of the second target object.

[0181] Step S1045B: Insert the second subview rendering object into the second insertion position to obtain the third list node.

[0182] Step S1046B: Refresh the layout of the rendering node tree based on the third list node to obtain the view to be loaded.

[0183] It should be noted that the implementation of steps S1041B to S1046B can refer to the above steps S1041A to S1046A. The implementation details of steps S1041B to S1046B in this embodiment will not be repeated.

[0184] Through steps S1041B to S1046B, the rendering engine is invoked to parse the second rendering instruction to obtain the list identifier, the second target object index identifier, and the second rendering parameters. The corresponding second list node is matched in the rendering node tree, and a second subview rendering object is generated based on the second rendering parameters. The insertion position in the second list node is determined by combining the index identifier and the insertion is completed to obtain the third list node. Finally, the rendering node tree layout is refreshed based on the third list node to generate the view to be loaded. This realizes the positioning and insertion of the second target object subview in the rendering node tree, ensures the accuracy and orderliness of the layout refresh of the view to be loaded, completes the rendering processing of the view to be loaded in advance, and effectively improves the view loading speed and display smoothness during list scrolling interaction.

[0185] In this embodiment, in response to a first operation on the list to be rendered, a first target object to be displayed within the viewport area and a second target object to be loaded outside the viewport area are determined from the list. On one hand, a first rendering instruction is generated based on the first and third target objects by calling a first coordinator located in the main execution thread. On the other hand, a second rendering instruction is generated based on the second and fourth target objects by calling a second coordinator. Then, the rendering engine is invoked in response to the first rendering instruction to obtain the current view to be displayed within the viewport area, and then the rendering engine is invoked again in response to the second rendering instruction to obtain the view to be loaded, which includes the current view to be displayed. Thus, this embodiment of the application utilizes the division of labor and cooperation between the first coordinator and the second coordinator, enabling the main execution thread to focus on updating the core visible content within the viewport area. This reduces the computational load on the main thread, improves the rendering efficiency of the current viewport view, and ensures the immediacy and accuracy of the response in the user's visible area. Furthermore, by combining the rendering engine's responses to the first and second rendering instructions to obtain the current view to be displayed and the view to be loaded, the electronic device can promptly present the current view to be displayed corresponding to the first operation to the user. When receiving the second operation, it can also quickly determine the new target display content using the view to be loaded. This significantly improves the rendering efficiency and smoothness of the list during continuous interaction, enhancing the user's human-computer interaction experience.

[0186] In some embodiments, after step S101, the following may also be performed: First, in response to the second operation on the list to be rendered, a fifth target object to be displayed within the viewport area of ​​the electronic device is determined; then, if the fifth target object is the same object as the second target object being processed by the second coordinator, and a view to be loaded has been obtained, the current view to be displayed corresponding to the second operation is determined from the view to be loaded. If the fifth target object is the same object as the second target object being processed by the second coordinator, and a view to be loaded has not been obtained, the first coordinator is prohibited from processing the fifth target object, and the process waits for the view to be loaded containing the fifth target object to be obtained through the second coordinator; when the view to be loaded containing the fifth target object is obtained, the current view to be displayed corresponding to the second operation is determined from the view to be loaded.

[0187] As an example, when a user is quickly scrolling through a product list, a new product card, "Product E" (the fifth target object), is about to enter the visible area of ​​the screen (within the viewport). The terminal detects that the second coordinator in the background execution thread is preloading or calculating product data (the second target object). After comparison, it is found that "Product E" is the same object being processed in the background (i.e., they are the same object). If the terminal detects that the second coordinator has just completed the layout calculation and rendering instructions for "Product E" and has generated a usable view to be loaded, the terminal can extract this view from the output of the background execution thread, use the view corresponding to the second target object in this view as the current view to be displayed, and immediately mount it to the corresponding position on the screen, achieving seamless display without requiring any further calculations from the main thread. Alternatively, if the terminal detects that the second coordinator is calculating "Product E" but has not yet output the final result (no view to be loaded yet),... To avoid a double waste of resources caused by the main thread (first coordinator) also calculating "product E", the terminal activates a debouncing / deduplication strategy, which can prevent the main thread's first coordinator from processing "product E". At this time, a lightweight placeholder can be temporarily displayed on the screen at the corresponding position. The terminal waits for the second coordinator to obtain the view containing the fifth target object to be loaded. Once the second coordinator completes the calculation of "product E" and generates the view to be loaded, the terminal uses the view corresponding to the second target object in that view as the current view to be displayed and immediately mounts it to the corresponding position on the screen.

[0188] By responding to the second operation of the list to be rendered and determining the fifth target object to be displayed within the viewport area, differentiated processing is performed for scenarios where the fifth target object and the second target object being processed by the second coordinator are the same object: if a view to be loaded has been generated, the corresponding current view to be displayed is directly determined from it; if a view to be loaded has not been generated, the first coordinator is prohibited from being called for repeated processing, and the process waits for the second coordinator to generate a view to be loaded before determining the current view to be displayed from it. This effectively avoids repeated rendering processing of the same target object, reduces the ineffective consumption of resources and the processing pressure on the main execution thread, and at the same time ensures the uniqueness and accuracy of view generation by waiting for the background processing flow, eliminating rendering conflicts caused by repeated processing, and further improving the rendering processing efficiency and the smoothness and stability of view display during list interaction.

[0189] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0190] In cross-platform application development, the framework provided in this application embodiment can adopt a "single coordinator" architecture to manage UI state and rendering. When the UI state changes (e.g., when a user scrolls through a list), the framework generates a new virtual DOM tree, and the new and old virtual DOM trees are compared by a single coordinator running on the main JS thread (i.e., the "single coordinator") to find the differences. Then, based on the differences, a minimal set of update instructions is generated. These instructions in the update instruction set are serialized and then centrally delivered to the native rendering layer for execution via a communication bridge.

[0191] When dealing with long lists (such as large tables or news feeds), a large number of new list items enter the viewport as the user scrolls rapidly. The single coordinator must complete the creation, comparison, and generation of rendering instructions for these new list items within a very short time (e.g., within 8ms).

[0192] The alternative dual-coordinator architecture provided in this application can resolve computational storms by offloading the diff calculation tasks of preloaded items to the secondary coordinator, reducing the instantaneous computational pressure on the primary coordinator. It can also streamline communication channels, offloading rendering instructions at the source. The primary coordinator (i.e., the first coordinator) generates only a small number of high-priority rendering instructions (i.e., the first target object), ensuring the smooth operation of the primary communication channel. The rendering instructions generated by the secondary coordinator (i.e., the second coordinator) can be sent through different methods (concurrent scheduling, independent threads, or other methods), avoiding competition with high-priority instructions. Furthermore, it reduces the parsing burden on the Flutter native layer. Because the peak instruction size of the primary channel is lower, and the viewport area is rendered first, the Flutter native layer can receive, parse, and render the most important content faster, thereby eliminating white screens and improving scrolling smoothness and responsiveness.

[0193] This application embodiment introduces a dedicated "secondary coordinator" to share the computational burden of the primary coordinator and separate the rendering load of React-Flutter long list components, thereby solving the performance bottleneck of long lists when scrolling quickly.

[0194] The embodiments of this application have the following features: dual coordinator architecture, dynamic task allocation, asynchronous merging of rendering results, and two flexible implementation methods.

[0195] Regarding the dual-coordinator architecture, this embodiment of the application instantiates a dedicated secondary coordinator on top of the single coordinator. The primary coordinator focuses on rendering the list items already visible on the screen, ensuring the smoothness of core interactions; while the secondary coordinator is responsible for "pre-rendering" the preloaded items (i.e., the second target object) that are about to enter the viewport, that is, completing the calculation of the virtual DOM (i.e., the second virtual node tree) in advance.

[0196] Regarding dynamic task allocation, this embodiment dynamically allocates the rendering tasks of list items to the primary coordinator or the secondary coordinator based on the scrolling state of the list. List items within the viewport (i.e., the first target object) are allocated to the primary coordinator, while preloaded items outside the viewport (i.e., the second target object) are allocated to the secondary coordinator.

[0197] Regarding the asynchronous merging of rendering results, the two coordinators in this embodiment work independently and generate their own UI update instructions. These UI update instructions are associated through a shared parent node identifier (i.e., list identifier). After receiving the two sets of UI update instructions, the native rendering layer (i.e., the rendering engine) can correctly merge the rendered visible items and preloaded items into the same parent node in the UI tree according to this parent node identifier, ultimately presenting a unified and complete view (i.e., the view to be loaded).

[0198] Regarding the two flexible implementation methods, the single-threaded concurrent scheduling of this application embodiment can utilize a task queue (i.e., a preset queue) and scheduling strategy within the main JS thread (i.e., the main execution thread) to divide the computational tasks of the secondary coordinator into multiple smaller tasks, which are then interspersed with the idle periods of the main coordinator tasks, avoiding prolonged blocking of the UI thread. The multi-threaded parallel computing of this application embodiment can place the secondary coordinator and its computational tasks entirely within an independent WebWorker thread (a background JS thread, i.e., a background execution thread), achieving true parallel computing and minimizing interference with the main JS thread.

[0199] See Figure 13 , Figure 13 This is a schematic diagram of the card view list architecture provided in an embodiment of this application, such as... Figure 13 As shown, in the project management smart sheet, a card layout can be used to encapsulate each task (such as "confirm customer requirements" and "feasibility analysis") into an independent card list item 1301.

[0200] See Figure 14 , Figure 14 This is a schematic diagram of the architecture of the table view list provided in the embodiments of this application, such as... Figure 14 As shown, in the project management smart table, a tabular layout can be used to encapsulate each task (such as "confirm customer requirements" and "feasibility analysis") into an independent table list item 1401.

[0201] See Figure 15 , Figure 15 This is a schematic diagram of the dual coordinator architecture provided in this application embodiment. In the JS execution environment, when the user interface state changes, the task allocator 1501 intelligently distributes rendering tasks (visible items and preloaded items) to the main coordinator 1502 and the list item coordinator 1503. After the two coordinators perform concurrent or parallel calculations, the main coordinator 1502 generates a main user interface update instruction (i.e., the first rendering instruction), and the list item coordinator 1503 generates a secondary user interface update instruction (i.e., the second rendering instruction). The main user interface update instruction is sent to the native rendering layer 1505 through the main communication channel of the communication bridge 1504, and the secondary user interface update instruction is sent to the native rendering layer 1505 through the secondary communication channel / low-priority queue of the communication bridge 1504. If there is only one channel in the communication bridge 1504, the main user interface update instruction and the secondary user interface update instruction are sent to the native rendering layer 1505 according to the priority of the instructions. Finally, the native rendering layer 1505 merges the main user interface update instructions and the secondary user interface update instructions based on the shared parent node identifier (ID), and renders the corresponding content of the main user interface update instructions and the secondary user interface update instructions onto the screen.

[0202] See Figure 16 , Figure 16 This is a flowchart illustrating the single-threaded concurrent scheduling provided in an embodiment of this application:

[0203] Step S1601: The main JS thread responds to the scroll event and calculates the visible items and preloaded items.

[0204] When a scroll event occurs, the Flutter native layer accumulates the offset pixels generated by the scrolling to obtain the pixel offset. This pixel offset is then divided by the pixel height of each list item to determine the number of scrolled list items. Based on the number of scrolled list items, the index a1 of the first visible list item after scrolling can be determined. Next, the screen width and height are divided by the list item height to obtain the number m of list items that the current electronic device's viewport area can accommodate. At this point, the index a2 of the last visible list item after scrolling is a1 + m. Finally, the indices a1 and a2 of the first and last visible list items after scrolling are sent together to the main JS thread. The main JS thread determines which list items are currently visible (assigned high priority) and which are preloaded items within the preload range (assigned low priority) based on the list item indices. (For example, there are 100 items in total, each with a unique number and an ordered index, such as 1-100. The current viewport can display 10 items (index 1-10). When scrolling forward 2 items, the visible items are the list items with index 3-12, and the preloaded items are the list items with index 13-22. The preloaded items can also be in multiple groups, such as the preloaded items with index 13-22 and 23-32, etc.)

[0205] In step S1602, the main JS thread calls the main coordinator to process visible items.

[0206] The main coordinator immediately processes visible items, quickly completes virtual DOM calculations to generate a new virtual DOM, compares the new virtual DOM with the previous virtual DOM generated by the main coordinator, and determines the differences. Based on these differences, rendering instructions for the visible items are generated.

[0207] In step S1603, the main JS thread sends rendering instructions for visible items to the Flutter native layer through the communication bridge.

[0208] The main JS thread sends rendering instructions for visible items to the Flutter native layer via a communication bridge, thus ensuring that the content within the viewport is updated as quickly as possible.

[0209] In step S1604, the main JS thread adds the preloaded item task to the low priority queue.

[0210] The rendering tasks for preloaded items are encapsulated and added to a low-priority task queue that runs on the main JS thread (e.g., using the PQueue library). These low-priority tasks are not executed immediately, thus avoiding blocking high-priority tasks.

[0211] When the main thread is idle, in step S1605, the main JS thread retrieves a task from the queue and calls the secondary coordinator to perform the calculation.

[0212] The main JavaScript thread utilizes its event loop mechanism to perform "sliced" computations on preloaded tasks (i.e., pending tasks) during idle time slices (when the main JavaScript thread is idle) after completing high-priority tasks (such as rendering and user interaction responses). This allows the secondary coordinator to complete virtual DOM computation within these time slices (i.e., idle time), generating a new virtual DOM (i.e., the second virtual node tree). The new virtual DOM is then compared with the previous virtual DOM generated by the secondary coordinator (i.e., the second historical virtual node tree), identifying differences (i.e., the second difference data). Based on these differences, rendering instructions for the preloaded items are generated.

[0213] In step S1606, the main JS thread sends rendering instructions for the preloaded items to the Flutter native layer through the communication bridge.

[0214] The rendering instructions generated by the coordinator are also sent to the Flutter native layer via the communication bridge.

[0215] Step S1607: The Flutter native layer merges and renders based on the shared ID.

[0216] The Flutter native layer receives two sets of instruction streams from the primary and secondary coordinators. Based on the shared parent node ID and the index of the list item, it seamlessly merges the rendered visible items and preloaded items into the correct position in the UI tree, and finally completes the rendering. (It should be noted that when the Flutter native layer receives the rendering instruction from the primary coordinator, the Flutter native layer directly renders the UI of the primary coordinator's visible items first.)

[0217] See Figure 17 , Figure 17 This is a flowchart illustrating multi-threaded parallel computing provided in an embodiment of this application:

[0218] In step S1701, the main JS thread responds to the scroll event trigger by calculating the visible items and preloaded items.

[0219] When a scroll event occurs, the Flutter native layer accumulates the pixels generated by the scrolling to obtain the pixel offset. The pixel offset is divided by the pixel height of each list item to determine the number of list items scrolling. The number of list items is then sent to the main JS thread. The main JS thread determines which list items are currently visible and which are preloaded items (which can also be regarded as preloaded items that are about to enter the viewport) based on the index of the list items and the number of list items.

[0220] In step S1702, the main JS thread sends preloaded item data to the background JS thread through the postMessage interface.

[0221] The main JS thread sends the data required by the preloaded item (such as index (i.e., index identifier), component type, etc.) along with a shared parent node ID to a pre-created or dynamically created background JS thread (WebWorker) through the postMessage interface.

[0222] In step S1703, the main JS thread sends rendering instructions for visible items to the Flutter native layer through the communication bridge.

[0223] The main coordinator processes visible items in the main JS thread and immediately sends the rendering instructions for the visible items to the Flutter native layer via the communication bridge.

[0224] In step S1704, the background JS thread runs the coordinator to calculate the differences and generate rendering instructions for the preloaded items.

[0225] After receiving the data, the background JavaScript thread runs the secondary coordinator in an environment completely independent of the main JavaScript thread. The secondary coordinator completes the creation, comparison, and generation of rendering instructions for the preloaded items, and this process does not block the main JavaScript thread in any way.

[0226] In step S1705, the background JS thread sends rendering instructions for the preloaded items to the Flutter native layer through the communication bridge.

[0227] After the background JS thread completes its calculations, it sends the generated rendering instructions to the Flutter native layer via a communication bridge.

[0228] In step S1706, the Flutter native layer performs merged rendering based on the two sets of received instructions and the shared parent node identifier.

[0229] The Flutter native layer eventually receives two sets of instructions from the main JS thread and the background JS thread, and merges the rendered visible items and preloaded items based on the shared parent node ID, ultimately rendering a complete UI view.

[0230] The beneficial effects of this application's embodiments include: significantly improving scrolling smoothness. By offloading computation and communication, it ensures that rendering instructions for visible items can reach the Flutter native layer with low latency and be processed preferentially by the Flutter native layer, fundamentally solving the problem of long scrolling time causing blank screens. It also reduces communication and parsing overhead. This application's embodiments offload rendering instructions, avoiding congestion on a single communication channel and centralized JSON parsing pressure on the Flutter native layer, thus improving the efficiency of the entire rendering chain. Furthermore, it enhances the user experience, providing users with a smooth and fluid scrolling experience like native applications, significantly improving application response speed and overall quality. Moreover, the architecture is flexible and non-intrusive to business logic. This application's embodiments provide both single-threaded and multi-threaded implementations, which can be selected as needed. This application's embodiments are implemented at the framework layer; business developers only need simple configuration to enable it without modifying business logic.

[0231] The following description continues to illustrate the exemplary structure of the list rendering apparatus 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the list rendering device 455 in the memory 450 may include: a determination module 4551, configured to determine, in response to a first operation on the list to be rendered, a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area; both the first target object and the second target object are list items in the list to be rendered; a first generation module 4552, configured to invoke a first coordinator located in the main execution thread to generate a first rendering instruction based on the first target object and a third target object currently displayed within the viewport area; a second generation module 4553, configured to invoke a second coordinator to generate a second rendering instruction based on the second target object and a fourth target object; the fourth target object is the object to be loaded when the third target object is the object to be displayed; and a rendering module 4554, configured to invoke a rendering engine in response to the first rendering instruction to obtain the current view to be displayed within the viewport area, and to invoke the rendering engine in response to the second rendering instruction to obtain a view to be loaded including the current view to be displayed; the view to be loaded is used to determine the target view to be displayed within the viewport area upon receiving a second operation, the second operation being an adjacent operation following the first operation.

[0232] In some embodiments, the determining module 4551 is further configured to, in response to a first operation on the list to be rendered, obtain a pixel offset generated by the first operation; the pixel offset is a pixel value representing the offset of the currently displayed view currently displayed in the viewport area in the movement direction corresponding to the first operation; calculate the number of list items based on the pixel offset and the table parameters of the list items to obtain a target number; and determine the first target object to be displayed and the second target object to be loaded from the list to be rendered according to the target number and the index identifier of the list items.

[0233] In some embodiments, the determining module 4551 is further configured to: when the table parameters of each list item in the list to be rendered are the same, divide the pixel offset by the table parameters to obtain the target quantity; when the table parameters of at least one list item in the list to be rendered are different from the table parameters of other list items, obtain the first index identifier of the last list item in the current display view located in the movement direction corresponding to the first operation; using the first index identifier as the starting identifier, obtain the table parameters of each list item in the movement direction one by one according to the preset index identifier order and accumulate them to obtain an accumulated value; when the accumulated value matches the pixel offset, determine the number of accumulated list items as the target quantity.

[0234] In some embodiments, the determining module 4551 is further configured to: determine a first index identifier of the last list item and a second index identifier of the first list item in the current display view; determine a removed list item and a moved-in list item from the list to be rendered based on the index identifier order, the target quantity, the first index identifier, and the second index identifier; determine the remaining list items after the removed list items are removed from the viewport area, as well as the moved-in list item, as the first target object; determine the target position of the first target object in the list to be rendered based on the index identifier order and the index identifier of the first target object; and determine a preset number of list items in the list to be rendered located in at least one target direction at the target position as the second target object.

[0235] In some embodiments, the first generation module 4552 is further configured to call a first coordinator located in the main execution thread to generate a first virtual node tree based on the attribute parameters of the first target object; obtain a first historical virtual node tree of the third target object currently displayed in the viewport area; compare the first virtual node tree with the first historical virtual node tree to obtain first difference data; and generate the first rendering instruction based on the first difference data.

[0236] In some embodiments, the second generation module 4553 is further configured to, when the main execution thread has idle time after calling the first coordinator, call the second coordinator located in the main execution thread during the idle time to obtain the task to be processed corresponding to the first operation from a preset queue; parse the task to be processed to obtain the attribute parameters of the second target object; generate a second virtual node tree according to the attribute parameters of the second target object; obtain the second historical virtual node tree of the fourth target object; compare the second virtual node tree with the second historical virtual node tree to obtain second difference data; and generate the second rendering instruction according to the second difference data.

[0237] In some embodiments, the second generation module 4553 is further configured to encapsulate the attribute parameters of the second target object to obtain the task to be processed; and add the task to be processed to the preset queue located in the main execution thread.

[0238] In some embodiments, the second generation module 4553 is further configured to configure the second coordinator in the background execution thread when the main execution thread has no idle time after calling the first coordinator; send the attribute parameters of the second target object and the list identifier of the list to be rendered to the second coordinator in the background execution thread through the main execution thread; and call the second coordinator located in the background execution thread to generate the second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object.

[0239] In some embodiments, the second generation module 4553 is further configured to call the second coordinator to generate a second virtual node tree based on the attribute parameters of the second target object; obtain the second historical virtual node tree of the fourth target object; compare the second virtual node tree with the second historical virtual node tree to obtain second difference data; generate the second rendering instruction based on the second difference data; and the second rendering instruction carries the list identifier.

[0240] In some embodiments, the first rendering instruction carries a list identifier of the list to be rendered. The rendering module 4554 is further configured to call the rendering engine to parse the first rendering instruction to obtain the list identifier, the index identifier of the first target object, and the first rendering parameters; search for a first list node corresponding to the list identifier in the rendering node tree of the current display view; generate a first subview rendering object of the first target object according to the first rendering parameters; determine the first insertion position of the first subview rendering object in the first list node according to the index identifier of the first target object; insert the first subview rendering object into the first insertion position to obtain a second list node located in the rendering node tree; and refresh the layout of the rendering node tree according to the second list node to obtain the current view to be displayed in the viewport area.

[0241] In some embodiments, the first rendering instruction further includes a template type identifier of the first target object; the rendering module 4554 is further configured to, when there is an idle view object in the preset view reuse pool that matches the template type identifier, update the attribute data of the idle view object according to the first rendering parameters to obtain the first sub-view rendering object; when there is no idle view object in the view reuse pool that matches the template type identifier, create a view object corresponding to the template type identifier; initialize the attribute data of the created view object according to the first rendering parameters to obtain the first sub-view rendering object.

[0242] In some embodiments, the rendering module 4554 is further configured to, when it is determined that the list item corresponding to the first subview rendering object is located outside the viewport area, determine the first subview rendering object as a new idle view object; and store the new idle view object in the view reuse pool after mapping it with the template type identifier of the first subview rendering object.

[0243] In some embodiments, the rendering module 4554 is further configured to: invoke the rendering engine to parse the second rendering instruction to obtain the list identifier, the index identifier of the second target object, and the second rendering parameters; search for the second list node corresponding to the list identifier in the rendering node tree of the currently displayed view; generate a second subview rendering object of the second target object according to the second rendering parameters; determine the second insertion position of the second subview rendering object in the second list node according to the index identifier of the second target object; insert the second subview rendering object into the second insertion position to obtain a third list node; and refresh the layout of the rendering node tree according to the third list node to obtain the view to be loaded.

[0244] In some embodiments, the determining module 4551 is further configured to, in response to a second operation on the list to be rendered, determine a fifth target object to be displayed within the viewport area of ​​the electronic device; if the fifth target object is the same object as the second target object being processed by the second coordinator, and if the view to be loaded has been obtained, determine the current view to be displayed corresponding to the second operation from the view to be loaded; if the view to be loaded has not been obtained, prohibit the first coordinator from processing the fifth target object, and wait for the view to be loaded containing the fifth target object to be obtained through the second coordinator; when the view to be loaded containing the fifth target object is obtained, determine the current view to be displayed corresponding to the second operation from the view to be loaded.

[0245] This application provides a computer program product including a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the list rendering method described above in this application.

[0246] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the list rendering method provided in this application. For example, ... Figure 4 The list rendering method is shown.

[0247] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0248] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0249] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0250] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0251] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A list rendering method, characterized in that, The method includes: In response to a first operation on the list to be rendered, a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area are determined; both the first target object and the second target object are list items in the list to be rendered. The first coordinator located in the main execution thread is invoked to generate a first rendering instruction based on the first target object and the third target object currently displayed in the viewport area; The second coordinator is invoked to generate a second rendering instruction based on the second target object and the fourth target object; the fourth target object is the object to be loaded when the third target object is the object to be displayed. The rendering engine is invoked in response to the first rendering instruction to obtain the current view to be displayed within the viewport area, and the rendering engine is invoked in response to the second rendering instruction to obtain a view to be loaded including the current view to be displayed; the view to be loaded is used to determine the target view to be displayed within the viewport area when a second operation is received, the second operation being an adjacent operation following the first operation.

2. The method according to claim 1, characterized in that, The step of responding to a first operation on a list to be rendered, determining a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area, includes: In response to a first operation on the list to be rendered, a pixel offset generated by the first operation is obtained; the pixel offset is the pixel value of the offset of the currently displayed view in the viewport area in the movement direction corresponding to the first operation. The number of list items is calculated based on the pixel offset and the table parameters of the list items to obtain the target number; Based on the target quantity and the index identifier of the list item, the first target object to be displayed and the second target object to be loaded are determined from the list to be rendered.

3. The method according to claim 2, characterized in that, The calculation of the number of list items based on the pixel offset and the table parameters of the list items to obtain the target number includes: When the table parameters of each list item in the list to be rendered are the same, the target quantity is obtained by dividing the pixel offset by the table parameters. When at least one list item in the list to be rendered has a table parameter that is different from the table parameters of other list items, obtain the first index identifier of the last list item in the current display view located in the movement direction corresponding to the first operation. Using the first index identifier as the starting identifier, the table parameters of each list item in the moving direction are obtained one by one in the preset index identifier order and accumulated to obtain the accumulated value; When the accumulated value matches the pixel offset, the number of accumulated list items is determined as the target number.

4. The method according to claim 3, characterized in that, The step of determining the first target object to be displayed and the second target object to be loaded from the list to be rendered based on the target quantity and the index identifier of the list item includes: Determine the first index identifier of the last list item and the second index identifier of the first list item in the current display view; Based on the index identifier order, the target quantity, the first index identifier, and the second index identifier, determine the items to be removed from the list to be rendered and the items to be removed from the list; The remaining list items after the removed list items are removed from the viewport area, along with the moved-in list items, are determined as the first target object; Based on the index identifier order and the index identifier of the first target object, the target position of the first target object in the list to be rendered is determined; A predetermined number of list items in the list to be rendered, located in at least one target direction at the target position, are determined as the second target object.

5. The method according to claim 1, characterized in that, The invocation of the first coordinator located in the main execution thread generates a first rendering instruction based on the first target object and the third target object currently displayed within the viewport area, including: The first coordinator located in the main execution thread is invoked to generate the first virtual node tree based on the attribute parameters of the first target object; Obtain the first historical virtual node tree of the third target object currently displayed within the viewport area; The first virtual node tree is compared with the first historical virtual node tree to obtain the first difference data; The first rendering instruction is generated based on the first difference data.

6. The method according to claim 1, characterized in that, The invocation of the second coordinator to generate a second rendering instruction based on the second target object and the fourth target object includes: When the main execution thread has idle time after calling the first coordinator, during the idle time, it calls the second coordinator located in the main execution thread to obtain the task to be processed corresponding to the first operation from the preset queue. The task to be processed is parsed to obtain the attribute parameters of the second target object; A second virtual node tree is generated based on the attribute parameters of the second target object; Obtain the second historical virtual node tree of the fourth target object; The second virtual node tree is compared with the second historical virtual node tree to obtain the second difference data; The second rendering instruction is generated based on the second difference data.

7. The method according to claim 6, characterized in that, When the main execution thread has idle time after calling the first coordinator, before calling the second coordinator located in the main execution thread during the idle time to retrieve the task to be processed corresponding to the first operation from the preset queue, the method further includes: The attribute parameters of the second target object are encapsulated to obtain the task to be processed; The task to be processed is added to the preset queue located in the main execution thread.

8. The method according to claim 1, characterized in that, The invocation of the second coordinator to generate a second rendering instruction based on the second target object and the fourth target object includes: When the main execution thread has no idle time after calling the first coordinator, the second coordinator is configured into the background execution thread; The main execution thread sends the attribute parameters of the second target object and the list identifier of the list to be rendered to the second coordinator in the background execution thread. The second coordinator, located in the background execution thread, is invoked to generate the second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object.

9. The method according to claim 8, characterized in that, The invocation of the second coordinator, located in the background execution thread, generates the second rendering instruction based on the attribute parameters of the second target object, the list identifier of the list to be rendered, and the fourth target object, including: The second coordinator is invoked to generate a second virtual node tree based on the attribute parameters of the second target object; Obtain the second historical virtual node tree of the fourth target object; The second virtual node tree is compared with the second historical virtual node tree to obtain the second difference data; Based on the second difference data, the second rendering instruction is generated; the second rendering instruction carries the list identifier.

10. The method according to any one of claims 1 to 9, characterized in that, The first rendering instruction carries a list identifier of the list to be rendered. The step of calling the rendering engine in response to the first rendering instruction to obtain the current view to be displayed within the viewport area includes: The rendering engine is invoked to parse the first rendering instruction to obtain the list identifier, the index identifier of the first target object, and the first rendering parameters; In the rendering node tree of the currently displayed view, find the first list node corresponding to the list identifier; Generate a first sub-view rendering object of the first target object based on the first rendering parameters; Based on the index identifier of the first target object, determine the first insertion position of the first subview rendering object in the first list node; Insert the first subview rendering object into the first insertion position to obtain the second list node in the rendering node tree; The layout of the rendering node tree is refreshed based on the second list node to obtain the current view to be displayed within the viewport area.

11. The method according to claim 10, characterized in that, The first rendering instruction also includes a template type identifier for the first target object; The step of generating a first subview rendering object of the first target object based on the first rendering parameters includes: When there is an idle view object in the preset view reuse pool that matches the template type identifier, the attribute data of the idle view object is updated according to the first rendering parameters to obtain the first sub-view rendering object; When there is no idle view object matching the template type identifier in the view reuse pool, a view object corresponding to the template type identifier is created; The attribute data of the created view object is initialized according to the first rendering parameters to obtain the first sub-view rendering object.

12. The method according to claim 11, characterized in that, After initializing the attribute data of the created view object according to the first rendering parameters to obtain the first subview rendering object, the process includes: When it is determined that the list item corresponding to the first subview rendering object is outside the viewport area, the first subview rendering object is determined as a new idle view object; The new idle view object is mapped to the template type identifier of the first subview rendering object and then stored in the view reuse pool.

13. The method according to claim 10, characterized in that, The second rendering instruction carries a list identifier of the list to be rendered. The step of calling the rendering engine in response to the second rendering instruction to obtain a view to be loaded, including the currently displayed view, includes: The rendering engine is invoked to parse the second rendering instruction, thereby obtaining the list identifier, the index identifier of the second target object, and the second rendering parameters; In the rendering node tree of the currently displayed view, find the second list node corresponding to the list identifier; Generate a second subview rendering object of the second target object based on the second rendering parameters; Based on the index identifier of the second target object, determine the second insertion position of the second subview rendering object in the second list node; Insert the second subview rendering object into the second insertion position to obtain the third list node; The layout of the rendering node tree is refreshed based on the third list node to obtain the view to be loaded.

14. The method according to any one of claims 1 to 9, characterized in that, After determining a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area in response to a first operation on the list to be rendered, the method further includes: In response to a second operation on the list to be rendered, a fifth target object to be displayed within the viewport area of ​​the electronic device is determined; If the fifth target object is the same object as the second target object being processed by the second coordinator. When the view to be loaded has been obtained, determine the current view to be displayed corresponding to the second operation from the view to be loaded; When the view to be loaded is not obtained, the first coordinator is prohibited from processing the fifth target object, and the process waits for the second coordinator to obtain the view to be loaded containing the fifth target object. When a view containing the fifth target object is obtained, the current view to be displayed corresponding to the second operation is determined from the view to be loaded.

15. A list rendering apparatus, characterized in that, The device includes: A determination module is configured to, in response to a first operation on a list to be rendered, determine a first target object to be displayed within the viewport area of ​​the electronic device and a second target object to be loaded outside the viewport area; both the first target object and the second target object are list items in the list to be rendered. The first generation module is used to call the first coordinator located in the main execution thread to generate a first rendering instruction based on the first target object and the third target object currently displayed in the viewport area; The second generation module is used to call the second coordinator to generate a second rendering instruction based on the second target object and the fourth target object; the fourth target object is the object to be loaded when the third target object is the object to be displayed. The rendering module is used to call the rendering engine in response to the first rendering instruction to obtain the current view to be displayed in the viewport area, and to call the rendering engine in response to the second rendering instruction to obtain a view to be loaded including the current view to be displayed; the view to be loaded is used to determine the target view to be displayed in the viewport area when a second operation is received, the second operation being an adjacent operation following the first operation.

16. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the list rendering method according to any one of claims 1 to 14.

17. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the list rendering method according to any one of claims 1 to 14 is implemented.

18. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the list rendering method according to any one of claims 1 to 14 is implemented.

Images