CN117170856A - Memory management method and related device - Google Patents

Memory management method and related device Download PDF

Info

Publication number
CN117170856A
CN117170856A CN202210592530.4A CN202210592530A CN117170856A CN 117170856 A CN117170856 A CN 117170856A CN 202210592530 A CN202210592530 A CN 202210592530A CN 117170856 A CN117170856 A CN 117170856A
Authority
CN
China
Prior art keywords
memory
service type
thread
program
type
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210592530.4A
Other languages
Chinese (zh)
Inventor
季柯丞
王琳
陈杰
王绪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202210592530.4A priority Critical patent/CN117170856A/en
Priority to PCT/CN2023/096330 priority patent/WO2023231900A1/en
Publication of CN117170856A publication Critical patent/CN117170856A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)

Abstract

The application discloses a memory management method. The electronic device 100 may determine the traffic type of the thread when receiving a memory allocation request of the thread of the application. The electronic device 100, based on the traffic type of the thread, divides a portion of memory in a memory area of a memory space of an application program for storing data of the thread of the traffic type into the thread. In the memory reclamation procedure, the electronic device 100 may reclaim the memory of different memory areas based on the priority of the service type. In this way, the electronic device 100 may preferentially reclaim the memory area for storing the data of the threads of the non-important business types, and ensure the running of the important threads of the application program.

Description

