Data recovery method, device and electronic equipment

Abstract

The application discloses a data recovery method and device and electronic equipment, and belongs to the technical field of electronics. The method comprises the following steps: in the case that a first input is received and the first input is used for triggering display of an application screenshot of a background running application, a first physical memory block is acquired, and the first physical memory block is allocated to a data recovery thread; a second physical memory block is acquired, and first screenshot cache data of the first application screenshot is subjected to data recovery by the data recovery thread based on a physical memory block corresponding to a first total data amount; wherein the first total data amount represents a total capacity of a physical memory block available for recovering the first screenshot cache data each time a physical memory block is acquired.

Description

Technical Field

[0001] This application belongs to the field of electronic technology, specifically relating to a data recovery method, apparatus, and electronic device. Background Technology

[0002] Screenshot cache, as application data stored in resident memory, can be directly and quickly displayed in the application's recovery interface through memory mapping, enabling functions such as multi-task preview and quick application switching.

[0003] In related technologies, when an application is completely terminated, its screenshot cache is released. For example, if a user manually closes the application from the background, the screenshot cache is released. If the application's screenshot cache is needed later, it needs to be restored. Restoring the application's screenshot cache involves first allocating memory blocks through a memory allocation thread, then passing all allocated memory blocks to a data recovery thread, which then restores the application's screenshot cache based on the allocated memory blocks.

[0004] However, due to the large size of the application's screenshot cache, the memory allocation thread spends a considerable amount of time allocating memory blocks when the application's screenshot cache needs to be restored, severely impacting the user experience for features such as multi-tasking preview and quick application switching. Therefore, the recovery efficiency of the screenshot cache in related technologies is relatively low. Summary of the Invention

[0005] The purpose of this application is to provide a data recovery method, apparatus, and electronic device that can improve the recovery efficiency of screenshot cache.

[0006] In a first aspect, embodiments of this application provide a data recovery method, the method comprising: upon receiving a first input, wherein the first input is used to trigger the display of an application screenshot of a background running application, acquiring a first physical memory block and allocating the first physical memory block to a data recovery thread; acquiring a second physical memory block, and through the data recovery thread, performing data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein the first total data amount represents the total capacity of the physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block.

[0007] Secondly, embodiments of this application provide a data recovery apparatus, which includes: a processing module;

[0008] The processing module is configured to, upon receiving a first input that triggers the display of an application screenshot of a background running application, acquire a first physical memory block and allocate the first physical memory block to a data recovery thread; and acquire a second physical memory block and, through the data recovery thread, perform data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein the first total data amount represents the total capacity of physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block.

[0009] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores a program or instructions executable on the processor, and the program or instructions, when executed by the processor, implement the steps of the data recovery method as described in the first aspect.

[0010] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the data recovery method as described in the first aspect.

[0011] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the data recovery method as described in the first aspect.

[0012] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the data recovery method as described in the first aspect.

[0013] In this embodiment, upon receiving a first input that triggers the display of an application screenshot of a background running application, a first physical memory block is acquired and allocated to a data recovery thread. A second physical memory block is acquired, and the data recovery thread, based on the physical memory block corresponding to the first total data amount, performs data recovery on the first screenshot cache data of the first application screenshot. The first total data amount represents the total capacity of physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block. In this solution, when it is necessary to recover the screenshot cache data of the application interface, after acquiring a physical memory block, it can be directly allocated to the recovery thread. Then, the next physical memory block is acquired, and simultaneously, the data recovery thread performs data recovery on the screenshot cache data of the application interface based on the previously acquired physical memory blocks. That is, by acquiring physical memory blocks while simultaneously recovering part of the screenshot cache data, it is not necessary to wait for all physical memory blocks to be allocated before recovering the screenshot cache data. Therefore, the recovery time for the screenshot cache data is shortened, and the recovery efficiency of the screenshot cache is improved. Attached Figure Description

[0014] Figure 1 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0015] Figure 2 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0016] Figure 3 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0017] Figure 4 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0018] Figure 5 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0019] Figure 6 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0020] Figure 7 This is a schematic diagram illustrating the parallel thread recovery of screenshot cache data provided in some embodiments of this application;

[0021] Figure 8 This is a flowchart of offline testing provided in some embodiments of this application;

[0022] Figure 9This is a flowchart of a data recovery method provided in some embodiments of this application;

[0023] Figure 10 This is a flowchart of a data recovery method provided in some embodiments of this application;

[0024] Figure 11 These are schematic diagrams of data recovery apparatuses provided in some embodiments of this application;

[0025] Figure 12 These are schematic diagrams of the electronic devices provided in some embodiments of this application;

[0026] Figure 13 These are schematic diagrams of the hardware structure of electronic devices provided in some embodiments of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0028] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0029] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0030] The following explains some concepts and terms involved in the data recovery method, apparatus and electronic device provided in the embodiments of this application.

[0031] Application: An application, also known simply as an application, is a computer program developed to meet user needs. It relies on the operating system's runtime environment to schedule hardware resources to achieve corresponding functions and can adapt to various scenarios such as office work, social interaction, entertainment, production operations and maintenance, and public services.

[0032] Screenshot caching: Each application has its own screenshot cache. During background multitasking previews and startup animation rendering, the application's screenshot cache directly restores the original image data quickly through memory mapping, achieving zero-copy interface rendering and making the application startup process smoother and less abrupt. The system captures the application interface, stores the screenshot data in the screenshot cache, and displays the captured screen in some high-frequency scenarios.

[0033] Shared memory (Direct Memory Access Buffer, DMABuf): Shared memory is a physical memory technology that supports cross-process and cross-driver access. Its core feature is to achieve zero-copy data transfer. It is often used as the underlying storage medium for scenarios that require multi-process and cross-device sharing, such as screenshot caching.

[0034] Virtual address: By mapping the virtual address space to physical memory through page tables, the on-demand translation of contiguous virtual addresses to discrete physical pages is realized, supporting process memory isolation and efficient memory management.

[0035] The data recovery method, apparatus, and electronic device provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0036] The embodiments of this application can be applied to scenarios where it is necessary to restore cached screenshot data.

[0037] In one possible application scenario, the data recovery method provided in this application embodiment can be applied to a scenario where, upon receiving a first input, and the first input is used to trigger the display of an application screenshot of an application running in the background, the screenshot cache data of the application screenshot is recovered, such as scenario 1.

[0038] Scenario 1: Taking the case where a user's click input is received, and this click input triggers the phone to display a screenshot of application A running in the background, the screenshot cache data of that application can be restored as an example. Upon receiving the aforementioned click input from the user, the phone can restore the screenshot cache data of application A.

[0039] In another possible application scenario, the data recovery method provided in this application embodiment can be applied to a scenario in which, upon receiving a first input and the first input is used to trigger the display of a multitasking preview interface on the mobile phone, the screenshot cache data of at least one application screenshot included in the multitasking preview interface is recovered, such as scenario 2.

[0040] Scenario 2: Taking the case where a user swipes up to trigger the phone to display a multitasking preview interface, and this preview interface includes screenshots of applications B and C, the example demonstrates how to restore the cached screenshot data of applications B and C. Upon receiving the aforementioned swipe-up input from the user, the phone can restore the cached screenshot data of the screenshots from applications B and C.

[0041] It should be noted that the above scenarios 1 and 2 are merely exemplary examples of some scenarios that may be applied to the embodiments of this application. In actual implementation, the embodiments of this application can also be applied to any possible scenario where more screenshot cache data needs to be recovered. The embodiments of this application are not limited here.

[0042] The data recovery method provided in this application can be executed by a data recovery device, which can be an electronic device, or a functional module or functional entity within an electronic device. The following description uses an electronic device as an example to illustrate the technical solution provided in this application.

[0043] Figure 1 A flowchart of a data recovery method provided in an embodiment of this application is shown, as follows: Figure 1 As shown, the data recovery method provided in this application embodiment may include the following steps 201 and 202.

[0044] Step 201: When the electronic device receives a first input, and the first input is used to trigger the display of an application screenshot of a background running application, it acquires a first physical memory block and allocates the first physical memory block to the data recovery thread.

[0045] In some embodiments of this application, the above-described application may also be referred to simply as an application.

[0046] In some embodiments of this application, the first input includes at least one of the following: touch input by the user using a touch device such as a finger or stylus, voice commands input by the user, or specific gestures input by the user. Of course, the first input can also be other forms of input used to trigger the display of screenshots of applications running in the background; the specific form can be determined according to actual usage needs, and this application does not limit it.

[0047] In some embodiments of this application, the touch input can be a single click, a double click, or any number of clicks, or it can be a long press or a short press.

[0048] In some embodiments of this application, the specific gestures mentioned above include at least one of the following: a single-click gesture, a swipe gesture, a drag gesture, a pressure-recognition gesture, a long-press gesture, an area-change gesture, a double-press gesture, and a double-tap gesture.

[0049] For example, taking scenario 1 as an example, the first input in scenario 1 can be a click input on application A.

[0050] For example, taking scenario 2 as an example, the first input in scenario 2 can be an up-swipe input on the phone's home screen.

[0051] In some embodiments of this application, the application screenshot may also be referred to as the application screenshot interface.

[0052] In some embodiments of this application, the first application screenshot may be an application screenshot corresponding to the application's startup interface; or, the first application screenshot may be an application screenshot of at least one application included in the multitasking preview interface.

[0053] In some embodiments of this application, the first input is used to trigger the display of an application screenshot of at least one application running in the background.

[0054] In some embodiments of this application, the first application described above is an application that is running in the background.

[0055] In some embodiments of this application, the first application mentioned above refers to an application program in at least one application running in the background.

[0056] In some embodiments of this application, the application type of the first application mentioned above includes any one of the following: social application, shopping application, office application, and video application. Of course, the application type of the first application mentioned above can also be other application types, which can be determined according to actual needs, and this application does not limit it in this regard.

[0057] In some embodiments of this application, the multitasking preview interface described above is an interface that centrally displays all background applications currently running on the electronic device.

[0058] In some embodiments of this application, the first input mentioned above, which is used to trigger the display of an application screenshot of a background application, refers to the electronic device receiving the first input, which is used to trigger the electronic device to launch a background application or display a multitasking preview interface.

[0059] For example, taking scenario 1, the first input in scenario 1 is the input that triggers the phone to display application A running in the background. That is, when application A is running in the background on the phone, the phone detects the user's input that application A is running. Specifically, when application A is running in the background, the phone receives the user's input of clicking on the icon of application A, triggering the phone to restore the screenshot cache data of application A's application interface.

[0060] For example, taking scenario 2, the first input in scenario 2 is the input that triggers the phone to display a multitasking preview interface. This multitasking preview interface includes screenshots of application B and application C running in the background. That is, while application B and application C are running in the background on the phone, the phone detects the user's input to run the multitasking preview interface. Specifically, the phone receives the user's swipe-up input, which triggers the phone to switch from the background to the foreground to run the multitasking preview interface, and triggers the phone to restore the cached screenshot data of the multitasking preview interface.

[0061] In some embodiments of this application, the first application screenshot includes at least one application screenshot. Specifically, when the first application screenshot is an application screenshot corresponding to the launch interface of the first application, the first application screenshot includes an application screenshot of the first application; when the first application screenshot is an application screenshot included in the multitasking preview interface, the first application screenshot includes an application screenshot of at least one application running in the background.

[0062] For example, taking scenario 1 as an example, assuming that application A is a social application A, the first application screenshot in scenario 1 includes the application screenshot of social application A. That is, when the user triggers the phone to display the application screenshot of social application A, the phone restores the screenshot cache data of the application screenshot of social application A.

[0063] For example, taking scenario 2, assuming that the applications currently running in the background on the phone are shopping application B and video application C, then in scenario 2, the first application screenshot includes the application screenshot of shopping application B and the application screenshot of video application C. That is, when the user triggers the phone to display the multitasking preview interface, the phone restores the cached screenshot data of shopping application B and video application C.

[0064] In some embodiments of this application, the first physical memory block mentioned above may be a physical memory block obtained through a memory allocation thread.

[0065] In some embodiments of this application, the first physical memory block can be a physical memory block requested from the system kernel through the memory request thread. Alternatively, the first physical memory block can also be a physical memory block directly obtained from the memory pool through the memory request thread.

[0066] In some embodiments of this application, when the first application screenshot is an application screenshot corresponding to the startup interface of the first application, the first physical memory block is a physical memory block requested from the system kernel through the memory request thread. When the first application screenshot is an application screenshot included in the multi-task preview interface, the first physical memory block is a physical memory block directly obtained from the memory pool through the memory request thread.

[0067] For example, taking scenario 1 as an example, when the mobile phone is recovering the screenshot cache data of application A's screenshot, it obtains the first physical memory block, which can be the physical memory block requested by the mobile phone from the system kernel.

