Memory resource management method and electronic equipment

By detecting and compressing the memory pages of the background application in electronic devices, the problem of the background application holding a large amount of unused memory is solved, and efficient management of memory resources is achieved and waste is reduced.

CN119493741APending Publication Date: 2025-02-21HONOR DEVICE CO LTD
View PDF 0 Cites 3 Cited by

Patent Information

Application Number
CN202311055560.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-08-21
Publication Date
2025-02-21

AI Technical Summary

Technical Problem

In some mobile phone systems, background application processes hold a large amount of unused memory resources, resulting in wasted memory resources.

Method used

By implementing the memory resource management method in an electronic device, detect that when the target application switches from the foreground to the background, it obtains and compresses its applied memory page, stores it to the virtual disk of memory, and frees the original memory page.

Benefits of technology

Reduce the memory space occupied by running applications in the background, avoid the waste of memory resources, and further free up space when memory is insufficient to alleviate memory pressure.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119493741A_ABST
    Figure CN119493741A_ABST
Patent Text Reader

Abstract

The invention provides a memory resource management method and electronic equipment, relates to the technical field of electronics, and is used for reducing memory resource waste caused by memory occupied by an application running in a background. The method is applied to the electronic equipment, a target application is installed in the electronic equipment, and the electronic equipment comprises a memory, a graphics processing unit (GPU) driver and a direct memory access cache (DMABUF) driver. The method comprises the following steps: in response to a first operation of switching a target application from a foreground to a background, obtaining an initial preset memory page applied by the target application from a memory; wherein the initial preset memory page comprises a memory page applied by the target application through the GPU driver and / or the DMABUF driver. And compressing the initial preset memory page to obtain a compressed preset memory page, and storing the compressed preset memory page to a virtual disk of the memory. And releasing the initial preset memory page in the memory.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to the field of electronic technology, and in particular to a memory resource management method and an electronic device. Background Art

[0002] When some mobile phone system applications are running in the foreground, they will apply for memory resources to save multimedia-related data such as application layer data and user interface (UI) data. It is currently found that after the application is switched from the foreground to the background, it still holds a part of the memory. The application process does not access this memory when it is in the background, but it still holds the memory.

[0003] Multiple background application processes hold a large amount of memory in total, but the application will not access this memory when running in the background, so it will cause a waste of memory resources. Summary of the invention

[0004] The embodiments of the present application provide a memory resource management method and an electronic device for reducing the waste of memory resources caused by the memory occupied by applications running in the background.

[0005] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0006] In a first aspect, a memory resource management method is provided, which is applied to an electronic device, wherein the electronic device is installed with a target application, and the electronic device includes a memory, a graphics processor GPU driver, and a direct memory access buffer DMABUF driver; the method includes:

[0007] In response to a first operation of switching a target application from the foreground to the background, an initial preset memory page applied for by the target application is obtained from the memory, and the initial preset memory page includes a memory page applied for by the target application through a GPU driver and / or a DMABUF driver. Then, the electronic device can compress the initial preset memory page to obtain a compressed preset memory page, and store the compressed preset memory page to a virtual disk of the memory. Finally, the initial preset memory page is released from the memory.

[0008] In this solution, for the target application, after detecting that it has switched to the background, the memory pages requested by the target application through the GPU driver and / or the DMABUF driver are compressed and stored in the virtual disk of the memory. Since the compressed memory pages have less data than the memory pages before compression, after compressing and storing the initial preset internal pages requested by the target application, the memory space occupied by the target application when switching to the background can be reduced, reducing the waste of memory resources.

[0009] In a possible implementation of the first aspect, the electronic device further includes a non-volatile memory. In this solution, after storing the compressed preset memory page to the virtual disk of the memory, the method may further include: moving the compressed preset memory page to the non-volatile memory. In this way, the memory space can be further freed up, the target application switched to the background is prevented from occupying the memory space, and the waste of memory resources is reduced.

[0010] In a possible implementation of the first aspect, before compressing the initial preset memory page, the method may further include: the electronic device may first obtain the memory usage and analyze the memory usage. In this scheme, moving the compressed preset memory page to the non-volatile memory may specifically include: if the memory usage indicates that the memory pressure value is greater than or equal to the preset pressure value, it means that the current memory pressure of the electronic device is large and the memory resources may be insufficient. Therefore, at this time, the compressed preset memory page can be moved to the non-volatile memory. On the contrary, if the memory usage indicates that the memory pressure value is less than the preset pressure value, it means that the current memory pressure is small and the memory resources are sufficient, so it is not necessary to move the compressed preset memory page to the non-volatile memory.

[0011] The read and write speed of the electronic device for the virtual disk of the memory is usually faster than the read and write speed of the non-volatile memory. Therefore, in this solution, when there is sufficient memory, the compressed preset memory page of the target application is stored in the virtual disk of the memory, and when the compressed preset memory page is read for decompression, the read and write speed is faster. When the memory is insufficient, the compressed preset memory page of the target application is stored in the non-volatile memory, giving priority to the use of the memory. Thus, the problem of taking into account both memory use and read and write efficiency is achieved.

[0012] In a possible implementation of the first aspect, before the above method compresses the initial preset memory page, the electronic device, in response to the first operation, may first apply for a target storage space for storing compressed memory data. Then, based on the address of the target storage space, a swap-out page identifier is generated, and the swap-out page identifier is used to characterize the address of the target storage space. In this scheme, storing the compressed preset memory page to the virtual disk of the memory may specifically include: storing the compressed preset memory page to the storage space corresponding to the swap-out page identifier. In this scheme, before compression, space for compressed data is first applied for, so that after compressing the initial preset memory page applied for by the target application, the compressed preset memory page can be saved.

[0013] In a possible implementation of the first aspect, before the electronic device applies for a target storage space for storing compressed memory data in response to a first operation, memory usage can be obtained. If the memory usage indicates that the memory pressure is greater than or equal to a preset pressure value, the target storage space can be applied for from a non-volatile memory. On the contrary, if the memory usage indicates that the memory pressure is less than the preset pressure value, the target storage space can be applied for from a virtual disk of the memory. Thus, it is convenient to store the compressed memory data.

[0014] In a possible implementation of the first aspect, the electronic device further includes a compression processing module. In this solution, in response to the first operation, applying for a target storage space for storing compressed memory data may specifically include: the GPU driver and / or the DMABUF driver applies for the target storage space from the compression processing module in response to the first operation. Based on the address of the target storage space, generating a swap-out page identifier may specifically include: the compression processing module generates a swap-out page identifier based on the address of the target storage space.

[0015] In a possible implementation of the first aspect, before the electronic device applies for a target storage space for storing compressed memory data in response to a first operation, memory usage can be obtained. If the memory usage indicates that the memory pressure is greater than or equal to a preset pressure value, the compression processing module can apply for the target storage space from the non-volatile memory. On the contrary, if the memory usage indicates that the memory pressure is less than the preset pressure value, the compression processing module can apply for the target storage space from the virtual disk of the memory. Thereby, it is convenient to store the compressed memory data.

[0016] In a possible implementation of the first aspect, after the compression processing module generates a swap-out page identifier based on the address of the target storage space, the method further includes: the compression processing module returns the swap-out page identifier to the GPU driver and / or the DMABUF driver. The GPU driver and / or the DMABUF driver writes the swap-out page identifier into a preset parameter of a page data structure corresponding to the initial preset memory page. Wherein, the page data structure is used to describe the initial preset memory page. When the GPU driver and / or the DMABUF driver can obtain the initial preset memory page, the page data structure corresponding to the initial preset memory page can be obtained. The above-mentioned compression of the initial preset memory page to obtain the compressed preset memory page may specifically include: the GPU driver and / or the DMABUF driver calls the preset compression interface of the compression processing module based on the page data structure. The compression processing module obtains the initial preset memory page based on the page data structure, and then the compression processing module compresses the initial preset memory page to obtain the compressed preset memory page. Afterwards, the compression processing module stores the compressed preset memory page in the storage space corresponding to the swap-out page identifier.

[0017] In this solution, the GPU driver and / or DMABUF driver applies for space for storing compressed memory data through the compression processing module, and obtains the swap-out page identifier generated by the compression processing module based on the space. Afterwards, the GPU driver and / or DMABUF driver writes the swap-out page identifier into the page data structure of the initial preset memory page, and then calls the preset compression interface of the compression processing module based on the page data structure. In this way, the compression processing module can obtain the initial preset memory page according to the page data structure and compress it. Afterwards, the compression processing module can store the compressed preset memory page obtained by compression into the space corresponding to the swap-out page identifier stored in the page data structure.

[0018] In a possible implementation of the first aspect, the compression processing module includes a ZRAM block device driver. The ZRAM block device driver is used to compress the initial preset memory page, and the compressed preset memory page obtained by compression can be stored in a virtual disk of the memory.

[0019] In a possible implementation of the first aspect, the above-mentioned obtaining the initial preset memory page applied for by the target application from the memory may specifically include: searching for the memory index corresponding to the target application in the GPU driver and / or the DMABUF driver. Then, the initial preset memory page is searched and obtained in the memory according to the memory index corresponding to the target application. The GPU driver and / or the DMABUF driver stores the storage location of the initial preset memory page applied for by the target application, that is, the memory index corresponding to the above-mentioned target application. It can be understood that before the initial preset memory page is compressed, the address indicated by the memory index corresponding to the target application is the storage location of the initial preset memory page in the memory. Therefore, the GPU driver and / or the DMABUF driver can find the above-mentioned initial preset memory page according to the memory index corresponding to the target application.

[0020] In a possible implementation of the first aspect, after compressing the initial preset memory page to obtain the compressed preset memory page, and storing the compressed preset memory page to the virtual disk of the memory, the above method also includes: obtaining a swap-out page identifier corresponding to the compressed preset memory page; the swap-out page identifier is used to indicate the storage location of the compressed preset memory page. Then, the swap-out page identifier is written into the storage location of the memory applied by the target application in the memory index corresponding to the target application. Since the preset memory page applied by the target application (i.e., the initial preset memory page) has been compressed and stored, in order to facilitate the subsequent search for the compressed storage location of the preset memory page applied by the target application, the swap-out page identifier used to indicate the storage location of the compressed preset memory page is written into the storage location of the memory applied by the target application in the memory index corresponding to the target application. Therefore, the swap-out page identifier can be obtained by searching the memory index corresponding to the target application, and the compressed storage location of the preset memory page applied by the target application can be found according to the swap-out page identifier.

[0021] In a possible implementation of the first aspect, after compressing the initial preset memory page to obtain the compressed preset memory page, and storing the compressed preset memory page in the virtual disk of the memory, it can specifically include: the GPU driver and / or the DMABUF driver obtains the swap-out page identifier corresponding to the compressed preset memory page, and writes the swap-out page identifier into the storage location of the memory applied by the target application in the memory index corresponding to the target application. Thus, it is convenient for the GPU driver and / or the DMABUF driver to find the compressed storage location of the preset memory page applied by the target application.

[0022] In a possible implementation of the first aspect, after the initial preset memory page is released in the memory, the method further includes: if a second operation of switching the target application from the background to the foreground is detected, in response to the second operation of switching the target application from the background to the foreground, a physical page is allocated to the target application, and the compressed preset memory page is obtained. The compressed preset memory page is then decompressed, and the decompressed data is written to the physical page. The preset memory page applied for by the target application is thereby decompressed. Finally, the physical page is written to the memory index corresponding to the target application in the GPU driver or the DMABUF driver, and the memory index corresponding to the target application is used to indicate the storage location of the memory applied for by the target application. Thus, the target application can access the corresponding preset memory page through the GPU driver and / or the DMABUF driver according to the memory index corresponding to the target application.

[0023] In a possible implementation of the first aspect, the electronic device can determine the compressed storage location of the preset memory page applied by the target application by searching the memory index corresponding to the target application, and then obtain the compressed preset memory page of the target application according to the memory index corresponding to the target application, and decompress it.

[0024] In a possible implementation of the first aspect, the electronic device can find a virtual disk in the memory that stores the compressed preset memory page of the target application according to the memory index corresponding to the target application, and can then obtain the compressed preset memory page from the virtual disk in the memory and decompress it.

[0025] In a possible implementation of the first aspect, the electronic device further includes a non-volatile memory; after the electronic device stores the compressed preset memory page in the virtual disk of the memory, the electronic device moves the compressed preset memory page to the non-volatile memory. The electronic device can find the compressed preset memory page of the target application stored in the non-volatile memory according to the memory index corresponding to the target application. In this solution, the electronic device can first move the compressed preset memory page from the non-volatile memory to the virtual disk, and then obtain the compressed preset memory page from the virtual disk and decompress it.

[0026] In a possible implementation manner of the first aspect, the target application includes a camera application or a game application.

[0027] In a second aspect, an electronic device is provided, comprising: a processor and a memory; the memory is used to store computer execution instructions, and when the electronic device is running, the processor executes the computer execution instructions stored in the memory to enable the electronic device to perform a memory resource management method as described in any one of the above-mentioned first aspects.

[0028] In a third aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on the computer, the computer can execute any one of the memory resource management methods in the first aspect.

[0029] In a fourth aspect, a computer program product comprising instructions is provided, which, when executed on an electronic device, enables the electronic device to execute any one of the memory resource management methods of the first aspect.

[0030] In a fifth aspect, a device (for example, the device may be a chip system) is provided, the device including a processor for supporting an electronic device to implement the functions involved in the first aspect above. In one possible design, the device also includes a memory for storing program instructions and data necessary for the electronic device. When the device is a chip system, it may be composed of a chip, or may include a chip and other discrete devices.

[0031] Among them, the technical effects brought about by any design method in the second to fifth aspects can refer to the technical effects brought about by different design methods in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A schematic diagram of a memory resource held by an application running in the background provided in an embodiment of the present application;

[0033] Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0034] Figure 3 A software architecture diagram of an electronic device provided in an embodiment of the present application;

[0035] Figure 4 A software architecture diagram of an electronic device provided in an embodiment of the present application;

[0036] Figure 5 A software architecture diagram of an electronic device provided in an embodiment of the present application;

[0037] Figure 6 A flowchart of a memory management method provided in an embodiment of the present application;

[0038] Figure 7 A flowchart of a memory management method provided in an embodiment of the present application;

[0039] Figure 8 A flowchart of a memory management method provided in an embodiment of the present application;

[0040] Fig. 9 A schematic diagram of a flow chart of a compression operation in a memory management method provided in an embodiment of the present application;

[0041] Fig.10 A schematic diagram of a flow chart of a decompression operation in a memory management method provided in an embodiment of the present application;

[0042] Fig.11 An architectural diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] First, technical terms that may be involved in the embodiments of the present application are introduced.

[0044] Anonymous pages are memory pages that have no corresponding files. When a process needs to allocate anonymous pages, the operating system will allocate some anonymous pages for it. These pages are usually used to store data and code when the program is running, such as dynamically allocated memory and function call stacks. The process can access this data and code by accessing anonymous pages in virtual memory. Anonymous pages can be mapped to the virtual address space of the process through the memory mapping mechanism.

[0045] Random Access Memory (RAM), also called main memory, is the internal memory that directly exchanges data with the CPU. It can be read and written at any time (except when refreshed) and is very fast. It is usually used as a temporary data storage medium for operating systems or other running programs. When working, RAM can write (store) or read (retrieve) information from any specified address at any time.

[0046] A graphics processing unit (GPU), also known as a display core, visual processor, or display chip, is a microprocessor that performs image and graphics-related calculations on personal computers, workstations, game consoles, and some mobile devices (such as tablets, smartphones, etc.).

[0047] GPU memory (video memory) is a high-speed storage space designed for graphics processing units to quickly access and process graphics data. GPU memory is separate from the host's main memory (RAM).

[0048] Direct memory access (DMA) is a high-speed data transfer operation that allows direct data read and write operations between peripherals and memory, without going through the CPU or requiring CPU intervention. It frees the CPU from a large number of data transfer operations and lets the DMA controller complete them, freeing up the CPU to do calculations, scheduling, and other tasks. In this way, in addition to processing at the beginning and end of data transfer, the CPU can do other things during the transfer, greatly improving the system's work efficiency.

[0049] The emergence of DMABUF is to solve the problem of buffer sharing between various drivers. It is essentially a combination of buffer and file, that is, DMABUF is both a physical buffer and a Linux file. Buffer is the content, file is the medium, and only through the medium of file can the same buffer be transferred between different drivers.

[0050] The memory pages (i.e., GPU memory) requested by the application through the GPU driver can be managed by the GPU driver. The memory pages (i.e., DMABUF memory) requested by the application through the DMABUF driver can be managed by the DMABUF driver. The memory pages managed by the GPU driver and the DMABUF driver can be stored through a preset data structure. It should be noted that the memory resources requested by the application through the GPU driver or the DMABUF driver can also be called physical pages requested by the application through the GPU driver, not anonymous pages.

[0051] Specifically, the GPU driver or DMABUF driver can store the memory resources requested by the application through the corresponding driver in a preset data structure by means of an index. Exemplarily, the memory resources requested by the target application through the GPU driver are stored in the preset data structure of the GPU driver with a corresponding memory index corresponding to the target application, and the memory index corresponding to the target application is used to indicate the storage address of the GPU memory requested by the target application. Similarly, the memory resources requested by the target application through the DMABUF driver are stored in the preset data structure of the DMABUF driver with a corresponding memory index corresponding to the target application, and the memory index corresponding to the target application is used to indicate the storage address of the DMABUF memory requested by the target application. Among them, the target application can be an application in an electronic device that belongs to a preset list.

[0052] In some examples, the preset data structure may be an xarray data structure. Xarray is a large array pointer, and each item in xarray can store both a general pointer and a value, and a marker is added at the end to distinguish whether the stored item is a pointer or a value.

[0053] When the GPU driver or DMABUF driver uses the xarray data structure to store the memory resources they manage, the memory index in the xarray data structure can be stored as page*. Page* is a data structure used in the kernel to describe a physical page.

[0054] The essence of ZRAM is a block device driver. It uses memory to simulate block devices and can provide virtual memory compression. ZRAM uses memory to virtualize a disk as a swap partition (swap), which consists of a set of page slots. The size of each page slot is the size of a physical page, usually 4096 bytes. When there are fewer allocatable memory resources, the kernel will compress the data in the occupied memory and then store the compressed data in the swap partition of the memory. After each physical page is compressed by ZRAM, the compressed data will be saved in the swap partition. The location of the data in the swap partition can be represented by a swap page identifier (swap_entry_t). ZRAM maintains an information table (table), which can store the storage address of the memory data compressed and stored by ZRAM. In the related art, ZRAM is used to compress anonymous pages in virtual memory.

[0055] ZRAM uses memory to virtualize a disk as a swap partition (swap). The swap partition consists of a set of pageslots, each of which is the size of a physical page. After the physical page is compressed by ZRAM, the compressed data is saved in the swap partition. The location of the data in the swap partition is represented by the swap-out page identifier (swap_entry_t). The last bit of the swap-out page identifier is 0, indicating that the page has been swapped out.

[0056] Pressure Stall Information (PSI) can identify and quantify interruptions caused by resource shortages such as the central processing unit (CPU), I / O, and memory, and count the time that tasks in the system wait for hardware resources. In an embodiment of the present application, PSI can be used as an indicator to measure the pressure of hardware resources. The longer the pause time, the greater the pressure on the resources.

[0057] When some mobile phone system applications are running in the foreground, they will apply for memory resources to save multimedia-related data such as application layer data and UI data. It is currently found that after the application is switched from the foreground to the background, the application still holds a portion of the memory.

[0058] like Figure 1 As shown in FIG. 1 , when multiple applications are running in the background, the multiple background application processes collectively hold a large amount of memory. However, these applications usually do not access this memory when running in the background, which will cause a waste of memory resources.

[0059] Based on this, an embodiment of the present application proposes a memory resource management method, which can be applied to an electronic device. Specifically, in this method, when the electronic device detects the operation of switching the target application from the foreground to the background, the preset memory page (such as GPU memory and / or DMABUF memory) applied by the target application is obtained, and the preset memory page is compressed and saved. In some embodiments, the preset memory page applied by the target application before compression can be recorded as the initial preset memory page. Thereby, the memory size occupied by the memory held by this part of the application when running in the background is reduced, and the waste of memory resources is reduced.

[0060] In some embodiments, the memory resource management method provided in the present application can be applied to mobile phones, tablet computers, personal computers (PC), smart screens, desktops, laptops, handheld computers, notebook computers, ultra-mobile personal computers (UMPC), netbooks, smart watches and other wearable devices, artificial intelligence (AI) speakers and vehicle-mounted devices, and can also be various teaching aids (such as learning machines, early education machines), smart toys, portable robots, personal digital assistants (PDA), augmented reality (AR) and virtual reality (VR) devices, media players and other devices, and can also be devices with mobile office functions, devices with smart home functions, devices with audio and video entertainment functions, devices supporting smart travel and other devices. The embodiments of the present application do not impose special restrictions on the specific form of the device.

[0061] like Figure 2 The figure shows a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application. The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, a camera 192, a display screen 193, and a subscriber identification module (SIM) card interface 194, etc. Among them, the sensor module 180 may include a pressure sensor 180A, a touch sensor 180B, etc.

[0062] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0063] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor, an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units may be independent devices or integrated into one or more processors. For example, the processor 110 is used to execute the memory resource management method in the embodiment of the present application.

[0064] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0065] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0066] The USB interface 130 is an interface that complies with USB standard specifications, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transmit data between the electronic device 100 and a peripheral device.

[0067] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0068] The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system and an application required for at least one function (such as a sound playback function, an image playback function, etc.).

[0069] In addition, the internal memory 121 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0070] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from the wired charger through the USB interface 130 .

[0071] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and provides power to the processor 110, the internal memory 121, the external memory interface 120, the display screen 193, the camera 192, and the wireless communication module 160.

[0072] In some other embodiments, the power management module 141 may also be disposed in the processor 110. In some other embodiments, the power management module 141 and the charging management module 140 may also be disposed in the same device.

[0073] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0074] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0075] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, etc. the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1.

[0076] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and filters it, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0077] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with the network and other devices through wireless communication technology.

[0078] The electronic device 100 can implement audio functions such as music playing and recording through the audio module 170 and the application processor.

[0079] The audio module 170 is used to convert digital audio signals into analog audio signals for output, and is also used to convert analog audio inputs into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0080] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 193. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. A capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure based on the change in capacitance. When a touch operation acts on the display screen 193, the electronic device 100 detects the intensity of the touch operation based on the pressure sensor 180A. The electronic device 100 can also calculate the position of the touch based on the detection signal of the pressure sensor 180A.

[0081] The touch sensor 180B is also called a "touch panel". The touch sensor 180B can be arranged on the display screen 193, and the touch sensor 180B and the display screen 193 form a touch screen, also called a "touch screen". The touch sensor 180B is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 193. In other embodiments, the touch sensor 180B can also be arranged on the surface of the electronic device 100, which is different from the position of the display screen 193.

[0082] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key input and generate key signal input related to user settings and function control of the electronic device 100.

[0083] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback.

[0084] The camera 192 is used to capture still images or videos. In some embodiments, the electronic device 100 may include 1 or N cameras 192, where N is a positive integer greater than 1.

[0085] The electronic device 100 implements the display function through a GPU, a display screen 193, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 193 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0086] The display screen 193 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include 1 or N display screens 193 , where N is a positive integer greater than 1.

[0087] The SIM card interface 194 is used to connect a SIM card. The SIM card can be connected to or disconnected from the electronic device 100 by inserting or removing the SIM card interface 194. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1.

[0088] The memory resource management methods in the following embodiments can all be implemented in the electronic device 100 having the above hardware structure.

[0089] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device 100.

[0090] Figure 3 It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0091] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers, from top to bottom: application layer, application framework layer, Android runtime (ART) and native C / C++ library, hardware abstract layer (HAL) and kernel layer.

[0092] The application layer can include a series of application packages.

[0093] like Figure 3 As shown, the application package may include applications such as camera, game, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, SMS, etc.

[0094] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0095] like Figure 3 As shown, the application framework layer may include a window manager, a content provider, a view system, a resource manager, a notification manager, an activity manager, an input manager, foreground and background listeners, and a whitelist management module.

[0096] The foreground and background listeners are used to monitor the events when the application switches from the foreground to the background, and the events when the application switches from the background to the foreground.

[0097] A preset list is stored in the whitelist management module, and the whitelist management module can query whether the application belongs to the preset list after receiving a notification message from the foreground and background listeners. The preset list may include one or more applications; after the applications in the preset list are switched to the background, a memory compression operation needs to be performed. In some embodiments of the present application, if the application is switched to the background and the application belongs to the preset list, the application can be considered as a target application. For the target application, it is necessary to perform a compression operation on the GPU memory and / or DMABUF driver that has been applied for by the target application.

[0098] The window manager provides window management services (WMS). WMS can be used for window management, window animation management, surface management, and as a transfer station for the input system.

[0099] Content providers are used to store and retrieve data and make it accessible to applications. This data can include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0100] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0101] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0102] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0103] The activity manager can provide activity management services (AMS), which can be used to start, switch, and schedule system components (such as activities, services, content providers, and broadcast receivers) as well as manage and schedule application processes.

[0104] The input manager can provide input management services (IMS), which can be used to manage system input, such as touch screen input, key input, sensor input, etc. IMS takes events from input device nodes and distributes them to appropriate windows through interaction with WMS.

[0105] The Android runtime includes the core library and the Android runtime. The Android runtime is responsible for converting source code into machine code. The Android runtime mainly uses the ahead of time (AOT) compilation technology and the just in time (JIT) compilation technology.

[0106] The core library is mainly used to provide basic Java class library functions, such as basic data structures, mathematics, IO, tools, databases, networks, etc. The core library provides an API for users to develop Android applications.

[0107] The native C / C++ library can include multiple functional modules, such as surface manager, media framework, libc, OpenGL ES, SQLite, Webkit, etc.

[0108] Among them, the surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications. The media framework supports playback and recording of multiple commonly used audio and video formats, as well as static image files, etc. The media library can support multiple audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. OpenGL ES provides drawing and operation of 2D graphics and 3D graphics in applications. SQLite provides a lightweight relational database for applications of electronic device 100.

[0109] The hardware abstraction layer runs in user space, encapsulates kernel layer drivers, and provides a calling interface to the upper layer.

[0110] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, Bluetooth driver, sensor driver, GPU driver, DMABUF driver, ZRAM driver and PSI module.

[0111] The GPU driver is used to drive the GPU. In some embodiments of the present application, the memory page requested by the target application through the GPU driver is the GPU memory. The DMABUF driver is used to drive the DMABUF. In some embodiments of the present application, the memory page requested by the target application through the DMABUF driver is the DMABUF memory.

[0112] The ZRAM driver can also be called ZRAM, which is used to perform memory compression and decompression operations. For an introduction to ZRAM, please refer to the previous description.

[0113] In some embodiments of the present application, the PSI module can be used to obtain the PSI value of the memory.

[0114] The memory resource management method provided in the present application can be applied to the scene where the game, camera and other applications in the electronic device are switched from the foreground to the background. In the process of running in the foreground, the corresponding display screen of the game and camera applications usually changes more and changes faster, that is, the preset memory pages (such as GPU memory and / or DMABUF memory) held by the game and camera applications are more. And when the game and camera applications are switched from the foreground to the background, they usually still hold some preset memory pages. In the method proposed in the embodiment of the present application, after detecting that the application switches from the foreground to the background, if the application applies for the preset memory page, the preset memory page (i.e., the initial preset memory page) applied by the application is compressed. Afterwards, the compressed preset memory page obtained by compression is stored in the virtual disk of the memory, and the original preset memory page is released. Compared with the original memory, the compressed memory has a reduced amount of data and a reduced storage space, thereby reducing the memory space occupied by the application running in the background.

[0115] In some embodiments of the present application, a preset list may be set to determine whether an application is a target application. For example, the target application may include the above-mentioned game or camera applications.

[0116] Furthermore, if it is detected that the target application switches from the background to the foreground, the compressed preset memory page corresponding to the target application is obtained and the compressed preset memory page is decompressed, so that the target application can access the preset memory page and restore the interface of the target application.

[0117] In some embodiments of the present application, for a target application that applies for memory resources through a GPU driver and / or a DMABUF driver, when the target application switches from the foreground to the background, ZRAM is used to compress the memory resources applied for by the application through the GPU driver and / or the DMABUF driver.

[0118] The native ZRAM compression mechanism in the related art usually triggers ZRAM to compress the memory only when the memory of the electronic device is insufficient and triggers memory recycling. In other words, the related art relies on memory usage to trigger the call of ZRAM to compress the memory. However, in the embodiment of the present application, when it is detected that an application that meets the conditions (such as the target application) switches from the foreground to the background, it can trigger the call of ZRAM to compress the memory corresponding to the target application, which relies on scene triggering. Among them, the target application can specifically be an application that has applied for memory resources through the GPU driver and / or DMABUF driver during the foreground operation.

[0119] Specifically, in the embodiment of the present application, in order to realize the above-mentioned compression operation of memory resources triggered by the scene, it is necessary to add a node in the kernel layer. After the upper layer of the electronic device perceives that the target application switches from the foreground to the background, the GPU driver and / or the DMABUF driver is notified through the added kernel node to perform a compression operation on the preset memory page applied by the target application.

[0120] Further, when the target application is switched from the foreground to the background, the target application is subjected to a compression operation on the memory resources requested by the GPU driver and / or DMABUF driver. Therefore, when the target application is switched from the background to the foreground, the GPU driver and / or DMABUF driver are also required to call the ZRAM interface to decompress the compressed memory resources corresponding to the target application. Therefore, in some embodiments of the present application, it is also necessary to increase the corresponding node in the kernel layer to trigger the GPU driver and / or DMABUF driver to perform a decompression operation. Exemplarily, after the upper layer of the electronic device perceives that the target application is switched from the background to the foreground, the GPU driver and / or DMABUF driver are notified through the increased kernel node to obtain the compressed memory resources corresponding to the target application, and to perform a decompression operation on it.

[0121] In addition, it can be seen from the above description that in the related art, ZRAM is used to compress anonymous pages in memory resources, while the memory resources requested by the application through the GPU driver and / or DMABUF driver do not belong to anonymous pages. In other words, in the related art, ZRAM cannot be used to compress the memory resources requested by the GPU driver provided by the target application.

[0122] Therefore, in the embodiment of the present application, in order to use ZRAM to compress the preset memory pages (such as GPU memory and / or DMABUF memory) applied by the target application, the following changes need to be made:

[0123] (1) Add compression paths and decompression paths to the GPU driver and DMABUF driver, so that both the GPU driver and the DMABUF driver can use the ZRAM compression mechanism to compress and decompress the memory resources requested by their respective drivers; such as the preset memory pages requested by the target application mentioned above.

