LiveData-based list local refreshing method and device
Through the combination of LiveData and Lifecycle components, the local refresh process of RecyclerView is optimized, and only visible entry data is identified and updated, solving the problems of inefficient rendering and invalid rendering of complex lists, achieving more efficient rendering and lower complexity Service access.
Patent Information
- Application Number
- CN202411166529.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-23
- Publication Date
- 2024-12-17
AI Technical Summary
RecyclerView has problems with low rendering efficiency and high service access complexity in complex list scenarios, especially the native local refresh mechanism fails to effectively avoid invalid rendering when the entry is invisible.
LiveData is used to wrap the business data corresponding to multiple entries in the page and bind them to the page rendering module. By identifying the changed entries and change fields, we can determine whether the display status meets the update conditions. The page is updated only when it is visible. diffUtil and Lifecycle components optimize the local refresh process.
Improve the rendering efficiency of the list, reduce the complexity of business access, avoid invalid rendering when the entry is invisible, and improve user experience and performance.
Smart Images

Figure CN119149006A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of software development, and in particular to a method and device for partially refreshing a list based on LiveData. Background Art
[0002] RecyclerView is a UI component on the Android platform for displaying and managing large or dynamic list data. It is widely used in various Android applications and has become the main choice for displaying lists, grids, and other dynamic content.
[0003] RecyclerView supports global and specified range refresh. Global refresh has the worst performance. Even if most of the screen has not changed, all items and internal elements will be re-rendered. Specified range refresh avoids re-refreshing all items, but all elements in the items still need to be rendered. In complex list scenarios, each element may change at any time (such as the number of unread items in the example). The existing solution has the problem of low rendering efficiency, so the local refresh solution came into being.
[0004] RecyclerView's native partial refresh solution needs to analyze which field has changed when the data changes, and save it in a difference data packet. The rendering module analyzes the difference data packet and performs a corresponding partial refresh. There is no universal solution for the above data analysis, data transmission, and view rendering process, which easily leads to problems such as complex processes, difficult maintenance, and difficult expansion.
[0005] RecyclerView has no awareness of item visibility, which means that even if an item is not visible, it may still be rendered, resulting in unnecessary performance loss. While mobile applications provide users with a convenient interactive experience, they also introduce complex page switching and component reuse scenarios to development. These scenarios are directly related to the performance, resource utilization efficiency, and user experience of the application. The refresh mechanism of the native RecyclerView does not take into account the issue of item visibility, and needs to be processed at the business layer to avoid invalid rendering. Summary of the invention
[0006] In order to solve the problems not studied in the prior art, the embodiments of this specification provide a method and device for partial refresh of a list based on LiveData. The method includes: using LiveData to package the business data corresponding to multiple items in a page to form packaged item data; binding the item data to a page rendering module, wherein the page rendering module includes a life cycle component corresponding to the item; identifying the item that has changed in the item data, and determining the position of the item that has changed in the page; according to the position, determining the changed field in the item that has changed; judging whether the display status of the item meets the update condition, and if so, updating the changed field on the page.
[0007] According to one aspect of an embodiment of the present specification, using LiveData to package business data corresponding to items in a page includes: creating a container for each item and constructing a LiveData corresponding to each item; each LiveData corresponds to LiveData of multiple fields, wherein the LiveData corresponding to the item is the first LiveData, and the LiveData of the field is the second LiveData.
[0008] According to one aspect of an embodiment of the present specification, binding the entry data to the page rendering module includes: obtaining business data in a list, the list including multiple entries; binding the second LiveData corresponding to each entry to each lifecycle component corresponding to the entry in the page rendering module; and determining that there is a mapping relationship between each lifecycle component and the second LiveData.
[0009] According to one aspect of an embodiment of the present specification, identifying changed entries in entry data and determining changed fields in the changed entries include: identifying changed entries in the entry data, and determining a first LiveData corresponding to the changed entry based on a correspondence between the entry and the first LiveData; and having a second LiveData corresponding to the first LiveData monitor the changed entries in the first LiveData and determine a changed field corresponding to the changed entry.
[0010] According to one aspect of the embodiments of this specification, after determining the changed fields in the changed entry, the method further includes: updating the changed entry data into the first LiveData and the second LiveData.
[0011] According to one aspect of an embodiment of the present specification, determining whether the display status of the entry meets the update conditions includes: respectively monitoring the first display status of the entry in the list and the second display status of the page where the entry is located, and determining whether the first display status is display; if so, determining whether the second display status is display; if so, updating the entry status of the changed field on the page.
[0012] According to one aspect of an embodiment of the present specification, identifying changed entries in the entry data includes: identifying the changed entries in a working thread through diffUtil.
[0013] The embodiment of this specification also provides a device for partial refresh of a list based on LiveData, the device comprising: a packaging unit, used to use LiveData to package business data corresponding to multiple items in a page to form item data packaged by LiveData; a binding unit, used to bind the item data to a page rendering module, wherein the page rendering module comprises a life cycle component corresponding to the item; a change field determination unit, used to identify items that have changed in the item data, and determine the change fields in the items that have changed; an update unit, used to determine whether the display status of the item meets the update conditions, and if so, to update the change fields on the page.
[0014] The embodiments of the present specification also provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the LiveData-based list partial refresh method when executing the computer program.
[0015] The embodiments of the present specification also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the LiveData-based list partial refresh method is implemented.
[0016] This application can achieve partial refresh of complex lists, improve rendering efficiency, and reduce business access complexity; it can avoid invalid rendering when entries are not visible. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0018] Figure 1Shown is a flowchart of a method for partially refreshing a list based on LiveData according to an embodiment of this specification;
[0019] Figure 2 The figure is a flow chart of a method for using LiveData to package business data corresponding to an entry in an embodiment of this specification;
[0020] Figure 3 The figure is a flow chart of a method for determining the position of a changed item in a page according to an embodiment of the present specification;
[0021] Figure 4 The figure is a flow chart of a method for determining the display status of an item according to an embodiment of the present specification;
[0022] Figure 5 It is a structural diagram of a device for partially refreshing a list based on LiveData according to an embodiment of this specification;
[0023] Figure 6 Shown are schematic diagrams of lists, items, and elements of the embodiments of this specification;
[0024] Fig. 7A The figure shows a schematic diagram of binding an item element to a page rendering module according to an embodiment of the present specification;
[0025] Figure 7B The figure shows an execution code diagram for determining the display status of an item according to an embodiment of the present specification;
[0026] Figure 8 The figure shows a schematic diagram of the structure of a computer device according to an embodiment of the present specification.
[0027] Description of the accompanying symbols:
[0028] 501. Packaging unit;
[0029] 502, binding unit;
[0030] 503, a change field determination unit;
[0031] 504, update unit;
[0032] 802. Computer equipment;
[0033] 804, processor;
[0034] 806. Memory;
[0035] 808, driving mechanism;
[0036] 810, input / output module;
[0037] 812. Input device;
[0038] 814. Output device;
[0039] 816. Presentation equipment;
[0040] 818. Graphical user interface;
[0041] 820, network interface;
[0042] 822, communication link;
[0043] 824. Communication bus. DETAILED DESCRIPTION
[0044] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.
[0045] It should be noted that the terms "first", "second", etc. in the description and claims of this specification and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of this specification described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, device, product or equipment that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.
[0046] This specification provides method operation steps as described in the embodiments or flow charts, but more or fewer operation steps may be included based on routine or non-creative work. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the system or device product is executed in practice, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel.
[0047] It should be noted that the LiveData-based list partial refresh method of this specification can be used in the field of software development, and this specification does not limit the application field of the LiveData-based list partial refresh method and device. The acquisition, transmission, storage, use, and processing of data in the technical solution of this application are in compliance with the relevant provisions of national laws and regulations.
[0048] Figure 1 The flowchart of a method for partially refreshing a list based on LiveData according to an embodiment of the present specification is shown, which specifically includes the following steps:
[0049] Step 101: Use LiveData to package the business data corresponding to multiple items in the page to form packaged item data.
[0050] In this step, the business data in the page is the data stream of business data received through instant messaging. Only after the data stream of business data is packaged with LiveData can the related features of LiveData be used. This manual takes the instant messaging application scenario as an example, and the pre-processed business data is presented in the form of list data, such as Figure 6 The figure shows a schematic diagram of a list, each list is composed of multiple entries, usually the entries have the same style, and each entry includes multiple elements.
[0051] In the embodiments of this specification, LiveData is a data holder class in the Android architecture component, which can provide a concise way to observe data and automatically update related UI components. This step creates LiveData corresponding to each entry while creating the entries in the page, and further uses LiveData to package multiple entries in each list in the page. Specifically, for each entry in the list, one LiveData is used to package the entry. For example, if there are 7 entries in a list, 7 LiveDatas are needed to package the 7 entries in the list respectively. After the business data in the entry is packaged with LiveData, the business data in the list forms a working thread.
[0052] In this step, using LiveData to package the business data corresponding to the items in the page specifically includes: creating a container for each item, and constructing LiveData corresponding to each item; each LiveData corresponds to LiveData of multiple fields. Among them, the LiveData corresponding to the item can be called the first LiveData, and the LiveData of the field can be called the second LiveData.
[0053] Specifically, the first LiveData corresponds to the container and the entry respectively, the entry data in the first LiveData corresponds to multiple second LiveData, and the second LiveData corresponds to each field in the entry. The specific fields used are packaged using the second LiveData.
[0054] Step 102: Bind the entry data to a page rendering module, wherein the page rendering module includes a life cycle component corresponding to the entry.
[0055] In this step, in the process of creating the entry data corresponding to the entry, the LiveData map and distinctUntilChange operators of LiveData are used at the same time to bind the LiveData corresponding to each entry in the rendering module. Among them, the map operator is used to generate the second LiveData from the first LiveData, and the distinctUntilChange operator is used to identify and determine the changed entry.
[0056] Specifically, the fields in the entry data are as follows:
[0057] UserName = "Zhang San" / / user name;
[0058] AvataUrl = "http: / / ..." / / avatar address;
[0059] MsgContent = "msg1" / / Latest news;
[0060] MsgTimestamp = 1713861411000L / / message timestamp;
[0061] unReadCount = 6 / / unread count;
[0062] isTop=false / / Whether to put it on top;
[0063] isQuiet = false / / Whether to do not disturb
[0064] …
[0065] In this step, the page rendering module includes multiple lifecycle components, which can also be called Lifecycle. This manual uses the map and distinctUntilChange operators of LiveData to associate or bind all entries in with all lifecycle components in the page rendering module, so as to monitor the field changes in the entries in subsequent steps. Specifically, the LiveData corresponding to all entries in are matched with the lifecycle components in the page rendering module. Figure 6 For example, the life cycle components in the page rendering module include but are not limited to: user name component, avatar component, message component, and unread count component. Each life cycle component has a corresponding entry.
[0066] Step 103, identifying the changed entries in the entry data, and determining the changed fields in the changed entries.
[0067] In this step, when the list is updated, the diffUtil tool can be used in the working thread to identify the changed items, including but not limited to: adding items, deleting items, modifying items, or moving items. Furthermore, the location of the changed items can also be identified.
[0068] In the embodiment of the present specification, the list component creates a container for each entry in advance, and each container corresponds to an entry and the first LiveData of an entry. During the operation of the list component, the fields in the entry may change. According to the updated data in the container corresponding to the entry, it can be determined that an entry in the entry data has changed, and the first LiveData of the changed entry can be further determined. According to the first LiveData of the changed entry, the second LiveData corresponding to the first LiveData can be notified to update the field data, and finally the change is published.
[0069] In the embodiment of this specification, LiveData can be used to conveniently analyze the changed fields and realize partial refresh of the item data in the list. At the same time, based on the characteristic that LiveData only notifies the change when the bound component is visible, the efficiency of data update and page rendering is improved. In the embodiment of this specification, if the item and the page are displayed, the field described in this step can also be called an element, and the changed field can be called a changed element.
[0070] Step 104: determine whether the display status of the entry meets the update condition.
[0071] This manual is based on LiveData of the Android platform and manages the items displayed on the page in combination with the life cycle of the items. This step monitors the life cycle of the items and the pages where the items are located. Specifically, it monitors the display status of the items and whether the display status of the pages where the items are located meets the conditions for data update. Among them, the data update conditions include: the entry is in a displayed state on the page, and the page is in a displayed state or is not blocked in the mobile application interface.
[0072] Step 105: If yes, update the changed field on the page.
[0073] In this step, if the display status of the entry and the page where the entry is located meets the above update conditions, the changed fields are updated and displayed on the page.
[0074] Step 106: If not, do not update the page.
[0075] In the embodiments of this specification, the entry may not be displayed on the page when the user slides the screen up and down. In this case, rendering the updated data of the entry is meaningless to the user; in other embodiments of this specification, the page may be blocked by other applications, or the page may be exited or closed, or minimized and hidden in the background, which can indicate that the user is not currently paying attention to the page. Therefore, in this case, updating the data of the page is also meaningless to the user. If the data is still updated here, it will cause a waste of resources and meaningless rendering.
[0076] Therefore, this manual solves the problems of low rendering efficiency, high complexity, and refreshing items even when they are not visible in the native solution. LiveData is used to conveniently analyze the changed fields, implement partial refresh of the list, and improve rendering efficiency.
[0077] Figure 2 The flowchart of a method for binding entry data to a page rendering module according to an embodiment of the present specification is shown, which specifically includes the following steps:
[0078] Step 201: Obtain business data in a list, where the list includes multiple entries. Figure 6 As shown, there are 7 items in the list, each of which includes elements such as avatar, name, latest message, do not disturb, etc. In this step, firstly, the data stream of the business data is received, the business data stream is mapped into the required format, and data preprocessing such as data filtering is performed to obtain the business data of multiple items in the list.
[0079] Step 202 , the second LiveData corresponding to each entry is respectively bound to each lifecycle component corresponding to the entry in the page rendering module.
[0080] As mentioned above, each entry in the list data corresponds to a first LiveData. Each entry contains multiple fields or elements, which can be understood as basic view components. The multiple elements or fields in each entry correspond to multiple second LiveData respectively. On the other hand, each second LiveData corresponds to each basic view component in the entry. In this specification, binding each view component in the entry with the rendering module means corresponding each second LiveData with each lifecycle component in the rendering module, thereby realizing the binding of the entry with the lifecycle component.
[0081] Step 203: Determine whether there is a mapping relationship between each lifecycle component and the second LiveData.
[0082] In this step, the map operator of LiveData is used to construct the second LiveData, and each second LiveData corresponds to each lifecycle component in the rendering module, thereby realizing the binding of entries and lifecycle components. Specifically, the map function of LiveData is used to convert or map the values stored in the LiveData object. The converted data will be encapsulated in a new LiveData object, and the converted result will be propagated to the rendering module.
[0083] For example, Fig. 7A As shown, the element "user name" in the entry is mapped to userName and bound to the lifecycle component "user name component" in the rendering module; the element "latest message" in the entry is mapped to MsgContent and bound to the lifecycle component "message component" in the rendering module.
[0084] Figure 3 The flowchart of a method for determining a changed field in a changed entry according to an embodiment of the present specification is shown, which specifically includes the following steps:
[0085] Step 301, identify the changed entry in the entry data, and determine the first LiveData corresponding to the changed entry based on the corresponding relationship between the entry and the first LiveData. Specifically, identify the entry change through diffUtil. When the entry changes, publish the latest value of the entry change to the first LiveData corresponding to the entry, so as to determine the first LiveData corresponding to the entry that actually changed.
[0086] Step 302: The second LiveData corresponding to the first LiveData monitors the changed entries in the first LiveData, and determines the changed fields corresponding to the changed entries.
[0087] In this specification, the second LiveData pre-subscribes to the changes of specific fields in the first LiveData entry data, so when the entry data changes, the second LiveData will receive a notification. Specifically, when the corresponding field of the first LiveData changes, an entry data update notification is received. Through the map and distinctUntilChange operators, it is determined whether the specific fields in the updated entry data subscribed by the second LiveData are consistent with the fields originally corresponding to the second LiveData. If they are inconsistent, it is determined that the updated entry data has changed. Furthermore, based on the correspondence between the second LiveData and the fields in the entry, the specific fields that have changed can be determined and the changed fields can be published to the second LiveData.
[0088] In this specification, as long as the entry changes, the first LiveData and the second LiveData that pre-set the entry change notification will receive the notification. Therefore, this specification has the effect of automatically determining the LiveData change field according to the entry change.
[0089] In some embodiments of the present specification, after determining the changed fields in the changed entry, the method further includes: updating the changed entry data to the first LiveData and the second LiveData. In the embodiments of the present specification, the container is set to inherit viewHolder so that it can be used by the list component, which queries the container and updates the entry data in the container. When an element in an entry changes, the list component first determines the container corresponding to the changed entry, and then updates the data in the container. Specifically, the changed entry data and the changed fields are updated to the corresponding first LiveData and second LiveData respectively.
[0090] Figure 4 The flowchart of a method for determining the display status of an item in an embodiment of the present specification is shown, which specifically includes the following steps:
[0091] Step 401 : monitor a first display state of the item in the list and a second display state of the page where the item is located.
[0092] In the embodiments of the present specification, as the list slides in the page, the items in the list may become visible or invisible as the list slides in the page; the page where the list is located may also become visible or invisible on the mobile application display end due to exiting, jumping to other pages, or being blocked. Among them, the display state of the item in the list is recorded as the first display state, and the entire page where the item is located on the mobile application display end is recorded as the second display state. Furthermore, the display state can be set to STARTED, and the non-display state can be set to CREATED.
[0093] In this manual, when creating a container for each entry, LiveData and the corresponding Lifecycler (that is, mergeLifecyclerOwner) will be constructed. Among them: vhLifecycleOwner reflects the visibility of the entry in the list; outLifecycleOwner reflects the visibility of the page externally; mergeLifecyclerOwner is the final result of the combination. The implementation method of mergeLifecyclerOwner is to monitor the status of vhLifecycleOwner and outLifecycleOwner respectively. When the status of vhLifecycleOwner and outLifecycleOwner are both visible, the mergeLifecyclerOwner result is visible. For the specific code to implement the logic of this step, see Figure 7B .
[0094] Step 402, determine whether the first display state is displayed. In this step, according to the setting of different display states in step 401, determine whether the first display state of the item in the list is STARTED. If so, it means that the item is visible in the list, and further execute step 402. If not, it means that the item is not visible in the list, and the subsequent steps are not executed.
[0095] Step 403, if yes, determine whether the second display state is display. In this step, based on the fact that the display state of the item in the list is visible, determine whether the second display state of the page where the item is located is visible. If yes, update the page data, and further update the data in the item in the page, to avoid invalid rendering and resource waste caused by automatic update when the user does not pay attention to the page or item.
[0096] Step 404: If yes, update the changed field on the page.
[0097] In the embodiments of this specification, for an entry or page, only when the first display state and the second display state are both displayed, the entry or page will receive a notification of data changes, thereby updating the change field on the page. Specifically, after the latest data is published to the first LiveData, the first LiveData is split into multiple second LiveData, and the entry is notified of the update. This specification can achieve partial refresh of complex lists, improve rendering efficiency, and avoid invalid rendering when the entry is not visible.
[0098] like Figure 5The figure shows a schematic diagram of a structure of a device for partially refreshing a list based on LiveData according to an embodiment of the present specification. The figure describes the basic structure of the device for partially refreshing a list based on LiveData, wherein the functional units and modules can be implemented in software, or a general chip or a specific chip can be used to implement a partial refresh of a list based on LiveData. The device specifically includes:
[0099] The packaging unit 501 is used to package the business data corresponding to the multiple items in the page using LiveData to form packaged item data;
[0100] A binding unit 502, configured to bind the entry data to a page rendering module, wherein the page rendering module includes a life cycle component corresponding to the entry;
[0101] A changed field determination unit 503, used to identify changed entries in the entry data, and determine changed fields in the changed entries;
[0102] The updating unit 504 is used to determine whether the display status of the entry meets the update condition, and if so, update the change field on the page.
[0103] Figure 6 Shown is a schematic diagram of the list, items and elements of the embodiments of this specification. The figure shows three lists at different times, each list consists of multiple items, usually the items have the same style, and each item includes multiple elements. For example, "Mailbox", "Notifications", "Zhang Xiaohu", etc. are each different item, and the "Zhang Xiaohu" item shows the corresponding avatar, name, latest news, time, top information, etc., which are the elements under the item. The 7 items displayed on the page constitute a list.
[0104] Fig. 7A Shown is a schematic diagram of binding an entry element to a page rendering module according to an embodiment of the present specification.
[0105] In the figure, the LiveData corresponding to each entry is bound to each lifecycle component corresponding to the entry in the page rendering module. Specifically, the element "user name" in the entry is mapped to userName and bound to the lifecycle component "user name component" in the rendering module; the element "latest message" in the entry is mapped to MsgContent and bound to the lifecycle component "message component" in the rendering module.
[0106] Figure 7BThe following is an execution code diagram for determining the display status of an item in an embodiment of the present specification. By monitoring the values of vhLifecycleOwner and outLifecycleOwner respectively, the result of mergeLifecyclerOwner is determined, which is the final result after the combination.
[0107] like Figure 8 Shown is a schematic diagram of a computer device provided by an embodiment of this specification. The LiveData-based list local refresh method described in this application can be applied to the computer device. The computer device 802 may include one or more processors 804, such as one or more central processing units (CPUs), each of which may implement one or more hardware threads. The computer device 802 may also include any memory 806, which is used to store any kind of information such as code, settings, data, etc. Non-restrictive, for example, the memory 806 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc. More generally, any memory may use any technology to store information. Further, any memory may provide volatile or non-volatile retention of information. Further, any memory may represent a fixed or removable component of the computer device 802. In one case, when the processor 804 executes an associated instruction stored in any memory or a combination of memories, the computer device 802 may perform any operation of the associated instruction. The computer device 802 also includes one or more drive mechanisms 808 for interacting with any storage, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.
[0108] The computer device 802 may also include an input / output module 810 (I / O) for receiving various inputs (via input devices 812) and for providing various outputs (via output devices 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface (GUI) 818. In other embodiments, the input / output module 810 (I / O), the input device 812, and the output device 814 may not be included, and the computer device 802 may be used as a computer device in a network. The computer device 802 may also include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.
[0109] The communication link 822 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.
[0110] Corresponds to Figures 1 to 4 The method in the embodiment of the present specification also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above method are executed.
[0111] The embodiment of the present specification also provides a computer-readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute the following Figures 1 to 4 The method shown.
[0112] The embodiment of the present specification also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, Figures 1 to 4 The method shown.
[0113] It should be understood that in the various embodiments of this specification, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.
[0114] It should also be understood that in the embodiments of this specification, the term "and / or" is only a description of the association relationship of the associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this specification generally indicates that the associated objects before and after are in an "or" relationship.
[0115] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this specification.
[0116] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0117] In the several embodiments provided in this specification, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or it can be an electrical, mechanical or other form of connection.
[0118] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of this specification.
[0119] In addition, each functional unit in each embodiment of this specification may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0120] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this specification is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of this specification. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.
[0121] Specific embodiments are used in this specification to illustrate the principles and implementation methods of this specification. The description of the above embodiments is only used to help understand the methods and core ideas of this specification. At the same time, for those skilled in the art, according to the ideas of this specification, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on this specification.
Claims
1. A method for partial refresh of a list based on LiveData, characterized in that: The method comprises: Use LiveData to package the business data corresponding to multiple items in the page to form packaged item data; Binding the entry data to a page rendering module, wherein the page rendering module includes a lifecycle component corresponding to the entry; Identify changed entries in the entry data, and determine changed fields in the changed entries; Determine whether the display status of the entry meets the update condition, and if so, update the change field on the page.
2. The method according to claim 1, characterized in that Using LiveData to package the business data corresponding to multiple items in the page includes: A container is created for each entry respectively, and a LiveData corresponding to each entry is constructed; each LiveData corresponds to LiveData of multiple fields, wherein the LiveData corresponding to the entry is the first LiveData, and the LiveData of the field is the second LiveData.
3. The method according to claim 2, characterized in that Binding the entry data to the page rendering module includes: Acquire business data in a list, where the list includes multiple entries; Bind the second LiveData corresponding to each entry to each lifecycle component corresponding to the entry in the page rendering module; Determine whether there is a mapping relationship between each lifecycle component and the second LiveData.
4. The method according to claim 3, characterized in that Identify the changed entries in the entry data, and determine that the changed fields in the changed entries include: Identify the changed entries in the entry data, and determine the first LiveData corresponding to the changed entries based on the correspondence between the entries and the first LiveData; and have the second LiveData corresponding to the first LiveData monitor the changed entries in the first LiveData and determine the changed fields corresponding to the changed entries.
5. The method according to claim 4, characterized in that After determining the changed fields in the changed entries, the method further comprises: Update the changed entry data to the first LiveData and the second LiveData.
6. The method according to claim 1, characterized in that Determining whether the display status of the entry meets the update condition includes: respectively monitoring a first display state of the item in the list and a second display state of the page where the item is located; Determining whether the first display state is display; If so, determining whether the second display state is display; If so, update the changed field on the page.
7. The method according to claim 2, characterized in that Identifying changed entries in the entry data includes: identifying the changed entries in the working thread by using diffUtil.
8. A list partial refresh device based on LiveData, characterized in that: The device comprises: The packaging unit is used to use LiveData to package the business data corresponding to multiple items in the page to form packaged item data; A binding unit, used to bind the entry data to a page rendering module, wherein the page rendering module includes a life cycle component corresponding to the entry; A changed field determination unit, used for identifying changed entries in the entry data, and determining changed fields in the changed entries; The updating unit is used to determine whether the display status of the entry meets the updating condition, and if so, to update the changed field on the page.
9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.