[0068] For example, taking scenario 2 as an example, when the mobile phone restores the screenshot cache data of application screenshots of application B and application screenshots of application C included in the multitasking preview interface, it obtains the first physical memory block. The first physical memory block can be a physical memory block that the mobile phone directly obtains from the memory pool.

[0069] In some embodiments of this application, the physical memory block described above may be simply referred to as a memory block.

[0070] In some embodiments of this application, the data recovery thread described above is used to recover the first screenshot cache data of the first application screenshot based on physical memory blocks.

[0071] In some embodiments of this application, the aforementioned memory allocation thread refers to a thread responsible for obtaining physical memory blocks from the system kernel or memory pool according to preset logic, so as to provide memory block resource support for the recovery of application screenshot cache data.

[0072] In some embodiments of this application, the memory allocation thread can be a single thread. Alternatively, the memory allocation thread can be multiple threads. The specific method can be determined based on actual needs, and this application does not impose any limitations on this.

[0073] In some embodiments of this application, allocating the first physical memory block to the data recovery thread means transferring the usage rights of the first physical memory block to the data recovery thread through the memory allocation thread.

[0074] In some embodiments of this application, after the electronic device obtains the first physical memory block through the memory allocation thread, it can bind the unique identifier (UID) of the first physical memory block to the UID of the data recovery thread through the memory allocation thread, and pass the memory block information of the first physical memory block to the data recovery thread, so as to mark the first physical memory block as the exclusive available physical memory block of the data recovery thread.

[0075] In some embodiments of this application, the aforementioned memory block information includes at least one of the following: memory block address information and memory block capacity information. Of course, the aforementioned memory block information may also include other information about the physical memory block, which can be determined according to actual needs, and this application does not limit this.

[0076] In some embodiments of this application, the aforementioned capacity may also be referred to as size. In other words, "size" in this application refers to capacity.

[0077] In some embodiments of this application, the electronic device can determine the first total amount of data based on memory block information of available physical memory blocks through a data recovery thread.

[0078] In some embodiments of this application, the above-mentioned allocation of the first physical memory block to the data recovery thread can also be referred to as transferring the first physical memory block to the data recovery thread.

[0079] In some embodiments of this application, the memory pool described above can be a memory pool that stores physical memory blocks for screenshot cache recovery.

[0080] In some embodiments of this application, the aforementioned screenshot cache recovery physical memory block refers to a physical memory block specifically used for data recovery of screenshot cache data.

[0081] In some embodiments of this application, the electronic device can request the aforementioned screenshot cache recovery physical memory block from the system kernel through an asynchronous memory request thread, and store the aforementioned screenshot cache recovery physical memory block in the aforementioned memory pool.

[0082] It should be noted that the specific implementation process of the electronic device requesting the above-mentioned screenshot cache recovery physical memory block from the system kernel through the asynchronous memory request thread and storing the above-mentioned screenshot cache recovery physical memory block into the above-mentioned memory pool can be found in the relevant description in the following embodiments. To avoid repetition, this application will not elaborate on it here.

[0083] In some embodiments of this application, the electronic device can acquire the first physical memory block upon receiving a recovery signal from the upper layer.

[0084] In some embodiments of this application, the aforementioned upper-layer recovery signal refers to a request sent by the application layer to the system kernel layer to instruct the system to restore the screenshot cache data.

[0085] In some embodiments of this application, the upper-layer recovery signal carries the following information: the total capacity of the screenshot cache data and the location information of the screenshot cache data. Of course, the upper-layer recovery signal may also carry other information, which can be determined according to actual needs, and this application does not limit it.

[0086] Step 202: The electronic device obtains the second physical memory block and, through the data recovery thread, performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount.

[0087] The aforementioned first data total represents the total capacity of physical memory blocks available for restoring the cached data of the first screenshot when a physical memory block is acquired.

[0088] In some embodiments of this application, the aforementioned first total data volume may also be referred to as the unrecovered total data volume.

[0089] In some embodiments of this application, the aforementioned first data total represents the total capacity of physical memory blocks that are not currently used to restore the first screenshot cache data when each physical memory block is acquired.

[0090] In some embodiments of this application, the aforementioned second physical memory block may be a physical memory block obtained through a memory allocation thread.

[0091] In some embodiments of this application, the second physical memory block can be a physical memory block requested from the system kernel through the memory request thread. Alternatively, the second physical memory block can also be a physical memory block directly obtained from the memory pool through the memory request thread.

[0092] In some embodiments of this application, when the first application screenshot is an application screenshot corresponding to the startup interface of the first application, the second physical memory block is a physical memory block requested from the system kernel through the memory request thread. When the first application screenshot is at least one application screenshot included in the multi-task preview interface, the second physical memory block is a physical memory block directly obtained from the memory pool through the memory request thread.

[0093] For example, taking scenario 1 as an example, in scenario 1, the second physical memory block can be a physical memory block requested by the mobile phone from the system kernel. That is, when the mobile phone performs data recovery on the screenshot cache data of application A, it can obtain the second physical memory block, which is a physical memory block requested from the system kernel.

[0094] For example, taking scenario 2 as an example, in scenario 2, the aforementioned second physical memory block can be a physical memory block that the mobile phone directly obtains from the memory pool. That is, when the mobile phone restores the data cache data of the application screenshots of application B and application C included in the multi-task preview interface, it can obtain the second physical memory block, which is a physical memory block requested from the system kernel.

[0095] In some embodiments of this application, the second physical memory block can be a physical memory block with the same capacity as the first physical memory block. Alternatively, the second physical memory block can also be a physical memory block with a different capacity than the first physical memory block.

[0096] In some embodiments of this application, when an electronic device requests a physical memory block from the system kernel through a memory request thread, the memory request thread first generates a memory request, and then initiates a request to the kernel through the memory allocation interface provided by the system kernel. The kernel first searches the free physical memory pool it manages. After finding a contiguous physical memory region, it maps the physical address of the region to the virtual address space of the memory request thread, and updates the physical memory usage status flag to avoid duplicate allocation. Finally, the kernel returns a successful request response and metadata such as the virtual address and physical address of the memory block to the memory request thread. The memory request thread can then transfer the usage rights of the physical memory block to the data recovery thread for the recovery operation of the screenshot cached data.

[0097] In some embodiments of this application, after acquiring the second physical memory block, the electronic device can allocate the second physical memory block to the aforementioned data recovery thread.

[0098] In some embodiments of this application, after the electronic device obtains the second physical memory block through the memory allocation thread, it can bind the unique identifier (UID) of the second physical memory block to the UID of the data recovery thread through the memory allocation thread, and pass the memory block information of the second physical memory block to the data recovery thread, so as to mark the second physical memory block as the exclusive available physical memory block of the data recovery thread.

[0099] In some embodiments of this application, the first total data represents the total capacity of the physical memory blocks available for restoring the screenshot cache data when a physical memory block is acquired.

[0100] In some embodiments of this application, the aforementioned first total data volume may also be referred to as the current first total data volume, which represents the available physical memory block currently allocated by the memory allocation thread for data recovery of the first screenshot cache data of the first application screenshot.

[0101] For example, taking scenario 1 as an example, in scenario 1, during the process of restoring the screenshot cache data of application A, when the mobile phone obtains the first physical memory block, the first total data is the first physical memory block. When the mobile phone obtains the second physical memory block, the first total data is the first physical memory block and the second physical memory block.

[0102] For example, taking scenario 2 as an example, in scenario 2, during the process of restoring the screenshot cache data of the multi-task preview interface, when the mobile phone obtains the first physical memory block, the first total data is the first physical memory block. When the mobile phone obtains the second physical memory block, the first total data is the first physical memory block and the second physical memory block.

[0103] In some embodiments of this application, data recovery of the first screenshot cache data of the first application screenshot refers to the process by which the electronic device reloads the released screenshot cache data into an available physical memory block and restores it to a recognizable image format.

[0104] In some embodiments of this application, the electronic device first reads metadata such as the address and size of the available physical memory block by a data recovery thread. Simultaneously, it calls the system's image data parsing interface to write the pre-stored screenshot cache raw data of the first application screenshot into the corresponding physical memory area in a fixed order. After all screenshot data has been written, the system marks the physical memory area as an image cache area that can be used for interface rendering. Subsequently, the image rendering driver converts the pixel data in memory into image signals that can be displayed on the screen to display the aforementioned first application screenshot.

[0105] In some embodiments of this application, the above-mentioned data recovery of the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount refers to data recovery of the application screenshot cache data with the same size as the first total data amount based on the physical memory block corresponding to the first total data amount.

[0106] This application provides a data recovery method. When it is necessary to recover the screenshot cache data of an application interface, after acquiring a physical memory block, the physical memory block can be directly allocated to the recovery thread. Then, the next physical memory block can be acquired. While acquiring the next physical memory block, the data recovery thread performs data recovery on the screenshot cache data of the application interface based on the previously acquired physical memory blocks. That is, by acquiring physical memory blocks while partially recovering the screenshot cache data, it is not necessary to wait for all physical memory blocks to be allocated before recovering the screenshot cache data. Therefore, the recovery time of the screenshot cache data is shortened and the recovery efficiency of the screenshot cache is improved.

[0107] In some embodiments of this application, combined with Figure 1 ,like Figure 2 As shown, step 201 above can be implemented through step 201a below.

[0108] Step 201a: When the electronic device receives the first input, and the first input is used to trigger the display of an application screenshot of the application running in the background, it obtains the first physical memory block through the memory allocation thread and sends the memory block information of the first physical memory block to the aforementioned data recovery thread.

[0109] The aforementioned memory block information includes at least one of the following: the address information of the aforementioned first physical memory block, and the capacity information of the aforementioned first physical memory block.

[0110] In some embodiments of this application, combined with Figure 2 ,like Figure 3 As shown, step 201a can be implemented through step 201a1 as described below. Step 202 can be implemented through step 202a as described below.

[0111] Step 201a1: When the electronic device receives the first input, and the first input is used to trigger the display of an application screenshot of the application running in the background, it requests a first physical memory block from the system kernel through the memory request thread, and allocates the first physical memory block to the data recovery thread.

[0112] In some embodiments of this application, when the first application screenshot is the application screenshot corresponding to the startup interface of the first application, the electronic device can, after detecting the first input, request a first physical memory block from the system kernel through a memory request thread.

[0113] For example, taking scenario 1 as an example, assuming that the first physical memory block is 1Mb in size, after the mobile phone obtains the 1Mb first physical memory block from the system kernel through the memory allocation thread, it can allocate the 1Mb first physical memory block to the data recovery thread so that the data recovery thread can subsequently recover the screenshot cache data of the application interface of application A.

[0114] In some embodiments of this application, after the electronic device has obtained the first physical memory block through the memory allocation thread, it may allocate the right to use the first physical memory block to the data recovery thread.

[0115] It should be noted that, for the specific implementation process of allocating the right to use the first physical memory block to the data recovery thread after the electronic device has requested the first physical memory block through the memory allocation thread, please refer to the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0116] Step 202a: The electronic device requests a second physical memory block from the system kernel through the memory request thread, and performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total amount of data through the data recovery thread.

[0117] In some embodiments of this application, after allocating the first physical memory block to the data recovery thread, the electronic device can request a second physical memory block from the system kernel through a memory request thread.

[0118] For example, taking scenario 1 as an example, assuming that the second physical memory block is 2Mb in size, after the mobile phone obtains the 2Mb first physical memory block from the system kernel through the memory allocation thread, it can allocate the 2Mb first physical memory block to the data recovery thread so that the data recovery thread can subsequently recover the screenshot cache data of application A's application interface.

[0119] In some embodiments of this application, after the electronic device obtains a second physical memory block through the memory allocation thread, it may allocate the right to use the second physical memory block to the data recovery thread.

[0120] It should be noted that, for the specific implementation process of allocating the right to use the second physical memory block to the data recovery thread after the electronic device has requested the second physical memory block through the memory allocation thread, please refer to the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0121] In some embodiments of this application, the electronic device can recover the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data volume through a data recovery thread.

[0122] It should be noted that the specific implementation process of restoring the first screenshot cache data of the first application screenshot through the data recovery thread of the electronic device based on the physical memory block corresponding to the first total amount of data can be found in the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0123] In this way, electronic devices can request physical memory blocks from the system kernel for screenshot data recovery through a memory allocation thread. Once a physical memory block is allocated, it is directly assigned to the recovery thread. Then, the next physical memory block is requested. While requesting the next physical memory block, the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the aforementioned physical memory block. This decouples memory allocation from data recovery, shortens the recovery time of screenshot cache data, and improves the recovery efficiency of screenshot cache.

[0124] In some embodiments of this application, step 201a can be implemented by step 201a2. Step 202 can be implemented by step 202b.

[0125] Step 201b: Upon receiving the first input, and the first input being used to trigger the display of an application screenshot of a background running application, the electronic device obtains a first physical memory block from the memory pool through the memory allocation thread and allocates the first physical memory block to the data recovery thread.

[0126] In some embodiments of this application, when the first application screenshot is at least one application screenshot included in the multi-task preview interface, the electronic device can detect the trigger to switch from the background to the foreground to run the multi-task preview interface, and then obtain the first physical memory block from the memory pool through the memory allocation thread.

[0127] For example, taking scenario 2 as an example, assuming that the first physical memory block is 2Mb in size, after the mobile phone obtains the 2Mb first physical memory block from the memory pool through the memory application thread, it can allocate the 2Mb first physical memory block to the data recovery thread so that the data recovery thread can subsequently recover the screenshot cache data of the multi-task preview interface.

[0128] In some embodiments of this application, after the electronic device obtains the first physical memory block through the memory allocation thread, it may allocate the right to use the first physical memory block to the data recovery thread.

[0129] It should be noted that, for the specific implementation process of allocating the right to use the first physical memory block to the data recovery thread after the electronic device obtains the first physical memory block through the memory allocation thread, please refer to the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0130] Step 202b: The electronic device obtains the second physical memory block from the memory pool through the memory request thread, and performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data volume through the data recovery thread.

[0131] In some embodiments of this application, the electronic device can obtain a second physical memory block from the memory pool through a memory request thread after allocating the first physical memory block to the data recovery thread.

[0132] For example, taking scenario 2 as an example, assuming that the second physical memory block is 4Mb in size, after the mobile phone obtains the 4Mb first physical memory block from the memory pool through the memory request thread, it can allocate the 4Mb first physical memory block to the data recovery thread so that the data recovery thread can subsequently recover the screenshot cache data of the multi-task preview interface.

[0133] In some embodiments of this application, after the electronic device obtains the second physical memory block through the memory allocation thread, it may allocate the right to use the second physical memory block to the data recovery thread.

[0134] It should be noted that, for the specific implementation process of allocating the right to use the second physical memory block to the data recovery thread after the electronic device obtains the second physical memory block through the memory allocation thread, please refer to the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0135] In some embodiments of this application, the electronic device can recover the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data volume through a data recovery thread.

[0136] It should be noted that the specific implementation process of restoring the first screenshot cache data of the first application screenshot through the data recovery thread of the electronic device based on the physical memory block corresponding to the first total amount of data can be found in the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0137] In this way, the electronic device can quickly obtain physical memory blocks for screenshot data recovery from the memory pool. After obtaining a physical memory block, it will be directly allocated to the recovery thread. Then, the next physical memory block will be obtained. At the same time as obtaining the next physical memory block, the data recovery thread will recover the first screenshot cache data of the first application screenshot based on the aforementioned physical memory block. This decouples memory allocation and data recovery, shortens the recovery time of screenshot cache data, and improves the recovery efficiency of screenshot cache.

[0138] In some embodiments of this application, combined with Figure 1 ,like Figure 4 As shown, step 202 above can be specifically implemented through steps 202c and 202d below.

[0139] Step 202c: The electronic device acquires the second physical memory block and determines the first judgment result through the data recovery thread.

[0140] In some embodiments of this application, the first judgment result described above indicates whether the total amount of the first data is greater than or equal to the first threshold.

[0141] In some embodiments of this application, the first threshold mentioned above may also be referred to as the batch recovery threshold.

[0142] In some embodiments of this application, the first threshold is greater than the first memory capacity and less than the second memory capacity.

[0143] In some embodiments of this application, the first memory capacity can be 4Kb.

[0144] In some embodiments of this application, the second memory capacity can be 5Mb.

[0145] In some embodiments of this application, the first threshold can be a fixed value, such as 1Mb. Of course, the first threshold can also be other values ​​preset by the system, which can be determined according to actual needs, and this application does not limit this.

[0146] For example, taking scenario 1 as an example, assuming that the first threshold in scenario 1 is 3Mb and the first total data is 3Mb, the mobile phone can use the data recovery thread to determine whether the first total data, i.e., 3Mb, is greater than or equal to the first threshold, i.e., 3Mb, so as to recover the screenshot cache data of application A's application interface based on the first total data in the future.

[0147] For example, taking scenario 2 as an example, assuming that the first threshold in scenario 1 is 6Mb and the first total data is 6Mb, the mobile phone can use the data recovery thread to determine whether the first total data, i.e., 6Mb, is greater than or equal to the first threshold, i.e., 6Mb, so as to recover the screenshot cache data of the multi-task preview interface based on the first total data in the future.

[0148] In some embodiments of this application, the aforementioned first total data volume corresponds to the total capacity of available physical memory blocks.

[0149] In some embodiments of this application, the electronic device can determine the first total amount of data based on memory block information of available physical memory blocks through a data recovery thread.

[0150] It should be noted that the specific implementation process for determining the first total amount of data based on the memory block information of available physical memory blocks through the data recovery thread of the electronic device can be found in the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0151] Step 202d: Based on the first judgment result mentioned above, the electronic device recovers the first screenshot cache data of the first application screenshot through at least one physical memory block.

[0152] In some embodiments of this application, the determination result of the first total data volume includes any one of the following: the first total data volume is greater than or equal to the first threshold, or the first total data volume is less than the first threshold.

[0153] In some embodiments of this application, the above-mentioned at least one physical memory block may be a physical memory block corresponding to the first total amount of data.

[0154] In some embodiments of this application, the electronic device can determine at least one physical memory block based on the judgment result of the first total amount of data, and then restore the first screenshot cache data of the first application screenshot through the at least one physical memory block.

[0155] It should be noted that the specific implementation process of determining at least one physical memory block based on the above-mentioned first total data amount of the electronic device, and then using the above-mentioned at least one physical memory block to restore the first screenshot cache data of the first application screenshot, can be found in the relevant description in the following embodiments. To avoid repetition, this application will not elaborate on it here.

[0156] In this way, the electronic device can determine whether the total amount of the first data is greater than or equal to the first threshold. Based on the determination result, while acquiring the next physical memory block, the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the already acquired physical memory block. This decouples memory allocation from data recovery, shortens the recovery time of the screenshot cache data, and improves the recovery efficiency of the screenshot cache.

[0157] In some embodiments of this application, combined with Figure 4 ,like Figure 5 As shown, step 202c can be implemented through step 202c1. Step 202d can be implemented through step 202d1 or 202d2.

[0158] Step 202c1: The electronic device acquires the second physical memory block and, through the data recovery thread, determines whether the first total capacity is greater than or equal to the first threshold.

[0159] In some embodiments of this application, the first total capacity is the total capacity of the first physical memory block and the second physical memory block corresponding to the first total data volume.

[0160] In some embodiments of this application, the first total capacity is the total capacity of the physical memory blocks corresponding to the first total data volume.

[0161] In some embodiments of this application, the electronic device can determine the first total capacity based on the memory block information of the first physical memory block and the memory block information of the second physical memory block through a data recovery thread.

[0162] For example, taking scenario 1 as an example, assuming that the capacity of the first physical memory block is 1Mb and the capacity of the second physical memory block is 2Mb, the mobile phone can pass the memory block information of the first physical memory block and the second physical memory block to the data recovery thread through the memory allocation thread, so that the mobile phone can calculate the first total capacity as 1Mb + 2Mb = 3Mb through the data recovery thread. Then, based on the relationship between the first total capacity and the first threshold, the screenshot cache data of the application interface of application A can be recovered through the physical memory block corresponding to the first total data volume.

[0163] For example, taking scenario 2, assuming the capacity of the first physical memory block is 2Mb and the capacity of the second physical memory block is 4Mb, the mobile phone can pass the memory block information of the first and second physical memory blocks to the data recovery thread through the memory allocation thread. This allows the mobile phone to calculate the first total capacity as 2Mb + 4Mb = 6Mb through the data recovery thread. Subsequently, based on the relationship between the first total capacity and the first threshold, the screenshot cache data of the multi-task preview interface can be recovered through the physical memory block corresponding to the first total data volume.

[0164] In some embodiments of this application, the electronic device can transmit the memory block information of the first physical memory block and the memory block information of the second physical memory block to the data recovery thread through the memory allocation thread, so that the data recovery thread can determine the first total capacity based on the memory block information of the first physical memory block and the memory block information of the second physical memory block.

[0165] It should be noted that the specific implementation process of the electronic device passing the memory block information of the first physical memory block and the memory block information of the second physical memory block to the aforementioned data recovery thread through the memory allocation thread can be found in the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0166] Step 202d1: When the total capacity is greater than or equal to the first threshold, the electronic device restores the first screenshot cache data of the first application screenshot based on the first physical memory block and the second physical memory block, and clears the total amount of the first data to zero.

[0167] In some embodiments of this application, when the first total capacity is greater than or equal to a first threshold, the electronic device can, through a data recovery thread, perform data recovery on the first screenshot cache data of the first application screenshot based on the first physical memory block and the second physical memory block, and clear the aforementioned first total data volume to zero.

[0168] For example, taking scenario 1, assuming the capacity of the first physical memory block is 1Mb, the capacity of the second physical memory block is 2Mb, and the first threshold is 3Mb, the mobile phone can pass the memory block information of the first and second physical memory blocks to the data recovery thread through the memory allocation thread. This allows the mobile phone to calculate the first total capacity as 1Mb + 2Mb = 3Mb. If the first total capacity of 3Mb is greater than or equal to the first threshold of 3Mb, the mobile phone can, through the data recovery thread, recover the first screenshot cache data of the first application screenshot based on the first and second physical memory blocks, and clear the total first data volume to zero.

[0169] For example, taking scenario 2, assuming the capacity of the first physical memory block is 2Mb, the capacity of the second physical memory block is 4Mb, and the first threshold is 6Mb, the phone can use the memory allocation thread to pass the memory block information of the first and second physical memory blocks to the data recovery thread. This allows the phone to calculate the first total capacity as 2Mb + 4Mb = 6Mb. If the first total capacity of 6Mb is greater than or equal to the first threshold of 6Mb, the phone can use the data recovery thread to recover the first screenshot cache data of the first application screenshot based on the first and second physical memory blocks, and then clear the total first data volume to zero.

[0170] Step 202d2: When the total capacity is less than the first threshold, the electronic device acquires the third physical memory block and, through the data recovery thread, recovers the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the total amount of first data.

[0171] In some embodiments of this application, the physical memory block corresponding to the first total amount of data includes a first physical memory block, a second physical memory block, and a third physical memory block.

[0172] In some embodiments of this application, the third physical memory block is the next physical memory block after the second physical memory block.

[0173] In some embodiments of this application, the electronic device may acquire a third physical memory block when the first total capacity is less than a first threshold, and restore the first screenshot cache data of the first application screenshot based on the first physical memory block, the second physical memory block and the third physical memory block corresponding to the first total data volume.

[0174] It should be noted that, for the case where the electronic device obtains a third physical memory block when the first total capacity is less than a first threshold, and performs data recovery on the first screenshot cache data of the first application screenshot based on the first physical memory block, the second physical memory block and the third physical memory block corresponding to the first total data amount, please refer to the relevant description in the following embodiments. To avoid repetition, this application will not elaborate further here.

[0175] In this way, electronic devices can determine whether to restore the physical memory block corresponding to the total amount of unrecovered data by judging whether the physical memory block corresponding to the total amount of data is greater than or equal to the first threshold. While realizing parallel processing of data restoration and memory block allocation, it prevents the waste of computing resources caused by electronic devices performing data restoration too frequently, and improves the recovery efficiency of screenshot cache data.

[0176] In some embodiments of this application, the data recovery method provided in this application further includes the following steps 202e and 202f.

[0177] Step 202e: After determining the first judgment result each time, the electronic device determines the second judgment result by allocating a memory thread.

[0178] In some embodiments of this application, the second judgment result described above indicates whether the cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data.

[0179] In some embodiments of this application, the aforementioned cumulative memory acquisition amount is the total capacity of the physical memory blocks acquired each time a physical memory block is acquired.

[0180] In some embodiments of this application, the electronic device can determine the cumulative memory acquisition amount based on the memory block information of a physical memory block each time a physical memory block is acquired through a memory acquisition thread.

[0181] For example, taking scenario 1, assuming the capacity of the first physical memory block is 1Mb and the capacity of the second physical memory block is 2Mb, when the mobile phone can request the second physical memory block through the memory request thread, based on the memory block information of the first physical memory block and the memory block information of the second physical memory block, the cumulative memory acquisition amount is determined to be 1Mb + 2Mb = 3Mb. Subsequently, the mobile phone can restore the screenshot cache data of the application interface of application A based on the relationship between the cumulative memory acquisition amount and the screenshot cache data size of application A, through the physical memory block corresponding to the first total data amount.

[0182] For example, taking scenario 2, assuming the capacity of the first physical memory block is 2Mb and the capacity of the second physical memory block is 4Mb, when the mobile phone can request the second physical memory block through the memory request thread, based on the memory block information of the first physical memory block and the memory block information of the second physical memory block, the cumulative memory acquisition amount is determined to be 2Mb + 3Mb = 6Mb. Subsequently, the mobile phone can restore the screenshot cache data of the application interface of application A based on the relationship between the cumulative memory acquisition amount and the screenshot cache data size of application A, through the physical memory block corresponding to the first total data amount.