Memory management method and related device
Technical Field
The present application relates to the field of terminals, and in particular, to a memory management method and related devices.
Background
When the electronic device runs a plurality of applications, because the memory space of the electronic device is limited, if the applications occupy a large amount of memory resources during running, part of the applications may be blocked during running. Therefore, how to manage the memory is a problem to be solved.
Disclosure of Invention
The application provides a memory management method and a related device, which realize that a part of memory of a memory area corresponding to a service type is allocated to a thread based on the service type of the thread. The electronic device 100 may sequentially recycle the memories of the memory areas corresponding to different service types according to the order of the priority from low to high based on the priority of the service types in the process of recycling the memories. Thus, the electronic device can collect the data of the threads of the service type which are not important (low in priority) in priority, and collect the data of the threads of the service type which are important (high in priority) as late as possible, so that the running of the application program is ensured.
In a first aspect, the present application provides a memory management method, applied to an electronic device, where the electronic device is allocated with memory areas of multiple service types, where the memory areas of multiple service types at least include a memory area of a first service type and a memory area of a second service type;
the memory area of the first service type is used for storing the data of the thread with the service type of the first service type, and the memory area of the second service type is used for storing the data of the thread with the service type of the second service type;
the second service type has a lower priority than the first service type;
The method comprises the following steps:
when the memory is recovered, firstly recovering the memory of the memory area of the second service type according to the high-low sequence of the service type priority corresponding to the memory area;
and after the memory of the memory area of the second service type is recovered, recovering the memory of the memory area of the first service type.
Thus, the data of the thread with the low service type priority is preferentially recovered based on the service type priority, and the data of the thread with the high service type priority (important) is not easily recovered. The problem of program blocking caused by recovering the anonymous page only according to the latest access condition of the anonymous page is solved.
It will be appreciated that "low priority" is defined as being recycled first, and that in some other implementations "high priority" may be defined as being recycled first.
In one possible implementation, the method further includes: receiving a memory allocation request of a first thread of a first program;
based on the service type of the first thread, the memory of the memory area of the first service type is allocated to the first thread, the memory area of the first service type is used for storing the data of the thread with the service type of the first program, and the service type of the first thread is the first service type.
In this way, the memory area is allocated to the thread based on the service type of the thread, so that the data of the threads with different service types can be recovered conveniently based on the priority of the service type.
In one possible implementation, the method further includes: receiving a memory allocation request of a first thread of a first program;
based on the service type of the first thread, dividing a memory area of the first service type in the memory space of the first program under the condition that the memory space of the first program does not comprise the memory area of the first service type;
and allocating the memory of the memory area of the first service type to the first thread.
Therefore, when the memory allocation request of the thread of a certain service type is received, the memory areas of the service type are divided, so that the number of the memory areas can be reduced, and the management is more convenient.
In one possible implementation manner, when the memory space of the first program divides the memory area of the first service type, the method further includes: and marking the memory area of the first service type by using the first service type.
Therefore, the memory area can be identified based on the service type, so that the memory area can be conveniently searched, and the memory of the memory area can be recovered.
In one possible implementation manner, the first service type and the second service type are any one of a non-key service type, a display service type, an interactive service type, a heap service type and a push service type;
the priority of the service types is from low to high in sequence: non-key service types, display service types, interactive service types, heap service types, push service types.
In this way, data for threads of different traffic types may be reclaimed according to the traffic type priority shown.
In one possible implementation manner, the first service type and the second service type are any one of a non-key service type, a display service type, an interactive service type, a heap service type and a push service type;
if the first program is an application program running in the foreground, the priority of the service types is sequentially from low to high: non-key service types, heap service types, push service types, display service types, and interactive service types;
if the first program is an application program running in the background, the priority of the service types is sequentially from low to high: non-key service types, display service types, interactive service types, heap service types, push service types.
Thus, as the application program running in the foreground needs to display the user interface, the threads displaying the service type and the interactive service type are responsible for generating the user interface which the application program needs to display. Thus, the threads displaying the service type and the interactive service type are more important for the application program running in the foreground and should be recycled finally. While the background running application does not need to display a user interface, it may need to receive push messages and keep the key data from being lost, so that the heap service type and the thread of the push service type are more important for the background running application and should be recycled finally.
In one possible implementation, where the memory space of the first program includes a memory region of the first traffic type and a memory region of the second traffic type, the memory space of the second program also includes a memory region of the first traffic type and a memory region of the second traffic type,
after the memory of the memory area of the second service type is recovered, recovering the memory of the memory area of the first service type specifically includes:
after the memory of the second service type memory area of the first program and the memory of the second service type memory area of the second program are recovered, the memory of the first service type memory area of the first program and the memory of the first service type memory area of the second program are recovered.
Therefore, the data of the thread with the lowest service type priority in all programs can be recovered, and the data of the thread with the second lowest service type priority can be recovered.
In one possible implementation manner, when the memory space of the first program includes a memory area of the first service type, the memory space of the second program also includes a memory area of the first service type, and the priority of the second program is lower than that of the first program, the method specifically includes:
firstly, recovering the memory of a memory area of a first service type of a second program;
after the memory of the memory area of the first service type of the second program is recovered, the memory of the memory area of the first service type of the first program is recovered.
In this way, the data of threads of the same traffic type can be reclaimed according to the priority of the application. The data of the application program with high priority is recovered after being ensured, and the operation of the application program with high priority can be maintained.
In one possible implementation, before reclaiming the memory of the memory area of the first service type of the second program, the method further includes:
The priorities of the second program and the first program are determined based on the frequency of use of the second program and the first program, the frequency of use of the second program being lower than the frequency of use of the first program.
In this way, the priority of the application program can be determined according to the use frequency of the application program, and the data of the application program used more by the user can be recovered later.
In one possible implementation, memory of the memory region of the first traffic type is reclaimed based on a least recently used LRU algorithm. Therefore, when the memory of a certain memory area is recovered, the memory page which is most frequently called is ensured to be recovered finally, and the operation frequency of the electronic equipment for re-reading data to the memory is reduced.
In one possible implementation, the method further includes:
before allocating memory of a memory area of the first traffic type to the first thread based on the traffic type of the first thread, the traffic type of the first thread is determined based on an identification and/or an application scenario of the first thread. Thus, the service type of the thread can be more accurately determined according to the identification and/or the application scene of the thread.
In a second aspect, the present application provides another memory management method, applied to an electronic device, including:
Receiving a memory allocation request of a first thread of a first program;
based on the service type of the first thread, memory of a first type memory area is allocated to the first thread, the first type memory area is used for storing data of the thread with the service type of the first type, and the service type of the first thread is the first service type;
when memory recovery is carried out, based on the priority of service types, the memories of the memory areas corresponding to different service types are sequentially recovered; the memory areas corresponding to different service types comprise memory areas of a first type.
Therefore, the memory area is allocated to the thread based on the service type of the thread, so that the data of the threads with different service types can be recovered conveniently based on the priority of the service type. Based on the priority of the service type, the data of the thread with low service type priority is recovered preferentially, the data of the thread with high service type priority (important) is not easy to recover, and the problem of program blocking caused by recovery of the data of the important thread is avoided.
In a third aspect, the present application provides an electronic device comprising one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, the one or more memories being operable to store computer program code comprising computer instructions that, when executed by the one or more processors, cause the electronic device to perform the memory management method of any of the possible implementations of the above aspect.
In a fourth aspect, embodiments of the present application provide a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform a memory management method in any one of the possible implementations of the above aspect.
In a fifth aspect, embodiments of the present application provide a computer program product, which when run on a computer causes the computer to perform the memory management method in any one of the possible implementations of the above aspect.
Drawings
Fig. 1 is a schematic structural diagram of an electronic device 100 according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a virtual address space according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a thread memory allocation according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a correspondence between virtual address space and a identifier according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a memory recycling process according to an embodiment of the present application;
FIG. 6 is a schematic diagram of a thread memory allocation flow according to an embodiment of the present application;
fig. 7 is a schematic diagram of a software architecture according to an embodiment of the present application;
FIG. 8 is a flowchart of a memory management method according to an embodiment of the present application;
FIG. 9 is a schematic diagram of a thread memory allocation flow according to an embodiment of the present application;
FIG. 10A is a schematic diagram of a memory recycling sequence according to an embodiment of the present application;
FIG. 10B is a schematic diagram of another memory reclamation sequence according to an embodiment of the present application;
FIG. 10C is a schematic diagram of another memory reclamation sequence according to an embodiment of the present application;
FIG. 11 is a flowchart of an example of a memory management method according to an embodiment of the present application;
FIG. 12A is a flowchart illustrating another example of a memory management method according to an embodiment of the present application;
FIG. 12B is a schematic diagram of another memory reclamation sequence according to an embodiment of the present application;
FIG. 13A is a flowchart illustrating another example of a memory management method according to an embodiment of the present application;
FIG. 13B is a schematic diagram of another memory reclamation sequence according to an embodiment of the present application;
FIG. 14 is a flowchart illustrating another memory management method according to an embodiment of the present application;
FIG. 15 is a schematic diagram of another thread memory allocation flow according to an embodiment of the present application;
FIG. 16 is a flowchart illustrating another example of a memory management method according to an embodiment of the present application;
FIG. 17A is a flowchart illustrating another example of a memory management method according to an embodiment of the present application;
FIG. 17B is a schematic diagram of another memory recycling sequence according to an embodiment of the present application;
FIG. 18 is a flowchart illustrating another memory management method according to an embodiment of the present application;
FIG. 19 is a flowchart of another example of a memory management method according to an embodiment of the present application;
fig. 20 is a flowchart of another example of a memory management method according to an embodiment of the present application.
Detailed Description
The technical solutions of the embodiments of the present application will be clearly and thoroughly described below with reference to the accompanying drawings. Wherein, in the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: a exists alone, A and B exist together, and B exists alone.
The terms "first," "second," and the like, are used below for descriptive purposes only and are not to be construed as implying or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature, and in the description of embodiments of the application, unless otherwise indicated, the meaning of "a plurality" is two or more.
Fig. 1 shows a schematic configuration of an electronic device 100.
The electronic device 100 may be a cell phone, tablet, desktop, laptop, handheld, notebook, ultra-mobile personal computer (ultra-mobile personal computer, UMPC), netbook, as well as a cellular telephone, personal digital assistant (personal digital assistant, PDA), augmented reality (augmented reality, AR) device, virtual Reality (VR) device, artificial intelligence (artificial intelligence, AI) device, wearable device, vehicle-mounted device, smart home device, and/or smart city device, with embodiments of the application not being particularly limited as to the particular type of electronic device.
The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge 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, an earphone interface 170D, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.
It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.
The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.
A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.
In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.
It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also employ different interfacing manners in the above embodiments, or a combination of multiple interfacing manners.
The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charge management module 140 may receive a charging input of a wired charger through the USB interface 130. In some wireless charging embodiments, the charge management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.
The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 to power the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be configured to monitor battery capacity, battery cycle number, battery health (leakage, impedance) and other parameters. In other embodiments, the power management module 141 may also be provided in the processor 110. In other embodiments, the power management module 141 and the charge management module 140 may be disposed in the same device.
The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.
The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.
The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.
The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low frequency baseband signal to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs sound signals through an audio device (not limited to the speaker 170A, the receiver 170B, etc.), or displays images or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional module, independent of the processor 110.
The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.
In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques. The wireless communication techniques may include the Global System for Mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).
The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.
The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED) or an active-matrix organic light-emitting diode (matrix organic light emitting diode), a flexible light-emitting diode (flex), a mini, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.
The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like. The ISP is used to process data fed back by the camera 193. The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The digital signal processor is used for processing the digital signal. Video codecs are used to compress or decompress digital video. The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.
The internal memory 121 may include one or more random access memories (random access memory, RAM) and one or more non-volatile memories (NVM).
The random access memory may include a static random-access memory (SRAM), a dynamic random-access memory (dynamic random access memory, DRAM), a synchronous dynamic random-access memory (synchronous dynamic random access memory, SDRAM), a double data rate synchronous dynamic random-access memory (double data rate synchronous dynamic random access memory, DDR SDRAM, such as fifth generation DDR SDRAM is commonly referred to as DDR5 SDRAM), etc.;
the nonvolatile memory may include a disk storage device, a flash memory (flash memory).
The FLASH memory may include NOR FLASH, NAND FLASH, 3D NAND FLASH, etc. divided according to an operation principle, may include single-level memory cells (SLC), multi-level memory cells (MLC), triple-level memory cells (TLC), quad-level memory cells (QLC), etc. divided according to a storage specification, may include universal FLASH memory (english: universal FLASH storage, UFS), embedded multimedia memory cards (embedded multi media Card, eMMC), etc. divided according to a storage specification.
The random access memory may be read directly from and written to by the processor 110, may be used to store executable programs (e.g., machine instructions) for an operating system or other on-the-fly programs, may also be used to store data for users and applications, and the like.
The nonvolatile memory may store executable programs, store data of users and applications, and the like, and may be loaded into the random access memory in advance for the processor 110 to directly read and write.
The external memory interface 120 may be used to connect external non-volatile memory to enable expansion of the memory capabilities of the electronic device 100. The external nonvolatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and video are stored in an external nonvolatile memory.
The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.
The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.
The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals. The electronic device 100 may listen to music, or to hands-free conversations, through the speaker 170A.
A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal. When electronic device 100 is answering a telephone call or voice message, voice may be received by placing receiver 170B in close proximity to the human ear.
Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can sound near the microphone 170C through the mouth, inputting a sound signal to the microphone 170C. The electronic device 100 may be provided with at least one microphone 170C. In other embodiments, the electronic device 100 may be provided with two microphones 170C, and may implement a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may also be provided with three, four, or more microphones 170C to enable collection of sound signals, noise reduction, identification of sound sources, directional recording functions, etc.
The earphone interface 170D is used to connect a wired earphone. The headset interface 170D may be a USB interface 130 or a 3.5mm open mobile electronic device platform (open mobile terminal platform, OMTP) standard interface, a american cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.
The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. The gyro sensor 180B may be used to determine a motion gesture of the electronic device 100. The air pressure sensor 180C is used to measure air pressure. The magnetic sensor 180D includes a hall sensor. The electronic device 100 may detect the opening and closing of the flip cover using the magnetic sensor 180D. The acceleration sensor 180E may detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). The magnitude and direction of gravity may be detected when the electronic device 100 is stationary. The electronic equipment gesture recognition method can also be used for recognizing the gesture of the electronic equipment, and is applied to horizontal and vertical screen switching, pedometers and other applications. A distance sensor 180F for measuring a distance. The electronic device 100 may measure the distance by infrared or laser. In some embodiments, the electronic device 100 may range using the distance sensor 180F to achieve quick focus. The proximity light sensor 180G may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic device 100 emits infrared light outward through the light emitting diode. The electronic device 100 detects infrared reflected light from nearby objects using a photodiode. When sufficient reflected light is detected, it may be determined that there is an object in the vicinity of the electronic device 100. When insufficient reflected light is detected, the electronic device 100 may determine that there is no object in the vicinity of the electronic device 100. The electronic device 100 can detect that the user holds the electronic device 100 close to the ear by using the proximity light sensor 180G, so as to automatically extinguish the screen for the purpose of saving power. The proximity light sensor 180G may also be used in holster mode, pocket mode to automatically unlock and lock the screen. The ambient light sensor 180L is used to sense ambient light level. The fingerprint sensor 180H is used to collect a fingerprint. The temperature sensor 180J is for detecting temperature. The touch sensor 180K, also referred to as a "touch device". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 100 at a different location than the display 194. The bone conduction sensor 180M may acquire a vibration signal. In some embodiments, bone conduction sensor 180M may acquire a vibration signal of a human vocal tract vibrating bone pieces.
The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.
The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 191 may also correspond to different vibration feedback effects by touching different areas of the display screen 194. Different application scenarios (such as time reminding, receiving information, alarm clock, game, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.
The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.
The SIM card interface 195 is used to connect a SIM card. The SIM card may be inserted into the SIM card interface 195, or removed from the SIM card interface 195 to enable contact and separation with the electronic device 100. The electronic device 100 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support Nano SIM cards, micro SIM cards, and the like. The same SIM card interface 195 may be used to insert multiple cards simultaneously. The types of the plurality of cards may be the same or different. The SIM card interface 195 may also be compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as communication and data communication. In some embodiments, the electronic device 100 employs esims, i.e.: an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.
The operating system may allocate a virtual address space to the target application program when the executable file of the target application program is running. During the running process of the target application program, when the target application program creates a thread, the operating system allocates a part of virtual memory addresses of the virtual address space for the thread. When the thread of the target application program executes the read-write operation, the address given in the instruction is a virtual address, and when the CPU executes the instruction, the virtual address is firstly converted into a physical address, and then the instruction and the data can be accessed in the physical. The address translation (address translation) may be performed by a memory management unit (memory management unit, MMU) in the CPU. Wherein, the physical address is an address which can be identified and accessed by specific physical hardware. Virtual addresses are addresses recognizable and accessible within operating system approved applications.
As shown in fig. 2, the virtual address space of the target application includes a plurality of functional areas. The plurality of functional areas may include kernel space, stacks, file map areas, stacks, bss segments, data segments, code segments, and reserved areas.
Wherein the kernel space stores the code of the operating system, and each process can map the virtual address of the kernel space to the same physical address. The stack is used for storing local variables used by the process, parameter values, return values and the like of the function, and is a data structure extending from a high virtual address to a low virtual address. The file mapping area is used for storing file data read from the hard disk. The heap is used for storing memory segments dynamically allocated in the running process, and is a data structure extending from a low virtual address to a high virtual address. The bss segment is used to store uninitialized global and static local variables. The data segment is used to store the initialized global and static local variables in the application. The code segments are used to store the execution code (machine instructions executed by the CPU) of the application program. The virtual address of the reserved area does not map to a physical address, and the operating system does not allow any user process to access the reserved area.
In some embodiments, the operating system divides the memory into a plurality of memory pages at a fixed size. Memory pages of the virtual address space and memory pages of the physical address space may be mapped by page tables. In the running process of the target application program, the operating system does not load all data of the target application program into the physical memory, and the operating system firstly only allocates virtual memory pages to the virtual address space, wherein the virtual memory pages do not have a mapping relation with the physical memory pages. When only the target application program accesses the instruction or data in the virtual memory page, the operating system can establish the mapping relation between the accessed virtual memory page and the physical memory page, and read the data indicated by the virtual memory page (such as local variables, disk data and the like generated in the running process of the program) into the physical memory page.
As shown in fig. 3, threads of the target application may include, but are not limited to, a window management thread (ui, ui), an image rendering thread (render), a system service thread (android), a push service thread, and so on. The window management thread may be used to manage windows, for example, the window management thread may be used to obtain a display screen size, determine whether a status bar exists, lock a screen, intercept a screen, and the like. The image rendering thread may be used for image rendering. The system service thread may be used to invoke system services. The push service thread may be used to manage communications. These threads are merely examples of threads of the target application program, and the names, functions, and the like of the threads of the target application program should not be specifically limited. When the operating system receives memory allocation requests submitted by threads of a target application, the threads may be allocated one or more memory pages, which may be collectively referred to as virtual memory regions (VMAs), by a memory allocator (e.g., jemalloc allocator, scudo allocator, musl allocator, etc.). The thread initiates a memory allocation request to the memory allocator to be executed in a user mode. The memory allocator allocates memory pages to the threads for execution in the kernel state. Wherein, the gray blocks in fig. 3 may represent memory pages occupied by threads, and the white blocks may represent memory pages unoccupied by threads. The memory pages allocated to the threads by the memory allocator are virtual memory pages which have established a mapping relationship with the physical memory pages.
The one or more memory pages may be divided into file-page (file-page) and anonymous page (anonymous page). Wherein the file pages may be used to store file class data. Such as code segments, accessed file data, and the like. The data stored in the file pages may be loaded from disk. The anonymous page is a memory dynamically allocated in the process of running the application program and is used for storing data generated when the application program runs.
It should be noted that the file pages all have corresponding file names. Anonymous pages have no corresponding identity. The electronic device 100 stores therein a file (e.g., a sms file) including a correspondence between the virtual address space and the identifier. As shown in fig. 4, the virtual address section of the file page and the name of the file page of the virtual address section, for example, "filename1", "filename2", are recorded in the file. Fig. 4 also shows address intervals for anonymous pages, but all anonymous pages are named "anon", that is, the operating system cannot distinguish between different anonymous pages based on their names.
When the memory resources are tensed, the operating system executes the memory reclamation operation. For example, the operating system may reclaim memory pages based on a Least Recently Used (LRU) algorithm. Specifically, as shown in fig. 5, the process of recovering the memory by the operating system is as follows: the operating system may add the most recently accessed memory page to the head of the active list (active list), the memory page of the active list moves to the tail, the memory page of the tail of the active list moves to the head of the inactive list (inactive list), the memory page of the inactive list moves to the tail, the memory page of the tail of the inactive list is removed from the inactive list, and the memory page is recovered by the operating system. Because the file pages and memory pages are different, the operating system may generate an active linked list, an inactive linked list for the file pages, and an active linked list and an inactive linked list for the anonymous pages. It should be noted that, when the operating system retrieves a file page, the operating system needs to query whether the file page is modified by an application program, if the file page is not modified, the memory of the file page is directly released, and if the file page is modified, the content of the modified file page is written back to the disk, and then the file page is released. Thus, the operating system can release the file pages which are not used recently based on the LRU algorithm, and the memory pressure is relieved.
When the operation system recovers the anonymous page, the operation system only recovers the anonymous page according to the latest access condition of the anonymous page, if the data stored in the anonymous page is the key data of the application program, the data in the anonymous page is the data generated in the running process of the program, and the data corresponding to the anonymous page does not exist in the disk, so that once the anonymous page is recovered, the program is possibly blocked due to the loss of the key data.
In some embodiments, the operating system, after assigning the virtual address space, may unify the naming of the assigned vma. For example, when the operating system may allocate a virtual address space to an application through a jamalloc memory allocator, the virtual address space may be named "libc_malloc". When an application thread calls a malloc function or a new function, and requests to allocate memory, the jemalloc memory allocator may call a mmap interface to allocate vma to the thread and map physical memory to vma. The jemalloc memory allocator may also call the prctl interface to name the allocated vma. For example, the jemalloc memory allocator may be collectively named "anon: libc_malloc" for the allocated vma, as shown in fig. 6. The electronic device 100 may store information such as a vma name in a memory, and specifically, may store information in a sms file in the memory. That is, the memory allocator does not name the allocated vma or, even if the allocated vma is named, only assigns all vmas the same name. Because vma allocated by the memory allocator has no identifier, or all vma identifiers are the same, the operating system cannot distinguish between different vmas, and anonymous pages where key data of threads are located cannot be reserved.
The following describes a software architecture schematic diagram provided in the embodiment of the present application.
The software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. The embodiment of the present application exemplifies the software structure of the electronic device 100 by taking the operating system with a layered architecture as an example.
Illustratively, as shown in FIG. 7, the software architecture of the electronic device 100 includes several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the operating system is divided into four layers, from top to bottom, an application layer, a system layer, a hardware abstraction layer, and a kernel layer, respectively.
The application layer may be an application layer and an application framework layer. Wherein the application layer comprises a series of application packages. For example, the application package may include applications for cameras, gallery, calendar, phone calls, maps, navigation, WLAN, bluetooth, music, video, short messages, etc. Wherein the application framework layer provides an application programming interface (application programming interface, API) and programming framework for the application. The application framework layer includes a number of predefined functions. For example, the application framework layer may include a window manager, a content provider, a view system, a resource manager, a notification manager, and the like.
The system layer may include a system library (native) and a runtime. Wherein the system library may comprise a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.
The runtime may refer to all code libraries, frameworks, etc. that are needed by the program to run. For example, for the C language, the runtime includes a series of libraries of functions that are required for the C program to run. For the Java language, the runtime includes a core library and a virtual machine, and the core library may include function functions that the Java language needs to call. The application layer and the application framework layer run in a virtual machine. The virtual machine executes Java files of the application layer and the application framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like. The hardware abstraction layer is used to provide access interfaces for different hardware devices to the application.
The hardware abstraction layer is used for packaging the kernel driver and providing a hardware interface for an upper layer.
The kernel layer is a layer between hardware and software, and can be used for process management, memory management and the like.
In some application scenarios, the application runs with Java threads and C/C++ threads created. The Java thread runs on the virtual machine and is mainly used for realizing program basic functions and user operation logic. The virtual machine may obtain the memory from the kernel layer through a mmap interface, which is used to map a portion of the physical memory from the kernel state to the user state. Wherein the C/c++ threads are mainly used to implement program core functions, such as rendering, communication, etc. The C/C++ thread may acquire memory through an active layer memory allocator (e.g., a jemalloc allocator, a scudo allocator, etc.). It should be noted that, the memory allocator also obtains the memory from the kernel layer through the mmap interface. It can be understood that, the memory management method provided by the present application can be implemented in any electronic device that obtains anonymous pages through the above-mentioned virtual machine or memory allocator.
The embodiment of the application provides a memory management method, and when an electronic device 100 receives a memory allocation request of a thread of an application program, a virtual memory area can be allocated to the thread. The electronic device 100 may also obtain the name of the thread and use the name of the thread to identify the virtual memory region allocated to the thread. In the memory reclamation flow, the electronic device 100 may preferentially reclaim the virtual memory area of the thread with the lowest priority based on the priority of each thread of the application program. Thus, the electronic device 100 can preferentially recycle the memory area of the unimportant threads, and ensure the running of the important threads of the application program.
In some embodiments, the electronic device 100 may categorize threads, different types of threads having different priorities, and the same type of threads having the same priority. When the electronic device 100 receives the memory allocation request of the thread, the service type of the thread may be determined, and the thread name of the thread may be obtained. The electronic device 100 may allocate an independent memory region to a thread in the memory space of the program and identify the memory region using the thread name of the thread. In the memory reclamation procedure, the electronic device 100 may sequentially reclaim the memory areas of the threads of different service types based on the service types. When the electronic device 100 recovers the memory areas of the plurality of threads of the same type of the application program, the memory areas of the threads that have not been run recently may be recovered preferentially, or the memory areas of a certain thread of the plurality of threads of the same type may be recovered randomly, which is not limited in the present application.
Next, a flowchart example of a memory management method provided by an embodiment of the present application will be described.
As shown in fig. 8, the memory management method includes:
s801, receiving a memory allocation request of a thread, and setting identification parameters and type parameters of the thread.
When the electronic device 100 receives a memory allocation request for a thread, an identification parameter and a type parameter for the thread may be set. The value of the identification parameter may be the name of the thread, and the electronic device 100 may obtain the name of the thread through the interface. For example, the electronic device 100 may obtain the thread name through the prctl function that satisfies the posix interface protocol. Wherein the input of prtcl includes an option parameter that can be used to set the function of the prctl function. When the option parameter is "pr_get_name", the prctl function is used to obtain the thread NAME. When the option parameter is "PR_SET_VMA", the prctl function is used to SET the name of the memory region.
Wherein the type parameter may be used to represent the traffic type of the thread. Wherein the electronic device 100 may be provided with a plurality of service types. The electronic device 100 may determine the traffic type of the thread based on the thread name, etc.
In some examples, the electronic device 100 may be provided with 5 service types, respectively: non-key service types, display service types, interactive service types, heap service types, push service types. The thread for displaying the service type can be used for completing the processing of the display content, for example, performing operations of synthesizing a layer, rendering an image and the like. The threads of the interactive service type may be used to obtain user input, and to perform corresponding operations in response to the user input, such as corresponding user operations to click on a screen to perform corresponding process flows. The heap service type thread is used for managing heap data, mainly virtual machine service related threads. The push service type thread is used to receive message data. The non-critical traffic type threads are threads other than the above traffic type threads.
The electronic device 100 may determine the service type of the thread by using the following methods.
(1) The electronic device 100 may determine the traffic type of the thread by determining whether the thread name of the thread includes a particular field. For example, when the specific fields include a string related to the display service such as "view", "Mali", "surface", "canvas", "GLTrack", "JS", "UI", "composition", "hwcomposition", "display", "ski", etc., the service type of the thread may be determined to be the display service type. When the specific field includes a character string related to the interactive service, such as "input", "event", "swing", etc., it can be determined that the service type of the thread is the interactive service type. When the specific field includes a string related to heap traffic such as "Java", "object", "area", etc., it can be determined that the traffic type of the thread is the heap traffic type. When the specific field includes a string related to the push service, such as "service", "message", "push", etc., it may be determined that the service type of the thread is a push service type.
In some examples, if a thread name of a thread does not include specific fields for a display traffic type, an interaction traffic type, a heap traffic type, and a push traffic type, electronic device 100 may determine that the traffic type of the thread is a non-critical traffic type.
(2) The electronic device 100 may determine a traffic type of the thread based on the application scenario. For example, electronic device 100 may determine the type of thread involved in receiving user input as the interactive traffic type. The electronic device 100 may determine the type of thread involved after receiving the user input as the display traffic type. The electronic device 100 may determine the type of thread involved after the application is switched to the background as a heap traffic type. The electronic device 100 may determine the type of thread involved in receiving the message data as a push traffic type. The electronic device 100 may determine threads of the application other than the threads of the above traffic types as non-critical traffic types.
In some examples, if a thread switches from a run state to a blocked state or a lock pool state due to another thread or threads, electronic device 100 may determine the traffic type of the other thread or threads as the traffic type of the thread.
In some examples, the electronic device 100 may determine the traffic type of the thread in combination with the various ways of determining the traffic type of the thread described above. For example, the electronic device 100 may determine whether the traffic type of the thread is any of a display traffic type, an interactive traffic type, a heap traffic type, and a push traffic type based on the name of the thread. And judging whether the service type of the thread is any one of a display service type, an interaction service type, a heap service type and a push service type based on the application scene according to the thread of which the service type cannot be determined based on the thread name. For the thread which cannot determine the service type based on the thread name and the application scene, whether the service type of the thread is any one of the display service type, the interactive service type, the heap service type and the push service type can be judged based on whether other threads which have determined the service type are caused to be switched from the running state to the blocking state or the lock pool state. If the electronic device 100 cannot determine whether the service type of a certain thread is any of the display service type, the interaction service type, the heap service type, and the push service type up to this point, the service type of the thread may be determined to be a non-critical service type.
Of course, the electronic device 100 may determine the traffic type of the thread using several methods including, but not limited to, those listed above, as the application is not limited in this regard.
In some embodiments, the electronic device 100 may store the correspondence between the thread name of the thread and the service type after determining the service type. In this way, when executing step S801, the electronic device 100 may directly acquire the service type of the thread based on the thread name. It should be noted that, the stored information of the correspondence between the thread name and the service type is not unmodified, and the electronic device 100 may update the correspondence between the stored thread name and the service type at intervals.
S802, a memory area is allocated to the thread, and the memory area is marked based on the identification parameter of the thread.
After determining the identification parameter of the thread, the electronic device 100 may allocate a memory area to the thread from the virtual address space of the application program, and use the identification parameter of the thread to mark the memory area. It should be noted that a memory area includes only one memory page of a thread. It should be further noted that, the memory page allocated herein is a virtual memory page that has a mapping relationship with a physical memory page. When the electronic device 100 reclaims the memory page of the memory area, the memory page of the memory area may be reclaimed by a memory reclamation algorithm such as LRU.
For example, as shown in fig. 9, when a thread requests to allocate memory to the electronic device 100, the electronic device 100 may allocate a memory allocation unit to the thread, and the memory allocation unit may obtain a memory area of a memory space of an application program for the thread, obtain a thread name of the thread, and identify the memory area using the thread name of the thread. The memory allocation unit may be used to allocate, manage and reclaim the memory area of the thread. The thread may request allocation of memory by calling a method such as malloc or new. The memory allocation unit of the thread may obtain a memory area of the memory space of the application program by calling the mmap interface. The memory allocation unit may also set the name of the memory region of the thread by the prctl function that satisfies the posix interface protocol. Wherein the input of prtcl includes an option parameter that can be used to set the function of the prctl function. When the option parameter is "pr_set_vma", the prctl function is used to SET the name of the memory area. Here, the application program includes three threads, and thread 1 may acquire a memory area of thread 1 through a thread 1 allocation unit. Thread 2 may acquire a thread 2 memory region through a thread 2 allocation unit. Thread 3 may acquire a thread 3 memory region through a thread 3 allocation unit.
S803, when the memory resources are insufficient, executing memory recycling operation based on the identification parameters and the type parameters of the threads.
The electronic device 100 may reclaim memory based on the identification parameter and the type parameter of the thread when the memory resources are insufficient. Specifically, the electronic device 100 stores the reclamation order of threads of different traffic types. The electronic device 100 may determine the thread of the service type to be recycled according to the thread type parameter. The electronic device 100 may determine the memory area to be reclaimed, i.e., the memory of the memory area of the reclaimed thread, based on the identification parameter of the thread.
The electronic device 100 may determine whether the memory resources are sufficient based on the free memory capacity. For example, the electronic device 100 may determine that the memory resources are insufficient when the free memory capacity is below a first memory capacity value (e.g., 3 GB). For another example, the electronic device 100 may determine that the memory resources are insufficient when the ratio of the free memory capacity to the total memory capacity is less than a first ratio (e.g., 40%). It should be noted that, the present application is not limited to the mentioned example of insufficient memory resources, and the electronic device 100 may determine that the memory resources are insufficient by other methods, which is not limited in the embodiment of the present application.
As shown in fig. 10A, when the service types of the electronic device 100 include a non-critical service type, a display service type, an interaction service type, a heap service type, and a push service type, the electronic device 100 may sequentially recover the memories of the threads of the corresponding service types according to the order of the non-critical service type, the display service type, the interaction service type, the heap service type, and the push service type. Specifically, when the application includes a thread of a non-critical traffic type, the electronic device 100 first reclaims the memory of the thread of the traffic type. When the application includes a non-critical traffic type, a thread displaying a traffic type, the electronic device 100 first reclaims the memory of the non-critical traffic type thread, then reclaims the memory of the thread displaying the traffic type, and so on.
In some examples, when electronic device 100 reclaims memory of threads of multiple programs, electronic device 100 may randomly reclaim memory of threads of the same traffic type for all programs based on traffic type. For example, the electronic device 100 may first reclaim the memory of the threads of the non-critical traffic types of all applications, then reclaim the memory of the threads of the display traffic types of all applications, and so on, in the reclaiming order of the traffic types shown in fig. 10A. It can be appreciated that, when the electronic device 100 reclaims the memory of a thread of a certain service type, a certain thread of all the threads of the service type may be randomly selected, and the memory of the memory area of the certain thread may be reclaimed. When the electronic device 100 reclaims the memory of the memory area of a certain thread, the memory page of the memory area may be reclaimed by a memory reclamation algorithm such as LRU.
In other examples, electronic device 100 may reclaim memory of threads of the same traffic type for all programs based on the priority and traffic type of the application program. For example, the electronic device 100 may first reclaim the memory of the threads of the non-critical traffic types of all applications, then reclaim the memory of the threads of the display traffic types of all applications, and so on, in the reclaiming order of the traffic types shown in fig. 10A. When the electronic device 100 recovers the memory of the thread of a certain service type, the memory of the thread of the application program with the lowest priority among all the threads of the service type may be preferentially recovered according to the priority of the application program. Wherein the electronic device 100 may determine the priority of the application program based on the frequency of use of the application. The application usage frequency may be a duration of time that the user uses the application program for a period of time (e.g., one day). The longer the user uses the application program in a period of time, the higher the application frequency, and the higher the priority of the application program. The frequency of use of an application may also be the number of times the user opens the application over a period of time (e.g., a day).
In some examples, the electronic device 100 may also determine the priority of the application by applying the duration of the CPU occupation. For example, the longer the application occupies the duration of the CPU during the last period of time (e.g., 200 ms), the higher the priority.
In some examples, electronic device 100 may also determine the priority of the application by the power consumption of the application over a period of time. For example, the more power consumption of an application is over the last period of time (e.g., a day), the higher the priority.
In some examples, electronic device 100 may also determine the priority of the application by the last time the application was used. For example, the closer the application has recently received user input or the closer the application has recently read data, the higher the priority.
In some examples, to avoid situations where multiple applications are prioritized identically, electronic device 100 may determine the priority of the application in combination with the various ways described above. For example, when determining that the priorities of the plurality of application programs are the same based on the application use frequency, the electronic device 100 may determine the priorities of the plurality of application programs based on the power consumption amount of the application, and so on.
Alternatively, when the priorities of the plurality of applications are the same, the electronic device 100 may determine the priority of the application according to the service type of the application. For example, the electronic device 100 may identify an instant messaging application among the plurality of applications as the highest priority application.
For example, as shown in fig. 10B, when the electronic device 100 runs the application 1, the application 2, and the application 3, it is assumed that the priority of the application 1 is lower than that of the application 2, and the priority of the application 2 is lower than that of the application 3. When the electronic device 100 recovers the memory of the thread of the same service type, the memory of the memory area of the thread of the service type of the application 1 may be recovered first, the memory of the memory area of the thread of the service type of the application 2 may be recovered, and the memory of the memory area of the thread of the service type of the application 3 may be recovered finally. As indicated by the arrow in fig. 10B, electronic device 100 may first reclaim memory of the non-critical traffic type threads of application 1, then reclaim memory of the non-critical traffic type threads of application 2, and so on. It will be appreciated that if application 1 does not include a thread of a certain traffic type, application 1 may be skipped and the memory of the memory region of the thread of the certain traffic type of application 2 may be reclaimed. When the application 1 includes a plurality of threads of the same service type, the memory of the plurality of threads may be recovered randomly or, alternatively, the least recently used threads may be recovered preferentially.
In one possible implementation, the priorities of the service types of the foreground-running application and the background-running application are different due to the different thread importance of the foreground-running application and the background-running application. For example, the service types of the electronic device 100 may include, but are not limited to, non-critical service types, display service types, interactive service types, heap service types, and push service types as shown in fig. 10A. For the application running in the foreground, because the interactive service and the display service of the application running in the foreground are more important, as shown in fig. 10C, the electronic device 100 may sequentially recover the memories of the threads of the corresponding service types according to the order of the non-critical service type, the heap service type, the push service type, the display service type, and the interactive service type. For the application running in the background, since the push service of the application running in the background is more important, the electronic device 100 may sequentially recover the memories of the threads of the corresponding service types according to the order of the non-critical service types, the display service types, the interactive service types, the heap service types, and the push service types as shown in fig. 10C.
It can be appreciated that the application running in the foreground needs to display a user interface, and the threads displaying the service type and the interactive service type are responsible for generating the user interface that the application needs to display. Thus, the threads displaying the service type and the interactive service type are more important for the application program running in the foreground and should be recycled finally. While the background running application does not need to display a user interface, it may need to receive push messages and keep the key data from being lost, so that the heap service type and the thread of the push service type are more important for the background running application and should be recycled finally.
For example, when a user switches a reading APP to the background, the reading APP no longer needs to display a thread of a service type to generate a user interface, but needs to ensure that the key data of the user reading progress (the memory space corresponding to the thread stored in the heap service type) can not be lost due to memory reclamation. Thus, for the reading APP, threads of the display traffic type may be preferentially reclaimed, while threads of the heap traffic type should be as little reclaimed as possible.
For another example, when the user switches the WeChat APP to the background, the user still wants to be able to continuously receive the message sent by the contact in the WeChat APP, and wants the mobile phone to push the message in real time. Thus, for a WeChat APP, the threads of the push traffic type should be as little reclaimed as possible.
For another example, when a user places a game APP in a foreground, the user may play the game APP, where the game APP needs to display a rendered game screen and receive an operation input by the user through a touch screen to perform interaction, and if threads displaying a service type and an interaction service type are recycled at this time, the game may crash and affect the user experience. Thus, for the game APP in the foreground, it should be ensured that threads showing the service type, interactive service type, are last recycled as much as possible.
It should be noted that, because the priorities of the service types of the application program running in the foreground and the application program running in the background are different, the electronic device 100 may preferentially recycle the memory of the application program running in the background, and then recycle the memory of the application program running in the foreground. The electronic device 100 may recycle the memory of the application running in the background, and the detailed description of recycling the memory of the application running in the foreground may refer to the above embodiment, which is not described herein.
In other embodiments, the electronic device 100 may categorize threads, different types of threads having different priorities, and the same type of threads having the same priority. When the electronic device 100 receives a memory allocation request for a thread, the thread name of the thread may be obtained. The electronic device 100 may allocate an independent memory region to a thread in the memory space of the program and identify the memory region using the thread name of the thread. In the memory reclamation flow, the electronic device 100 may determine a service type of a thread, and reclaim memory areas of threads of different service types in sequence based on the service type. When the electronic device 100 recovers the memory areas of the plurality of threads of the same type of the application program, the memory areas of the threads that have not been run recently may be recovered preferentially, or the memory areas of a certain thread of the plurality of threads of the same type may be recovered randomly, which is not limited in the present application.
In some examples, electronic device 100 may allocate different memory regions to different threads of a program upon receiving memory allocation requests for the different threads and identify the memory regions based on the thread names of the threads. When the memory resources are insufficient, the electronic device 100 may reclaim the memory of the thread based on the service type of the thread, as shown in fig. 11:
s1101, the electronic device 100 receives memory allocation requests of a first thread and a second thread of a first program, wherein the first thread belongs to a first service type, the second thread belongs to a second service type, and the priority of the first service type is higher than that of the second service type.
The more important the higher priority service type thread is, the electronic device 100 will preferentially reclaim the memory of the lower priority service type thread, and keep the memory of the higher priority service type thread as much as possible.
The application program running in the foreground needs to display the user interface, and the threads of the display service type and the interaction service type are responsible for generating the user interface which the application program needs to display. Thus, the threads displaying the service type and the interactive service type are more important for the application program running in the foreground and should be recycled finally. While the background running application does not need to display a user interface, it may need to receive push messages and keep the key data from being lost, so that the heap service type and the thread of the push service type are more important for the background running application and should be recycled finally. Therefore, in the case that the first program is a program running in the background, if the first service type is a heap service type, the second service type may be a non-critical service type, a display service type, or an interactive service type. If the first program is a program operated by a foreground, the second service type may be a non-critical service type, a heap service type or a push service type if the first service type is a display service type. Specifically, the description of the service type may refer to the embodiment shown in fig. 8, and will not be repeated herein.
S1102, the electronic device 100 allocates a first memory area to a first thread from a memory space of the first program, marks the first memory area with an identifier of the first thread, allocates a second memory area to a second thread, and marks the second memory area with an identifier of the second thread.
The identification of the thread may be a thread name of the thread, and the electronic device 100 may determine the memory area of the thread based on the thread name of the thread. The electronic device 100 allocates a memory area to the thread, obtains the thread name, and details of naming the memory area can be referred to the embodiment shown in fig. 8, which is not described herein again.
S1103, when the memory resources are insufficient, based on the priority of the service types, the memories are sequentially recovered according to the sequence of recovering the second memory area corresponding to the second thread of the second service type and recovering the first memory area corresponding to the first thread of the first service type.
As previously mentioned, the priority of the first traffic type is higher than the priority of the second traffic type, the higher the priority the later should be reclaimed. Therefore, when the memory resource is insufficient, the second memory area corresponding to the second thread of the second service type should be recovered first, and then the first memory area corresponding to the first thread of the first service type should be recovered.
When the electronic device 100 retrieves the memory of the second memory area corresponding to the second thread (or the first memory area corresponding to the first thread), the memory pages of the second memory area (or the first memory area) may be gradually retrieved through the LRU algorithm. Specifically, reference may be made to the embodiment shown in fig. 5, and details thereof are not repeated here.
In some examples, if the traffic types of the first thread and the second thread are the same, the electronic device 100 may randomly reclaim the first memory area corresponding to the first thread and the second memory area corresponding to the second thread, or the electronic device 100 may preferentially reclaim the memory area corresponding to a thread that is not used recently (e.g., the second memory area is preferentially reclaimed if the second thread is not used recently) in the first thread and the second thread, and so on.
In some examples, electronic device 100 may allocate different memory regions to different threads of a plurality of programs upon receiving memory allocation requests for the different threads and identify the memory regions based on the thread names of the threads. When the memory resources are insufficient, the electronic device 100 may reclaim the memory based on the service type of the thread and the priority of the program, as shown in fig. 12A:
S1201. the electronic device 100 receives a memory allocation request of a first thread of a first program, a second thread of the first program, and a third thread of the second program, where the first thread and the third thread Cheng Shuyu are of a first service type, and the second thread is of a second service type, and a priority of the first service type is higher than a priority of the second service type.
The more important the thread is due to the higher priority traffic type. When the memory resources are insufficient, the memory area corresponding to the thread of the service type with low priority should be recovered first, and then the memory area corresponding to the thread of the service type with high priority should be recovered.
S1202, the electronic device 100 allocates a first memory area to a first thread from a memory space of the first program, allocates a second memory area to a second thread, marks the first memory area with an identification of the first thread, marks the second memory area with an identification of the second thread, allocates a third memory area to a third thread from a memory space of the second program, and marks the third memory area with an identification of the third thread.
S1203, when the memory resource is insufficient, if the first program is higher than the second program, based on the priority of the service type and the priority of the program, sequentially recovering the memory according to the order of recovering the second memory area corresponding to the second thread of the second service type of the first program, recovering the third memory area of the third line Cheng Duiying of the first service type of the second program, and finally recovering the first memory area corresponding to the first thread of the first service type of the first program.
As shown in fig. 12B, the service types of the first thread and the third thread are the first service type, and the service type of the second thread is the second service type.
The priority of the second traffic type is priority 2 for the priority of the traffic type. The priority of the first traffic type is priority 1. The second traffic type has a lower priority than the first traffic type. The lower the priority of the service type is, the more the memory area corresponding to the thread of the service type is recovered. Therefore, when the memory resources are insufficient, the memory area corresponding to the thread of the second service type (in this example, the second thread) may be recovered preferentially, and the memory area corresponding to the thread of the first service type (in this example, the third thread, the first thread) may be recovered.
For threads of the same service type, the memory reclamation sequence can be determined according to the priority of the program. In this example, the third thread and the first thread are both threads of the first traffic type of "priority 1". Since the second program of the third line Cheng Duiying has a lower priority than the first program corresponding to the first program, the lower the program priority, the more memory area corresponding to the thread of the program is reclaimed. Thus, in this example, the third memory region of the third thread Cheng Duiying can be reclaimed first and then the first memory region corresponding to the first thread can be reclaimed.
Thus, in this example, the order of reclamation of the memory regions is: the second memory area corresponding to the second thread is recovered, the third memory area of the third thread Cheng Duiying is recovered, and the first memory area corresponding to the first thread is recovered.
How the electronic device 100 allocates the memory areas and how to reclaim the memory in each memory area can be referred to the embodiment shown in fig. 8 (for example, how to reclaim the memory in each memory area based on the LRU algorithm), which is not described herein.
In some examples, electronic device 100 may, upon receiving memory allocation requests for multiple threads of multiple programs, allocate different memory regions to the multiple threads and identify corresponding memory regions based on thread names of the threads. When the memory resources are insufficient, the electronic device 100 may reclaim the memory based on the service type of the thread and the priority of the program, as shown in fig. 13A:
s1301, the electronic device 100 receives memory allocation requests of a first thread of a first program, a second thread of the first program, a third thread of the second program and a fourth thread of the second program, wherein the first thread and the third thread Cheng Shuyu are of a first service type, the second thread and the fourth thread Cheng Shuyu are of a second service type, and the priority of the first service type is higher than that of the second service type.
The more important the thread is due to the higher priority traffic type. When the memory resources are insufficient, the memory area corresponding to the thread of the service type with low priority should be recovered first, and then the memory area corresponding to the thread of the service type with high priority should be recovered.
S1302, the electronic device 100 allocates a first memory area to a first thread from a memory space of the first program, allocates a second memory area to a second thread, marks the first memory area with an identifier of the first thread, marks the second memory area with an identifier of the second thread, allocates a third memory area to a third thread from a memory space of the second program, allocates a fourth memory area to a fourth thread, marks the third memory area with an identifier of the third thread, and marks the fourth memory area with an identifier of the fourth thread.
S1303, when the memory resource is insufficient, if the first program is higher than the second program, based on the priority of the service type and the priority of the program, the memory is sequentially recovered according to the order of recovering the fourth memory region of the fourth line Cheng Duiying of the second service type of the second program, recovering the second memory region corresponding to the second thread of the second service type of the first program, recovering the third memory region of the third line Cheng Duiying of the first service type of the second program, and finally recovering the first memory region corresponding to the first thread of the first service type of the first program.
As shown in fig. 13B, the service types of the first thread and the third thread are the first service type, and the service types of the second thread and the fourth thread are the second service type.
The priority of the second traffic type is priority 2 for the priority of the traffic type. The priority of the first traffic type is priority 1. The second traffic type has a lower priority than the first traffic type. The lower the priority of the service type is, the more the memory area corresponding to the thread of the service type is recovered. Therefore, when the memory resources are insufficient, the memory area corresponding to the thread of the second service type (in this example, the second thread and the fourth thread) can be recovered preferentially, and the memory area corresponding to the thread of the first service type (in this example, the third thread and the first thread) can be recovered.
For threads of the same service type, the memory reclamation sequence can be determined according to the priority of the program. In this example, the third thread and the first thread are both threads of the first traffic type of "priority 1". Since the second program of the third line Cheng Duiying has a lower priority than the first program corresponding to the first program, the lower the program priority, the more memory area corresponding to the thread of the program is reclaimed. Thus, in this example, the third memory region of the third thread Cheng Duiying can be reclaimed first and then the first memory region corresponding to the first thread can be reclaimed. The fourth thread and the second thread are both threads of the second service type with the priority of 2. Since the second program of the fourth line Cheng Duiying has a lower priority than the first program corresponding to the second thread, the lower the program priority, the more memory area corresponding to the thread of the program is reclaimed. Thus, in this example, the fourth memory region of the fourth line Cheng Duiying may be reclaimed first, and then the second memory region corresponding to the second thread may be reclaimed.
Thus, in this example, the order of reclamation of the memory regions is: the fourth memory region of the fourth line Cheng Duiying is recovered, the second memory region corresponding to the second thread is recovered, the third memory region of the third line Cheng Duiying is recovered, and the first memory region corresponding to the first thread is recovered.
How the electronic device 100 allocates the memory areas and how to reclaim the memory in each memory area can be referred to the embodiment shown in fig. 8 (for example, how to reclaim the memory in each memory area based on the LRU algorithm), which is not described herein.
In other embodiments, the electronic device 100 may assign each thread a corresponding memory region and name the memory region using the thread name of the thread. When the electronic device 100 recovers the memory, the memory of the application with the lowest priority may be preferentially recovered according to the priority of the application. When the electronic device 100 recovers the memory of the application program, the memory of the thread with the lowest priority may be preferentially recovered according to the priority of the thread of the application program. When the electronic device 100 reclaims the memory of the thread, the memory page of the memory area of the thread may be reclaimed according to a memory reclamation algorithm such as LRU. Thus, the electronic device 100 can avoid reclaiming the memory of the important thread. Wherein the electronic device 100 may determine the priority of the application program based on the frequency of use of the application. The application frequency may be a time when the user uses the application program for a period of time (for example, one day). The longer the user uses the application program in a period of time, the higher the application frequency, and the higher the priority of the application program.
In some examples, the electronic device 100 may also determine the priority of the application by applying the time the CPU is occupied. For example, the longer an application occupies the CPU within a recent period of time (e.g., 200 ms), the higher the priority.
In some examples, electronic device 100 may also determine the priority of the application by the last time the application was used. For example, the closer the application has recently received user input or the closer the application has recently read data, the higher the priority.
However, in the above implementation, each thread is allocated with a memory area, and if the number of threads is large, the memory management is complex.
The application provides another memory management method. The electronic device 100 may determine the traffic type of the thread when receiving a memory allocation request of the thread of the application. The electronic device 100, based on the traffic type of the thread, divides a portion of memory in a memory area of a memory space of an application program for storing data of the thread of the traffic type into the thread. In the memory reclamation procedure, the electronic device 100 may reclaim the memory of different memory areas based on the priority of the service type. In this way, the electronic device 100 may preferentially reclaim the memory area for storing the data of the threads of the non-important business types, and ensure the running of the important threads of the application program.
In some embodiments, the electronic device 100 presets M service types, and the memory space of each program of the electronic device 100 includes M memory areas, where the M memory areas and the M service types are in a one-to-one correspondence. One memory area is used to store data for all threads of one traffic type. When the electronic device 100 receives a memory allocation request of a thread, it may determine a service type of the thread, where M service types include a service type of the thread, and allocate a portion of memory in a memory area corresponding to the service type to the thread. When the memory resources are insufficient, the electronic device 100 may sequentially recover the memories of the corresponding memory areas based on the priority order of the M service types.
Next, another example of a flowchart of a memory management method provided by an embodiment of the present application will be described.
As shown in fig. 14, the memory management method includes:
s1401, the electronic device 100 presets M service types, M is greater than or equal to 1, M memory areas are divided in a memory space based on the M service types, and the memory of each memory area can be allocated to threads of the corresponding service type.
When the electronic device 100 allocates a virtual address space to an application program, M memory areas may be partitioned in the virtual address space, where each of the M memory areas is used to store data of threads of one service type. That is, the M service types and the M memory areas are in a one-to-one correspondence. It is understood that a memory region may include memory pages having one or more threads.
In some examples, the electronic device 100 presets 5 service types, respectively: non-key service types, display service types, interactive service types, heap service types, push service types. Specifically, reference may be made to the embodiment shown in fig. 8, and details thereof are not repeated here. The virtual address space of each application of the electronic device 100 includes 5 memory areas, which are respectively a memory area for storing data of a thread of a non-critical service type, a memory area for storing data of a thread of a display service type, a memory area for storing data of a thread of an interactive service type, a memory area for storing data of a thread of a heap service type, and a memory area for storing data of a thread of a push service type. Here, M is equal to 5.
In some examples, the electronic device 100 may obtain the memory area through the mmap interface, and the electronic device 100 may further set a name of the memory area, for example, through the prctl function shown in fig. 8. The name of the memory area may be a value of the service type. Therefore, the memory area can be associated through the service type, so that the memory allocation and recovery of the memory area are facilitated.
S1402, the electronic device 100 receives the memory allocation request of the thread, and determines the service type of the thread.
The electronic device 100 may determine a service type of the thread when receiving a memory allocation request of the thread. Specifically, reference may be made to the embodiment shown in fig. 8, and details thereof are not repeated here.
S1403, the electronic device 100 allocates the memory in the corresponding memory area to the thread based on the service type of the thread.
When the electronic device 100 determines the service type of the thread, a portion of memory in a memory area in a virtual address space of the application program for storing data of the thread of the service type may be allocated to the thread.
For example, as shown in fig. 15, when a thread requests to allocate memory to the electronic device 100, the electronic device 100 may determine a service type of the thread, allocate a corresponding memory allocation unit to the thread based on the service type, and the memory allocation unit may allocate a portion of memory of the corresponding memory area to the thread. The memory allocation unit may be used for allocating, managing and reclaiming the memory area. The thread may request allocation of memory by calling a method such as malloc or new. The memory allocation unit of the thread may obtain a portion of the memory area by calling the mmap interface. The memory allocation unit may also set the name of the memory region by a prctl function that satisfies the posix interface protocol. Wherein the input of prtcl includes an option parameter that can be used to set the function of the prctl function. When the option parameter is "pr_set_vma", the prctl function is used to SET the name of the memory area.
Here, the application includes, but is not limited to, 7 threads, the service type of thread 1 is a non-critical service type, the service type of thread 2 is an interactive service type, the service types of thread 3 and thread 4 are display service allocation units, the service types of thread 5 and thread 6 are push service types, and the service type of thread 7 is a heap service type. Memory region 1 may be allocated to threads of a non-critical traffic type, memory region 2 may be allocated to threads of a display traffic allocation unit, memory region 3 may be allocated to threads of an interactive traffic type, memory region 4 may be allocated to threads of a heap traffic type, and memory region 5 may be allocated to threads of a push traffic type.
Thread 1 may acquire a portion of memory region 1 through a non-critical traffic allocation unit. The thread 2 may obtain a portion of the memory area 3 through the interactive service allocation unit. The thread 3 may obtain a portion of the memory area 2 by displaying the service allocation unit. The thread 4 may also obtain a portion of the memory area 2 by displaying the service allocation unit. The thread 5 may obtain a portion of the memory area 5 by pushing the service allocation unit. The thread 6 may also acquire a portion of the memory in the memory area 5 by pushing the service allocation unit. The thread 7 may obtain a portion of the memory area 4 through the heap service allocation unit.
S1404, when the memory resource is insufficient, executing memory recycling operation based on the service type.
The electronic device 100 may sequentially recover the memories of different memory areas based on the service type when the memory resources are insufficient. When the electronic device 100 reclaims the memory of a certain memory area, the memory page of the memory area may be reclaimed by a memory reclamation algorithm such as LRU.
In some examples, the electronic device 100 may sequentially reclaim the memory of the memory area for storing data of the non-critical traffic type threads, the memory of the memory area for storing data of the threads displaying the traffic type, the memory of the memory area for storing data of the threads of the interactive traffic type, the memory of the memory area for storing data of the threads of the heap traffic type, and the memory of the memory area for storing data of the threads of the push traffic type, in the order shown in fig. 10A.
In some examples, when electronic device 100 reclaims memory of memory regions of multiple programs, electronic device 100 may randomly reclaim memory of memory regions of the same traffic type for all programs based on traffic type. For example, the electronic device 100 may first reclaim the memory of the memory area of the non-critical traffic type of all the application programs according to the reclaiming order of the traffic types shown in fig. 10A, then reclaim the memory of the memory area of the display traffic type, and so on.
In other examples, electronic device 100 may reclaim memory of memory regions of the same service type for all programs based on the priority and service type of the application program. For example, the electronic device 100 may first reclaim the memory of the memory area of the non-critical traffic type of all the application programs according to the reclaiming order of the traffic types shown in fig. 10A, then reclaim the memory of the memory area of the display traffic type, and so on. When the electronic device 100 recovers the memory of the memory area of a certain service type, the memory of the memory area of the service type of the application program with the lowest priority may be preferentially recovered according to the priority of the application program. The electronic device 100 may determine the priority of the application program based on any one of the frequency of use of the application, the time of last receiving the user input, and the like, and specifically, refer to the embodiment shown in fig. 8, which is not described herein.
For example, as shown in fig. 10B, when the electronic device 100 runs the application 1, the application 2, and the application 3, if the priority of the application 1 is lower than that of the application 2, the priority of the application 2 is lower than that of the application 3. When the electronic device 100 recovers the memory of the memory area of the same service type, the memory of the memory area of the service type of the application 1 may be recovered first, the memory of the memory area of the service type of the application 2 may be recovered, and the memory of the memory area of the service type of the application 3 may be recovered finally.
In one possible implementation, the priorities of the service types of the foreground-running application and the background-running application are different due to the different thread importance of the foreground-running application and the background-running application. Specifically, reference may be made to the embodiment shown in fig. 8, and details thereof are not repeated here.
In some examples, electronic device 100 may determine a traffic type of a thread when receiving a memory allocation request for a different thread of a program, and allocate a portion of memory of a corresponding memory region to the thread based on the traffic type. When the memory resources are insufficient, the electronic device 100 may reclaim the memory of different memory areas based on the service type, as shown in fig. 16:
s1601, the electronic device 100 receives a memory allocation request of a first thread and a second thread of a first program, where a memory space of the first program includes a first type memory area and a second type memory area, where the first type memory area is used to store data of the thread of a first service type, and the second type memory area is used to store data of the thread of a second service type, and a priority of the first service type is higher than a priority of the second service type.
In the memory reclamation process, the electronic device 100 will reclaim the memory area for storing the thread data of the service type with low priority, and then reclaim the memory area for storing the thread data of the service type with high priority.
S1602, the electronic device 100 determines that the service type of the first thread is the first service type, the service type of the second thread is the second service type, allocates the memory in the first type memory area to the first thread, and allocates the memory in the second type memory area to the second thread.
The details of determining the service type of the thread by the electronic device 100 and allocating the memory area to the thread can be referred to the embodiment shown in fig. 14, which will not be described herein.
S1603, when the memory resource is insufficient, based on the priority of the service types, sequentially recovering the memories according to the sequence of recovering the second type memory area for storing the thread data of the second service type and then recovering the first type memory area for storing the thread data of the first service type.
As previously mentioned, the priority of the first traffic type is higher than the priority of the second traffic type, the higher the priority the later should be reclaimed. Therefore, when the memory resource is insufficient, the second memory area corresponding to the second service type should be recovered first, and then the first memory area corresponding to the first service type should be recovered.
When the electronic device 100 reclaims the memory of the second type memory area (or the first type memory area), the memory pages of the second type memory area (or the first type memory area) may be gradually reclaimed through a memory reclamation algorithm such as LRU. Specifically, reference may be made to the embodiment shown in fig. 5, and details thereof are not repeated here.
In some examples, electronic device 100 may determine a traffic type of a thread when receiving memory allocation requests for different threads of a plurality of programs, and allocate a portion of memory of a corresponding memory region to the thread based on the traffic type. When the memory resources are insufficient, the electronic device 100 may reclaim the memory of different memory areas based on the service type, as shown in fig. 17A:
s1701, the electronic device 100 receives memory allocation requests of a first thread and a second thread of a first program, and a third thread and a fourth thread of a second program, where a memory space of the first program includes a first type memory area and a second type memory area, and a memory space of the second program includes the first type memory area and the second type memory area, where the first type memory area is used for storing data of the thread of the first service type, and the second type memory area is used for storing data of the thread of the second service type, and a priority of the first service type is higher than a priority of the second service type.
It will be appreciated that a first type of memory region of a first program may be allocated to threads of a first traffic type of the first program, a second type of memory region of the first program may be allocated to threads of a second traffic type of the first program, a first type of memory region of a second program may be allocated to threads of a first traffic type of the second program, and a second type of memory region of the second program may be allocated to threads of a second traffic type of the second program.
In the memory reclamation process, the electronic device 100 will reclaim the memory area for storing the thread data of the service type with low priority, and then reclaim the memory area for storing the thread data of the service type with high priority.
S1702, the electronic device 100 determines that a service type of a first thread is a first service type, a service type of a second thread is a second service type, a service type of a third thread is the first service type, a service type of a fourth thread is the second service type, memory in a first type memory area of the first program is allocated to the first thread, memory in a second type memory area of the first program is allocated to the second thread, memory in the first type memory area of the second program is allocated to the third thread, and memory in a second type memory area of the second program is allocated to the fourth thread.
The details of the electronic device 100 for determining the service type of the thread and allocating the memory area to the thread can be referred to the embodiment shown in fig. 14, which will not be described herein.
S1703, when the memory resource is insufficient, if the first program is higher than the second program, based on the priority of the service type and the priority of the program, recovering the second type memory area of the second program, recovering the second type memory area of the first program, recovering the first type memory area of the second program, and finally recovering the sequence of the first type memory area of the first program, and sequentially recovering the memory.
When the electronic device 100 reclaims the memory of the second type memory area of the second program, the first type memory area of the second program, the second type memory area of the first program, or the first type memory area of the first program, the memory pages of the memory area may be gradually reclaimed through a memory reclamation algorithm such as LRU. Specifically, reference may be made to the embodiment shown in fig. 5, and details thereof are not repeated here.
As shown in fig. 17B, the second type memory area of the first program is used for storing data of a thread (e.g., a second thread) of the second service type in the first program, the first type memory area of the first program is used for storing data of a thread (e.g., a first thread) of the first service type in the first program, the second type memory area of the second program is used for storing data of a thread (e.g., a fourth thread) of the second service type in the second program, and the first type memory area of the second program is used for storing data of a thread (e.g., a third thread) of the first service type in the second program.
The priority of the second traffic type is priority 2 for the priority of the traffic type. The priority of the first traffic type is priority 1. The second traffic type has a lower priority than the first traffic type. The lower the priority of a service type, the more the memory area storing the thread data of that service type is reclaimed. Therefore, when the memory resources are insufficient, the memory area storing the thread data of the second service type (in this example, the second type memory area of the first program and the second type memory area of the second program) can be recovered preferentially, and then the memory area storing the thread data of the first service type (in this example, the first type memory area of the first program and the first type memory area of the second program) can be recovered.
For the memory areas with the same service type, the recovery sequence of the memory areas can be determined according to the priority of the program. In this example, the first type memory area of the first program and the first type memory area of the second program are both memory areas storing thread data of the first service type of "priority 1". Since the second program has a lower priority than the first program, the lower the program priority, the more memory area of the program is reclaimed. Thus, in this example, the first type memory region of the second program may be reclaimed first, and then the first type memory region of the first program may be reclaimed. Similarly, in this example, the second type memory region of the second program may be reclaimed first, and then the second type memory region of the first program may be reclaimed.
Thus, in this example, the order of reclamation of the memory regions is: the second type memory area of the second program is recovered, the second type memory area of the first program is recovered, the first type memory area of the second program is recovered, and finally the first type memory area of the first program is recovered.
How the electronic device 100 allocates the memory areas and how to reclaim the memory in each memory area can be referred to the embodiment shown in fig. 14 (for example, how to reclaim the memory in each memory area based on the LRU algorithm), which is not described herein.
In other embodiments, the electronic device 100 is preset with M service types, and when the electronic device 100 receives a memory allocation request of a thread, the service type of the thread may be determined, where the M service types include the service type of the thread. If the memory space of the program includes a memory area corresponding to the service type, the electronic device 100 may allocate a portion of the memory in the corresponding memory area to the thread. If the memory space of the program does not include the memory area corresponding to the service type, the electronic device 100 may divide the memory area corresponding to the service type in the memory space of the program, and then allocate a portion of the memory in the corresponding memory area to the thread. When the memory resources are insufficient, the electronic device 100 may sequentially recover the memories of the corresponding memory areas based on the priority order of the service types corresponding to the memory areas in the memory space of the program. Therefore, when the program only comprises the threads of part of the M service types, the memory area corresponding to the part of the service types which are not included in the M service types is not required to be divided in the memory space, and the management cost is reduced.
Next, another example of a flowchart of a memory management method provided by an embodiment of the present application will be described.
As shown in fig. 18, the memory management method includes:
s1801, presetting M service types by the electronic device 100, wherein M is greater than or equal to 1.
In some examples, the electronic device 100 presets 5 service types, respectively: non-key service types, display service types, interactive service types, heap service types, push service types. Specifically, reference may be made to the embodiment shown in fig. 8, and details thereof are not repeated here.
S1802. the electronic device 100 receives a memory allocation request of a thread, and determines a service type of the thread.
Specifically, reference may be made to the embodiment shown in fig. 8, and details thereof are not repeated here.
S1803, if the memory space comprises a memory area for storing data of the thread of the service type, distributing the memory in the corresponding memory area to the thread; if the memory space does not include the memory area for storing the data of the thread of the service type, the memory area for storing the data of the thread of the service type is allocated in the memory space, and the memory in the memory area is allocated to the thread.
In some examples, after determining the service type of the thread, the electronic device 100 may allocate the memory of the corresponding memory area to the thread through the corresponding memory allocation unit. If the memory space of the program does not include the memory area corresponding to the service type, the corresponding memory allocation unit may divide a block of memory area in the memory space of the program, and use the memory area as the memory area for storing the data of all threads of the service type, for example, the memory allocation unit may divide the memory area by calling a mmap function. The corresponding memory allocation unit may also name the memory region based on the traffic type, e.g. the memory allocation unit may name the memory region by a prctl function. The memory allocation unit may allocate a portion of the memory region for use by the thread. If the memory space of the program includes a memory area corresponding to the service type, the corresponding memory allocation unit may allocate a portion of the memory of the corresponding memory area to the thread.
It will be appreciated that one memory region may be allocated for use by multiple threads of a corresponding traffic type of a program.
S1804. when the memory resource is insufficient, based on the service type, executing the memory recycling operation.
The electronic device 100 may recycle the memory of different memory areas based on the service type when the memory resources are insufficient. When the electronic device 100 reclaims the memory resource, the memory area of the service type with the lowest priority may be reclaimed first. When the electronic device 100 retrieves all the memory areas corresponding to a certain service type, the memory area of the application program with the lowest priority may be retrieved first. When the electronic device 100 reclaims the memory of a certain memory area, the memory page of the memory area may be reclaimed by a memory reclamation algorithm such as LRU. Specifically, reference may be made to the embodiment shown in fig. 14, and details thereof are not repeated here.
In some examples, electronic device 100 may determine a traffic type of a thread when a memory allocation request for the thread is received, and allocate a portion of memory of a corresponding memory region to the thread based on the traffic type. When the memory resources are insufficient, the electronic device 100 may reclaim the memory of different memory areas based on the service type, as shown in fig. 19:
S1901, the electronic device 100 receives memory allocation requests of a first thread and a second thread of a first program, determines that the service type of the first thread is a first service type, and the service type of the second thread is a second service type, wherein the priority of the first service type is higher than that of the second service type.
In the memory reclamation process, the electronic device 100 will reclaim the memory area for storing the thread data of the service type with low priority, and then reclaim the memory area for storing the thread data of the service type with high priority.
S1902, if the memory space of the first program includes a first type memory area and a second type memory area, allocating a part of memory in the first type memory area to the first thread, and allocating a part of memory in the second type memory area to the second thread, where the first type memory area is used for storing data of threads of the first service type, and the second type memory area is used for storing data of threads of the second service type.
The details of determining the service type of the thread by the electronic device 100 and allocating the memory area to the thread can be referred to the embodiment shown in fig. 18, which will not be described herein.
If the memory space of the first program includes the first type memory region and does not include the second type memory region, the electronic device 100 allocates a portion of the memory in the first type memory region to the first thread, and allocates a portion of the memory in the second type memory region to the second thread.
If the memory space of the first program does not include the first type memory region, including the second type memory region, the electronic device 100 allocates a portion of the memory in the second type memory region to the second thread, the memory space of the first program divides the first type memory region, and allocates a portion of the memory in the first type memory region to the first thread.
If the memory space of the first program does not include the first type memory area and does not include the second type memory area, dividing the memory space of the first program into the second type memory area, distributing a part of the memory in the second type memory area to the second thread, dividing the memory space of the first program into the first type memory area, and distributing a part of the memory in the first type memory area to the first thread.
And S1903, when the memory resource is insufficient, executing memory recycling operation on the memory area based on the priority of the service type.
When the electronic device 100 reclaims the memory of the second type memory area and the first type memory area, the memory pages of the memory area may be gradually reclaimed through a memory reclamation algorithm such as LRU. Specifically, reference may be made to the embodiment shown in fig. 5, and details thereof are not repeated here.
The more important the data of the thread of the service type with higher priority is, in the memory reclamation process, the electronic device 100 will firstly reclaim the memory area for storing the thread data of the service type with lower priority, and then reclaim the memory area for storing the thread data of the service type with higher priority. Because the priority of the first service type is higher than that of the second service type, when the memory space of the first program comprises the first type memory area and the second type memory area, firstly recovering the memory of the second type memory area, and after the memory of the second type memory area is recovered, recovering the memory of the first type memory area.
In some examples, electronic device 100 may determine a traffic type of a thread when receiving memory allocation requests for a plurality of threads of a plurality of programs, and allocate a portion of memory of a corresponding memory region to the thread based on the traffic type. When the memory resources are insufficient, the electronic device 100 may reclaim the memory of different memory areas based on the service type and the program priority, as shown in fig. 20:
S2001, the electronic device 100 receives memory allocation requests of a first thread and a second thread of a first program, and a third thread and a fourth thread of the second program, determines that service types of the first thread and the third thread are first service types, service types of the second thread and the fourth thread are second service types, and priority of the first service types is higher than that of the second service types.
S2002, if the memory space of the first program comprises a first type memory area and a second type memory area, the memory space of the second program comprises the first type memory area and the second type memory area, the memory in the first type memory area of the first program is allocated to the first thread, the memory in the second type memory area of the first program is allocated to the second thread, the memory in the first type memory area of the second program is allocated to the third thread, and the memory in the second type memory area of the second program is allocated to the fourth thread, wherein the first type memory area is used for storing data of threads of the first service type, and the second type memory area is used for storing data of threads of the second service type.
The details of determining the service type of the thread by the electronic device 100 and allocating the memory area to the thread can be referred to the embodiment shown in fig. 18, which will not be described herein.
It should be noted that, if the memory space of the first program includes the first type memory area and does not include the second type memory area, the electronic device 100 allocates a portion of the memory in the first type memory area to the first thread, and allocates a portion of the memory in the second type memory area to the second thread. If the memory space of the first program does not include the first type memory region, including the second type memory region, the electronic device 100 allocates a portion of the memory in the second type memory region to the second thread, the memory space of the first program divides the first type memory region, and allocates a portion of the memory in the first type memory region to the first thread. If the memory space of the first program does not include the first type memory area and does not include the second type memory area, dividing the memory space of the first program into the second type memory area, distributing a part of the memory in the second type memory area to the second thread, dividing the memory space of the first program into the first type memory area, and distributing a part of the memory in the first type memory area to the first thread. Similarly, the description of whether the memory space of the second program includes the first type memory area and/or the second type memory area may be referred to the above embodiments, and will not be repeated here.
And S2003, when the memory resource is insufficient, executing memory recycling operation on the memory area based on the priority of the service type and the priority of the program.
When the electronic device 100 reclaims the memory of the second type memory area and the first type memory area, the memory pages of the memory area may be gradually reclaimed through a memory reclamation algorithm such as LRU. Specifically, reference may be made to the embodiment shown in fig. 5, and details thereof are not repeated here.
For example, if the priority of the second program is lower than the priority of the first program. When the memory space of the first program includes the first type memory area and the second type memory area, and the memory space of the second program includes the first type memory area and the second type memory area, the memory is recovered according to the order of the second type memory area of the second program, the second type memory area of the first program, the first type memory area of the second program, and the first type memory area of the first program, which can be seen in the embodiment shown in fig. 17A, and will not be repeated here. When the memory space of the first program comprises a first type memory area and the memory space of the second program comprises a first type memory area and a second type memory area, the memory is recovered according to the sequence of the second type memory area of the second program, the first type memory area of the second program and the first type memory area of the first program. When the memory space of the first program includes the second type memory area and the memory space of the second program includes the first type memory area, the memory is recovered according to the order of the second type memory area of the first program and the first type memory area of the second program, and so on.
In one possible implementation, the electronic device 100 is provided with M service types, and the electronic device 100 may divide M memory areas in the memory, where each memory area is used to store data of all threads of one service type. When the electronic device 100 receives a memory allocation request of a thread, a service type of the thread may be determined, and a portion of memory in a memory area corresponding to the service type may be allocated to the thread. When the memory resources are insufficient, the electronic device 100 may sequentially recover the memories of the corresponding memory areas based on the priority order of the M service types. The priority of the M service types may be set, as shown in fig. 10A. It should be noted that, one memory area may store data of threads of the same service type of all application programs.
In some embodiments, the electronic device 100 may reassign the memory region upon receiving a memory allocation request for a thread. That is, when the electronic device 100 receives a memory allocation request of a thread, the traffic type of the thread is first determined. If the memory comprises a memory area corresponding to the service type of the thread, the memory of the memory area is distributed to the thread. If the memory does not comprise the memory area corresponding to the service type of the thread, firstly dividing a memory area for storing data of all threads of the service type of the thread in the memory, and then distributing the memory of the memory area to the threads.
In some embodiments, the electronic device 100 may allocate M memory areas for the application running in the foreground and also allocate M memory areas for the application running in the background. The memory recovery of the application program running in the foreground and the memory recovery of the application program running in the background are not interfered with each other. The electronic device 100 may preferentially reclaim the memory of the application running in the background.
The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims (14)

1. A memory management method is applied to electronic equipment, and is characterized in that,
the electronic equipment is distributed with memory areas with multiple service types, and the memory areas with the multiple service types at least comprise a memory area with a first service type and a memory area with a second service type;
The memory area of the first service type is used for storing data of threads with the service type being the first service type, and the memory area of the second service type is used for storing data of threads with the service type being the second service type;
the priority of the second service type is lower than the priority of the first service type;
the method comprises the following steps:
when memory recovery is carried out, firstly recovering the memory of the memory area of the second service type according to the high-low sequence of the service type priority corresponding to the memory area;
and after the memory of the memory area of the second service type is recovered, recovering the memory of the memory area of the first service type.
2. The method according to claim 1, wherein the method further comprises:
receiving a memory allocation request of a first thread of a first program;
and based on the service type of the first thread, allocating the memory of a memory area of a first service type to the first thread, wherein the memory area of the first service type is in a memory space of the first program, the memory area of the first service type is used for storing data of the thread with the service type of the first program being the first service type, and the service type of the first thread is the first service type.
3. The method according to claim 1, wherein the method further comprises:
receiving a memory allocation request of a first thread of a first program;
dividing a memory area of the first service type in a memory space of the first program under the condition that the memory space of the first program does not comprise the memory area of the first service type based on the service type of the first thread;
and distributing the memory of the memory area of the first service type to the first thread.
4. The method of claim 3, wherein when the memory space of the first program divides the memory area of the first service type, the method further comprises:
and marking the memory area of the first service type by using the first service type.
5. The method according to any one of claims 1-4, wherein the first service type and the second service type are any one of a non-critical service type, a display service type, an interactive service type, a heap service type, and a push service type;
the priority of the service types is from low to high in sequence: non-key service types, display service types, interactive service types, heap service types, push service types.
6. The method according to any one of claims 1-4, wherein the first service type and the second service type are any one of a non-critical service type, a display service type, an interactive service type, a heap service type, and a push service type;
if the first program is an application program running in the foreground, the priority of the service types is sequentially from low to high: non-key service types, heap service types, push service types, display service types, and interactive service types;
if the first program is an application program running in the background, the priority of the service types is sequentially from low to high: non-key service types, display service types, interactive service types, heap service types, push service types.
7. The method according to any one of claims 1 to 6, wherein,
in case the memory space of the first program comprises a memory area of the first service type and a memory area of the second service type, the memory space of the second program also comprises a memory area of the first service type and a memory area of the second service type,
after the recovering of the memory area of the second service type, recovering the memory of the memory area of the first service type specifically includes:
And after the memory of the memory area of the second service type of the first program and the memory of the memory area of the second service type of the second program are recovered, recovering the memory of the memory area of the first service type of the first program and the memory of the memory area of the first service type of the second program.
8. The method according to any one of claims 1 to 7, wherein,
in case the memory space of the first program comprises a memory area of the first traffic type, the memory space of the second program also comprises a memory area of the first traffic type, and the priority of the second program is lower than the priority of the first program,
the recovering the memory of the memory area of the first service type specifically includes:
firstly, recovering the memory of the memory area of the first service type of the second program;
and after the memory of the memory area of the first service type of the second program is recovered, recovering the memory of the memory area of the first service type of the first program.
9. The method of claim 8, wherein prior to said reclaiming memory of said first traffic type memory region of said second program, said method further comprises:
The priorities of the second program and the first program are determined based on the frequency of use of the second program and the first program, and the frequency of use of the second program is lower than the frequency of use of the first program.
10. The method of any of claims 1-9, wherein memory of the memory region of the first traffic type is reclaimed based on a least recently used LRU algorithm.
11. The method according to any one of claims 1-10, further comprising:
before a memory of a memory area of a first service type is allocated to a first thread based on the service type of the first thread, the service type of the first thread is determined based on an identification and/or an application scenario of the first thread.
12. A memory management method applied to an electronic device, comprising:
receiving a memory allocation request of a first thread of a first program;
based on the service type of the first thread, memory of a first type memory area is allocated to the first thread, wherein the first type memory area is used for storing data of a thread with a service type of a first type, and the service type of the first thread is the first service type;
When memory recovery is carried out, based on the priority of the service types, the memories of the memory areas corresponding to different service types are sequentially recovered; the memory areas corresponding to different service types comprise the first type of memory areas.
13. An electronic device, comprising: one or more processors, one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories for storing computer program code comprising computer instructions that, when executed by the one or more processors, cause the electronic device to perform the method of any of claims 1-11.
14. A computer readable storage medium comprising instructions which, when run on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 11.
CN202210592530.4A 2022-05-28 2022-05-28 Memory management method and related device Pending CN117170856A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210592530.4A CN117170856A (en) 2022-05-28 2022-05-28 Memory management method and related device
PCT/CN2023/096330 WO2023231900A1 (en) 2022-05-28 2023-05-25 Memory management method and related apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210592530.4A CN117170856A (en) 2022-05-28 2022-05-28 Memory management method and related device

Publications (1)

Publication Number Publication Date
CN117170856A true CN117170856A (en) 2023-12-05

Family

ID=88945596

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210592530.4A Pending CN117170856A (en) 2022-05-28 2022-05-28 Memory management method and related device

Country Status (2)

Country Link
CN (1) CN117170856A (en)
WO (1) WO2023231900A1 (en)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11144318B2 (en) * 2019-08-26 2021-10-12 Arm Limited Method and apparatus for application thread prioritization
CN111831441A (en) * 2020-07-01 2020-10-27 Oppo广东移动通信有限公司 Memory recovery method and device, storage medium and electronic equipment
CN111831440A (en) * 2020-07-01 2020-10-27 Oppo广东移动通信有限公司 Memory recovery method and device, storage medium and electronic equipment

Also Published As

Publication number Publication date
WO2023231900A1 (en) 2023-12-07

Similar Documents

Publication Publication Date Title
CN116244067B (en) Virtual memory management method and electronic equipment
CN114443277A (en) Memory management method and device, electronic equipment and computer readable storage medium
CN112817736B (en) Memory management method and electronic equipment
EP4209906A1 (en) Memory management method, electronic device, and computer-readable storage medium
CN113553130A (en) Method for executing drawing operation by application and electronic equipment
CN114461375B (en) Memory resource management method and electronic equipment
CN117130541B (en) Storage space configuration method and related equipment
CN115729684B (en) Input/output request processing method and electronic equipment
CN114461589B (en) Method for reading compressed file, file system and electronic equipment
WO2023231900A1 (en) Memory management method and related apparatus
CN112783418B (en) Method for storing application program data and mobile terminal
CN114489471A (en) Input and output processing method and electronic equipment
CN114443109A (en) Patch repair method, electronic device, and storage medium
CN116627855B (en) Memory processing method and related device
CN116795476B (en) Wallpaper deleting method and electronic equipment
CN113704209B (en) Data sharing method, electronic device and storage medium
WO2022143891A1 (en) Focal point synchronization method and electronic device
WO2024045841A1 (en) Storage method and apparatus, and electronic device
WO2024007944A1 (en) Method for extending memory isolation domain, and electronic device
CN116860429A (en) Memory management method and electronic equipment
CN117687770A (en) Memory application method and related device
CN116719633A (en) Method for managing memory exchange partition and electronic equipment
CN114816028A (en) Screen refreshing method, electronic device and computer-readable storage medium
CN116841455A (en) Data storage method, system, host equipment and storage equipment
CN116841761A (en) Equipment cooperation method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination