Memory management method and electronic device

Abstract

Provided in the present application are a memory management method and an electronic device. In the method, when it is detected that a first application switches to a background state and a binding state of texture data of the first application is in a stable state, an electronic device can determine that the first application does not need to display an image and does not need to perform graphics rendering, that is, it can be determined that the first application does not currently need to use a GPU physical memory. In this case, the electronic device can store in a magnetic disk first content stored in a first GPU physical memory corresponding to the first application, and can release the first GPU physical memory, so as to reduce the occupation of the GPU physical memory, which can increase the remaining available physical memory of the electronic device, improve the response speed of the electronic device to user operations, improve the smoothness of a system, and improve the user experience.

Description

Memory management methods and electronic devices

[0001] This application claims priority to Chinese Patent Application No. 202411506338.4, filed on October 25, 2024, entitled "Memory Management Method and Electronic Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of terminal technology, and in particular to a memory management method and an electronic device. Background Technology

[0003] Electronic devices such as mobile phones and tablets generally include a graphics processing unit (GPU). The GPU is used to render the user interface required by applications. Before rendering the user interface, the GPU encodes interface elements such as images and text into texture data. The GPU caches this encoded texture data in its memory. This texture data serves as input to the rendering module (e.g., the rendering engine) within the GPU. After the rendering module renders the texture data, it does not release the cached texture data from the GPU's memory. Therefore, for applications requiring a large amount of texture memory (e.g., games), the GPU's memory usage increases significantly during rendering. This can lead to insufficient GPU memory, causing the electronic device to become increasingly responsive to user actions, thus negatively impacting the user experience. Summary of the Invention

[0004] This application provides a memory management method and an electronic device. This method allows for timely write-to-disk texture data when an application is moved to the background, thus releasing memory and alleviating memory pressure. When the application returns to the foreground, it only reads the texture data needed for the displayed interface from the disk. When the user swipes within the application interface, the electronic device can pre-read the content currently displayed and the content to be displayed on the next screen from the disk based on the swipe direction, enabling the electronic device to display the content of the next screen more quickly. This accelerates the response speed of the electronic device to user operations and improves the user experience.

[0005] In a first aspect, this application provides a memory management method applicable to an electronic device, the electronic device including a central processing unit (CPU), a disk, memory, and a first application. The method may include: displaying a first interface of the first application, the first interface including first content; in response to a first operation, the first application switching to the background; in response to a second operation, the CPU obtaining a first index code of a first table, the second operation being used to instruct the first application to switch from the background to the foreground, the first index code being located at the top of the stack of the first table, the first table being used to store index codes of multiple contents of the first interface, the multiple contents including the first content, the first index code being the index code of the first content; the CPU determining a first storage address of the first content based on the first index code; the CPU sending a first command to the disk, the first command being used to instruct the disk to read the first content from the first storage address into memory; and redisplaying the first content.

[0006] The first content may include one or more texture data.

[0007] Using the method provided in the first aspect, when the first application returns to the foreground, it can read only the content to be displayed from the disk, without needing to read all the data of the first application stored on the disk. This reduces the number of disk reads, reduces disk wear, and extends the lifespan of the disk. Furthermore, not reading all the data of the first application into memory avoids increasing memory pressure and prevents a sudden increase in memory pressure from slowing down the operation of electronic devices.

[0008] In conjunction with the first aspect, in one possible implementation, the method may further include: in response to a third operation, the CPU obtains a second index code and a third index code of a first table, the third operation being used to instruct a first application to display a second interface, the second interface including second content, the second index code being an index code of the second content, the third index code being an index code of the third content, and the third index code and the second index code being adjacent; the CPU determines a second storage address of the second content based on the second index code, and determines a third storage address of the third content based on the third index code; sends a second command to the disk, the second command being used to instruct the disk to read the second content at the second storage address and the third content at the third storage address into memory; and displays the second interface.

[0009] The second interface can be the interface displayed after the user swipes up or down on the first interface, or it can be the interface displayed after the user enters an operation to jump to another interface on the first interface.

[0010] The third operation is an upward sliding operation, with the third index code above the second index code; the third operation is a downward sliding operation, with the third index code below the second index code.

[0011] In this way, when a user swipes, the electronic device can preload third content from its disk based on that swipe. That is, the electronic device not only loads the second content that is about to be displayed, but also the third content that may be displayed later. This allows the electronic device to display the third content more quickly, thus improving the user experience.

[0012] In conjunction with the first aspect, in one possible implementation, the electronic device further includes a graphics processing unit (GPU), and after displaying the second interface, the method may further include: in response to a fourth operation, the CPU instructs the GPU to render third content in memory, the fourth operation being used to instruct the first application to display the third interface, the third interface including the third content; and displaying the third interface.

[0013] In this way, since the third content is pre-loaded into memory, when the user needs to view this third content in the first application, the electronic device does not need to read it from the disk; it can directly render the third content in memory. This allows the electronic device to display the third content faster. In other words, it improves the responsiveness of the electronic device to this fourth operation, thereby enhancing the user experience.

[0014] In conjunction with the first aspect, in one possible implementation, in response to the first operation, after the first application switches to the background, the method may further include: releasing the mapping relationship between the first GPU virtual address of the first content in the GPU and the first physical address of the first content in memory; storing the first content stored in the physical memory corresponding to the first physical address to the disk; and releasing the physical memory corresponding to the first physical address.

[0015] This way, when the first application is switched to the background, the data of the first application stored in memory can be promptly written to disk. This can alleviate memory pressure and prevent electronic devices from slowing down due to excessive memory load.

[0016] In conjunction with the first aspect, in one possible implementation, before storing the first content stored in the physical memory corresponding to the first physical address to the disk, the method may further include: the CPU determining that the first physical address of the first content has not established a mapping relationship with the virtual address in the GPU within a preset time period.

[0017] In this way, the data of the first application stored in memory is only written to disk after it is confirmed that the first application will not be switched back to the foreground or unfrozen in the background within a short period of time. This implementation method can avoid the situation where the user suddenly switches the first application to the foreground or unfrozen in the background while the data of the first application stored in memory is being written to disk, which would prevent the electronic device from displaying the first application in time and affect the user experience.

[0018] In conjunction with the first aspect, in one possible implementation, when storing the first content stored in the physical memory corresponding to the first physical address to the disk, it may further include: storing all the content of the first application stored in memory to the disk.

[0019] In this way, once it is determined that the first application will not be switched back to the foreground or unfrozen in the background in a short period of time, storing all the contents of the first application stored in memory to the disk can alleviate memory pressure.

[0020] In conjunction with the first aspect, in one possible implementation, after the CPU determines that the first physical address of the first content has not established a mapping relationship with the virtual address in the GPU within a preset time period, the method may further include: the electronic device detecting that the memory occupancy rate is higher than a preset threshold. In this way, the electronic device can promptly detect excessive memory pressure.

[0021] In conjunction with the first aspect, in one possible implementation, after the electronic device detects that the memory occupancy rate is higher than a preset threshold, the method may further include: the electronic device determining a first data volume, the first data volume being the amount of data in memory that needs to be stored on the disk; if the amount of data of all content of the first application stored in memory is greater than the first data volume, the electronic device stores a portion of the content of the first application on the disk, the portion of content including the first content, and the amount of the portion of content being less than or equal to the first data volume.

[0022] This allows for data write-to-disk adjustments based on memory usage, writing only a portion of the data and reducing the total amount written. This reduces the number of disk I / O calls, improving data read / write speeds. Furthermore, it reduces disk space usage and extends disk lifespan.

[0023] In conjunction with the first aspect, in one possible implementation, the method may further include: in response to a fifth operation, the CPU sends a third command to the disk, the fifth operation instructing the first application to exit execution, and the third command instructing the disk to clean up all or part of the stored content of the first application; the disk receives the third command and cleans up all or part of the content. This can reduce disk space usage in a timely manner.

[0024] In a second aspect, an electronic device is provided, characterized in that it includes one or more processors; one or more memories; the one or more memories storing one or more computer programs, the one or more computer programs including instructions that, when executed by the one or more processors, cause the electronic device to perform the method described in any possible implementation of the first aspect above.

[0025] Thirdly, a chip is provided, the chip including a processor and a communication interface, the communication interface being used to receive a signal and transmit the signal to the processor, the processor processing the signal, causing the chip to perform the method described in any possible implementation of the first aspect above.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a computer, causes the computer to implement the method described in any possible implementation of the first aspect above.

[0027] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in any possible implementation of the first aspect above.

[0028] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0029] Figure 1A is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0030] Figure 1B is a schematic diagram of the structure of an electronic device processor and memory provided in an embodiment of this application;

[0031] Figure 2 is a software structure diagram of an electronic device provided in an embodiment of this application;

[0032] Figure 3 is a schematic diagram of a memory allocation and release mechanism provided in an embodiment of this application;

[0033] Figure 4 is a schematic diagram of the memory occupied by the texture data of an application when the application is moved to the background, according to an embodiment of this application.

[0034] Figure 5 is a schematic diagram of texture data binding and disk writing provided in an embodiment of this application;

[0035] Figure 6 is a schematic diagram of a process for writing memory data to disk according to an embodiment of this application;

[0036] Figure 7 is a set of interface diagrams provided in an embodiment of this application;

[0037] Figure 8 is a schematic diagram of texture data being written to disk according to an embodiment of this application;

[0038] Figure 9 is a schematic diagram of another process for writing memory data to disk provided in an embodiment of this application;

[0039] Figure 10 is a flowchart illustrating a memory management method provided in an embodiment of this application;

[0040] Figure 11 is a schematic diagram of an interface provided in an embodiment of this application;

[0041] Figures 12A and 12B are schematic diagrams of texture data loading provided in the embodiments of this application;

[0042] Figure 13 is a flowchart illustrating a memory management method provided in an embodiment of this application. Detailed Implementation

[0043] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0044] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. The terms “first” and “second” are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as “first” or “second” may explicitly or implicitly include one or more of that feature. “First” and “second,” etc., are used to distinguish different objects, not to describe a particular order of objects. For example, a first object and a second object are used to distinguish different objects, not to describe a particular order of objects.

[0045] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

[0046] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or related scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0047] The term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A existing alone, A and B existing simultaneously, and B existing alone.

[0048] To better understand the technical solutions provided in this application, before describing the technical solutions, we will first refer to the accompanying drawings to explain the electronic device 100 with a camera function to which this application applies. In the embodiments of this application, the electronic device 100 may include, but is not limited to, devices with camera functions such as mobile phones, tablets, and smartwatches. The embodiments of this application do not limit the specific form or type of the electronic device 100.

[0049] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0050] For ease of understanding, the key technical terms that may be involved in the embodiments of this application will be introduced below.

[0051] Texture data: A format of image data that can contain details of the surface of objects in an image. Specifically, texture data can represent the colored planar patterns or uneven grooves in an image. Texture data is data that the GPU can recognize and process for rendering.

[0052] Rendered data: The GPU performs pixel rendering and pixel filling processes based on texture data and drawing instructions, and the resulting data is called rendered data. The display module of an electronic device (e.g., a display screen) can display images based on the rendered data.

[0053] Foreground: This refers to the state in which an application is being opened, operated, or currently displayed by the user. Applications in the foreground can perform actions that are noticeable to the user.

[0054] Background: This refers to an application that is still running but no longer displayed on the screen, and the user is no longer directly interacting with or paying attention to its state. Users generally won't directly notice the operations performed by an application in the background.

[0055] A process is the execution vehicle of an application. A process can be viewed as an independent program. It is the basic unit of resource allocation and scheduling. For example, when a user runs an application, the system creates a process and allocates resources to it (such as CPU and / or GPU resources). Then, the process is placed in the process ready queue. When the process is selected by the scheduler, the system allocates CPU and / or GPU resources to it, and only then does the process actually run.

[0056] Virtual memory (VA): also known as logical memory. Virtual memory is a memory management technique that allows the system to provide each process with a larger address space than the actual physical memory. This address space is called the virtual address space, while the actual physical memory is called the physical address space. The virtual address space can include one or more virtual addresses, and the physical address space can include one or more physical addresses.

[0057] Physical memory (PA) refers to random access memory (RAM), which is the actual hardware memory of an electronic device used to store running programs and data. The physical memory of an electronic device can also be called its system memory.

[0058] GPU physical memory, also known as GPU memory, refers to the physical memory allocated to the GPU in an electronic device. GPU physical memory is used to store data related to graphics rendering. When a running application requires graphics rendering, the GPU can allocate corresponding GPU physical memory for that application and store the application's graphics rendering-related data in that application's dedicated GPU physical memory. GPU physical memory can be a portion of system memory. For example, the GPU physical memory of an integrated graphics card can be part of the system memory, meaning that the GPU physical memory of an integrated graphics card will consume a portion of the system memory, resulting in a reduction in system memory. Alternatively, GPU physical memory can be a separate physical memory from system memory. For example, a dedicated graphics card can have its own dedicated GPU physical memory, meaning that the dedicated graphics card does not consume system memory.

[0059] Page: In memory management, a page is the smallest unit of address space; that is, a page can be the smallest unit of both virtual and physical address space. A typical page is 4 kilobytes (KB).

[0060] Generally, a system can divide both the virtual address space and the physical address space into multiple fixed-size pages, and maintain a page table for each process. The page table stores the mapping between virtual pages and physical pages within that process. A virtual page can refer to a page in the virtual address space, and a physical page can refer to a page in the physical address space.

[0061] When a process needs to access a specific virtual address, the system can determine the virtual page corresponding to that address. Based on the process's page table, it can look up the physical page mapped to that virtual page and determine the physical address of that mapped physical page. This allows the process to access physical memory based on the physical address. The virtual address can include a virtual page number and a virtual page offset. The physical address can include a physical page number and a physical page offset. Therefore, the system can determine the virtual page based on the virtual address and the physical address based on the physical page.

[0062] For a process, not all virtual addresses have corresponding physical pages in physical memory. When a process accesses a virtual address and cannot find a corresponding physical page by looking up the page table, or finds a corresponding physical page but does not have the access permission, a page fault will occur.

[0063] A page fault is an error triggered by a hardware interrupt that can be corrected by software logic.

[0064] Page faults can include hard page faults, soft page faults, and invalid page faults. Hard page faults are also called major page faults, and soft page faults are also called minor page faults.

[0065] A hard page fault occurs when a process needs to access a virtual address, but there is no corresponding physical page in physical memory. When a hard page fault occurs, the system can read the corresponding data from the disk into physical memory. In other words, it can request a physical page in physical memory to store the data and establish a mapping between the virtual page corresponding to the virtual address and the physical page. This allows the process to access physical memory by mapping the virtual address to the corresponding physical address.

[0066] A soft page fault occurs when a process needs to access a virtual address, for which a corresponding physical page exists in physical memory, but this page might have been loaded by another process, and the process that issued the page fault is unaware of it. When a soft page fault occurs, the system only needs to establish a mapping between the virtual page and the physical page corresponding to that virtual address; it does not need to read the corresponding data from the disk into physical memory. Soft page faults typically occur in scenarios where multiple processes share a memory region.

[0067] Invalid page fault exception: This means that the process accesses a physical address that is out of bounds or references a null pointer. In this case, the system can send an exception notification and terminate the process.

[0068] Similarly, GPU physical memory can be managed by the GPU in an electronic device. For each running application, the GPU can maintain a GPU page table for its corresponding process. The GPU page table can store the mapping between virtual pages and GPU physical pages (also simply called physical pages). When a process needs to access a certain virtual address, the GPU can determine the virtual page corresponding to that virtual address, and according to the GPU page table for that process, map that virtual page to the corresponding GPU physical page, and determine the physical address corresponding to the mapped GPU physical page, thus allowing the process to access GPU physical memory based on the physical address.

[0069] In some examples, when an electronic device uses an integrated graphics card, the CPU and GPU can also share a memory block. That is, both the CPU and GPU can access the data stored in the same memory space. This application embodiment uses the storage of texture data in a memory space that can be shared by the CPU and GPU as an example for illustration.

[0070] To better understand the technical solutions provided in this application, the electronic device 100 of this application will be described first with reference to the accompanying drawings before the technical solutions are explained. In the embodiments of this application, the electronic device 100 may include, but is not limited to: mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices (e.g., smartwatches, smart bracelets, etc.), in-vehicle devices, and smart home devices (e.g., smart TVs, smart screens, large-screen devices, etc.). The embodiments of this application do not limit the specific form or type of the electronic device 100.

[0071] The following describes an exemplary electronic device 100 provided in an embodiment of this application.

[0072] Figure 1A is a schematic diagram of the structure of the electronic device 100 provided in an embodiment of this application.

[0073] As shown in Figure 1A, 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 speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0074] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0075] Processor 110 may include one or more processing units, such as a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors. As an example, only the CPU and GPU are shown in processor 110 in Figure 1A.

[0076] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0077] The processor 110 may also include a memory for storing instructions and data. In some examples, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or is reusing. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0078] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback.

[0079] The charging management module 140 receives charging input from a charger, which can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0080] 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 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

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

[0082] 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 one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0083] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc.

[0084] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc.

[0085] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering.

[0086] The display screen 194 is used to display images, videos, etc. The display screen 194 can be a liquid crystal display (LCD), an OLED display, etc. This application embodiment does not limit the material of the display screen 194. In some embodiments, the display screen 194 may also include a flexible foldable screen. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0087] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0088] The ISP is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye.

[0089] Camera 193 is used to capture still images or videos. In some embodiments, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0090] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0091] NPU stands for Neural Network (NN) Computing Processor. By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as AI image generation, image fusion, image recognition, facial recognition, speech recognition, and text understanding.

[0092] The external storage 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 storage interface 120 to perform data storage functions. For example, music, video, and other files can be stored on the external memory card.

[0093] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0094] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0095] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 170 can also be used for encoding and decoding audio signals.

[0096] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, gravity sensors, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, angle sensors, etc.

[0097] The gyroscope sensor can be used to determine the motion attitude of the electronic device 100. In some embodiments, the angular velocity of the electronic device 100 about three axes (i.e., the x, y, and z axes) can be determined by the gyroscope sensor. The offset angle of the electronic device 100 can also be determined by the gyroscope sensor.

[0098] An accelerometer can detect the magnitude of acceleration of an electronic device 100 in various directions (typically three axes). In some embodiments, the accelerometer can be used to identify the posture of the electronic device 100, and can be applied to applications such as screen orientation switching and pedometers.

[0099] Magnetic sensors can include Hall effect sensors, magnetometers, and so on.

[0100] Angle sensors can be used to detect the folding angle of a 100° foldable screen in electronic devices.

[0101] Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0102] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with or separate from the electronic device 100.

[0103] The following section describes the hardware relationship between the CPU, GPU, and memory included in the electronic device 100, as well as the respective functions of each component.

[0104] For example, Figure 1B shows a schematic diagram of the structure of the processor and memory of the electronic device 100.

[0105] As shown in Figure 1B, a CPU can be a large-scale integrated circuit, serving as the core of a computer's processing and control center. The main functions of a CPU are to interpret computer instructions and process data within computer software.

[0106] The CPU mainly consists of an arithmetic logic unit (ALU), a cache, and a bus that connects them for data, control, and status.

[0107] The CPU may include a memory management unit 1 (MMU1). The MMU1 can be used to map virtual addresses on the CPU to the physical addresses corresponding to texture data, and to demap the virtual addresses on the CPU to the physical addresses corresponding to texture data.

[0108] A GPU, also known as a graphics processing unit (GPU), visual processor, or display chip, is a microprocessor specifically designed for image processing. The GPU converts and drives the information required for display by an electronic device, providing scanning signals to the monitor to control its correct display. The GPU is a crucial component connecting the monitor and the CPU.

[0109] As shown in Figure 1B, a GPU may include a task management module, a shader module, an advanced peripheral bus (APB) module, a rendering module, and an MMU2. The task management module manages the GPU's execution of rendering instructions issued by the CPU. The shader module converts input data (such as vertex positions and colors) into output data (such as pixel colors) to achieve image rendering and processing. The APB module connects low-power external peripherals. Rendering materials are used to shape the appearance of images, simulate lighting and texture, and enhance visual effects during GPU rendering. The MMU2 maps virtual addresses on the GPU to the physical addresses corresponding to texture data and demaps the virtual addresses on the GPU to the physical addresses corresponding to texture data.

[0110] The CPU can send commands to the GPU; for example, this command could be an instruction to render an image. The GPU can interact with the CPU by sending interrupts.

[0111] Internal memory 121, often simply referred to as RAM, is a device in electronic devices used to store data and programs, and also serves as a bridge for interaction between the CPU and GPU. The data storage area in internal memory 121 may include memory partitions accessible by the CPU and memory partitions accessible by the GPU.

[0112] As shown in Figure 1B, the internal memory 121 can be double data rate (DDR) memory, or simply DDR memory. All programs in the electronic device 100 run in memory. The data stored in memory can be used to temporarily store computational data from the CPU or GPU, as well as data exchanged with external storage devices such as hard drives. As long as the electronic device 100 is running, the CPU or GPU will load the data required for computation into memory for processing, and then retrieve the result from memory after the computation is complete.

[0113] Alternatively, in one possible implementation, as shown in Figure 1B, the DDR memory may include GPU-accessible memory partitions and CPU-accessible memory partitions.

[0114] In another possible implementation, the memory partition accessible to the GPU and the memory partition accessible to the CPU can be the same. That is, the CPU and GPU can also share a memory block. Both the CPU and GPU can access the data stored in the same memory space. This application embodiment uses the example of texture data being stored in a memory space that can be shared by the CPU and GPU for illustration.

[0115] Figure 2 is a software structure block diagram of an electronic device 100 according to an embodiment of this application.

[0116] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the system is divided into four layers, from top to bottom: the application layer, the application framework layer, the runtime and system libraries, and the kernel layer.

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

[0118] As shown in Figure 2, the application package may include applications (also known as apps) such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0119] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0120] As shown in Figure 2, the application framework layer may include an activity manager service (AMS), a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc.

[0121] Activity management services are used to manage activities, such as managing their lifecycle. An activity is a component that can contain a user interface and is primarily used for interaction with the user, such as making a phone call, sending an email, and viewing a map. Most of the content that users see in an application is provided by activity components, and an application can include multiple activities.

[0122] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0123] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

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

[0125] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0126] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0127] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog-style notifications on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0128] The runtime consists of the core libraries and the virtual machine. The runtime is responsible for system scheduling and management.

[0129] The core library consists of two parts: one part is the functionalities that the programming language (e.g., Java) needs to call, and the other part is the system's core library.

[0130] The application layer and application framework layer run in a virtual machine. The virtual machine executes the programming files (e.g., Java files) of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0131] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0132] The Surface Manager is used to manage the display subsystem and provides the fusion of two-dimensional (2D) and three-dimensional (3D) layers for multiple applications.

[0133] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0134] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0135] A 2D graphics engine is a graphics engine for 2D drawing.

[0136] The kernel layer is the layer between hardware and software. The kernel layer includes at least the display driver, camera driver, audio driver, sensor driver, and virtual card driver.

[0137] The following example, using scenarios that trigger image display, illustrates the workflow of the software and hardware of electronic device 100.

[0138] When the touch sensor receives a touch operation, the corresponding hardware interrupt is sent to the kernel layer. The kernel layer processes the touch operation into a raw input event (including touch coordinates, timestamp of the touch operation, etc.). The raw input event is stored in the kernel layer. The application framework layer retrieves the raw input event from the kernel layer and identifies the control corresponding to the input event. Taking a touch click as an example, where the corresponding control is the gallery application icon, the gallery application calls the application framework layer's interface to launch the gallery application, and then calls the kernel layer to launch the display driver, displaying the image on the screen.

[0139] Currently, when an application performs graphics rendering using the GPU, the relevant graphics rendering data can be stored in the application's corresponding GPU physical memory (or GPU memory). Taking application A installed on electronic device 100 as an example, application A can be any application with a graphical user interface on electronic device 100, such as a gallery, browser, or video player. When application A displays image 1, it can send the data to be rendered corresponding to image 1 to the GPU. For example, it can send images, fonts, or coordinate points to the GPU. The GPU can request a portion of the electronic device's physical memory as the GPU physical memory corresponding to application A, and after obtaining the data to be rendered corresponding to image 1, it can store the data to be rendered corresponding to image 1 in the GPU physical memory corresponding to application A.

[0140] When the GPU renders image 1, it can retrieve the data to be rendered for image 1 from the GPU physical memory corresponding to application A. Subsequently, the GPU can decode and compute the data to be rendered for image 1, and store the resulting texture data in the GPU physical memory corresponding to application A. Finally, the electronic device can render the processed texture data to obtain the rendered data. The GPU can then send the rendered data to the display module (e.g., a display screen) to display image 1, thus enabling application A to display image 1.

[0141] GPU physical memory is typically managed jointly by the 2D / 3D engine and the GPU driver. If application A is not exiting the application and the 2D / 3D engine and GPU driver do not release memory, the texture data associated with application A will remain stored in the GPU physical memory. For example, when application A goes into the background, the GPU physical memory it occupies is not released. This leads to an increasing consumption of GPU physical memory as the number of applications performing graphics rendering on the electronic device increases, resulting in less and less available physical memory. Consequently, the electronic device becomes increasingly responsive to user actions, negatively impacting the user experience.

[0142] In one possible implementation, the electronic device can manage GPU memory through three layers. As shown in Figure 3, the first layer can be a 2D / 3D engine layer, the second layer can be a user-mode driver layer, and the third layer can be a kernel-mode driver layer. The 2D / 3D engine layer can be used to manage abstract resources for rendering operations, including texture attributes, texture size, and resource binding usage. The 2D / 3D engine can be the Skia engine, Unity engine, etc., and this embodiment does not limit this.

[0143] The user-mode driver layer can be used to implement the APIs of the upper layer used to call the 2D / 3D engine. This user-mode driver layer can also be used to manage the GPU physical memory buffer pool and accelerate subsequent GPU physical memory allocation.

[0144] The kernel-mode driver layer can be used to request and release actual physical memory in the kernel, handling the allocation and release of GPU physical memory. This kernel-mode driver layer can contain GPU drivers.

[0145] For the 2D / 3D engine layer, the operating system of electronic device 100 allocates a GPU physical memory usage limit for each application that needs to be rendered. Taking application A as an example, when the texture data of application A's foreground business exceeds the specified limit, it will require the texture data to be reused in the GPU physical memory allocated for application A and already storing the texture data. If the GPU physical memory cannot be reused, the operating system will release the GPU physical memory allocated for application A and re-allocate GPU physical memory with a larger limit for application A. However, in this way, electronic device 100 needs to regenerate the released texture data. The generation of texture data consumes GPU resources and takes a long time. Electronic device 100 discarding the already generated texture data and regenerating it will affect the performance of the application's foreground business, which may cause frame drops in the business being rendered, thus causing the application interface to lag.

[0146] As shown in Figure 4, when an application goes to the background, the operating system actively instructs the 2D / 3D engine layer to release most of the GPU physical memory occupied by texture data. The released GPU physical memory is then returned to the unallocated cache space of the user-mode driver. The user-mode driver layer periodically returns the unallocated cache space to the kernel space. This reduces the application's memory usage in the background. However, for games or third-party cross-platform rendering engines such as Cocos, Unity, or Flutter, the operating system cannot align texture memory usage and promptly instruct the engine layer to release texture data. This leads to high GPU physical memory usage and low efficiency. As third-party cross-platform rendering engines become more widespread, the problems of high GPU physical memory usage and low efficiency will become increasingly prominent.

[0147] To reduce GPU physical memory usage and improve its efficiency, in one possible implementation, the electronic device 100 can set an upper limit on the GPU physical memory used by each application while it is running in the foreground. When an application switches to the background, the electronic device 100 clears the texture data in the GPU physical memory occupied by that application. This effectively limits the memory resource usage limit for each application and keeps GPU physical memory usage low when background applications are not displayed. However, the fixed amount of GPU physical memory allocated to an application for storing texture data can be reused only if the size of the texture data required for rendering each application is the same. When the memory required for the texture data of the application's current rendering needs to exceed the allocated GPU physical memory, the application needs to request new GPU physical memory, and the system will reclaim the previously allocated GPU physical memory. Discarding and regenerating already generated texture data by the electronic device 100 will impact the performance of the application's foreground operations. Furthermore, after clearing the texture data of an application that has switched to the background, when that application returns to the foreground, the electronic device 100 needs to calculate the texture data required for the application's foreground display. When a large amount of texture data is required, or when the CPU's computing power is insufficient, a white screen or screen flickering may occur when the application returns to the foreground, thus affecting the user experience.

[0148] In another possible implementation, the electronic device 100 is equipped with a GPU chip capable of supporting page faults. When the foreground application has rendering tasks, the electronic device 100 can store the application's texture data in multiple pages. When the electronic device 100 experiences high memory pressure, it can reclaim one or more pages and discard or write the texture data in those pages to disk. When the application needs to display the interface content corresponding to the discarded texture data again, if the GPU cannot find the corresponding texture data in memory, it can trigger a page fault, load the required texture data from the hard drive into memory, and update the relevant page tables and other data structures. In this way, the GPU can continue to execute graphics rendering tasks. However, this requires the electronic device 100 to support a unified memory architecture, that is, the CPU and GPU of the electronic device 100 can share the same physical memory. This places high demands on the hardware of the electronic device 100; if the hardware of the electronic device 100 does not support a unified memory architecture, then the GPU of the electronic device 100 cannot support page faults.

[0149] To address the aforementioned issues, this application provides a memory management method applicable to electronic devices with any chip (supporting or not supporting a unified memory architecture). In this method, when the GPU renders texture data stored in its physical memory, it pre-binds the physical memory containing the texture data to the GPU driver. After rendering is complete, the electronic device 100 dynamically unbinds the texture data from the GPU driver and writes the unbound texture data to disk. This reduces the usage of GPU physical memory. After the texture data is written to disk, when it needs to be re-bound, the electronic device 100 can dynamically predict the texture data that subsequent operations might access based on the texture data loading order and pre-load that potentially accessed data. This ensures that when an application switches from the background to the foreground, the required texture data can be loaded promptly and effectively. When an application starts, it can request a memory space to store its application data. Then, the CPU calculates the data required for the current application display, converts the data to be rendered into texture data, and stores this texture data in the application's requested memory space. The CPU can establish a mapping relationship between virtual addresses in the CPU and physical addresses of texture data in the application. For example, as shown in Figure 5, taking texture data 1, texture data 2, texture data 3, and texture data 4 in the application as an example, the physical addresses of texture data 1, texture data 2, texture data 3, and texture data 4 in memory are respectively mapped to virtual addresses in the CPU. When the GPU needs to draw based on texture data 2, as shown in step ① of Figure 5, the GPU will bind texture data 2 in advance. For example, the GPU's MMU2 can establish a mapping relationship between the physical address of texture data 2 and the virtual address in the GPU. After the GPU finishes drawing, as shown in step ② of Figure 5, the GPU's MMU2 can unbind the mapping relationship between the physical address of texture data 2 and the virtual address in the GPU. After the GPU unbinds texture data 2, as shown in step ③ of Figure 5, the CPU can unbind itself from texture data 2. That is, the CPU can unbind the mapping relationship between the physical address of texture data 2 and the virtual address in the CPU.

[0150] Then, as shown in step ④ of Figure 5, the electronic device 100 can write the texture data 2 to the disk, that is, store the texture data 2 in the disk (also called: Read-Only Memory (ROM)). Exemplarily, the CPU can send command 1 to the disk, which instructs the disk to write the texture data 2. This command 1 may carry the physical address of the texture data 2. The disk can locate the texture data 2 in memory according to its physical address and write the texture data 2 to the disk.

[0151] When electronic device 100 can predict, based on user operation, that it is about to display content corresponding to texture data 2, it can preload texture data 2 from the disk. For example, when electronic device 100 predicts that it is about to display content corresponding to texture data 2, the CPU can send command 2 to the disk. This command 2 can be used to instruct the disk to load the texture data 2 into memory. After receiving command 2, as shown in step ⑤ of Figure 5, the disk can load texture data 2 into memory. Then, the CPU and GPU will bind the texture data 2 respectively.

[0152] In this embodiment, the mapping between the physical address of texture data and the virtual address in the CPU can be simply referred to as the CPU binding the texture data. The CPU de-mapping the physical address of texture data can be simply referred to as the CPU de-binding the texture data. Similarly, the mapping between the physical address of texture data and the virtual address in the GPU can be simply referred to as the GPU binding the texture data. The GPU de-mapping the physical address of texture data can be simply referred to as the GPU de-binding the texture data.

[0153] The following describes how application data is written to disk in this embodiment. In this embodiment, the electronic device 100 can write the application's texture data to disk at different times. For example, in one possible implementation, when the first application is in the background and the binding state of the first application's texture data is stable, the electronic device 100 can write all the texture data of the first application to disk. Here, the process of writing the texture data of the first application to disk in this implementation will be described in detail with reference to FIG6.

[0154] Figure 6 illustrates an exemplary flowchart of a memory data write-to-disk process according to an embodiment of this application. As shown in Figure 6, the process of writing application texture data stored in memory to disk according to an embodiment of this application may include the following steps:

[0155] S601. The first application has been detected to switch to the background.

[0156] For example, the first application can be any application in the electronic device that requires graphics rendering. The first application can be a system application or a third-party application. It should be understood that a system application can refer to an application provided by the provider of the electronic device's operating system. A third-party application can refer to an application provided by a provider other than the provider of the electronic device's operating system. That is, a third-party application can refer to an application provided by another provider (not the operating system provider).

[0157] For example, the app stores, SMS messages, and cameras that come pre-installed on electronic devices can be applications provided by the operating system provider; these can be considered system applications. For instance, applications downloaded and installed from the app store onto the electronic device... or Applications can be provided by non-operating system providers, i.e., downloaded from app stores. and These can be referred to as third-party applications.

[0158] Electronic device 100 can monitor the status of the first application, such as the first application starting up, the first application running in the foreground, the first application switching from the foreground to the background, the first application switching from the background to the foreground, and the first application exiting the running state.

[0159] For example, electronic device 100 can monitor the status of each application through AMS. That is, electronic device 100 can monitor the status of the first application through AMS. When it is detected that the first application has started running, that is, when it is detected that the first application has entered the foreground state, but not switched from the background state to the foreground state, AMS can determine that GPU physical memory needs to be allocated to the first application.

[0160] Since the physical memory of an electronic device is managed by the GPU, meaning that the release or allocation of GPU physical memory is performed by the GPU, AMS can send information (hereinafter referred to as third information) to the GPU upon detecting the startup of the first application. This third information can be used to notify the GPU that the first application has started running and that GPU physical memory needs to be allocated for it. After receiving the third information, the GPU can allocate the corresponding GPU physical memory (e.g., first GPU physical memory) for the first application.

[0161] While the first application is running, AMS can continue to monitor its status. When the first application switches to the background based on user interaction, AMS can detect this transition.