[0183] Step 202f: Based on the second judgment result above, the electronic device determines whether to continue acquiring the next physical memory block.

[0184] In some embodiments of this application, the determination result of the cumulative memory acquisition includes any one of the following: the cumulative memory acquisition is greater than or equal to the capacity of the screenshot cache data, or the cumulative memory acquisition is less than the capacity of the screenshot cache data.

[0185] It is understood that in some embodiments of this application, the electronic device can determine whether it has already obtained a memory block sufficient for data recovery of the first screenshot cache data of the first application screenshot through the memory allocation thread based on the judgment result of the above-mentioned cumulative memory acquisition amount. If it is determined that a memory block sufficient for data recovery of the first screenshot cache data of the first application screenshot has been obtained through the memory allocation thread, then it is not necessary to continue to acquire the next physical memory block; otherwise, it is necessary to continue to acquire the next physical memory block.

[0186] In this way, the electronic device can determine whether to restore the physical memory block corresponding to the first data volume by judging whether the total amount of the first data is greater than the first threshold, and determine whether to obtain the next physical memory block by judging whether the cumulative memory acquisition is greater than or equal to the capacity of the screenshot cache data. This realizes that when it is necessary to restore the screenshot cache data of the first application interface, after obtaining a physical memory block, the physical memory block is directly allocated to the restoration thread, and then the next physical memory block is obtained. At the same time as obtaining the next physical memory block, the data restoration thread restores the first screenshot cache data of the first application screenshot based on the aforementioned physical memory block. This decouples memory allocation and data restoration, shortens the restoration time of the screenshot cache data, and improves the restoration efficiency of the screenshot cache.

[0187] In some embodiments of this application, the data recovery method provided in this application further includes the following steps 202g and 202h.

[0188] Step 202g: The electronic device uses a memory request thread to determine whether the first cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data mentioned above.

[0189] In some embodiments of this application, the first cumulative memory acquisition amount is the total capacity of the first physical memory block and the second physical memory block.

[0190] In some embodiments of this application, the first cumulative memory acquisition amount mentioned above refers to the value of the cumulative memory acquisition amount at the current moment.

[0191] In some embodiments of this application, the first cumulative memory acquisition amount is a fixed value, the size of which is equal to the total capacity of the first physical memory block and the second physical memory block.

[0192] In some embodiments of this application, the electronic device can determine the first cumulative memory acquisition amount based on the memory block information of the first physical memory block and the memory block information of the second physical memory block.

[0193] It should be noted that the specific implementation process for determining the first cumulative memory acquisition amount based on the memory block information of the first physical memory block and the memory block information of the second physical memory block of the electronic device can be found in the relevant description in the above embodiments. To avoid repetition, this application will not repeat it here.

[0194] Step 202h: If the first cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, the electronic device acquires the fourth physical memory block and, through the data recovery thread, performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount.

[0195] In some embodiments of this application, the physical memory block corresponding to the first total data volume mentioned above includes a fourth physical memory block.

[0196] In some embodiments of this application, if the first cumulative memory acquisition amount is less than the capacity of the screenshot cache data, the electronic device can determine that it has not yet acquired a memory block sufficient for data recovery of the first screenshot cache data of the first application screenshot through the memory acquisition thread, and the electronic device needs to acquire a fourth physical memory block.

[0197] For example, taking scenario 1 as an example, assuming that the first cumulative memory acquisition amount in scenario 1 is 3Mb and the capacity of the screenshot cache data of the application interface of social application A is 5Mb, then after the mobile phone determines that the first cumulative memory acquisition amount is less than the capacity of the screenshot cache data of the application interface of social application A, it can acquire the fourth physical memory block through the mobile phone and restore the screenshot cache data of the application interface of application A through the physical memory block corresponding to the first total data amount.

[0198] For example, taking scenario 2 as an example, assuming that the first cumulative memory acquisition amount in scenario 1 is 6Mb and the capacity of the screenshot cache data of the multi-task preview interface is 10Mb, then after the mobile phone determines that the first cumulative memory acquisition amount is less than the capacity of the screenshot cache data of the multi-task preview interface, it can acquire the fourth physical memory block through the mobile phone and restore the screenshot cache data of the multi-task preview interface through the physical memory block corresponding to the first total data amount.

[0199] In this way, the electronic device can determine whether to restore the physical memory block corresponding to the first data volume by judging whether the total amount of the first data is greater than the first threshold. If the cumulative memory acquisition is less than the capacity of the screenshot cache data, it can continue to acquire the next physical memory block through the memory allocation thread. This achieves the following: when it is necessary to restore the screenshot cache data of the first application interface, after acquiring a physical memory block, it directly allocates the physical memory block to the restoration thread, and then acquires the next physical memory block. While acquiring the next physical memory block, the data restoration thread restores the first screenshot cache data of the first application screenshot based on the aforementioned physical memory block. This decouples memory allocation from data restoration, shortens the recovery time of the screenshot cache data, and improves the recovery efficiency of the screenshot cache.

[0200] In some embodiments of this application, step 202h can be specifically implemented by step 202h1 as described below.

[0201] Step 202h1: When the first cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, the electronic device acquires a fourth physical memory block. When the capacity of the fourth physical memory block corresponding to the first total data amount is less than the first threshold and the second cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, the electronic device performs data recovery on the first screenshot cache data of the first application screenshot based on the fourth physical memory block.

[0202] In some embodiments of this application, the second cumulative memory acquisition amount is the total capacity of the first physical memory block, the second physical memory block, and the fourth physical memory block.

[0203] In some embodiments of this application, when the second cumulative memory acquisition amount is greater than or equal to the capacity of the screenshot cache data, the electronic device can determine that it has already acquired a memory block sufficient for data recovery of the first screenshot cache data of the first application screenshot through the memory acquisition thread, and the electronic device does not need to acquire the next physical memory block.

[0204] For example, taking scenario 1 as an example, assuming that the second cumulative memory acquisition amount in scenario 1 is 5Mb and the capacity of the screenshot cache data of the application interface of social application A is 5Mb, then after the mobile phone determines that the second cumulative memory acquisition amount is equal to the capacity of the screenshot cache data of the application interface of social application A, it can restore the screenshot cache data of the application interface of social application A through the fourth physical memory block.

[0205] For example, taking scenario 2 as an example, assuming that the second cumulative memory acquisition amount in scenario 1 is 10Mb and the capacity of the screenshot cache data of the multitasking preview interface is 10Mb, then after the mobile phone determines that the second cumulative memory acquisition amount is equal to the capacity of the screenshot cache data of the multitasking preview interface, it can restore the screenshot cache data of the multitasking preview interface through the fourth physical memory block.

[0206] In this way, when the electronic device determines that the total amount of the first data is less than the first threshold and the cumulative memory acquisition is greater than or equal to the capacity of the screenshot cache data, it can directly perform data recovery based on the physical memory block corresponding to the total amount of the first data, thereby realizing the complete data recovery process of the first application screenshot. When it is necessary to recover the screenshot cache data of the first application interface, after obtaining a physical memory block, it directly allocates the physical memory block to the recovery thread, and then obtains the next physical memory block. While obtaining the next physical memory block, the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the aforementioned physical memory block. This decouples memory allocation and data recovery, shortens the recovery time of the screenshot cache data, and improves the recovery efficiency of the screenshot cache.

[0207] In some embodiments of this application, combined with Figure 1 ,like Figure 6 As shown, step 202 above can be implemented through step 202j below.

[0208] Step 202j: When the capacity of the first physical memory block is less than the first threshold and the third cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, the electronic device acquires the second physical memory block and, through the data recovery thread, performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount.

[0209] In some embodiments of this application, the third cumulative memory acquisition amount is the capacity of the first physical memory block.

[0210] In some embodiments of this application, when the capacity of the first physical memory block is less than a first threshold and the third cumulative memory acquisition amount is less than the capacity of the screenshot cache data, the electronic device can retain the first physical memory block, determine that the capacity of the currently acquired physical memory block is insufficient to recover the first screenshot cache data of the first application screenshot, thereby acquiring the second physical memory block, and recovering the first screenshot cache data of the first application screenshot through the data recovery thread based on the physical memory block corresponding to the first total data amount.

[0211] For example, taking scenario 1 as an example, assuming that in scenario 1, the capacity of the first physical memory block obtained by the mobile phone is 1Mb, the first threshold is 3Mb, the third cumulative memory obtained is 1Mb, and the capacity of the screenshot cache data of the application interface of social application A is 5Mb, then the mobile phone can retain the first physical memory block and determine that the capacity of the currently obtained physical memory block is insufficient to restore the screenshot cache data of the application interface of social application A, thereby obtaining the second physical memory block, and through the data recovery thread, restore the screenshot cache data of the application interface of social application A based on the physical memory block corresponding to the first total amount of data.

[0212] For example, taking scenario 2, assuming that in scenario 2, the capacity of the first physical memory block obtained by the mobile phone is 2Mb, the first threshold is 6Mb, the third cumulative memory obtained is 2Mb, and the capacity of the screenshot cache data of the multi-task preview interface is 10Mb, then the mobile phone can retain the first physical memory block and determine that the capacity of the currently obtained physical memory block is insufficient to restore the screenshot cache data of the multi-task preview interface. In this way, the second physical memory block is obtained, and the screenshot cache data of the multi-task preview interface is restored through the data recovery thread based on the physical memory block corresponding to the first total amount of data.

[0213] In this way, when the electronic device determines that the total amount of the first data is less than the first threshold and the cumulative memory acquisition is less than the capacity of the screenshot cache data, it can perform data recovery while simultaneously acquiring the next physical memory block through the memory allocation thread. This achieves the following: when it is necessary to recover the screenshot cache data of the first application interface, after acquiring a physical memory block, it directly allocates the physical memory block to the recovery thread, and then acquires the next physical memory block. While acquiring the next physical memory block, the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the aforementioned physical memory block. This decouples memory allocation from data recovery, shortens the recovery time of the screenshot cache data, and improves the recovery efficiency of the screenshot cache.

[0214] In some embodiments of this application, the first application screenshot mentioned above refers to screenshots of at least two applications in the multitasking preview interface. Step 202 can be specifically implemented through steps 202k1 to 202k3 described below.

[0215] Step 202k1: The electronic device acquires the second physical memory block and obtains the recovery list corresponding to the cached data in the first screenshot.

[0216] In some embodiments of this application, the recovery list includes screenshot cache data of the at least two application screenshots sorted by display priority, wherein the at least two application screenshots are application screenshots of background running applications.

[0217] In some embodiments of this application, the aforementioned second physical memory block may be a physical memory block obtained by the electronic device from the memory pool through a memory allocation thread.

[0218] In some embodiments of this application, the recovery list includes screenshot cache data of at least one second application interface sorted by display priority.

[0219] In some embodiments of this application, the recovery list described above is an ordered data structure used to store screenshot cache data.

[0220] In some embodiments of this application, the recovery list described above includes at least one node.

[0221] In some embodiments of this application, each node in the recovery list corresponds to a screenshot cache data of an application interface.

[0222] For example, taking scenario 2, assume that the applications running in the background of the mobile phone are shopping application B, video application C, shopping application B, social application B, shopping application C, and social application C. In scenario 2, the recovery list includes nodes 1 to 6, which correspond to the screenshot cache data of shopping application B, video application C, shopping application B, social application B, shopping application C, and social application C, respectively.

[0223] In some embodiments of this application, the above-mentioned display priority can also be simply referred to as priority.

[0224] In some embodiments of this application, the above-mentioned display priority refers to the display priority of the screenshot cache data of the application interface.

[0225] In some embodiments of this application, the above display priority includes: a first display priority and a second display priority.

[0226] In some embodiments of this application, the display priority of screenshot cache data of an application interface is determined by whether the application interface is about to be displayed in the multitasking preview interface.

[0227] In some embodiments of this application, when an application interface is about to be displayed in the multitasking preview interface, the display priority of the screenshot cache data of that application interface is the first display priority. Alternatively, when an application interface will not be displayed in the multitasking preview interface, the display priority of the screenshot cache data of that application interface is the second display priority. The application corresponding to that application interface is an application currently running in the background.

[0228] For example, taking scenario 2, assume that the following applications are running in the background of the phone: shopping application B, video application C, shopping application B, social application B, shopping application C, and social application C. The interfaces of shopping application B and video application B will soon be displayed in the phone's multitasking preview interface. In scenario 1, the display priority of the screenshot cache data of shopping application B and video application C is the first display priority, while the display priority of the screenshot cache data of shopping application B, social application B, shopping application C, and social application C is the second display priority.

[0229] In some embodiments of this application, the at least one second application interface is the application interface in the multitasking preview interface.

[0230] In some embodiments of this application, the recovery list corresponding to the screenshot cache data mentioned above refers to the recovery list containing the first screenshot cache data of the first application screenshot mentioned above.

[0231] In some embodiments of this application, the electronic device can read the recovery list through a data recovery thread to recover the first screenshot cache data of the first application screenshot based on the screenshot cache data included in the recovery list.

[0232] It should be noted that the specific implementation process of the electronic device reading the above-mentioned recovery list through the data recovery thread, and performing data recovery on the first screenshot cache data of the first application screenshot based on the screenshot cache data included in the above-mentioned recovery list, can be found in the relevant description in the following embodiments. To avoid repetition, this application will not elaborate further here.

[0233] Step 202k2: The electronic device uses at least one data recovery thread to recover the N screenshot cache data with the first display priority in the recovery chain based on the physical memory block corresponding to the first total amount of data.

[0234] In some embodiments of this application, the at least one data recovery thread can be K data recovery threads, where K is a positive integer.

[0235] In some embodiments of this application, when K is 1, the electronic device can use a data recovery thread to sequentially recover the N screenshot cache data with the first display priority in the recovery chain based on the physical memory block corresponding to the first total amount of data.

[0236] In some embodiments of this application, when K is an integer greater than 1, the electronic device can allocate the N screenshot cache data with the first display priority in the recovery chain to the K data recovery threads, so that the K data recovery threads can perform data recovery on the N screenshot cache data with the first display priority in the recovery chain in parallel.

[0237] For example, taking scenario 2, suppose that in scenario 2, the display priority of the screenshot cache data of shopping app B and video app C is the first display priority, and suppose that K is 2, meaning that the phone recovers the screenshot cache data of shopping app B through data recovery thread A and data recovery thread B. Suppose that the phone can assign the screenshot cache data of shopping app B to data recovery thread A and the screenshot cache data of video app C to data recovery thread B, then the phone can simultaneously recover the screenshot cache data of video app C through data recovery thread B while simultaneously recovering the screenshot cache data of shopping app B through data recovery thread A.

[0238] In some embodiments of this application, the electronic device may distribute the above-mentioned N screenshot cache data equally among the above-mentioned K data recovery threads.

[0239] Step 202k3: The electronic device uses at least one data recovery thread to recover the M screenshot cache data with the second display priority in the recovery chain based on the physical memory block corresponding to the first total amount of data.

[0240] Among them, the first display priority is higher than the second display priority.

[0241] In some embodiments of this application, N and M are both positive integers.

[0242] In some embodiments of this application, when K is 1, the electronic device can use a data recovery thread to sequentially recover the M screenshot cache data with the second display priority in the recovery chain based on the physical memory block corresponding to the first total amount of data.

[0243] In some embodiments of this application, when K is an integer greater than 1, the electronic device can allocate the M screenshot cache data with the second display priority in the recovery chain to the K data recovery threads, so that the M second screenshot cache data with the second display priority in the recovery chain can be recovered in parallel by the K data recovery threads.

[0244] In some embodiments of this application, when the at least one data recovery thread includes a first data recovery thread and a second data recovery thread, the electronic device can use the first data recovery thread to recover the M screenshot cache data in ascending order based on the arrangement order of the M screenshot cache data in the recovery chain, and use the second data recovery thread to recover the M screenshot cache data in descending order based on the arrangement order of the M screenshot cache data in the recovery chain.

[0245] It should be noted that, for the electronic device, the first data recovery thread restores the M screenshot cache data in ascending order based on the arrangement order of the M screenshot cache data in the recovery chain, and the second data recovery thread restores the M screenshot cache data in descending order based on the arrangement order of the M screenshot cache data in the recovery chain. For the specific implementation process, please refer to the relevant description in the following embodiments. To avoid repetition, this application will not repeat it here.

[0246] In this way, the electronic device can restore the screenshot cache data with the first display priority by restoring the recovery list, and then restore the screenshot cache data with the second display priority. Furthermore, the electronic device can restore the screenshot cache data simultaneously through at least two data recovery threads, which speeds up the data recovery process, shortens the recovery time, and improves the recovery efficiency of the screenshot cache.

[0247] In some embodiments of this application, the at least one data recovery thread includes a first data recovery thread and a second data recovery thread. Step 202k3 can be specifically implemented through step 302k3 described below.

[0248] Step 302k3: Based on the physical memory block corresponding to the first total amount of data, the electronic device performs data recovery on the screenshot cache data in the first order, starting from the first screenshot cache data in the M screenshot cache data through the first data recovery thread, and simultaneously performs data recovery on the screenshot cache data in the second order, starting from the last screenshot cache data in the M screenshot cache data through the second data recovery thread.

[0249] In some embodiments of this application, the above-mentioned data recovery of screenshot cache data in the first order means recovering the above-mentioned M screenshot cache data in the same order as the arrangement order of the above-mentioned M screenshot cache data in the recovery chain.

[0250] In some embodiments of this application, the above-mentioned data recovery of screenshot cache data in the second order refers to recovering the above-mentioned M screenshot cache data in the order opposite to the order in which the above-mentioned M screenshot cache data are arranged in the recovery chain, in sequence.

[0251] For example, taking scenario 2, suppose the following applications are running in the background of the phone: shopping application B, video application C, shopping application B, social application B, shopping application C, and social application C. Assume that the screenshot cache data of shopping application B and video application C has the highest display priority, meaning their screenshot cache data is for immediate display, while the screenshot cache data of shopping application B, social application B, shopping application C, and social application C are for future display. Assume the phone uses data recovery thread A and data recovery thread B to recover the screenshot cache data included in the recovery list. For example... Figure 7 As shown in Scenario 2, the recovery chain includes nodes 70 to 75, corresponding to screenshot cache data of shopping application B, video application C, shopping application B, social application B, shopping application C, and social application C, respectively. The mobile phone can recover the screenshot cache of shopping application B through data recovery thread A, and simultaneously recover the screenshot cache of video application C through recovery thread B. After the mobile phone completes the recovery of the screenshot cache data of shopping application B through data recovery thread A, it recovers the screenshot cache data of the second display priority in the order of shopping application B, social application B, shopping application C, and social application C in sequence through data recovery thread A. After the mobile phone completes the recovery of the screenshot cache data of shopping application B through data recovery thread B, it recovers the screenshot cache data of the second display priority in the order of social application C, shopping application C, social application B, and shopping application B in sequence through data recovery thread B.

[0252] In this way, electronic devices can use two data recovery threads to perform bidirectional parallel recovery of the screenshot cache data with the second display priority in the recovery list. On the one hand, the total recovery time is greatly reduced by the parallel execution of the two threads. On the other hand, since the traversal direction is completely opposite and the task intervals do not overlap, the conflict problem of the two threads repeatedly recovering the same screenshot cache is avoided, thereby shortening the recovery time of the screenshot cache data and improving the recovery efficiency of the screenshot cache.

[0253] In some embodiments of this application, the data recovery method provided in this application further includes the following steps 301a and 301b.

[0254] Step 301a: If the duration of the second application interface displayed on the foreground by the electronic device exceeds the second threshold, the screenshot cache data of the second application interface is released by releasing the thread, and the capacity of the second screenshot cache data is determined.

[0255] In some embodiments of this application, the second threshold can be a fixed value, such as 3s. Of course, the second threshold can also be other values ​​preset by the system, which can be determined according to actual needs, and this application does not limit this.

[0256] In some embodiments of this application, the release thread is used to automatically release the screenshot cache data of an application interface when the display time of an application interface exceeds a second threshold, and to count the capacity of the second screenshot cache data and synchronize the capacity of the second screenshot cache data to the asynchronous memory allocation thread.

[0257] In some embodiments of this application, the release thread can determine the total capacity of the released screenshot cache data corresponding to the second application interface based on the total capacity of the memory block storing the screenshot cache data corresponding to the second application interface.

[0258] In some embodiments of this application, the second threshold can be determined through offline experiments. Specifically, the electronic device can actively release the screenshot cache through offline testing, statistically analyze the abnormal scenarios that occur, and identify the usage scenarios of the screenshot cache to obtain the usage timing of the screenshot cache in the system. Based on the usage timing of the screenshot cache in the system, the release and restoration timing of the screenshot cache can be determined.

[0259] For example, such as Figure 8 As shown, the above offline test includes the following process: First, when the electronic device detects that the user has manually cleared the background of the third application, it releases the third screenshot cache data of the third application. Then, the electronic device counts the scenarios in which the third screenshot cache data needs to be used. Based on the scenarios in which the third screenshot cache data needs to be used, the electronic device determines when to restore the third screenshot cache data.

[0260] In some embodiments of this application, the timing for restoring the third screenshot cache data refers to the moment when the electronic device detects an application screenshot used to trigger the display of a third application.

[0261] In some embodiments of this application, the electronic device may use 3 seconds after entering the application as the time to release the screenshot cache.

[0262] In some embodiments of this application, the electronic device may determine the timing of restoring the screenshot cache as the timing of entering the application or entering the multitasking preview interface.

[0263] In some embodiments of this application, when the electronic device releases screenshot cache data through a release thread, it records the information of the screenshot cache data released by the current release thread under the release thread name, on a thread-by-thread basis.

[0264] In some embodiments of this application, the information of the screenshot cache data includes: the capacity information of the screenshot cache data, the display priority information of the screenshot cache data, the release time information of the screenshot cache data, and the storage location information of the screenshot cache data. Of course, the information of the screenshot cache data may also include other information of the screenshot cache data, which can be determined according to actual needs, and this application does not limit it.

[0265] In some embodiments of this application, after the electronic device releases the screenshot cache data through the release thread, it can insert the released screenshot cache into the head of the release list through the release thread, and determine the insertion position of the released screenshot cache based on the information of the screenshot cache data.

[0266] Step 301b: The electronic device sends the second screenshot cache data capacity to the asynchronous memory request thread through the release thread.

[0267] In some embodiments of this application, the aforementioned asynchronous memory allocation thread is a designated memory allocation thread. The electronic device receives the second screenshot cache data capacity sent by the release thread through the asynchronous memory allocation thread, and uses this as a basis to apply for a physical memory block of the corresponding size from the system kernel and store it in the memory pool as a physical memory block for subsequent recovery of the screenshot cache data.

[0268] In some embodiments of this application, the asynchronous memory allocation thread described above can be a thread created in advance by the electronic device.

[0269] In some embodiments of this application, the electronic device receives the second screenshot cache data capacity through the aforementioned asynchronous memory allocation thread, can apply for a physical memory block corresponding to the second screenshot cache data capacity through the asynchronous memory allocation thread, and stores the applied physical memory block in the memory pool.

[0270] It should be noted that the specific implementation process of the electronic device receiving the second screenshot cache data capacity through the above-mentioned asynchronous memory allocation thread, allocating the physical memory block corresponding to the second screenshot cache data capacity through the asynchronous memory allocation thread, and storing the allocated physical memory block in the memory pool can be found in the relevant description in the following embodiments. To avoid repetition, this application will not elaborate further here.

[0271] In this way, the electronic device can release the screenshot cache data of an application interface after it has run for more than the second threshold. This reduces the system computing resources occupied by the screenshot cache data and prevents system lag caused by excessive screenshot cache data. Furthermore, after the electronic device releases the screenshot cache data of an application interface through the release thread, it records the screenshot cache data information of that application interface under the name of the release thread. Subsequently, the electronic device can send the second screenshot cache data capacity to the asynchronous memory allocation thread through the release thread. This allows the asynchronous memory allocation thread to pre-allocate physical memory blocks from the memory pool based on the second screenshot cache data capacity and store the allocated physical memory blocks in the memory pool. This facilitates the memory allocation thread to quickly obtain physical memory blocks from the memory pool when restoring the screenshot cache data, saving the time of obtaining memory blocks and improving the recovery efficiency of the screenshot cache.

[0272] In some embodiments of this application, after step 301b above, the data recovery method provided by the embodiments of this application further includes steps 301c and 301d as described below.

[0273] Step 301c: The electronic device requests at least one physical memory block from the system kernel based on the cached data capacity of the second screenshot through an asynchronous memory request thread.

[0274] In some embodiments of this application, the total capacity of the at least one physical memory block is greater than or equal to the capacity of the cached data in the second screenshot.

[0275] In some embodiments of this application, the electronic device may request at least one physical memory block from the system kernel via an asynchronous memory request thread.

[0276] Specifically, when an electronic device requests a physical memory block from the system kernel through an asynchronous memory request thread, the asynchronous memory request thread first generates a memory request, and then sends a request to the kernel through the memory allocation interface provided by the system kernel. The kernel first searches the free physical memory pool it manages. After finding a contiguous physical memory region, it maps the physical address of the region to the virtual address space of the asynchronous memory request thread, and updates the physical memory usage status flag to avoid duplicate allocation. Finally, the kernel returns a successful request response and metadata such as the virtual address and physical address of the memory block to the asynchronous memory request thread.