[0124] (2) A compression interface for compressing preset memory pages and a decompression interface for decompressing compressed preset memory pages are added to ZRAM. This makes it easier to use the ZRAM mechanism to compress and decompress preset memory pages requested by applications through GPU drivers and / or DMABUF drivers.

[0125] In an embodiment of the present application, through the above-mentioned improvement, the electronic device can trigger the GPU driver and / or DMABUF driver through the newly added node of the kernel layer when detecting that the target application switches from the foreground to the background, and perform compression operation on the preset memory page applied for by the target application by calling the preset compression interface of ZRAM. And, when perceiving that the target application switches from the background to the foreground, the GPU driver and / or DMABUF driver is triggered through the newly added node of the kernel layer, and the preset decompression interface of ZRAM is called to perform decompression operation on the compressed preset memory page corresponding to the target application. It can be understood that when the target application applies for GPU memory through the GPU driver, the GPU driver can compress the GPU memory through ZRAM, and the GPU driver can also decompress the compressed GPU memory through ZRAM. When the target application applies for DMABUF memory through the DMABUF driver, the DMABUF driver can compress the DMABUF memory through ZRAM, and the DMABUF driver can decompress the compressed DMABUF memory through ZRAM.

[0126] In some embodiments, the above-mentioned GPU driver and / or DMABUF driver can be represented by a preset driver. The memory applied for by the application through the preset driver is recorded as a preset memory page. Before being compressed, the preset memory page applied for by the application can be recorded as an initial preset memory page. For example, the initial preset memory page corresponding to the target application represents the preset memory page that has been applied for by the target application and has not been compressed. After being compressed, the preset memory page applied for by the application can be recorded as a compressed preset memory page. For example, the compressed preset memory page corresponding to the target application represents the preset memory page that has been applied for by the target application and is compressed.

[0127] Before the preset memory page applied by the target application is compressed, the memory index corresponding to the target application in the preset driver indicates the storage address of the preset memory page before compression (i.e., the initial preset memory page). After the preset memory page applied by the target application is compressed, the memory index corresponding to the target application in the preset driver indicates the storage address of the preset memory page after compression (i.e., the compressed preset memory page).

[0128] The following will describe in detail the specific implementation process of the memory resource management method provided by the present application in conjunction with the accompanying drawings. In the embodiment of the present application, the electronic device is a mobile phone as an example for description. Figure 4 , which shows the software modules involved in the memory resource management method.

[0129] like Figure 4 As shown, the mobile phone is installed with application A and application B. The foreground and background listeners can monitor the events of application A and application B switching from the foreground to the background, and from the background to the foreground.

[0130] In some embodiments, the foreground and background listeners can monitor changes in the application interface to determine whether the application is switched from the foreground to the background, and whether the application is switched from the background to the foreground. For example, if the current interface switches from displaying the interface of application A to displaying other interfaces, such as the interface or desktop of application B, it means that application A switches from the foreground to the background. Alternatively, if the current interface switches from displaying other interfaces to displaying the interface of application A, it means that application A switches from the background to the foreground.

[0131] In other embodiments, the foreground and background listeners may also monitor the operation of the application running in the foreground to determine whether the application is switched from the foreground to the background. Exemplarily, application A is running in the foreground, and the foreground and background listeners detect the first operation performed on the application A, and it is considered that the application A is monitored to switch from the foreground to the background. Among them, the first operation is used to switch application A from the foreground to the background. Exemplarily, the first operation can be a click operation of controls such as "exit", "return to the previous level" or "return to the desktop" on the display interface of application A. Alternatively, the first operation can also be a preset operation for "exit", "return to the previous level" or "return to the desktop" based on the current display interface. The preset operation can specifically be a gesture of exit, return to the previous level or return to the desktop set by the user in advance on the mobile phone, for example, an operation of sliding up from the bottom of the mobile phone screen, an operation of sliding from the left / right side of the mobile phone screen to the middle of the screen, etc. In response to the first operation, the mobile phone will switch from displaying the interface of application A to displaying other interfaces, such as the interface or desktop of application B.

[0132] In some embodiments, the mobile phone includes a button for returning to the desktop, which can be a virtual button or a physical button. The foreground and background listeners can also monitor the application currently running in the foreground and the button for returning to the desktop at the same time to determine whether the application is switched from the foreground to the background. For example, when the mobile phone detects the triggering operation of the button for returning to the desktop during the running of application A in the foreground, it can be determined that application A is switched from the foreground to the background.

[0133] Optionally, after detecting an event that an application switches from the foreground to the background, it can be determined whether the application switched to the background needs to perform a memory compression operation. In some embodiments, the foreground and background listeners can send the application identifier of the application switched from the foreground to the background to the whitelist management module, thereby triggering the whitelist management module to query whether the application switched to the background belongs to a preset list based on the application identifier. It is understandable that the preset list can be pre-set and saved in the mobile phone.

[0134] When the whitelist management module determines through query that the application switched to the background belongs to the preset list, it indicates that the application needs to perform a memory compression operation. In some embodiments, the application determined to belong to the preset list can be recorded as the target application. If the whitelist management module determines through query that the application switched to the background does not belong to the preset list, it indicates that the memory compression operation does not need to be performed for the application.

[0135] Furthermore, in some embodiments, after searching and determining that the application belongs to the preset application, the whitelist management module may also send a first feedback message to the foreground and background listeners, and the first feedback message is used to indicate that the application belongs to the preset application. After receiving the first feedback message, the foreground and background listeners may send a compressed notification message to the preset driver (such as the GPU driver and / or the DMABUF driver). The compressed notification message sent by the foreground and background listeners to the preset driver may carry the application identifier of the target application.

[0136] In other embodiments, after searching and determining that the application belongs to the preset application, the whitelist management module may send a compression notification message to the preset driver to trigger the preset driver to perform a compression operation on the preset memory page applied for by the target application after receiving the compression notification message. The compression notification message sent by the whitelist management module to the preset driver may carry the application identifier of the target application.

[0137] Specifically, the preset driver can query the preset memory applied by the target application. For example, the GPU driver can query the GPU memory applied by the target application, and the DMABUF driver can query the DMABUF memory applied by the target application.

[0138] Then, the preset driver can call the preset compression interface of the compression processing module to perform compression operation on the preset memory applied by the target application. After the compression processing module completes the compression of the preset memory page applied by the target application, the compressed preset memory page obtained by compression can be stored in the virtual disk of the memory. Among them, the preset compression interface of the compression processing module can be used to compress GPU memory and / or DMABUF memory.

[0139] In some embodiments, the compression processing module may specifically be Figure 3 The ZRAM in the kernel layer shown. As can be seen from the above description, in the embodiment of the present application, a compression path is added to the GPU driver and the DMABUF driver, and a preset compression interface for compressing the GPU memory and the DMABUF driver is added to the ZRAM driver. Thus, after receiving the compression notification message, the GPU driver can call the preset compression interface of the ZRAM to compress the GPU memory and / or DMABUF memory applied by the target application. Among them, the preset compression interface of the ZRAM can be a preset compression interface in the ZRAM for compressing the GPU memory and / or DMABUF memory.

[0140] In some embodiments, the preset driver calls the preset compression interface of ZRAM, which may specifically include: the preset driver sends a call request for the preset compression interface to ZRAM based on the page data structure page* corresponding to the preset memory page applied for by the target application. As can be seen from the above description, page* is a data structure used to describe the physical page in the kernel, and the parameters of the corresponding physical page are stored in page*. According to the page*, the storage location of the preset memory page applied for by the target application can be found, and the relevant data of the preset memory page can be obtained.

[0141] After receiving the call request from the preset driver for the preset compression interface, ZRAM can parse the call request to obtain page*. Then, ZRAM can perform compression processing on the preset memory page corresponding to the page* (i.e., the GPU memory and / or DMABUF memory applied by the target application).

[0142] The memory virtual disk is an area divided in the memory by the compression processing module, which can be used to store compressed memory resources. It is understandable that in other embodiments, the memory virtual disk used to store compressed memory resources can also be named other names, such as swap partition swap, etc.

[0143] Afterwards, the ZRAM can save the storage location of the compressed preset memory page corresponding to the target application in the virtual disk of the memory in the ZRAM. In some examples, the storage location of the compressed preset memory page corresponding to the target application saved in the ZRAM can be called the index of the compressed preset memory page corresponding to the target application in the ZRAM.

[0144] In addition, after ZRAM compresses and stores the preset memory pages applied by the target application to the virtual disk of the memory, the preset driver can release the preset memory pages applied by the target application from the memory, thereby reducing the memory space occupied by the background running application.

[0145] After the preset driver releases the preset memory page applied by the target application from the memory, in order for the preset driver to find the storage location of the compressed preset memory page corresponding to the target application, the preset driver can save the storage location of the compressed preset memory page. From the above description, it can be seen that in the preset driver, the storage location of the compressed preset memory page corresponding to the target application can be saved using the memory index corresponding to the target application.

[0146] In some embodiments, the preset driver can obtain the index of the compressed preset memory page corresponding to the target application in ZRAM (hereinafter referred to as the ZRAM index) and save the ZRAM index. Afterwards, the preset driver can search for the compressed preset memory page corresponding to the target application based on the ZRAM index. Specifically, after the preset driver obtains the ZRAM index, a mapping relationship between the memory index corresponding to the target application and the ZRAM index can be established in the preset driver. Thus, when the preset driver searches for the preset memory page applied for by the target application, it can obtain the mapping relationship between the memory index corresponding to the target application and the ZRAM index by searching for the memory index corresponding to the target application, thereby obtaining the ZRAM index. Furthermore, the compressed preset memory page corresponding to the target application is found according to the ZRAM index.

[0147] It is understandable that when the target application is running in the background, the memory it holds will be stored in the virtual disk of the memory.

[0148] In the memory resource management method provided in the embodiment of the present application, a list of applications that need to perform memory compression operations is pre-set, and after detecting an event that an application in the list switches from the foreground to the background, a preset driver is triggered to perform memory compression operations on the preset memory pages applied for by the application. This reduces the space occupied by the memory resources in the memory after the application switches to the background, and reduces the waste of memory resources.

[0149] After the target application switches to the background, the user may need to switch the target application from the background to the foreground. Therefore, after the target application switches to the background, the foreground and background listeners continue to monitor the target application. After the foreground and background listeners monitor the event that the application switches from the background to the foreground, the application needs to access the memory resources it has applied for.