[0162] For example, when a first application is running in the foreground on an electronic device, the user can perform an input (hereinafter referred to as the first input) to switch the first application to the background. That is, the first input can be used to switch the first application from the foreground to the background. In other words, the first application can be in the foreground when the user performs the first input. After detecting the user's first input, the electronic device can switch the first application from the foreground to the background.

[0163] It should be noted that the embodiments of this application do not limit the first input for switching the first application to the background, and can be determined according to the actual scenario. For example, the first input can be the user's input when returning to the desktop or main interface by swiping up from the bottom of the screen or clicking the home button (virtual button, floating button, or physical button). For example, the first input can be the user's input when bringing up the multitasking interface on the current screen, thereby putting the first application into the background state. For example, the user can bring up the multitasking interface by swiping up from the bottom of the screen and pausing, and can click on the window of another application in the multitasking interface to bring the other application into the foreground state and the first application into the background state.

[0164] Optionally, in one possible implementation, the electronic device 100 executes step S602 only when the duration of the first application switching from the foreground to the background reaches a duration threshold. This duration threshold can be configured by the system of the electronic device 100 and is a natural number greater than 0. For example, the duration threshold can be 10 minutes, 15 minutes, etc., and this embodiment does not limit the duration threshold.

[0165] S602. Determine if the first application has a background task. If it does, proceed to step S603; otherwise, proceed to step S604.

[0166] After the first application is switched to background operation, the electronic device 100 also needs to monitor whether the first application still has background tasks. For example, background tasks include, but are not limited to: background music playback, background navigation, background game idling, background live streaming, background downloading, background installation, etc.

[0167] When electronic device 100 detects that the first application has a background task, electronic device 100 can execute step S603. If not, electronic device 100 can execute step S604.

[0168] S603. Run background tasks.

[0169] When the first application has a background task, it can run that background task. For example, if the first application is an audio application, and there is still a background music playback task when the first application is switched to the background, then the first application can play music in the background.

[0170] S604. The first application enters a frozen state.

[0171] When the first application has no background tasks, the operating system of the electronic device 100 can put the first application into a frozen state. When the first application is in a frozen state, it no longer runs or consumes system resources. However, the relevant data of the user interface before the first application entered the frozen state can be stored in memory. In this way, when the user switches the first application back to the foreground, they can quickly return to the user interface before the first application entered the frozen state.

[0172] S605. Determine that the texture data binding relationship of the first application has reached a stable state.

[0173] Electronic device 100 can determine that the texture data binding relationship of the first application has reached a stable state. That is, within a preset time period, the texture data of the first application no longer binds to or unbinds from the GPU. For example, when electronic device 100 does not switch from the background to the foreground or unfreeze from the background within the preset time period, the first application does not need to display interface content. Therefore, the GPU does not need to bind the texture data of the first application. At this time, electronic device 100 can determine that the texture data binding relationship of the first application has reached a stable state.

[0174] S606. Filter out texture data in memory that is not bound to the GPU.

[0175] The CPU can filter out texture data in memory that is not bound to the GPU. For example, when the first application is switched to the background and enters a frozen state, none of the texture data of the first application stored in memory is bound to the GPU. At this time, the CPU can filter out the texture data of the first application stored in memory that is not bound to the GPU.

[0176] S607. Write texture data that is not bound to the GPU to disk.

[0177] Electronic device 100 can write texture data of a first application not bound to a GPU to disk. For example, the CPU can send command 3 to the disk, instructing the disk to write the texture data not bound to the GPU stored in memory. Optionally, command 3 may carry the physical address of the texture data of the first application not bound to the GPU stored in memory. When the disk receives command 3, it can write the texture data of the first application not bound to the GPU stored in memory.

[0178] Furthermore, in one possible implementation, when writing texture data of the first application not bound to the GPU to memory, the disk can write the texture data of the first application not bound to the GPU to memory in Least Recently Used (LRU) order. That is, the disk can first write the Least Recently Used texture data of the first application among the texture data not bound to the GPU. In other words, texture data that is unbound from the GPU first can be written to the disk first, and texture data that is unbound from the GPU later can be written to the disk later.

[0179] For example, as shown in Figure 7, the first application can display interface 701 in the foreground. Interface 701 may include image 1 corresponding to texture data 1 and image 2 corresponding to texture data 2. When the GPU renders interface 701, the GPU can bind texture data 1 and texture data 2. The user can input a downward swipe operation in interface 701, and in response to this user operation, the first application can display interface 702.

[0180] As shown in Figure 7, the interface 702 can include texture data 6 corresponding to image 6. When rendering the interface 702, the GPU can bind texture data 6. The GPU also unbinds texture data 1 and texture data 2. The user can continue to swipe upwards within the user interface 702; in response to this user action, the first application can display interface 703.

[0181] As shown in Figure 7, the interface 703 can include image 3 corresponding to texture data 3, image 4 corresponding to texture data 4, image 5 corresponding to texture data 5, and font. When rendering this interface 703, the GPU can bind texture data 3, texture data 4, and texture data 5. The GPU then unbinds texture data 6.

[0182] Then, the user can switch the first application to the background. Responding to the user's action, the first application is moved to the background. The GPU can unbind texture data 3, texture data 4, and texture data 5. When the texture data binding relationship of the first application reaches a stable state, the first application can enter a frozen state. The CPU can filter out unbound texture data from the texture data stored in memory. For example, texture data 1, texture data 2, texture data 3, texture data 4, texture data 5, and texture data 6 of the first application are all unbound. The CPU can instruct the disk to write texture data 1, texture data 2, texture data 3, texture data 4, texture data 5, and texture data 6. That is, the electronic device 100 can unbind texture data 1, texture data 2, texture data 3, texture data 4, texture data 5, and texture data 6.

[0183] In one possible implementation, as shown in Figure 8, the disk can write all the texture data stored in the memory of the first application, namely texture data 1, texture data 2, texture data 3, texture data 4, texture data 5, and texture data 6.

[0184] In this way, when the first application is moved to the background, has no background tasks, and is not invoked by another application, the electronic device 100 can store all the texture data of the first application to the disk and release the memory space occupied by the texture data of the first application. This can alleviate memory usage in a timely manner and improve the operating speed of the electronic device 100.

[0185] Alternatively, in another possible implementation, when the first application goes into the background and the electronic device detects that the memory usage exceeds a preset threshold, the electronic device 100 releases a portion of the memory space and writes the texture data in that portion of the memory space to disk. That is, if all the texture data of the first application is in that portion of the memory space, then all of the texture data of the first application will be written to disk. If only a portion of the texture data of the first application is stored in that portion of the memory space, then only the texture data in that portion of the memory space will be written to disk. Here, the process of writing the texture data of the first application to disk in this implementation will be described in detail with reference to Figure 9.

[0186] For example, Figure 9 illustrates another flowchart of writing memory data to disk provided by an embodiment of this application. As shown in Figure 9, writing application texture data stored in memory to disk according to an embodiment of this application may include the following steps:

[0187] S901. The first application has been detected to switch to the background.

[0188] Step S901 can be referred to the description in step S601, and will not be repeated here.

[0189] S902. Determine if the first application has a background task. If it does, proceed to step S903; otherwise, proceed to step S904.

[0190] Step S902 can be referred to the description in step S602, and will not be repeated here.

[0191] S903. Run background tasks.

[0192] Step S903 can be referred to the description in step S603, and will not be repeated here.

[0193] S904. The first application enters a frozen state.

[0194] Step S904 can be referred to the description in step S604, and will not be repeated here.

[0195] S905. Determine that the texture data binding relationship of the first application has reached a stable state.

[0196] Step S905 can be referred to the description in step S605, and will not be repeated here.

[0197] S906. Filter out texture data in memory that is not bound to the GPU.

[0198] Step S906 can be referred to the description in step S606, and will not be repeated here.

[0199] S907. Detects that the memory usage rate is higher than the preset threshold and determines the amount of memory that needs to be reclaimed.

[0200] The electronic device 100's system can monitor memory usage and configure preset thresholds. When the detected memory usage exceeds the preset threshold, the electronic device 100 can determine the amount of memory that needs to be reclaimed.

[0201] In one possible implementation, the amount of memory to be reclaimed is also configured by the system and is a fixed value. That is, when the memory usage rate is detected to be higher than a preset threshold, the CPU can determine the amount of memory to be reclaimed and instruct the disk to write it to disk.

[0202] In one possible implementation, the amount of memory to be reclaimed can be dynamically determined by the electronic device 100. For example, the electronic device 100 can determine the amount of memory to be reclaimed based on the number of processes currently running on the electronic device 100. The more processes currently running on the electronic device 100, the larger the amount of memory to be reclaimed.

[0203] Alternatively, in one possible implementation, the electronic device 100 can determine the amount of memory to be reclaimed based on one or more factors such as the current battery level, the number of running processes, and the type of service corresponding to the running processes (e.g., video service, game service, etc.).

[0204] S908. Write the texture data that is not bound to the GPU to disk according to the amount of memory that needs to be reclaimed.

[0205] Electronic device 100 can write unbound texture data to disk according to the amount of memory to be reclaimed. For example, if electronic device 100 determines that the amount of memory to be reclaimed is 1KB (memory unit: kilobyte), then the CPU of electronic device 100 can determine that 1KB of texture data in memory needs to be written to disk, and determine that the 1KB of texture data not bound to the GPU needs to be written to disk. The CPU can send a command to the disk, carrying the physical address of the texture data to be written to disk. The disk can then write the texture data corresponding to the physical address carried in the command to disk based on the command.

[0206] In one possible implementation, the amount of memory occupied by texture data not bound to the GPU is greater than the amount of memory that needs to be reclaimed. The electronic device 100 can arbitrarily select a portion of the texture data not bound to the GPU for disk writing, according to the LRU order of the texture data. This application embodiment does not limit the method by which the electronic device selects texture data not bound to the GPU.

[0207] Alternatively, in another possible implementation, the amount of memory occupied by texture data not bound to the GPU is less than or equal to the amount of memory that needs to be reclaimed. The electronic device 100 can write all texture data not bound to the GPU in memory to disk.

[0208] Understandably, when the memory occupied by the texture data of the first application is greater than the amount of memory that needs to be reclaimed, only a portion of the texture data of the first application is written to disk. When the memory occupied by the texture data of the first application is less than or equal to the amount of memory that needs to be reclaimed, all the texture data of the first application is written to disk.

[0209] In this way, through the above-described method of storing memory data to disk, the electronic device 100 can promptly store the data in memory to the disk when memory pressure is high, thereby reclaiming memory and alleviating the memory pressure on the electronic device 100.

[0210] Through the memory management methods described above, electronic device 100 can reclaim memory in a timely manner when memory pressure is high, thereby alleviating the memory pressure on electronic device 100.

[0211] When the first application is switched to the background and its texture data is stored on the disk, if the user switches the first application back to the foreground, the electronic device 100 needs to read the texture data from the disk into memory, then render it, and display the user interface of the first application in the foreground. This application provides a memory management method that, when the first application is switched back to the foreground, preloads the texture data from the disk into memory, avoiding frequent disk reads that could cause I / O blocking and thus lag in the application's interface display.

[0212] The following describes a memory management method provided by an embodiment of this application with reference to the accompanying drawings. For example, Figure 10 shows a schematic flowchart of a memory management method provided by an embodiment of this application. As shown in Figure 10, a memory management method provided by an embodiment of this application may include the following steps:

[0213] S1000 detected that the first application was using GPU resources. The first application was in the background and was in a frozen state.

[0214] When the first application is in the background and in a frozen state, the electronic device 100 can detect the first application's use of GPU resources. For example, when the first application switches from the background to the foreground, it will use GPU resources to render the application interface. Or, when the first application unfreezes in the background, it will use GPU resources to render the application interface. When the first application is in a frozen state in the background, if another application running in the foreground calls a function of the first application, the first application will unfreeze in the background. For example, if the first application is a payment application, and a shopping application running in the foreground calls the first application to perform the payment, then the first application will unfreeze in the background and use GPU resources to render the payment-related interface.

[0215] S1001. Read and render the texture data required for the first application.

[0216] In order to more clearly describe the memory management method provided in the embodiments of this application, taking the first application as an example, the specific memory management process of the electronic device 100 during the process from the startup of the first application, to its exit to the background, and then to the switching of the first application to the foreground is described.

[0217] First, when the first application starts, the electronic device 100 allocates a memory space in memory, which will be referred to as memory space 1 below. Memory space 1 is used to store the texture data of the first application. That is, the texture data that the first application needs to render will be stored in memory space 1.

[0218] When the first application starts, the CPU needs to calculate the content 1 of the interface 1 displayed after the application starts and store this content 1 in the memory space 1. The CPU establishes a mapping relationship between the physical address 1 of the first texture data in memory space 1 and the CPU virtual address 1 in the CPU. The CPU can send a command to the GPU, instructing the GPU to render the texture data 1. Before rendering the texture data 1, the GPU establishes a mapping relationship between the physical address 1 of the texture data 1 and the GPU virtual address 1 in the GPU. Then, the GPU renders the first content. After the GPU finishes rendering the content 1, it releases the mapping relationship between the physical address 1 of the content 1 and the GPU virtual address 1.

[0219] After the first application starts, other interfaces can be displayed based on user actions. The rendering process of the content of other interfaces is the same as that of content 1 in user interface 1. There are no restrictions on the number of interfaces displayed by the first application before it enters the background, or on the specific content displayed.

[0220] For example, the first application may be as shown in Figure 7, which displays interface 701, interface 702, and interface 703 after startup, and then displays interface 702 again.

[0221] After the first application is moved to the background, and the binding relationship of the texture data in the first application reaches a stable state, or when the electronic device 100 detects that the memory usage rate exceeds a preset threshold, the electronic device 100 can store the content to the disk and release the memory corresponding to physical address 1 occupied by content 1. Then, the memory will notify the CPU that content 1 has been written to the disk, and the CPU will also release the mapping relationship between physical address 1 of content 1 and CPU virtual address 1. Furthermore, the CPU will record the storage address or storage index of content 1 on the disk.

[0222] When the first application switches back to the foreground, the CPU determines to load the top element (1) of the LRU table corresponding to the first application from the disk. The CPU can send a command to the disk. Then, the disk can load the content (1) into memory based on the command sent by the CPU. Memory stores the content (1) in the memory space with physical address 2. Then, the CPU re-establishes the mapping relationship between CPU virtual address 1 and physical address 2. Then, the CPU can send a command to instruct the GPU to render the content (1). After receiving the command, the GPU can establish the mapping relationship between physical address 2 and GPU virtual address 1. Then, the GPU can render the content (1). After rendering is complete, the electronic device 100 can display the application's interface 1.

[0223] The LRU table corresponding to the first application stores the index numbers of all texture data displayed before the first application went to the background. The CPU can find the CPU virtual address of the corresponding texture data through this index number. For example, in the LRU table corresponding to the first application, the index number of content 1 is number 1. This number 1 is used to indicate the CPU virtual address of content 1. In the LRU table corresponding to the first application, the index number of the texture data of the last screen displayed by the first application before going to the background is at the top of the stack.

[0224] Table 1

[0225] As shown in Table 1, the LRU table corresponding to the first application stores the index numbers of all content displayed by the first application from startup to before it enters the background. For example, index numbers 1, 2, and 3, etc. Index number 1 is the index number of content 1, index number 2 is the index number of content 2, and index number 3 is the index number of content 3. The last content displayed by the first application before entering the background is content 1. The first application displayed content 2 before displaying content 1, and content 3 before displaying content 2. For example, content 1 may include texture data 3, texture data 4, and texture data 5 as shown in interface 702 of Figure 7. Content 2 may include texture data 6 as shown in interface 703 of Figure 7. Content 3 may include texture data 1 and texture data 2 as shown in interface 701 of Figure 7.

[0226] When an operation to switch a first application from the background to the foreground is detected, the CPU of electronic device 100 can determine the CPU virtual address of the content (e.g., content 1) to be displayed when the first application switches to the foreground from the index number at the top of the stack of the LRU table corresponding to the first application. Then, the CPU of electronic device 100 can determine the storage address of content 1 on the disk from this CPU virtual address. The CPU can then send command 4 to the disk, instructing the disk to load content 1 into memory. That is, when the first application switches to the foreground, only the content to be displayed, i.e., content 1, is loaded from the disk; the content corresponding to all index numbers in the LRU record is not loaded. This reduces the number of disk reads, thereby reducing disk wear and extending the disk's lifespan.

[0227] After the disk loads content 1 into memory, the CPU can establish a mapping between the new physical address of content 1 and its corresponding CPU virtual address. The CPU can then inform the GPU of this new physical address and instruct the GPU to render content 1. The GPU can then establish a mapping between the new physical address of content 1 and its corresponding GPU virtual address. Finally, the GPU locates and renders content 1 using its corresponding GPU virtual address. Finally, the electronic device 100 can display content 1.

[0228] When the first application switches back to displaying content 1 in the foreground, if a user swipe operation is detected, the electronic device 100 can determine, based on the user's swipe operation, that the first application is about to display content 2 corresponding to number 2 in the LRU table. Then, the CPU instructs the disk to load content 2 and its adjacent content (e.g., content 3) into the content library. This way, when the user continues to swipe, causing the first application to display content 3, the GPU can more quickly find content 3 in memory and render it. This reduces the time the GPU spends accessing the content to be rendered.

[0229] It is understandable that if a user has viewed multiple pieces of content from the first application before it is moved to the background, and then views those same pieces of content again by swiping after the first application is brought to the foreground, the electronic device 100 can preload the content the user needs to view from the disk based on the direction of the user's swipe. That is, the electronic device 100 not only loads the content to be displayed from the disk, but also loads one or more pieces of content to be displayed after the current content. For example, as shown in Figure 7, when the first application is brought to the foreground, the electronic device 100 indexes the content (texture data 3, texture data 4, and texture data 5) in the interface 703 to be displayed by the first application from the index number at the top of the LRU stack corresponding to the first application, and then loads the texture data 3, texture data 4, and texture data 5 corresponding to that CPU virtual address from the disk. For example, as shown in Figure 12A, the disk can load texture data 3, texture data 4, and texture data 5 from the stored texture data of the first application into the DDR. Then, the GPU can render texture data 3, texture data 4, and texture data 5. Finally, the electronic device 100 can redisplay the interface 703.

[0230] Furthermore, in one possible implementation, when the user swipes upwards on interface 703, while the electronic device 100 loads texture data 6 from the disk for the interface 702 to be displayed, it can also load texture data 1 and texture data 2, which are adjacent to texture data 6 in the LRU table, into memory according to the swiping direction. For example, as shown in FIG12B, the disk can load texture data 6, texture data 1, and texture data 2 into DDR. Thus, when the user continues to swipe upwards after displaying interface 702, texture data 1 and texture data 2 in the interface 701 to be displayed can be rendered more quickly, reducing the time required for the selected GPU to access the required texture data.

[0231] In one possible implementation, the electronic device 100 can preload the content of the next interface (referred to as interface 2) after the currently displayed interface (referred to as interface 1) into memory according to the sliding direction, and can also preload the content of the next interface (referred to as interface 3) after interface 2 into memory. The electronic device 100 can dynamically determine the preloading step size based on the user's operation direction or the number of index codes of the texture data stored in the LRU table. This preloading step size can be 1, 2, or 3; this application does not limit the preloading step size. It is understood that when the preloading step size is 1, the electronic device 100 loads the content of interface 1 and preloads the content of interface 2. When the preloading step size is 2, the electronic device 100 loads the content of interface 1, preloads the content of interface 2, and preloads the content of interface 3.

[0232] For example, if there is only one index number above or below the index number of interface 1 in the LRU table, then electronic device 100 can determine that the preload step size is 1.

[0233] When the swipe operation is an upward swipe, in the LRU table, the index number of the content of interface 2 is above the index code of the content of interface 1. The index number of the content of interface 3 is above the index code of the content of interface 2.

[0234] When the swipe operation is a downward swipe, in the LRU table, the index number of the content of interface 2 is below the index code of the content of interface 1. The index number of the content of interface 3 is below the index code of the content of interface 2.

[0235] S1002. Determine whether the first application has exited. If yes, proceed to step S1003; otherwise, proceed to step S1001.

[0236] The electronic device can continue to monitor the status of the first application and determine whether the first application has exited. If the first application has exited, the electronic device can execute step S1003. If the first application has not exited, the electronic device 100 can execute step S1001. That is, if the first application remains in the foreground, the electronic device 100 can continuously read and render the texture data required by the first application and display the interface of the first application. When the texture data required by the first application is stored on the disk, the electronic device can read the texture data required by the first application from the disk and render the texture data required by the first application. If the texture data required by the first application is not stored in memory or on the disk, the CPU needs to calculate the texture data required by the current interface of the first application and store it in memory. The GPU can bind the texture data required by the first application and render the texture data required by the first application to obtain the rendered data. The display screen of the electronic device 100 can display the interface of the first application according to the rendered data.

[0237] S1003. Clean up the texture data of the first application on the disk.

[0238] When electronic device 100 determines that the first application has exited runtime, electronic device 100 can clean up the texture data of the first application on the disk. For example, the CPU can send a command to the disk to clean up the texture data of the first application, based on which the disk can erase the stored texture data of the first application.

[0239] Thus, through the memory management method provided in this application embodiment, the electronic device can determine and index the texture data that can be written to disk based on the binding status of the texture data stored in memory. That is, the electronic device 100 can write texture data that is not bound to the GPU to disk, thereby reducing the physical memory occupation of the texture data required for rendering the graphical interface in the electronic device 100. Furthermore, the electronic device 100 can dynamically predict the texture data that subsequent operations may access based on the loading order of the texture data estimated by the user operation and load it, thereby reducing the number of times the GPU loads texture data. Moreover, it is not necessary to load all the texture data written to disk by the application, which can save the memory utilization of texture data. When the application switches to the foreground, since the texture data required by the application is already stored on the disk, it only needs to be loaded from the disk, and there is no need to recalculate the texture data required for the application to switch to the foreground. Thus, since loading texture data takes less time than recalculating the texture data required by the application, white screen textures will not be caused by texture recalculation.

[0240] Figure 13 illustrates a flowchart of a memory management method provided in an embodiment of this application. As shown in Figure 13, a memory management method provided in an embodiment of this application may include the following steps:

[0241] S1301. Display the first interface of the first application, the first interface including the first content.

[0242] The electronic device 100 may include a central processing unit (CPU), a disk, memory, and a first application installed thereon. The electronic device may run the first application in the foreground and display a first interface of the first application, which may include first content. For example, the first interface may be interface 703 shown in FIG. 7 above, and the first content may be texture data 3, texture data 4, and texture data 5 in interface 703. This application does not specifically limit the first interface and the first content.

[0243] S1302. In response to the first operation, the first application is switched to the background.

[0244] When the electronic device 100 displays the first interface, it can receive the user's first operation. In response to the first operation, the electronic device 100 can switch the first application to the background. For example, this step S1302 can be referred to the description in step S601 above, and will not be repeated here.

[0245] S1303. In response to the second operation, the CPU obtains the first index code of the first table. The second operation is used to instruct the first application to switch from the background to the foreground. The first index code is located at the top of the stack of the first table. The first table is used to store the index codes of multiple contents of the first interface. The multiple contents include the first content. The first index code is the index code of the first content.

[0246] The electronic device 100 can receive a second operation from the user, which is used to switch the first application to the foreground. In response to the second operation, the CPU in the electronic device 100 can obtain the first index code of the first table. The second operation is used to instruct the first application to switch from the background to the foreground. The first index code is located at the top of the stack of the first table. The first table is used to store the index codes of multiple contents displayed by the first application on the first interface. The multiple contents include the first content, and the first index code is the index code of the first content.

[0247] For example, the first table may be the LRU table shown in Table 1 above. This application embodiment does not limit the specific index encoding stored in the first table.

[0248] For example, the first content can be content 1 mentioned above, and the first index code can be number 1 mentioned above. This application embodiment does not limit this.

[0249] This step S1303 can be found in the description of step S1001 above.

[0250] S1304. The CPU determines the first storage address of the first content based on the first index code.

[0251] The CPU can determine the first CPU virtual address of the first content in the CPU based on the first index code, and then determine the first storage address of the first content in the disk based on the first CPU virtual address.

[0252] This step S1304 can also be found in the description of step S1001 above.

[0253] S1305. The CPU sends a first command to the disk, which instructs the disk to read the first content from the first storage address into memory.

[0254] The CPU can send a first command to the disk, which can then read the first content from the first memory address into memory based on the command. Memory can then store the first content in the memory space with a second physical address. The CPU then re-establishes the mapping between the first CPU virtual address and the second physical address. The CPU can then send a command to instruct the GPU to render the first content. Upon receiving the command, the GPU can establish a mapping between the second physical address and the first GPU virtual address of the first content within the GPU. The GPU can then render the first content.

[0255] For example, the first physical address can be physical address 1 mentioned above, and the second physical address can be physical address 2 mentioned above.

[0256] Step S1305 can be referred to the description in step S1001 above, and will not be repeated here.

[0257] S1306. Redisplay the first screen.

[0258] Electronic device 100 can redisplay the first interface, that is, bring the first application back to the foreground.

[0259] In one possible implementation, the method may further include: in response to a third operation, the CPU obtains a second index code and a third index code of a first table, the third operation being used to instruct a first application to display a second interface, the second interface including second content, the second index code being the index code of the second content, the third index code being the index code of the third content, and the third index code and the second index code being adjacent; the CPU determines a second storage address of the second content based on the second index code, and determines a third storage address of the third content based on the third index code; sends a second command to the disk, the second command being used to instruct the disk to read the second content at the second storage address and the third content at the third storage address into memory; and displays the second interface.

[0260] The second interface can be the interface displayed after the user swipes up or down on the first interface, or it can be the interface displayed after the user enters an operation to jump to another interface on the first interface.

[0261] The third operation is an upward sliding operation, with the third index code above the second index code; the third operation is a downward sliding operation, with the third index code below the second index code.

[0262] For example, the second interface may be interface 702 shown in FIG11, and the second content may be texture data 6 in interface 702 shown in FIG11.

[0263] In this way, when a user swipes, the electronic device can preload third content from its disk based on that swipe. That is, the electronic device not only loads the second content that is about to be displayed, but also the third content that may be displayed later. This allows the electronic device to display the third content more quickly, thus improving the user experience.

[0264] In one possible implementation, the electronic device further includes a graphics processing unit (GPU), and after displaying the second interface, the method may further include: in response to a fourth operation, the CPU instructs the GPU to render third content in memory, the fourth operation being used to instruct the first application to display the third interface, the third interface including the third content; and displaying the third interface.

[0265] For example, the third interface may be interface 701 shown in FIG11, and the third content may be texture data 1 and texture data 2 in interface 701 shown in FIG11.

[0266] In this way, since the third content is pre-loaded into memory, when the user needs to view this third content in the first application, the electronic device does not need to read it from the disk; it can directly render the third content in memory. This allows the electronic device to display the third content faster. In other words, it improves the responsiveness of the electronic device to this fourth operation, thereby enhancing the user experience.

[0267] In one possible implementation, in response to the first operation, after the first application switches to the background, the method may further include: unmapping the mapping relationship between the first GPU virtual address of the first content in the GPU and the first physical address of the first content in memory; storing the first content stored in the physical memory corresponding to the first physical address to the disk; and releasing the physical memory corresponding to the first physical address.

[0268] This way, when the first application is switched to the background, the data of the first application stored in memory can be promptly written to disk. This can alleviate memory pressure and prevent electronic devices from slowing down due to excessive memory load.

[0269] In one possible implementation, before storing the first content stored in the physical memory corresponding to the first physical address to the disk, the method may further include: the CPU determining that the first physical address of the first content has not established a mapping relationship with the virtual address in the GPU within a preset time period.

[0270] In this way, the data of the first application stored in memory is only written to disk after it is confirmed that the first application will not be switched back to the foreground or unfrozen in the background within a short period of time. This implementation method can avoid the situation where the user suddenly switches the first application to the foreground or unfrozen in the background while the data of the first application stored in memory is being written to disk, which would prevent the electronic device from displaying the first application in time and affect the user experience.

[0271] In one possible implementation, when storing the first content stored in the physical memory corresponding to the first physical address to the disk, it may further include: storing all the contents of the first application stored in memory to the disk.

[0272] In this way, once it is determined that the first application will not be switched back to the foreground or unfrozen in the background in a short period of time, storing all the contents of the first application stored in memory to the disk can alleviate memory pressure.

[0273] In one possible implementation, after the CPU determines that the first physical address of the first content has not established a mapping relationship with the virtual address in the GPU within a preset time period, the method may further include: the electronic device detecting that the memory occupancy rate is higher than a preset threshold. In this way, the electronic device can promptly detect excessive memory pressure.

[0274] In one possible implementation, after the electronic device detects that the memory occupancy rate is higher than a preset threshold, the method may further include: the electronic device determining a first data volume, the first data volume being the amount of data in memory that needs to be stored on the disk; if the amount of data of all the content of the first application stored in memory is greater than the first data volume, the electronic device stores a portion of the content of the first application on the disk, the portion of content including the first content, and the amount of the portion of content being less than or equal to the first data volume.

[0275] This allows for data write-to-disk adjustments based on memory usage, writing only a portion of the data and reducing the total amount written. This reduces the number of disk I / O calls, improving data read / write speeds. Furthermore, it reduces disk space usage and extends disk lifespan.

[0276] The specific steps for storing all the content of the first application to the disk can be found in Figure 6, and will not be repeated here. The specific steps for storing a portion of the content of the first application to the disk can be found in Figure 9, and will not be repeated here.

[0277] In one possible implementation, the method may further include: in response to a fifth operation, the CPU sends a third command to the disk, the fifth operation instructing the first application to exit execution, and the third command instructing the disk to clean up all or part of the content of the first application stored therein; the disk receives the third command and cleans up all or part of the content. This can reduce disk space usage in a timely manner. For details regarding the disk cleaning up the content of the first application stored on the disk, please refer to the description in step S1003 above, which will not be repeated here.

[0278] The method provided in this application embodiment allows the first application to read only the content to be displayed from the disk when it returns to the foreground, without needing to read all the data of the first application stored on the disk. This reduces the number of disk reads, thus reducing disk wear and extending disk lifespan. Furthermore, not reading all the data of the first application into memory avoids increasing memory pressure and prevents a sudden increase in memory pressure from slowing down the operating speed of the electronic device.

[0279] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar to those of the related embodiments described above, and will not be repeated here.

[0280] This application provides a readable storage medium containing instructions that, when executed by an electronic device, cause the electronic device to perform the technical solution described in the above embodiments. The implementation principle and technical effects are similar and will not be repeated here.

[0281] This application provides a chip for executing instructions. When the chip is running, it executes the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0282] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0283] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0284] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0285] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A memory management method, characterized in that, The method is applied to an electronic device, the electronic device including a central processing unit (CPU), a disk and memory, and a first application, the method comprising: The first interface of the first application is displayed, and the first interface includes first content; In response to the first operation, the first application switches to the background; In response to the second operation, the CPU obtains the first index code of the first table. The second operation is used to instruct the first application to switch from the background to the foreground. The first index code is located at the top of the stack of the first table. The first table is used to store the index codes of multiple contents of the first interface. The multiple contents include the first content. The first index code is the index code of the first content. The CPU determines the first storage address of the first content based on the first index code. The CPU sends a first command to the disk, the first command being used to instruct the disk to read the first content from the first storage address into the memory; Redisplay the first interface.

2. The method according to claim 1, characterized in that, The method further includes: In response to a third operation, the CPU obtains the second index code and the third index code of the first table. The third operation is used to instruct the first application to display a second interface, the second interface including second content, the second index code being the index code of the second content, the third index code being the index code of the third content, and the third index code being adjacent to the second index code. The CPU determines the second storage address of the second content based on the second index code, and determines the third storage address of the third content based on the third index code; A second command is sent to the disk, the second command being used to instruct the disk to read the second content in the second storage address and the third content in the third storage address into the memory; The second interface is displayed.

3. The method according to claim 2, characterized in that, The third operation is an upward sliding operation, and the third index code is above the second index code; or, The third operation is a downward sliding operation, and the third index code is below the second index code.

4. The method according to claim 3, characterized in that, The electronic device further includes a graphics processing unit (GPU), and after displaying the second interface, the method further includes: In response to a fourth operation, the CPU instructs the GPU to render the third content in the memory, the fourth operation being used to instruct the first application to display a third interface, the third interface including the third content; The third interface is displayed.

5. The method according to claim 4, characterized in that, In response to the first operation, after the first application switches to the background, the method further includes: Remove the mapping relationship between the first GPU virtual address of the first content in the GPU and the first physical address of the first content in the memory; Store the first content stored in the physical memory corresponding to the first physical address to the disk; Release the physical memory corresponding to the first physical address.

6. The method according to claim 5, characterized in that, Before storing the first content stored in the physical memory corresponding to the first physical address to the disk, the method further includes: The CPU determines that the first physical address of the first content has not established a mapping relationship with the virtual address in the GPU within a preset time period.

7. The method according to claim 6, characterized in that, When storing the first content stored in the physical memory corresponding to the first physical address to the disk, the method further includes: Store all content of the first application stored in the memory to the disk.

8. The method according to claim 6, characterized in that, After the CPU determines that the first physical address of the first content has not established a mapping relationship with the virtual address in the GPU within a preset time period, the method further includes: The electronic device detected that the memory usage rate was higher than a preset threshold.

9. The method according to claim 8, characterized in that, After the electronic device detects that the memory occupancy rate is higher than a preset threshold, the method further includes: The electronic device determines a first data volume, which is the amount of data in the memory that needs to be stored on the disk. If the amount of data of all the content of the first application stored in the memory is greater than the first data amount, the electronic device stores a portion of the content of the first application to the disk, wherein the portion of content includes the first content, and the amount of data of the portion of content is less than or equal to the first data amount.

10. The method according to any one of claims 7 or 9, characterized in that, The method further includes: In response to the fifth operation, the CPU sends a third command to the disk, the fifth operation being used to instruct the first application to exit running, and the third command being used to instruct the disk to clean up all or part of the content of the first application stored therein; The disk receives the third command and cleans up all or part of the content.

11. The method according to any one of claims 1-10, characterized in that, The first content includes one or more texture data.

12. An electronic device, characterized in that, It includes one or more processors; one or more memories; said one or more memories storing one or more computer programs, said one or more computer programs including instructions that, when executed by said one or more processors, cause the method of any one of claims 1 to 11 to be performed.

13. A chip, characterized in that, The chip includes a processor and a communication interface, the communication interface being used to receive signals and transmit the signals to the processor, the processor processing the signals such that the method as described in any one of claims 1 to 11 is executed.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer, cause the method as described in any one of claims 1 to 11 to be performed.

15. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 11.

Images