[0277] In some embodiments of this application, the memory pool described above may also be referred to as a screenshot cache memory pool.

[0278] In some embodiments of this application, the total capacity of the at least one physical memory block is greater than or equal to the total capacity of the released screenshot cache data corresponding to the second application interface.

[0279] Step 301d: The electronic device stores at least one physical memory block into the memory pool through an asynchronous memory request thread.

[0280] The aforementioned asynchronous memory allocation thread is a memory allocation thread used to request physical memory blocks and store them in the memory pool.

[0281] In some embodiments of this application, the aforementioned asynchronous memory allocation thread may also be referred to as the screenshot cache memory allocation thread.

[0282] In some embodiments of this application, the electronic device can use an asynchronous memory request thread to record the metadata of at least one physical memory block into the management list of the memory pool, ensuring that the memory block can be quickly acquired by the memory request thread in the future.

[0283] In some embodiments of this application, the electronic device may set a timeout recycling mechanism for the memory pool, so that if the physical memory blocks in the memory pool are not accessed or referenced by any process or module for a continuous period of time exceeding a preset debugging time threshold, all physical memory blocks in the memory pool will be automatically cleared and recycled.

[0284] In some embodiments of this application, the preset debugging time threshold can be a fixed value, such as 10s. Of course, the preset debugging time threshold can also be other values ​​preset by the system. The specific value can be determined according to actual needs, and this application does not limit it.

[0285] It is understandable that setting the timeout recycling mechanism for the aforementioned memory pool in electronic devices can prevent the memory pool from increasing system memory usage pressure due to the failure to reclaim idle physical memory blocks in a timely manner.

[0286] In some embodiments of this application, during the process of batch restoring screenshot cache data, the electronic device can cancel the timeout recycling mechanism of the memory pool, and then restart the timeout recycling mechanism of the memory pool after the electronic device has completed the batch recycling of the screenshot cache data.

[0287] In this way, the electronic device can send the total capacity of the released screenshot cache data to the asynchronous memory request thread through the release thread. This allows the asynchronous memory request thread to pre-allocate physical memory blocks from the memory pool based on the total capacity of the released screenshot cache data and store the allocated physical memory blocks in the memory pool. This makes it easier for the memory request thread to quickly obtain physical memory blocks from the memory pool when restoring the screenshot cache data, saving the time of obtaining memory blocks and improving the recovery efficiency of the screenshot cache.

[0288] In some embodiments of this application, the data recovery method provided in this application further includes the following step 203.

[0289] Step 203: After restoring all the cached data of the first screenshot to the physical memory block, the electronic device displays the first application screenshot based on the cached data of the first screenshot through the application corresponding to the first application screenshot.

[0290] In some embodiments of this application, the data recovery method provided in this application introduces a passive recovery mechanism. Specifically, the electronic device will wait for the first screenshot cache data of the first application screenshot to be fully recovered before returning the recovered screenshot cache data to the application corresponding to the first application screenshot, so as to avoid the problem of abnormal display caused by the application using the screenshot cache data that has not been fully recovered.

[0291] For example, taking scenario 1 as an example, the mobile phone will wait for the screenshot cache data of social application A to be fully restored before returning the screenshot cache data of social application A to application A, so as to avoid abnormal display problems such as screen flickering caused by social application A using screenshot cache data that has not been fully restored.

[0292] For example, taking scenario 2 as an example, assuming that the multitasking preview interface of the mobile phone includes the application interfaces of shopping application B and video application C, the mobile phone can wait until the application interfaces of shopping application B and video application C are fully restored before returning the application interface cache data of shopping application B and video application C to shopping application B and video application C respectively, so as to avoid display abnormalities such as screen flickering caused by shopping application B or video application C using screenshot cache data that has not been fully restored.

[0293] In this way, the electronic device will only return the screenshot cache data of an application interface to the application corresponding to that application interface after it has completed the recovery of the screenshot cache data of the application interface, thus avoiding abnormal phenomena such as screen flickering caused by slow data recovery speed.

[0294] This application proposes a data recovery method that ensures both the safe release of screenshot cache and its rapid recovery. The proposed data recovery method can be applied to scenarios involving the recovery of screenshot cache data from a single application interface. For example, as shown... Figure 9 As shown, the data recovery method proposed in this application may include the following steps 40 to 50:

[0295] Step 40: The electronic device receives the first input.

[0296] Step 41: The electronic device acquires the first physical memory block.

[0297] Step 42: The electronic device determines whether the cumulative memory acquisition amount is greater than or equal to the cached data capacity of the first screenshot. If yes, proceed to step 49; otherwise, proceed to step 43.

[0298] Step 43: The electronic device acquires the second physical memory block.

[0299] Step 44: The electronic device allocates the second physical memory block to the data recovery thread.

[0300] Step 45: The electronic device determines the first total amount of data through the data recovery thread.

[0301] Step 46: The electronic device determines whether the total amount of the first data is greater than or equal to the first threshold. If yes, then execute steps 47a and 47b below, and then jump to step 48 below; if no, then execute step 47c below, and then jump to step 48 below.

[0302] Step 47a: The electronic device restores the data to the physical memory block corresponding to the first total amount of data.

[0303] Step 47b: The electronic device clears the first total data volume to zero.

[0304] Step 47c: The electronic device records the information of the physical memory block.

[0305] Step 48: The electronic device updates the cumulative memory acquisition amount. After completing step 48, the electronic device jumps to step 42 above.

[0306] Step 49: The electronic device recovers the cached data of the first screenshot using the physical memory block corresponding to the total amount of the first data.

[0307] Step 50: Electronic device recovery complete.

[0308] In some embodiments of this application, the data recovery method proposed in this application can be applied to scenarios involving data recovery of multiple screenshot cache data, that is, scenarios involving data recovery of screenshot cache data of multiple application interfaces corresponding to a multi-task preview interface. For example, as... Figure 10 As shown, the data recovery method proposed in this application may include the following steps 32 to 36. Among them, step 32 is the process of releasing the screenshot cache data, hereinafter referred to as the release process; step 33 is the process of batch recovering the screenshot cache data, hereinafter referred to as the batch recovery process.

[0309] Step 32: The electronic device releases the second screenshot cache data by releasing the thread and determines the capacity of the second screenshot cache data.

[0310] Step 33: The electronic device cancels the screenshot cache memory pool timeout mechanism and obtains the second screenshot cache data capacity.

[0311] Step 34: The electronic device sends the determined second screenshot cache data capacity to the asynchronous memory request thread.

[0312] Step 35: The electronic device iterates through and retrieves the current screenshot cache to be recovered, and recovers the screenshot cache. Then, it determines whether there are any more screenshot caches to be recovered. If yes, then repeat step 34; otherwise, proceed to step 36 below.

[0313] Step 36: Electronic device starts memory pool timeout mechanism.

[0314] It is understandable that the execution of step 36 signifies the completion of the entire recovery process.

[0315] This application provides a screenshot cache data management scheme that safely releases screenshot cache data when not in use and quickly restores it when needed, i.e., an on-demand scheduling scheme. This reduces the proportion of screenshot cache data in memory, lowers system memory pressure, and thus reduces lag issues caused by insufficient memory. The screenshot cache data management scheme provided in this application specifically includes the following processes:

[0316] First, offline testing was used to determine the time points for releasing the screenshot cache and restoring the screenshot data.

[0317] Specifically, the application's screenshot cache is released 3 seconds after entering the application, and restored on the Nth time the application is entered or when entering the multitasking preview interface. Specifically, on the Nth time the application is entered, the screenshot cache of the current application is restored; when entering the multitasking preview interface, the screenshot caches of all background applications are restored, where N is an integer greater than 1.

[0318] Secondly, when recovering screenshot data, a memory allocation thread and a data recovery thread are used to achieve parallel operation of memory allocation and data recovery.

[0319] Specifically, during screenshot data recovery, each time a memory allocation thread acquires a physical memory block, it passes that physical memory block to the data recovery thread. The data recovery thread records the size of that memory block and accumulates the total amount of unrecovered data. It also determines whether the total amount of unrecovered data exceeds a first threshold. If it does, the data recovery operation is performed based on all the physical memory blocks acquired by the current memory allocation thread; otherwise, it continues to wait for the memory allocation thread to acquire the next physical memory block.

[0320] In addition, the memory required for data recovery should be requested in advance before performing screenshot data recovery.

[0321] Specifically, an asynchronous memory allocation thread is created to pre-allocate the physical memory blocks needed for data recovery. During screenshot cache release, information such as the corresponding application information and the size of the screenshot cache released by the current release thread is recorded under the release thread's name, and the released screenshot cache is inserted at the head of the release list. During batch recovery, i.e., when a user enters the multi-task preview interface, the total capacity of the screenshot cache already released by the current data recovery thread is obtained. This total capacity of the currently released screenshot cache is passed to the aforementioned asynchronous memory allocation thread. The asynchronous memory allocation thread then synchronously allocates memory with the regular memory allocation thread, and the memory blocks allocated asynchronously are stored in the memory pool. Combined with the aforementioned first threshold, it is determined whether data recovery should be performed.

[0322] Finally, during batch data recovery, two parallel data recovery threads, such as thread a and thread b, are used to prioritize the parallel recovery of high-priority screenshot caches. After either thread completes the data recovery of its assigned high-priority screenshot cache, it starts recovering low-priority screenshot caches from the beginning. After the other thread completes the data recovery of its assigned high-priority screenshot cache, it starts recovering low-priority screenshot caches from the end.

[0323] It should be noted that each of the above method embodiments, or various possible implementations of each method embodiment, can be executed individually or in combination of any two or more. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0324] For the various scenarios in which the embodiments of this application can be applied, and in conjunction with the various implementation schemes of the embodiments of this application described above, specific examples are given below to illustrate the implementation process of the embodiments of this application in various scenarios:

[0325] Example 1: Assume a social media app A is running in the background on a mobile phone. Assume the screenshot cache size of social media app A is 5MB, and the first threshold is 3MB. When a user triggers the phone to switch from the background to the foreground of the social media app A, the phone first allocates physical memory block 'a' through a memory allocation thread. Assume the size of physical memory block 'a' is 1MB. The memory allocation thread then passes the memory block information of memory block 'a' to the data recovery thread and records the cumulative memory acquisition as 1MB. The data recovery thread records the first total data volume as 1MB. Next, it checks whether the first total data volume, 1MB, is equal to or greater than the first threshold, 3MB. If it finds that 1MB < 3MB (meaning the first total data volume is less than the first threshold), the phone continues to check whether the cumulative memory acquisition volume, 1MB, is greater than or equal to the screenshot cache size of social media app A. The memory allocation thread allocates 5MB of physical memory. If 1MB < 5MB, the memory allocation thread continues to allocate the next physical memory block b, assuming the size of physical memory block b is 2MB. The memory block information of physical memory block b is passed to the data recovery thread through the memory allocation thread, and the cumulative memory acquisition is recorded as 3MB. The data recovery thread records the first total data volume as 3MB. Then, the phone determines whether the first total data volume, 3MB, is equal to or greater than a first threshold, 3MB. If it is determined that 3MB = 3MB, that is, the first total data volume equals the first threshold, the phone, through the data recovery thread, uses the physical memory blocks already allocated by the memory allocation thread that have not been used. The process involves physical memory blocks a and b, which recover the screenshot cache data of social application A and reset the initial total data size to zero. The phone then checks if the cumulative memory acquisition (3Mb) is greater than or equal to the screenshot cache size of social application A (5Mb). If 3Mb < 5Mb (the first threshold is less than the screenshot cache size of social application A), the phone requests the next physical memory block c through a request thread. Assuming physical memory block c is 2Mb, the phone uses the memory request thread to pass the memory block information of memory block c to the data recovery thread and records the cumulative memory acquisition as 5Mb. The data recovery thread then... The process records the first total data volume as 2Mb; then it checks whether the first total data volume, 2Mb, is equal to or greater than the first threshold, 3Mb; if it is determined that 2Mb < 3Mb, that is, the first total data volume is less than the first threshold, the phone continues to check whether the cumulative memory acquisition volume, 5Mb, is greater than or equal to the memory size of the screenshot cache of social application A, 5Mb; if it is determined that 5Mb = 5Mb, that is, the cumulative memory acquisition volume is equal to the memory size of the screenshot cache of social application A, the phone then uses the data recovery thread to recover the screenshot cache data of the application interface of social application A based on the physical memory block that has been allocated by the memory allocation thread and has not been used, i.e., memory block c.