[0150] When the target application is switched to the background, the preset driver has compressed the preset memory page applied by the target application through the compression processing module. Therefore, if the application switched to the foreground is the target application, the preset memory page applied by the target application needs to be decompressed before the target application can access the corresponding preset memory page. In addition, the preset driver has released the preset memory page applied by the target application from the memory. Therefore, when the target application needs to access this part of the memory again, a new physical page needs to be allocated for it.

[0151] Exemplarily, after the foreground and background listeners monitor the event of the application switching from the background to the foreground, they can query whether the application belongs to the preset list through the whitelist management module, that is, determine whether the application switched to the foreground is the target application. If the application is determined to be the target application, the preset driver can be notified to perform a decompression operation on the compressed memory resources. Exemplarily, the foreground and background listeners can send a decompression notification message to the preset driver. Alternatively, the whitelist management module can also send a decompression notification message to the preset driver.

[0152] After receiving the decompression notification message, the preset driver may first allocate a new physical page for the target application to store the decompressed memory resources of the target application. After the preset driver allocates the new physical page, it may generate a page data structure page* corresponding to the new physical page.

[0153] Combination Figure 4 As can be seen from the description of the above embodiment, after the target application is switched, the preset memory page applied by the target application is compressed and stored in the virtual disk of the memory. Therefore, after receiving the decompression notification message, the preset driver can complete the operation of decompressing the preset memory page applied by the target application through the compression processing module.

[0154] The preset decompression interface of the compression processing module can be used to decompress the compressed memory resources, and the preset driver can call the preset decompression interface of the compression processing module to decompress the compressed preset memory pages corresponding to the target application.

[0155] In some embodiments, after receiving the decompression notification message, the preset driver can first search the preset driver for the storage location of the compressed preset memory page corresponding to the target application. From the description of the above embodiment, it can be seen that the preset driver is used to indicate the storage location of the compressed preset memory page corresponding to the target application (i.e., the memory index corresponding to the target application) is the ZRAM index. Furthermore, the preset driver can call the ZRAM preset decompression interface based on the ZRAM index and the newly allocated physical page.

[0156] The preset driver can write the storage location of the compressed preset memory page corresponding to the target application (i.e., the index of ZRAM) into a parameter in page* corresponding to the newly allocated physical page. For example, the index of ZRAM can be written into page->private of page*. After that, the preset driver sends a call request for the preset compression interface to ZRAM based on the page*.

[0157] When the compression processing module receives a call request for a preset decompression interface, it can parse and obtain page*. The compression processing module finds the storage location of the compressed preset memory page corresponding to the target application according to the index of the ZRAM carried in the page*. In addition, the compression processing module can also know the location where the decompressed data is to be written according to the page*, that is, the physical page newly allocated by the above-mentioned preset driver. Therefore, in response to the call request for the preset decompression interface, the compression processing module can obtain the preset memory page (that is, the above-mentioned compressed preset memory page) applied for by the target application from the virtual disk of the memory. Then, the compression processing module decompresses the preset memory page applied for by the target application, and copies the decompressed data to the new physical page. After ZRAM writes the decompressed data to the new physical page, the page* corresponding to the new physical page is updated accordingly. After that, the compression processing module feeds back the page* after decompressing the initial preset memory page to the preset driver. So that the preset driver can find the new physical page (write the decompressed data) according to the updated page*. The preset driver can insert the new physical page into the memory index corresponding to the target application in the preset driver, and then the target application can access the part of the preset memory page through the preset driver, so as to display the interface of the target application. It can be understood that the data obtained by decompressing the compressed preset memory page should be the initial preset memory page applied by the target application (that is, the preset memory page before compression).

[0158] When a user opens multiple applications on a mobile phone and does not close them, most of the multiple applications may run in the background at the same time, requiring more memory space. When the memory usage exceeds a certain value, there may be insufficient memory resources.

[0159] In the memory resource management method of the above embodiment, when an application switches to the background, the preset memory pages applied for by the application are compressed and stored in the virtual disk of the memory, so as to reduce the memory space occupied by the application running in the background. If the memory resources are still insufficient after compressing the preset memory pages applied for by the application switched to the background, the compressed preset memory pages stored in the virtual disk of the memory can be further stored in the non-volatile memory. In this way, the space of the virtual disk of the memory can be further released, and the memory pressure can be relieved.

[0160] Please refer to Figure 5 After the foreground and background listeners monitor the event that the application switches from the foreground to the background, the whitelist management module is triggered to query whether the application belongs to the preset list. After the whitelist management module determines that the application belongs to the preset list (that is, the application is the target application), it can send a compression notification message to the preset driver (such as the GPU driver and / or the DMABUF driver).

[0161] In some embodiments, after receiving the compression notification message, the preset driver can obtain the current memory usage of the mobile phone. Then, according to the memory usage of the mobile phone, the compression operation of the preset memory page applied for by the target application is selected. Specifically, when the memory usage indicates that the memory pressure is greater than or equal to the preset pressure value, the compressed preset memory page can be stored in the non-volatile memory. When the memory usage indicates that the memory pressure is less than the preset pressure value, the compressed preset memory page can be stored in the virtual disk of the memory.

[0162] In some embodiments, the memory usage of the mobile phone can be specifically characterized by the available memory capacity. Specifically, when the available memory capacity is small, the memory resources are tight. On the contrary, if the available memory capacity is large, it means that the pressure on the memory resources is small. Exemplarily, when the available memory capacity is lower than the preset capacity threshold, the preset driver can store the compressed preset memory page to the non-volatile memory through ZRAM. When the available memory capacity is greater than or equal to the preset capacity threshold, the preset driver can store the compressed preset memory page in the virtual disk of the memory through ZRAM.

[0163] In other embodiments, the memory usage of the mobile phone can be specifically represented by the PSI value of the memory. For example, after receiving the compression notification message, the preset driver obtains the current PSI value from the PSI module of the kernel layer.

[0164] As can be seen from the above description, PSI counts the time that tasks in the system wait for hardware resources. The longer the pause time, the greater the pressure on the resources. Exemplarily, when the PSI value is lower than the preset PSI threshold, the preset driver can store the compressed preset memory page to the non-volatile memory. When the PSI value is greater than or equal to the preset PSI threshold, the preset driver can store the compressed preset memory page in the virtual disk of the memory.

[0165] In other embodiments, the memory usage of the mobile phone may also be obtained through other methods, which are not listed one by one in the embodiments of the present application.

[0166] The preset driver calls the preset compression interface of the ZRAM driver to trigger ZRAM to compress the preset memory page applied by the target application, and first stores the compressed preset memory page to the virtual disk of the memory. Then, the compressed preset memory page is moved from the virtual disk of the memory to the non-volatile memory. After that, the compressed preset memory page can be released from the virtual disk of the memory.

[0167] In some embodiments, the non-volatile memory may specifically include silicon chip storage media (such as flash memory, UFS, and solid-state hard disk, etc.) and disk storage media (such as mechanical hard disk, floppy disk, etc.).

[0168] Similarly, when the foreground and background listeners detect that the target application switches from the background to the foreground, the preset driver needs to be triggered to decompress the preset memory page that the target application has applied for. After decompression, the preset memory page that the target application has applied for is obtained, and the target application can access this part of the preset memory page through the preset driver. Figure 5 In the embodiment shown, when the target application switches to the background, the preset memory page applied by the target application is compressed and stored in the non-volatile memory. Therefore, when the foreground and background listeners listen to the event of the target application switching from the background to the foreground, the foreground and background listeners can trigger the preset driver to obtain the preset memory page (compressed preset memory page) applied by the target application from the non-volatile memory through ZRAM, and perform a decompression operation on it.

[0169] Specifically, after the foreground and background listeners send a decompression notification message to the preset driver, the preset driver can determine the storage location of the compressed preset memory page corresponding to the target application by searching the memory index corresponding to the target application in the preset data structure (such as the index of the above-mentioned ZRAM). When it is determined that the storage location of the compressed preset memory page corresponding to the target application is a non-volatile memory according to the ZRAM index, the preset driver can call the preset decompression interface to the compression processing module, triggering the compression processing module to search and decompress the compressed preset memory page corresponding to the target application. The compression processing module can first search for the compressed preset memory page corresponding to the target application from the non-volatile memory, and move the compressed preset memory page to the virtual disk of the memory. Then, the preset driver reads the compressed preset memory page from the virtual disk of the memory, calls and decompresses it.

[0170] In the technical solution provided in the embodiment of the present application, when the target application switches to the background, if the memory pressure of the mobile phone is relatively large, the preset driver can store the compressed preset memory page corresponding to the target application to the non-volatile memory. Thereby further releasing the memory space and alleviating the memory pressure. If the memory pressure of the mobile phone does not reach the threshold when the target application switches to the background, the compressed preset memory page corresponding to the target application will not be stored in the non-volatile memory. Compared with storing the compressed preset memory page in the virtual disk of the memory, storing the compressed preset memory page in the non-volatile memory requires more time during the compression and decompression operations. Therefore, only when the memory pressure is relatively large, the compressed preset memory page is further stored in the non-volatile memory, which can reduce the time used for compression and decompression. When the target application switches from the background to the foreground, the speed of obtaining the compressed preset memory page for decompression can be increased, thereby improving the performance of the device.

[0171] Figure 6 The process of compression operation in the memory management method in some embodiments of the present application is shown. In this embodiment, the memory management method is applied to a mobile phone, which is installed with application A and application B, and the mobile phone includes a front-end and back-end listener, a whitelist management module, a GPU driver, a DMABUF driver, a ZRAM driver, and a memory.

[0172] S601. Monitor the event of the application switching from the foreground to the background.

[0173] As can be seen from the description of the above embodiment, S601 can be specifically executed by the foreground and background listeners in the application framework layer of the mobile phone. After the event of switching the application from the foreground to the background is monitored, S602 can be executed.

[0174] S602. Determine whether the application belongs to the preset list.

[0175] If it is determined that the application switched to the background belongs to the preset list, the application can be recorded as the target application. Next, the preset memory page applied by the target application can be found, and the compression operation can be performed on the preset memory page applied by the target application. It should be noted that if the judgment result of S602 is no, it means that the compression operation does not need to be performed on the memory of the application.

[0176] Optionally, before performing the compression operation on the preset memory page applied for by the target application, the memory usage may be obtained for analysis, such as S603. Then, the compression operation to be performed is selected according to the memory usage.

[0177] S603. Is the PSI of the memory lower than the preset PSI value?

[0178] In combination with the description of the above embodiment, it can be known that when the PSI value of the memory is lower than the preset PSI value, that is, when the judgment result of S603 is yes, the mobile phone can store the compressed preset memory page in the non-volatile memory after compressing the memory; such as S604-S609. If the judgment result of S603 is no, after compressing the preset memory page applied by the target application, the compressed preset memory page can be stored in the virtual disk of the memory, such as S610-S614.

[0179] In some embodiments, when the PSI value of the memory is lower than a preset value, a compression notification message may be sent to a preset driver so that the preset driver performs a compression operation on the preset memory page applied for by the target application.

[0180] S604. The default driver searches for the default memory page that has been requested by the target application.

[0181] The preset driver includes a GPU driver and / or a DMABUF driver.

[0182] It should be noted that, in the actual execution process, the mobile phone may execute S603 first and then S604, or may execute S604 first and then S603, or may execute S603 and S604 simultaneously. The execution order of S603 and S604 is not limited in this application.

[0183] During the operation of the mobile phone, if an application applies for memory resources through a preset driver, the corresponding driver manages the memory resources applied for by the application. In some embodiments, the preset driver manages the memory resources applied for by the application through the preset driver, which may specifically include: the preset driver saves the page* corresponding to the physical page (preset memory page) applied for by the application in a preset data structure (such as xarray) by means of an index (memory index corresponding to the target application).

[0184] In some embodiments, the preset driver may traverse and search for the preset memory page applied for by the target application. Exemplarily, the preset driver may traverse and search for the page* corresponding to the preset memory page applied for by the target application in the preset data structure of the preset driver.

[0185] S605. The preset driver calls the preset compression interface of ZRAM.

[0186] Exemplarily, the above S605 may specifically include: the preset driver sends a call request for a preset compression interface to the ZRAM.

[0187] In some embodiments, the call request sent by the preset driver to ZRAM may carry the page* of the preset memory page applied by the target application. The page* is used by ZRAM to search for the preset memory page applied by the target application. It should be noted that the specific implementation process of the preset driver calling the preset compression interface of ZRAM can refer to the description of the embodiments below.

[0188] S606. ZRAM performs a compression operation and stores the compressed preset memory page obtained by compression to the virtual disk of the memory.

[0189] In response to the calling request of the preset driver to the preset compression interface of the ZRAM, the ZRAM may perform a compression operation on the preset memory page applied for by the target application.

[0190] After ZRAM stores the compressed preset memory pages to the virtual disk of the memory, the preset memory pages applied for by the target application can be released from the memory to achieve the effect of reducing the memory storage space.

[0191] Since the determination result of S603 is yes, after the ZRAM stores the compressed preset memory page to the virtual disk of the memory, the preset driver also needs to move the compressed preset memory page to the non-volatile memory.

[0192] S607.ZRAM moves the compressed preset memory page from the virtual disk in the memory to the physical disk.

[0193] Specifically, the ZRAM can write the compressed preset memory page to an unused slot in the physical disk. The unused slot of the physical disk represents an idle storage area in the physical disk. It should be noted that the physical disk here can also be replaced by other non-volatile memories.

[0194] In S606, after ZRAM performs a compression operation on the preset memory page applied for by the target application, the compressed preset memory page is stored in the virtual disk of the memory. Therefore, the above S607 may specifically include: ZRAM copies the compressed preset memory page from the virtual disk of the memory to the physical disk; and then releases the compressed file in the virtual disk of the memory.

[0195] If the judgment result of S603 is yes, the preset memory page applied for by the target application is compressed and then stored in the disk, thereby further releasing the storage space of the memory and alleviating the memory pressure.

[0196] In some embodiments, after receiving the decompression notification message, the preset driver may wake up the low-priority work queue workL, and the low-priority work queue obtains the preset memory page applied for by the target application, compresses and stores it.

[0197] S608. ZRAM saves the storage location of the compressed preset memory page and generates an index of ZRAM.

[0198] S609. Establish a mapping relationship between the memory index corresponding to the target application in the preset driver and the ZRAM index.

[0199] Specifically, a mapping relationship between a memory index corresponding to a target application in a preset driver and an index of ZRAM is established, which may specifically include establishing a mapping relationship between a memory index corresponding to a target application in a GPU driver and an index of ZRAM, and / or establishing a mapping relationship between a memory index corresponding to a target application in a DMABUF driver and an index of ZRAM.

[0200] Exemplarily, a mapping relationship between a memory index corresponding to a target application in a preset driver and an index of a ZRAM may be established in a preset data structure of the preset driver.

[0201] The memory index corresponding to the target application in the preset driver represents: the index of the storage location of the preset memory page applied for by the target application in the GPU driver or the DMABUF driver. It can be understood that before compressing the preset memory page applied for by the target application, the location where the preset memory page applied for by the target application is stored can be found according to the memory index corresponding to the target application in the preset driver. It can be seen from the description of the above embodiment that the preset memory page applied for by the target application can be stored in the page* data structure in the preset driver, and the storage location of the preset memory page in the page* data structure can be used as the memory index corresponding to the target application in the above preset driver.

[0202] Figure 6S610-S614 in the above are the execution methods for the preset memory pages applied by the target application when the judgment result of S603 is no. It can be seen from the description of the above embodiment that when the PSI value of the memory is greater than or equal to the preset PSI value, it means that the memory pressure of the current mobile phone is relatively small. Therefore, the preset driver can compress the preset memory pages applied by the target application and store them in the virtual disk of the memory. In other words, compared with when the judgment result of S603 is yes, there is no need to store the compressed preset memory pages from the virtual disk of the memory to the non-volatile memory.

[0203] S610. The default driver searches for the default memory page that has been requested by the target application.

[0204] S611. The preset driver calls the preset compression interface of ZRAM.

[0205] S612. ZRAM performs a compression operation and stores the compressed preset memory page obtained by compression to the virtual disk of the memory.

[0206] S613. ZRAM saves the storage location of the compressed preset memory page and generates an index of ZRAM.

[0207] S614. Establish a mapping relationship between the memory index corresponding to the target application in the preset driver and the ZRAM index.

[0208] In some embodiments, if S603 is not executed, when the mobile phone detects an event that a target application belonging to the preset list switches from the foreground to the background, for the preset memory page applied by the target application, S604-S609 may be executed, that is, the preset memory page applied by the target application is compressed and stored in a non-volatile memory (such as a physical disk). Alternatively, when the mobile phone detects an event that the target application switches from the foreground to the background, S610-S614 may also be executed; that is, the preset memory page applied by the target application is compressed and stored in a virtual disk of the memory.

[0209] Afterwards, if the target application switches from the background to the foreground, the preset driver can find the compressed storage location of the preset memory page applied by the target application according to its saved index (such as the mapping relationship in S609). Then, based on the ZRAM index in the mapping relationship, the preset driver calls the preset decompression interface of the ZRAM to decompress the compressed preset memory page corresponding to the target application. Figure 7 The flowchart of the decompression operation in the memory management method in some embodiments of the present application is shown.

[0210] S701. Monitor the event of an application switching from the background to the foreground.

[0211] S702: Whether the application belongs to the preset list.

[0212] If it is determined that the application switched to the foreground belongs to the preset list, then when the application was previously switched to the background, the preset memory pages that it had applied for will be compressed and stored. Therefore, when the application is switched from the background to the foreground, the preset driver needs to first decompress the memory resources corresponding to the application. If the application belongs to the preset list, the application can be recorded as the target application.

[0213] If the application switched to the foreground is not in the preset list, it means that the corresponding memory resources of the application were not compressed and stored when the application was switched to the background. In this case, the mobile phone can normally read the memory resources applied by the application and access the memory resources through the application. Figure 7 Not shown.

[0214] S703. The preset driver searches for the storage location of the compressed preset memory page corresponding to the target application.

[0215] As can be seen from the above embodiments, after determining that the application belongs to the preset list, the whitelist management module can send a decompression notification message to the preset driver to trigger the preset driver to perform the decompression operation. The whitelist management module can also notify the foreground and background listeners, and the foreground and background listeners trigger the preset driver to perform the decompression operation.

[0216] It can be seen from the description of the above embodiment that after the preset driver calls ZRAM to compress the preset memory page that has been applied for by the target application, the preset driver will establish a mapping relationship between the memory index corresponding to the target application and the index of ZRAM. The preset driver can find the index of ZRAM based on the mapping relationship. The index of ZRAM can indicate the storage location after ZRAM compresses the preset memory page that has been applied for by the target application. In other words, the above S703 can specifically include: the preset driver searches for the index of ZRAM according to the respective saved mapping relationships; the index of ZRAM is used to indicate the storage location of the preset memory page after compression.

[0217] S704. The preset driver allocates a new physical page.

[0218] Combination Figure 6 As can be seen from the process, the preset driver has released the preset memory page physical page requested by the target application from the memory. Therefore, when the target application needs to access this part of memory again, a new physical page needs to be allocated for it.

[0219] S705. The preset driver calls the preset decompression interface of the ZRAM driver.

[0220] Exemplarily, the above S704 may specifically include: the preset driver sends a call request for the preset decompression interface to the ZRAM. In some embodiments, the call request for the preset decompression interface carries the storage location of the compressed preset memory page, such as the index of the above ZRAM.

[0221] In some embodiments, when the preset driver sends a call request for the preset decompression interface to ZRAM, it can carry the page* corresponding to the newly allocated physical page. Among them, the preset driver can write the index of the above ZRAM into a parameter of the page* corresponding to the newly allocated physical page. Exemplarily, the preset driver can write the index of ZRAM into the page->private of the page* corresponding to the newly allocated physical page. Therefore, when ZRAM receives the call request of the preset decompression interface, it can obtain the compressed preset memory page and the physical page written after decompression (that is, the above newly allocated physical page) according to the page* therein. It should be noted that the specific implementation process of the preset driver calling the preset decompression interface of ZRAM can refer to the description of the embodiments below.

[0222] S706. ZRAM performs a decompression operation on the compressed preset memory page corresponding to the target application, and writes the decompressed data into a new physical page in the memory.

[0223] In response to the calling request of the preset driver to the preset decompression interface of the ZRAM, the ZRAM may perform a compression operation on the compressed preset memory page corresponding to the target application.

[0224] It can be seen from the description of the above embodiment that the preset memory page applied for by the target application may be stored in the virtual disk of the memory or in the physical disk. Therefore, the above S705 can be divided into two cases.

[0225] In some embodiments, the ZRAM may first search for the storage location of the compressed preset memory page corresponding to the target application according to the ZRAM index. The ZRAM may determine whether the compressed preset memory page is stored in a virtual disk of the memory or a non-volatile memory (such as a physical disk) according to the ZRAM index.

[0226] When the compressed preset memory page corresponding to the target application is stored in the virtual disk of the memory, the ZRAM obtains the compressed preset memory page corresponding to the target application from the virtual disk of the memory and then decompresses it. Then the ZRAM writes the decompressed preset memory page (i.e., the preset memory page requested by the target application) into a new physical page in the memory.

[0227] In the case where the compressed preset memory page corresponding to the target application is stored in a non-volatile memory (such as a physical disk), ZRAM needs to first obtain the compressed preset memory page corresponding to the target application from the physical disk. In some embodiments, ZRAM can move the compressed preset memory page corresponding to the target application from the physical disk to the virtual disk in the memory. Then, ZRAM can obtain the compressed preset memory page corresponding to the target application from the virtual disk in the memory and decompress it. Finally, ZRAM writes the decompressed preset memory page (i.e., the preset memory page that the target application has applied for) to a new physical page in the memory.

[0228] The new physical page for storing the decompressed data can be allocated by the preset driver after the preset driver receives the decompression notification message. In some embodiments, the preset driver can wake up the high-priority work queue workH after receiving the decompression notification message, and the high-priority work queue allocates the new physical page.

[0229] S707. ZRAM returns the new physical page to the default driver.

[0230] S708. The preset driver inserts the new physical page into the position corresponding to the memory index corresponding to the target application in the preset driver.

[0231] In some embodiments, the above S708 may specifically include: the preset driver inserts the page* corresponding to the new physical page into the position corresponding to the index in the preset driver.

[0232] In the technical solution provided in the embodiment of the present application, when an event of an application switching from the background to the foreground is detected, it is determined whether it is necessary to perform a decompression operation on the memory resources corresponding to the application by querying whether the application belongs to the preset list. When it is determined that the application belongs to the preset list, the memory resources (preset memory pages) applied by the application are first searched and decompressed, and written into new physical pages. This ensures that the application can run normally when it switches from the background to the foreground.

[0233] In other embodiments, when an application is detected to switch from the background to the foreground, it is not necessary to determine whether the memory resources applied by the application need to be decompressed by using the preset list. Instead, the preset driver searches for the storage location of the preset memory page applied by the target application to determine whether the preset memory page applied by the target application is compressed and stored.

[0234] It can be seen from the description of the above embodiments that in some embodiments, after the preset memory page applied by the target application is compressed and stored, the preset driver releases the preset memory page applied by the target application from the memory, and then the preset driver saves the index in ZRAM through the memory index corresponding to the target application, which is used to find the storage location of the compressed preset memory page corresponding to the target application. In some embodiments, when the preset driver finds that the storage location of the preset memory page applied by the application switched to the foreground is written with the index of ZRAM, it means that the preset memory page applied by the application is compressed and stored. In other words, when the application switches from the background to the foreground, it needs to perform a memory decompression operation.

[0235] In some embodiments, when the foreground and background listeners monitor the event that the application switches from the background to the foreground, they can send a memory query request to the preset driver. After receiving the memory query request, the preset driver queries the storage location of the memory resources corresponding to the application. If the preset driver queries that the storage location of the memory resources (preset memory page) applied for by the application is written with the index of ZRAM, it can be determined that the application is the target application, and the memory resources of the target application need to be decompressed. Afterwards, the preset driver can send a call request for the preset decompression interface to the compression processing module (such as ZRAM). Afterwards, the operation of ZRAM decompressing the memory resources of the application can refer to the above-mentioned S705-S708 process, which will not be repeated here.

[0236] In the technical solution provided in the embodiment of the present application, when an event of an application switching from the background to the foreground is detected, by querying the storage location of the memory resource (preset memory page) corresponding to the application, it is determined whether a decompression operation needs to be performed on the memory resource corresponding to the application. This ensures that the application can run normally when it switches from the background to the foreground.

[0237] In some embodiments, the user may operate on the mobile phone and switch from application A to application B. At this time, application A switches from the foreground to the background, and application B switches from the background to the foreground. Figure 8 , which shows the process of interaction between internal software modules when application A switches from the foreground to the background and application B switches from the background to the foreground.

[0238] S801. Application A switches from the foreground to the background.

[0239] S802. The foreground and background listeners detect an event in which application A switches from the foreground to the background.

[0240] S803. The foreground and background listeners notify the whitelist management module to perform a preset list check.

[0241] S804. The whitelist management module queries whether application A belongs to the preset list.

[0242] If the whitelist management module inquires and determines in S804 that application A belongs to the preset list, S805 is executed.

[0243] S805. The whitelist management module feeds back to the front and back listeners that application A belongs to the preset list.

[0244] S806. The foreground and background listeners send a compression notification message to the preset driver.

[0245] S807. The preset driver obtains the PSI value of the memory from the PSI module.

[0246] S808. The preset driver determines whether the PSI value of the memory is lower than the preset PSI value.

[0247] If the judgment result of S808 is no, execute S809-S811.

[0248] S809. The preset driver calls the preset compression interface of ZRAM.

[0249] S810.ZRAM compresses the preset memory page requested by application A.

[0250] S811.ZRAM writes the compressed preset memory page to the virtual disk of the memory.

[0251] If the judgment result of S808 is yes, execute S812-S815.

[0252] S812. The preset driver calls the preset compression interface of ZRAM.

[0253] S813. ZRAM compresses the preset memory page requested by application A.

[0254] S814.ZRAM writes the compressed preset memory page to the virtual disk of the memory.

[0255] S815.ZRAM moves the compressed preset memory pages to the physical disk.

[0256] While the preset driver compresses the memory of the application switched to the background (application A), the preset driver can also decompress the memory resources corresponding to the application switched to the foreground (application B), such as S816-S828.

[0257] S816. Application B switches from the background to the foreground.

[0258] S817. The foreground and background listeners detect the event that application B switches from the background to the foreground.

[0259] S818. The front-end and back-end listeners notify the whitelist management module to perform a preset list check.

[0260] S819. The whitelist management module queries whether application B belongs to the preset list.

[0261] If the whitelist management module inquires and determines in S819 that application B belongs to the preset list, S820 is executed.

[0262] S820. The whitelist management module feeds back to the front and back listeners that application B belongs to the preset list.

[0263] S821. The foreground and background listeners send a decompression notification message to the preset driver.

[0264] S822. The default driver calls the default decompression interface of ZRAM.

[0265] S823. ZRAM queries the storage location of the compressed preset memory page corresponding to the target application.

[0266] The ZRAM can search for the storage location of the compressed preset memory page corresponding to the target application according to the ZRAM index.

[0267] If the compressed preset memory page corresponding to the target application is stored in the virtual disk of the memory, S824 and S825 are executed.

[0268] S824.ZRAM obtains the compressed preset memory page corresponding to the target application from the virtual disk in the memory.

[0269] S825.ZRAM decompresses the compressed preset memory pages.

[0270] If the compressed preset memory page corresponding to the target application is stored in the physical disk, S826 - S828 are executed.

[0271] S826.ZRAM reads the compressed preset memory page corresponding to the application from the physical disk into the virtual disk in the memory.

[0272] S827.ZRAM obtains the compressed preset memory page corresponding to the application from the virtual disk in the memory.

[0273] S828.ZRAM decompresses the compressed preset memory pages.

[0274] It should be noted that the above S801-S815 and S816-S828 can be executed simultaneously by different processes of the mobile phone, and the two processes do not affect each other.

[0275] For the specific implementation process of the above S801-S815 and S816-S828, reference may be made to the description of the memory resource management method in the previous embodiment.

[0276] Next, combine Fig. 9and Fig.10 , the interaction between the preset driver and ZRAM is described in detail in the process in which the preset driver calls ZRAM to compress the preset memory page applied for by the target application, and the preset driver calls ZRAM to decompress the compressed preset memory page corresponding to the target application.

[0277] Please refer to Fig. 9 , which shows the interaction process between the preset driver and ZRAM in the process of the preset driver calling ZRAM to compress the preset memory page applied for by the target application. Specifically, the process includes steps after the preset driver receives the compression notification message.

[0278] After receiving the compression notification message, the preset driver calls the address allocation interface of ZRAM to obtain the swap-out page identifier (swap_entry_t).

[0279] Among them, swap_entry_t can be used to represent the address of the target storage space obtained by ZRAM and can be used to store compressed data. After receiving the call request for the address allocation interface sent by the preset driver, ZRAM can allocate an idle address for the target application and generate a corresponding swap_entry_t.

[0280] As can be seen from the above embodiments, when ZRAM compresses memory resources, it can store the compressed memory resources in a virtual disk in the memory or a physical disk. Therefore, the swap_entry_t allocated by the ZRAM driver to the preset driver can specifically correspond to the space in the virtual disk in the memory or the space in the physical disk.

[0281] Further, in combination with the description of the above embodiments, it can be known that the preset driver can determine whether to compress the preset memory page applied by the target application and store it in the virtual disk of the memory or in the physical disk in combination with the memory usage (such as the PSI value). Therefore, in some embodiments, when the preset driver calls the address allocation interface of ZRAM, it can carry a storage mark; the storage mark is used to indicate whether the compressed memory data needs to be stored in the virtual disk of the memory or in the physical disk. In this way, when ZRAM receives a call request for the address allocation interface of ZRAM, it can allocate swap_entry_t for the target application according to the storage mark carried therein. Specifically, if the storage mark indicates that the compressed memory data needs to be stored in the virtual disk of the memory, ZRAM allocates the target storage space from the virtual disk of the memory for the preset driver and generates the corresponding swap_entry_t. If the storage mark indicates that the compressed memory data needs to be stored in the physical disk, ZRAM allocates the target storage space from the physical disk for the preset driver and generates the corresponding swap_entry_t.

[0282] Then, ZRAM returns the generated swap_entry_t to the default driver.

[0283] Combined with the previous description, it can be known that the preset driver stores the storage location of the preset memory page requested by the application through the preset driver through the preset data structure. Therefore, the preset driver can find the preset memory page that the target application has requested, that is, the physical page, according to the preset data structure. Then, the preset driver can obtain the page* corresponding to the physical page. ZRAM can assign the obtained swap_entry_t to the parameters in page*, such as page->private.

[0284] The preset data structure may be an xarray data structure.

[0285] The preset driver calls the preset compression interface of ZRAM based on page*. Since page* corresponds to the preset memory page that the target application has applied for, ZRAM can find the preset memory page that the target application has applied for and perform compression operations on it. In addition, swap_entry_t is written in page*, so ZRAM can store the compressed memory data in the target storage space corresponding to swap_entry_t (virtual disk or physical disk of memory).

[0286] After ZRAM stores the compressed data in the target storage space corresponding to swap_entry_t, it can notify the preset driver that the compression storage is completed.

[0287] After receiving the message, the preset driver can release the original physical page of the preset memory page applied by the target application from the memory. In addition, since ZRAM has compressed the preset memory page applied by the target application and stored it in the target storage space corresponding to swap_entry_t, the preset driver can store swap_entry_t in the preset data structure. This makes it easier for the preset driver to find the storage location of the compressed preset memory page corresponding to the target application. Fig. 9 As shown, after releasing the original physical page of the preset memory page applied for by the target application, the preset driver inserts the swap_entry_t indicating the compressed preset memory page corresponding to the target application into the memory index position corresponding to the target application in the preset data structure.

[0288] Please refer to Fig.10, which shows the interaction process between the preset driver (including the GPU driver and / or the DMABUF driver) and the ZRAM in the process of the preset driver calling the ZRAM to decompress the preset memory page applied for by the target application. Specifically, the process includes the steps after the preset driver receives the decompression notification message.

[0289] After receiving the decompression notification message, the preset driver can find the memory index corresponding to the target application from the preset data structure of the preset driver to find the storage location of the compressed preset memory page, that is, Fig. 9 swap_entry_t in the process shown.

[0290] Since the physical pages applied for by the target application are released after compression, the preset driver needs to allocate new physical pages for the target application when performing a decompression operation on the memory resources of the target application.

[0291] Then, the preset driver assigns the swap_entry_t found in the preset data structure to the parameter of page* corresponding to the newly allocated physical page, such as page->private, so that ZRAM can find the compressed preset memory page corresponding to the target application and decompress it.

[0292] The default driver calls the default decompression interface of ZRAM based on the page* corresponding to the new physical page.

[0293] After ZRAM receives the call request for the preset decompression interface, it can obtain the page* carried therein. Since swap_entry_t is written in page*, ZRAM can find the data that needs to be decompressed according to swap_entry_t, that is, the compressed preset memory page corresponding to the target application. In addition, the page* corresponds to the physical page newly allocated by the preset driver for the target application, so ZRAM can find the address of the new physical page and copy the decompressed data (that is, the preset memory page applied for by the target application) to the new physical page.

[0294] It can be understood that after ZRAM copies the decompressed data to the new physical page, the compressed preset memory page corresponding to the target application in the target storage space indicated by the swap_entry_t can be released.

[0295] Afterwards, ZRAM can feedback a message of successful decompression to the preset driver. In some embodiments, after ZRAM copies the decompressed data to a new physical page, the page* corresponding to the new physical page will be updated accordingly. Therefore, ZRAM can return the updated page* to the preset driver.

[0296] After receiving the feedback message from ZRAM, the preset driver can insert the page* corresponding to the new physical page into the location corresponding to the memory index corresponding to the target application in the preset data structure of the preset driver. Thus, the target application can access the preset memory page applied by the target application based on the memory index corresponding to the target application through the preset driver.

[0297] Some other embodiments of the present application provide an electronic device (such as a mobile phone). The computer device may include: a memory and one or more processors. The memory is coupled to the processor. The memory is also used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the computer device can execute the various functions or steps executed by the mobile phone in the above method embodiment. When the computer device is an electronic device, its structure can refer to Figure 2 The structure of the electronic device 100 is shown.

[0298] The present application also provides a chip system, such as Fig.11 As shown, the chip system 110 includes at least one processor 1101 and at least one interface circuit 1102. The processor 1101 and the interface circuit 1102 can be interconnected via lines. For example, the interface circuit 1102 can be used to receive signals from other devices (such as the memory of a computer device). For another example, the interface circuit 1102 can be used to send signals to other devices (such as the processor 1101). Exemplarily, the interface circuit 1102 can read instructions stored in the memory and send the instructions to the processor 1101. When the instruction is executed by the processor 1101, the computer device can execute the various steps in the above embodiments. Of course, the chip system can also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0299] An embodiment of the present application also provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device (such as a mobile phone), the electronic device executes each function or step executed by the mobile phone in the above-mentioned method embodiment.

[0300] The present application also provides a computer program product, which, when executed on a computer, enables the computer to execute the functions or steps executed by the mobile phone in the above method embodiment. The computer may be an electronic device, such as a mobile phone.

[0301] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0302] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0303] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0304] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0305] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to perform all or part of the steps of the methods of each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory, disk or optical disk and other media that can store program code.

[0306] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A memory resource management method, characterized in that: The method is applied to an electronic device, the electronic device is installed with a target application, the electronic device includes a memory, a graphics processor GPU driver and a direct memory access buffer DMABUF driver, and the method includes: In response to a first operation of switching the target application from the foreground to the background, obtaining an initial preset memory page applied for by the target application from the memory; the initial preset memory page includes a memory page applied for by the target application through a GPU driver and / or a DMABUF driver; Compressing the initial preset memory page to obtain a compressed preset memory page, and storing the compressed preset memory page to a virtual disk of the memory; The initial preset memory page is released in the memory.

2. The method according to claim 1, characterized in that The electronic device further includes a non-volatile memory; after storing the compressed preset memory page to the virtual disk of the memory, the method further includes: The compressed preset memory page is moved to the non-volatile memory.

3. The method according to claim 2, characterized in that Before compressing the initial preset memory page, the method further includes: Obtaining usage of the memory; The step of moving the compressed preset memory page to the non-volatile memory comprises: If the memory usage indicates that the pressure value of the memory is greater than or equal to the preset pressure value, the compressed preset memory page is moved to the non-volatile memory; wherein, if the memory usage indicates that the pressure value of the memory is less than the preset pressure value, the compressed preset memory page is not moved to the non-volatile memory.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: In response to the first operation, applying for a target storage space for storing compressed memory data; Based on the address of the target storage space, generating a swap-out page identifier; the swap-out page identifier is used to represent the address of the target storage space; The step of storing the compressed preset memory page to the virtual disk of the memory includes: The compressed preset memory page is stored in the storage space corresponding to the swap-out page identifier.

5. The method according to claim 4, characterized in that The electronic device further comprises a compression processing module; The step of applying for a target storage space for storing compressed memory data in response to the first operation includes: the GPU driver and / or the DMABUF driver applying for the target storage space from the compression processing module in response to the first operation; The generating of the swap-out page identifier based on the address of the target storage space includes: the compression processing module generating the swap-out page identifier based on the address of the target storage space.

6. The method according to claim 5, characterized in that The method further comprises: The compression processing module returns the swap-out page identifier to the GPU driver and / or the DMABUF driver; The GPU driver and / or the DMABUF driver writes the swap-out page identifier into a preset parameter of a page data structure corresponding to the initial preset memory page; the page data structure is used to describe the initial preset memory page; The compressing the initial preset memory page to obtain a compressed preset memory page includes: The GPU driver and / or the DMABUF driver calls a preset compression interface of the compression processing module based on the page data structure; The compression processing module obtains the initial preset memory page based on the page data structure; The compression processing module compresses the initial preset memory page to obtain a compressed preset memory page; The step of storing the compressed preset memory page in the storage space corresponding to the swap-out page identifier includes: The compression processing module stores the compressed preset memory page in the storage space corresponding to the swap-out page identifier.

7. The method according to claim 5 or 6, characterized in that: The compression processing module includes a ZRAM block device driver.

8. The method according to any one of claims 1 to 7, characterized in that The acquiring, from the memory, the initial preset memory page applied for by the target application includes: Searching for a memory index corresponding to the target application in the GPU driver and / or the DMABUF driver; According to the memory index corresponding to the target application, the initial preset memory page is searched and obtained in the memory.

9. The method according to claim 8, characterized in that After compressing the initial preset memory page to obtain a compressed preset memory page, and storing the compressed preset memory page in the virtual disk of the memory, the method further includes: Acquire a swap-out page identifier corresponding to the compressed preset memory page; the swap-out page identifier is used to indicate a storage location of the compressed preset memory page; The swap-out page identifier is written into a storage location of a preset memory page applied for by the target application in a memory index corresponding to the target application.

10. The method according to any one of claims 1 to 9, characterized in that After releasing the initial preset memory page in the memory, the method further includes: In response to a second operation of switching the target application from the background to the foreground, allocating a physical page for the target application and acquiring the compressed preset memory page; Decompressing the compressed preset memory page, and writing the decompressed data into the physical page; The physical page is written into a memory index corresponding to the target application in the GPU driver or the DMABUF driver, where the memory index corresponding to the target application is used to indicate a storage location of the memory applied for by the target application.

11. The method according to claim 10, characterized in that The electronic device further includes a non-volatile memory; after storing the compressed preset memory page to the virtual disk of the memory, the method further includes: Moving the compressed preset memory page to the non-volatile memory; Wherein, the obtaining of the compressed preset memory page comprises: moving the compressed preset memory page from the non-volatile memory to the virtual disk; The compressed preset memory page is obtained from the virtual disk.

12. The method according to any one of claims 1 to 11, characterized in that The target application includes a camera application or a game application.

13. An electronic device, characterized in that: The electronic device comprises: a processor and a memory; the memory is coupled to the processor; a computer program code is stored in the memory, and the computer program code comprises computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method as described in any one of claims 1-12.

14. A computer-readable storage medium, characterized in that: The method comprises computer instructions, which, when executed on an electronic device, cause the electronic device to execute the method as claimed in any one of claims 1 to 12.

Citation Information

Cited By

  • Method for releasing DMA buffer area, electronic equipment, readable storage medium and program product

    CN120670134A

  • Method, electronic device, readable storage medium and program product for releasing DMA buffer

    CN120670134B

  • Data processing method, readable storage medium, program product, and electronic device

    WO2026179121A1