[0326] Example 2: Suppose a shopping app B, a video app C, and another shopping app B are running in the background on a mobile phone. The following example, using the shopping app B, illustrates how a mobile phone can restore app screenshot cache data. Assume the screenshot cache size of the shopping app B is 10MB, and the first threshold is 6MB.When a user triggers the phone to switch from the background to the foreground and run a multitasking preview interface, the phone first allocates physical memory block d through a memory allocation thread. Assuming the size of physical memory block d is 2MB, the memory allocation thread passes the memory block information of memory block d to the data recovery thread and records the cumulative memory acquisition as 2MB. The data recovery thread records the first total data volume as 2MB. Then, it checks whether the first total data volume, 2MB, is equal to or greater than a first threshold, 6MB. If it finds that 2MB < 6MB, meaning the first total data volume is less than the first threshold, the phone continues to check whether the cumulative memory acquisition volume, 2MB, is greater than or equal to the memory size of the screenshot cache of the shopping app B. If the size of physical memory block 'e' is 4Mb, the memory allocation thread continues to allocate the next physical memory block 'e', ​​assuming the size of physical memory block 'e' is 4Mb. The memory block information of physical memory block 'e' is passed to the data recovery thread through the memory allocation thread, and the cumulative memory acquisition is recorded as 6Mb. The data recovery thread records the first total data volume as 6Mb. Then, the phone determines whether the first total data volume, 6Mb, is equal to or greater than the first threshold, 6Mb. If it is determined that 6Mb = 6Mb, meaning the first total data volume equals the first threshold, the phone, through the data recovery thread, uses the physical memory blocks already allocated by the memory allocation thread but not yet used to allocate the next physical memory block 'e'. The phone uses memory blocks d and e to recover the cached screenshot data of the shopping app B's interface in the multitasking preview, and resets the first total data volume to zero. Then, the phone checks if the cumulative memory acquisition amount, 6Mb, is greater than or equal to the memory size of the shopping app B's screenshot cache, which is 10Mb. If it determines that 6Mb < 10Mb (i.e., the first threshold is less than the memory size of the shopping app B's screenshot cache), the phone continues to request the next physical memory block f through the request thread. Assuming the size of physical memory block f is 4Mb, the phone passes the memory block information of memory block f to the data recovery thread through the memory request thread and records the cumulative memory acquisition amount as 10Mb. Through the data... The recovery thread records that the total amount of the first data is 4Mb. Then, it checks whether the total amount of the first data, 4Mb, is equal to or greater than the first threshold, 6Mb. If it is determined that 4Mb < 6Mb, meaning the total amount of the first data is less than the first threshold, the phone continues to check whether the cumulative memory acquisition amount, 10Mb, is greater than or equal to the memory size of the screenshot cache of shopping app B, 10Mb. If it is determined that 5Mb = 5Mb, meaning the cumulative memory acquisition amount is equal to the memory size of the screenshot cache of shopping app B, the phone, through the data recovery thread, recovers the screenshot cache data of the multitasking preview interface based on the physical memory block that has been allocated by the memory allocation thread but has not been used, i.e., memory block c.

[0327] In the data recovery method provided in this application embodiment, memory allocation and data recovery are decoupled for a single screenshot recovery process to improve the recovery speed of screenshot cache. For batch recovery of screenshot cache scenarios, the memory required for batch recovery is pre-allocated by using the screenshot cache information and size recorded during release, avoiding the problem of slow recovery under memory pressure. In addition, dual-thread concurrent and orderly recovery of all screenshot caches is adopted, which greatly improves the speed of batch recovery of screenshot cache.

[0328] It should be noted that each of the above method embodiments, or various possible implementations of each method embodiment, can be executed individually or in combination of any two or more. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0329] The data recovery method provided in this application can be executed by a data recovery device. This application uses a data recovery device to perform the data recovery method as an example to illustrate the data recovery device provided in this application.

[0330] Figure 11 This is a schematic diagram of a data recovery device provided in an embodiment of this application. Figure 11 As shown, the data recovery device includes a processing module 501.

[0331] The processing module 501 is configured to, upon receiving a first input that triggers the display of an application screenshot of a background application, acquire a first physical memory block and allocate the first physical memory block to a data recovery thread; acquire a second physical memory block and, through the data recovery thread, recover the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein the first total data amount represents the total capacity of physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block.

[0332] In one possible implementation, the processing module 501 is specifically used to: obtain a first physical memory block through a memory allocation thread, and send the memory block information of the first physical memory block to the data recovery thread; wherein the memory block information includes at least one of the following: the address information of the first physical memory block and the capacity information of the first physical memory block.

[0333] In one possible implementation, the aforementioned processing module 501 is specifically used to: request a first physical memory block from the system kernel through a memory request thread; and request a second physical memory block from the system kernel through a memory request thread.

[0334] In one possible implementation, the processing module 501 is specifically used to: obtain a first physical memory block from the memory pool through a memory allocation thread; and obtain a second physical memory block from the memory pool through a memory allocation thread.

[0335] In one possible implementation, the processing module 501 is specifically used to: determine a first judgment result through the data recovery thread, the first judgment result representing whether the total amount of the first data is greater than or equal to a first threshold; and based on the first judgment result, perform data recovery on the first screenshot cache data of the first application screenshot through at least one physical memory block.

[0336] In one possible implementation, the processing module 501 is specifically configured to: determine, via the data recovery thread, whether the first total capacity is greater than or equal to a first threshold, wherein the first total capacity is the total capacity of the first physical memory block and the second physical memory block corresponding to the first total data; if the first total capacity is greater than or equal to the first threshold, perform data recovery on the first screenshot cache data of the first application screenshot based on the first physical memory block and the second physical memory block, and clear the first total data; if the first total capacity is less than the first threshold, obtain the third physical memory block, and perform data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data through the data recovery thread; wherein the physical memory block corresponding to the first total data includes the first physical memory block, the second physical memory block, and the third physical memory block.

[0337] In one possible implementation, the processing module 501 is further configured to determine a second judgment result through a memory allocation thread after each determination of the first judgment result, wherein the second judgment result indicates whether the cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, wherein the cumulative memory acquisition amount is the total capacity of the physical memory blocks acquired for each physical memory block acquired; and, based on the second judgment result, determine whether to continue acquiring the next physical memory block.

[0338] In one possible implementation, the processing module 501 is further configured to, after clearing the first total data amount to zero, determine, through a memory allocation thread, whether the first cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, wherein the first cumulative memory acquisition amount is the total capacity of the first physical memory block and the second physical memory block; and, if the first cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, acquire a fourth physical memory block, and through the data recovery thread, perform data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein the physical memory block corresponding to the first total data amount includes the fourth physical memory block.

[0339] In one possible implementation, the processing module 501 is specifically used to: when the capacity of the fourth physical memory block corresponding to the first total amount of data is less than the first threshold and the second cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, perform data recovery on the first screenshot cache data of the first application screenshot based on the fourth physical memory block, wherein the second cumulative memory acquisition amount is the total capacity of the first physical memory block, the second physical memory block and the fourth physical memory block.

[0340] In one possible implementation, the processing module 501 is specifically used to: acquire a second physical memory block when the capacity of the first physical memory block is less than a first threshold and the third cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, wherein the third cumulative memory acquisition amount is the capacity of the first physical memory block.

[0341] In one possible implementation, the first application screenshot refers to at least two application screenshots in the multi-task preview interface; the processing module 501 is specifically used to: obtain a recovery list corresponding to the first screenshot cache data, the recovery list including screenshot cache data of the at least two application screenshots sorted according to display priority, the at least two application screenshots being application screenshots of background running applications; perform data recovery on N screenshot cache data with first display priority in the recovery list based on the physical memory block corresponding to the first total data volume through at least one data recovery thread; perform data recovery on M screenshot cache data with second display priority in the recovery list based on the physical memory block corresponding to the first total data volume through at least one data recovery thread, where N and M are both positive integers; wherein the first display priority is higher than the second display priority.

[0342] In one possible implementation, the at least one data recovery thread includes a first data recovery thread and a second data recovery thread; the processing module 501 is specifically used to: based on the physical memory block corresponding to the first total amount of data, perform data recovery on the screenshot cache data in a first order starting from the first screenshot cache data in the M screenshot cache data through the first data recovery thread, and simultaneously perform data recovery on the screenshot cache data in a second order starting from the last screenshot cache data in the M screenshot cache data through the second data recovery thread; wherein the first order is the same as the order of the M screenshot cache data in the recovery chain, and the second order is the opposite of the first order.

[0343] In one possible implementation, the processing module 501 is further configured to release the second screenshot cache data of the second application interface through a release thread when the duration of displaying the second application interface in the foreground exceeds a second threshold, and determine the capacity of the second screenshot cache data; and send the capacity of the second screenshot cache data to the asynchronous memory request thread through the release thread.

[0344] In one possible implementation, the processing module 501 is further configured to, after sending the second screenshot cache data capacity to the asynchronous memory request thread through the release thread, request at least one physical memory block from the system kernel based on the second screenshot cache data capacity through the asynchronous memory request thread, wherein the total capacity of the at least one physical memory block is greater than or equal to the second screenshot cache data capacity; and store the at least one physical memory block in a memory pool through the asynchronous memory request thread; wherein the asynchronous memory request thread is a memory request thread used to request physical memory blocks and store physical memory blocks in a memory pool.

[0345] In one possible implementation, the processing module 501 is further configured to, after restoring all of the first screenshot cache data to the physical memory block, display the first application screenshot based on the first screenshot cache data through the application corresponding to the first application screenshot.

[0346] This application provides a data recovery device. When it is necessary to recover the screenshot cache data of an application interface, after acquiring a physical memory block, the device can directly allocate the physical memory block to the recovery thread, and then acquire the next physical memory block. While acquiring the next physical memory block, the data recovery thread performs data recovery on the screenshot cache data of the application interface based on the previously acquired physical memory blocks. That is, by acquiring physical memory blocks while partially recovering the screenshot cache data, it is not necessary to wait for all physical memory blocks to be allocated before recovering the screenshot cache data. Therefore, the recovery time of the screenshot cache data is shortened and the recovery efficiency of the screenshot cache is improved.

[0347] The data recovery device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.

[0348] The data recovery device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0349] The data recovery apparatus provided in this application embodiment can realize the various processes implemented in the above method embodiments, and will not be described again here to avoid repetition.

[0350] Optionally, such as Figure 12As shown, this application embodiment also provides an electronic device 600, including a processor 601 and a memory 602. The memory 602 stores a program or instructions that can run on the processor 601. When the program or instructions are executed by the processor 601, they implement the various steps of the above-described data recovery method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0351] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0352] Figure 13 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0353] The electronic device 100 includes, but is not limited to, components such as: radio frequency unit 101, network module 102, audio output unit 103, input unit 104, sensor 105, display unit 106, user input unit 107, interface unit 108, memory 109, and processor 110.

[0354] Those skilled in the art will understand that the electronic device 100 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 110 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 13 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0355] The processor 110 is configured to, upon receiving a first input that triggers the display of an application screenshot of a background application, acquire a first physical memory block and allocate the first physical memory block to a data recovery thread; acquire a second physical memory block and, through the data recovery thread, recover the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein the first total data amount represents the total capacity of the physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block.

[0356] Optionally, the processor 110 is specifically configured to: obtain a first physical memory block through a memory request thread, and send the memory block information of the first physical memory block to the data recovery thread; wherein the memory block information includes at least one of the following: the address information of the first physical memory block and the capacity information of the first physical memory block.

[0357] Optionally, the processor 110 is specifically used to: request a first physical memory block from the system kernel through a memory request thread; and request a second physical memory block from the system kernel through a memory request thread.

[0358] Optionally, the processor 110 is specifically used to: obtain a first physical memory block from the memory pool through a memory allocation thread; and obtain a second physical memory block from the memory pool through a memory allocation thread.

[0359] Optionally, the processor 110 is specifically configured to: determine a first judgment result through the data recovery thread, the first judgment result representing whether the total amount of first data is greater than or equal to a first threshold; and based on the first judgment result, perform data recovery on the first screenshot cache data of the first application screenshot through at least one physical memory block.

[0360] Optionally, the processor 110 is specifically configured to: determine, via the data recovery thread, whether the first total capacity is greater than or equal to a first threshold, wherein the first total capacity is the total capacity of the first physical memory block and the second physical memory block corresponding to the first total data; if the first total capacity is greater than or equal to the first threshold, perform data recovery on the first screenshot cache data of the first application screenshot based on the first physical memory block and the second physical memory block, and clear the first total data; if the first total capacity is less than the first threshold, obtain the third physical memory block, and perform data recovery on the first screenshot cache data of the first application screenshot via the data recovery thread based on the physical memory block corresponding to the first total data; wherein the physical memory block corresponding to the first total data includes the first physical memory block, the second physical memory block, and the third physical memory block.

[0361] Optionally, the processor 110 is further configured to determine a second judgment result through a memory allocation thread after each determination of the first judgment result, wherein the second judgment result indicates whether the cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, wherein the cumulative memory acquisition amount is the total capacity of the physical memory blocks acquired for each physical memory block acquired; and, based on the second judgment result, determine whether to continue acquiring the next physical memory block.

[0362] Optionally, the processor 110 is further configured to, after clearing the first total data amount to zero, determine, through a memory allocation thread, whether the first cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, wherein the first cumulative memory acquisition amount is the total capacity of the first physical memory block and the second physical memory block; and, if the first cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, acquire a fourth physical memory block, and through the data recovery thread, perform data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein the physical memory block corresponding to the first total data amount includes the fourth physical memory block.

[0363] Optionally, the processor 110 is specifically configured to: when the capacity of the fourth physical memory block corresponding to the first total amount of data is less than the first threshold and the second cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data, perform data recovery on the first screenshot cache data of the first application screenshot based on the fourth physical memory block, wherein the second cumulative memory acquisition amount is the total capacity of the first physical memory block, the second physical memory block and the fourth physical memory block.

[0364] Optionally, the processor 110 is specifically configured to: acquire a second physical memory block when the capacity of the first physical memory block is less than a first threshold and the third cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, wherein the third cumulative memory acquisition amount is the capacity of the first physical memory block.

[0365] Optionally, the first application screenshot refers to at least two application screenshots in the multi-task preview interface; the processor 110 is specifically configured to: obtain a recovery list corresponding to the first screenshot cache data, the recovery list including screenshot cache data of the at least two application screenshots sorted by display priority, the at least two application screenshots being application screenshots of background running applications; perform data recovery on N screenshot cache data with first display priority in the recovery list based on the physical memory block corresponding to the first total data volume through at least one data recovery thread; perform data recovery on M screenshot cache data with second display priority in the recovery list based on the physical memory block corresponding to the first total data volume through at least one data recovery thread, where N and M are both positive integers; wherein the first display priority is higher than the second display priority.

[0366] Optionally, the at least one data recovery thread includes a first data recovery thread and a second data recovery thread; the processor 110 is specifically configured to: based on the physical memory block corresponding to the first total amount of data, perform data recovery on the screenshot cache data in the first order, starting from the first screenshot cache data among the M screenshot cache data, through the first data recovery thread, and simultaneously perform data recovery on the screenshot cache data in the second order, starting from the last screenshot cache data among the M screenshot cache data; wherein the first order is the same as the arrangement order of the M screenshot cache data in the recovery chain, and the second order is the opposite of the first order.

[0367] Optionally, the processor 110 is further configured to, when the duration of displaying the second application interface in the foreground exceeds a second threshold, release the second screenshot cache data of the second application interface through a release thread, and determine the capacity of the second screenshot cache data; and send the capacity of the second screenshot cache data to the asynchronous memory request thread through the release thread.

[0368] Optionally, the processor 110 is further configured to, after sending the second screenshot cache data capacity to the asynchronous memory request thread via the release thread, request at least one physical memory block from the system kernel based on the second screenshot cache data capacity via the asynchronous memory request thread, wherein the total capacity of the at least one physical memory block is greater than or equal to the second screenshot cache data capacity; and store the at least one physical memory block in a memory pool via the asynchronous memory request thread; wherein the asynchronous memory request thread is a memory request thread used to request physical memory blocks and store physical memory blocks in a memory pool.

[0369] Optionally, the processor 110 is further configured to, when all the first screenshot cache data has been restored to the physical memory block, display the first application screenshot based on the first screenshot cache data through the application corresponding to the first application screenshot.

[0370] This application provides an electronic device that, when it is necessary to restore the screenshot cache data of an application interface, can directly allocate a physical memory block to a recovery thread after acquiring it, and then acquire the next physical memory block. While acquiring the next physical memory block, the data recovery thread restores the screenshot cache data of the application interface based on the previously acquired physical memory blocks. That is, by acquiring physical memory blocks while partially restoring the screenshot cache data, it is not necessary to wait for all physical memory blocks to be allocated before restoring the screenshot cache data. Therefore, the recovery time of the screenshot cache data is shortened and the recovery efficiency of the screenshot cache is improved.

[0371] It should be understood that, in this embodiment, the input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 106 may include a display panel 1061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 107 includes at least one of a touch panel 1071 and other input devices 1072. The touch panel 1071 is also called a touch screen. The touch panel 1071 may include a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0372] The memory 109 can be used to store software programs and various data. The memory 109 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 109 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 109 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0373] Processor 110 may include one or more processing units; optionally, processor 110 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 110.

[0374] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described data recovery method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0375] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0376] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above data recovery method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0377] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0378] This application provides a computer program product stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the data recovery method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0379] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0380] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0381] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A data recovery method, characterized in that, include: Upon receiving the first input, and the first input being used to trigger the display of an application screenshot of a background running application, the first physical memory block is obtained and allocated to the data recovery thread. A second physical memory block is acquired, and the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein, the first total data amount represents the total capacity of the physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block.

2. The method according to claim 1, characterized in that, The step of acquiring the first physical memory block and allocating the first physical memory block to the data recovery thread includes: The memory allocation thread acquires the first physical memory block and sends the memory block information of the first physical memory block to the data recovery thread. The memory block information includes at least one of the following: the address information of the first physical memory block and the capacity information of the first physical memory block.

3. The method according to claim 2, characterized in that, The process of acquiring the first physical memory block via a memory allocation thread includes: The first physical memory block is requested from the system kernel through a memory allocation thread. The acquisition of the second physical memory block includes: The system allocates a second physical memory block from the system kernel through a memory allocation thread.

4. The method according to claim 2, characterized in that, The process of acquiring the first physical memory block via a memory allocation thread includes: The first physical memory block is obtained from the memory pool through the memory allocation thread; The acquisition of the second physical memory block includes: The second physical memory block is obtained from the memory pool through a memory allocation thread.

5. The method according to claim 1, characterized in that, The step of restoring the cached data of the first screenshot of the first application screenshot through the data recovery thread, based on the physical memory block corresponding to the first total data volume, includes: The data recovery thread determines a first judgment result, which indicates whether the total amount of the first data is greater than or equal to a first threshold. Based on the first judgment result, the first screenshot cache data of the first application screenshot is recovered using at least one physical memory block.

6. The method according to claim 5, characterized in that, The determination of the first judgment result through the data recovery thread includes: The data recovery thread determines whether the first total capacity is greater than or equal to the first threshold, where the first total capacity is the total capacity of the first physical memory block and the second physical memory block corresponding to the first total data volume. The step of restoring the first screenshot cache data of the first application screenshot based on the first judgment result, using at least one physical memory block, includes: If the first total capacity is greater than or equal to the first threshold, based on the first physical memory block and the second physical memory block, the first screenshot cache data of the first application screenshot is restored, and the first total data is cleared to zero. If the first total capacity is less than the first threshold, a third physical memory block is obtained, and the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; the physical memory block corresponding to the first total data amount includes the first physical memory block, the second physical memory block and the third physical memory block.

7. The method according to claim 5, characterized in that, The method further includes: After determining the first judgment result each time, the second judgment result is determined through the memory allocation thread. The second judgment result indicates whether the cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data. The cumulative memory acquisition amount is the total capacity of the physical memory blocks acquired for each physical memory block acquired. Based on the second judgment result, determine whether to continue acquiring the next physical memory block.

8. The method according to claim 6 or 7, characterized in that, After clearing the first total data volume to zero, the method further includes: The memory allocation thread determines whether the first cumulative memory acquisition amount is greater than or equal to the capacity of the first screenshot cache data. The first cumulative memory acquisition amount is the total capacity of the first physical memory block and the second physical memory block. If the first cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, a fourth physical memory block is acquired, and the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; the physical memory block corresponding to the first total data amount includes the fourth physical memory block.

9. The method according to claim 8, characterized in that, The step of restoring the cached data of the first screenshot of the first application screenshot through the data recovery thread, based on the physical memory block corresponding to the first total data volume, includes: If the capacity of the fourth physical memory block corresponding to the first total data is less than the first threshold, and the second cumulative memory acquisition is greater than or equal to the capacity of the first screenshot cache data, the first screenshot cache data of the first application screenshot is restored based on the fourth physical memory block, and the second cumulative memory acquisition is the total capacity of the first physical memory block, the second physical memory block and the fourth physical memory block.

10. The method according to claim 1, characterized in that, The acquisition of the second physical memory block includes: If the capacity of the first physical memory block is less than the first threshold and the third cumulative memory acquisition amount is less than the capacity of the first screenshot cache data, then a second physical memory block is acquired, wherein the third cumulative memory acquisition amount is the capacity of the first physical memory block.

11. The method according to claim 1, characterized in that, The first application screenshot is a screenshot of at least two applications in the multitasking preview interface; The process of restoring the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data volume includes: Obtain the recovery list corresponding to the first screenshot cache data. The recovery list includes screenshot cache data of the at least two application screenshots sorted by display priority. The at least two application screenshots are application screenshots of background running applications. Data recovery is performed on N screenshot cache data with the first display priority in the recovery chain, based on the physical memory block corresponding to the first total amount of data, using at least one data recovery thread; Through the at least one data recovery thread, based on the physical memory block corresponding to the first total amount of data, data recovery is performed on M screenshot cache data with the second display priority in the recovery chain, where N and M are both positive integers; The first display priority is higher than the second display priority.

12. The method according to claim 11, characterized in that, The at least one data recovery thread includes a first data recovery thread and a second data recovery thread; The data recovery process, based on the physical memory blocks corresponding to the first total data volume, involves restoring the M screenshot cache data items with the second display priority in the recovery list, including: Based on the physical memory block corresponding to the first total amount of data, the first data recovery thread starts from the first screenshot cache data in the M screenshot cache data and performs data recovery in the first order. The second data recovery thread then synchronously starts from the last screenshot cache data in the M screenshot cache data and performs data recovery in the second order. The first order is the same as the order in which the M screenshot cache data are arranged in the recovery list, and the second order is the opposite of the first order.

13. The method according to claim 4, characterized in that, The method further includes: If the duration of displaying the second application interface in the foreground exceeds the second threshold, release the second screenshot cache data of the second application interface by releasing the thread, and determine the capacity of the second screenshot cache data. The release thread sends the second screenshot cache data capacity to the asynchronous memory request thread.

14. The method according to claim 13, characterized in that, After the release thread sends the second screenshot cache data capacity to the asynchronous memory request thread, the method further includes: Using an asynchronous memory allocation thread, at least one physical memory block is allocated from the system kernel based on the capacity of the second screenshot cache data, and the total capacity of the at least one physical memory block is greater than or equal to the capacity of the second screenshot cache data; The at least one physical memory block is stored in the memory pool through the asynchronous memory allocation thread; The asynchronous memory allocation thread is a memory allocation thread used to request physical memory blocks and store them in the memory pool.

15. The method according to claim 1, characterized in that, The method further includes: If all the first screenshot cache data is restored to the physical memory block, the first application screenshot is displayed by the application corresponding to the first application screenshot based on the first screenshot cache data.

16. A data recovery device, characterized in that, include: Processing module; The processing module is configured to, upon receiving a first input, and wherein the first input is used to trigger the display of an application screenshot of a background running application, acquire a first physical memory block and allocate the first physical memory block to the data recovery thread; and, A second physical memory block is acquired, and the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; wherein, the first total data amount represents the total capacity of the physical memory blocks available for recovering the first screenshot cache data for each acquired physical memory block.

17. The apparatus according to claim 16, characterized in that, The processing module is specifically used for: The data recovery thread determines a first judgment result, which indicates whether the total amount of the first data is greater than or equal to a first threshold. Based on the first judgment result, the first screenshot cache data of the first application screenshot is recovered using at least one physical memory block.

18. The apparatus according to claim 17, characterized in that, The processing module is specifically used for: The data recovery thread determines whether the first total capacity is greater than or equal to the first threshold, where the first total capacity is the total capacity of the first physical memory block and the second physical memory block corresponding to the first total data volume. If the first total capacity is greater than or equal to the first threshold, based on the first physical memory block and the second physical memory block, the first screenshot cache data of the first application screenshot is restored, and the first total data is cleared to zero. If the first total capacity is less than the first threshold, a third physical memory block is obtained, and the data recovery thread performs data recovery on the first screenshot cache data of the first application screenshot based on the physical memory block corresponding to the first total data amount; the physical memory block corresponding to the first total data amount includes the first physical memory block, the second physical memory block and the third physical memory block.

19. The apparatus according to claim 16, characterized in that, The first application screenshot is a screenshot of at least two applications in the multitasking preview interface; The processing module is specifically used for: Obtain the recovery list corresponding to the first screenshot cache data. The recovery list includes screenshot cache data of the at least two application screenshots sorted by display priority. The at least two application screenshots are application screenshots of background running applications. Data recovery is performed on N screenshot cache data with the first display priority in the recovery chain, based on the physical memory block corresponding to the first total amount of data, using at least one data recovery thread; Through the at least one data recovery thread, based on the physical memory block corresponding to the first total amount of data, data recovery is performed on M screenshot cache data with the second display priority in the recovery chain, where N and M are both positive integers; The first display priority is higher than the second display priority.

20. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the data recovery method as described in any one of claims 1-15.

Images