Method for memory management and electronic device

Abstract

Embodiments of the present application provide a memory management method and electronic equipment, and belong to the technical field of storage. The method comprises the following steps: starting an application program, and providing virtual memory for the application program; detecting the space of the virtual memory occupied by the application program during running; when the space of the virtual memory occupied by the application program is greater than a first threshold, detecting the bit number of the process of the application program; and performing a process killing operation on the application program according to the bit number of the process of the application program. The above method solves the problem of memory leakage by killing specific application programs according to the occupation of virtual memory and multi-dimensional information when memory exceptions occur in running application programs, and according to a preset strategy.

Description

[0001] This application is a divisional application. The original application has the application number 202110669220.3 and the filing date is June 16, 2021. The entire contents of the original application are incorporated herein by reference. Technical Field

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

[0003] A memory leak refers to the phenomenon where unused memory is not released due to errors in the application's (app's) runtime logic, or due to poor application performance, leading to a continuous accumulation of occupied memory. Currently, memory leaks remain a major pain point in the software industry. Improper use of resources, objects, images, threads, files, and displays can all potentially cause memory leaks.

[0004] If a memory leak occurs during application runtime, the allocated memory will remain occupied and cannot be released for reuse. Since the system's memory resources are limited, each subsequent dynamic memory request by the application will reduce the system's memory resources, ultimately affecting the normal operation of the business.

[0005] Therefore, how to alleviate memory leaks, optimize the memory performance of electronic devices, and improve the user experience has become an important research topic. Summary of the Invention

[0006] This application provides a memory management method and electronic device, which solves the memory leak problem by combining multi-dimensional information with the virtual memory usage when a running application experiences a memory anomaly, and then killing specific applications according to a preset strategy.

[0007] In a first aspect, a memory management method is provided, applied to an electronic device, comprising: launching an application and providing virtual memory to the application; detecting the space of the virtual memory occupied by the application during its operation; when the space of the occupied virtual memory is greater than a first threshold, detecting the number of bits of the process running the application; and performing a process-killing operation on the application according to the number of bits of the process running the application.

[0008] The bitness of the target process can indicate how many bits the application is running as, such as a 32-bit process or a 64-bit process. Performing process killing on an application can also be described below as detecting and eliminating the application.

[0009] In one implementation, since applications with different bit widths can support different maximum virtual memory (e.g., a 32-bit application can support a maximum of 4GB of virtual memory), the first threshold can be determined based on the bit width of the process running the application. For example, for an application running a 32-bit process, the first threshold can be set to 3.2GB or 3.5GB. In other words, there can be a corresponding relationship between the first threshold and the bit width of the process running the application.

[0010] According to the method provided in this implementation, a threshold for the virtual memory space that an application can occupy can be set. During the application's operation, if the virtual memory space occupied by the application is detected to be greater than the threshold, the bitness of the process can be further determined. Combined with the bitness information of the process, it can be determined whether the application is causing a memory leak. If so, the application can be killed, thereby accurately handling applications with abnormal memory usage and effectively managing memory resources.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the step of performing a process-killing operation on the application based on the number of bits of the process running the application specifically includes: when it is determined that the process running the application is a target process based on the number of bits of the process running the application, performing a process-killing operation on the application.

[0012] It should be understood that the target process here may include the process corresponding to the first threshold. For example, if the first threshold is based on the maximum virtual memory setting supported by a 32-bit application, then the target process may be a 32-bit process. Alternatively, the target process may also refer to a process that does not correspond to the first threshold but meets the detection conditions of other applications, such as a process whose virtual memory usage reaches a preset threshold.

[0013] According to the method provided in this implementation, when the application running is determined to be the target process based on the bitness of the application's running process, the application is killed. This can accurately handle applications with abnormal memory usage, effectively manage memory resources, and avoid the problem of directly killing applications interfering with the user's use of the application, resulting in a poor user experience.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, the step of performing a process-killing operation on the application when the process running the application is determined to be the target process based on the bitness of the process running the application specifically includes: performing a process-killing operation on the application when the process running the application is determined to be a 32-bit process based on the bitness of the process running the application.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, when the application is running in the background, the method further includes: when it is determined that the application is running a 32-bit process based on the number of processes running the application, detecting the duration of the application running in the background; when the duration of the application running in the background exceeds a preset duration, performing a process-killing operation on the application.

[0016] It should be understood that in some cases, if an application switches to the background running state for a short period of time, it may mean that the user is temporarily not using the application. Therefore, in order to avoid directly killing applications that the user has temporarily switched to the background but still needs to use later, this implementation further judges the duration of the application in the background running state. Only when the duration exceeds the preset duration will the application be killed.

[0017] According to the method provided in this implementation, when the number of running processes of an application meets the target process requirement, the duration of the application's background running state can be further determined. Only when the duration of its background running state exceeds a preset duration will the application be killed. By further combining the duration of the application's background running state to determine whether to kill the application, the problem of interfering with the user's use of the application and thus degrading the user experience can be avoided.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, the step of performing a process-killing operation on the application when the application has been in the background running state for a longer than a preset duration further includes: detecting the type of the application when the application has been in the background running state for a longer than the preset duration; and performing a process-killing operation on the application when the type of the application meets a preset type.

[0019] It should be understood that applications meeting the preset type refer to applications that can be detected and killed when a memory leak occurs, provided that the target process is specified. For example, applications meeting the preset type may include those that significantly impact user experience or are important to the user.

[0020] In some implementations, users can independently set a specific application as an application that can be detected and removed; or the system can default to a specific application as a preset type of application; or the system can determine whether an application is a preset type of application by querying the user.

[0021] According to the method provided in this implementation, for applications running in the background, the decision to kill them can be made by combining the application's running process, the duration of its background running state, and the application type. In other words, after determining that the application is a target 32-bit process and has been running in the background for more than a preset duration, it can be further determined whether the application's type belongs to a preset type. If so, it indicates that the application needs to be killed, and the process of the application is killed. By detecting whether applications running 32-bit processes belong to a preset type of application and killing applications that meet the preset type, the direct killing of applications that are important to the user can be avoided, thus avoiding impacting the user experience.

[0022] In conjunction with the first aspect, in some implementations of the first aspect, the application of the preset type includes at least one of the following: the application of the communication type, the application of the tool type, the application of the shopping type, the application of the news type, and the application of the news type.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, when the application is in a foreground running state, the method further includes: detecting the remaining space of the system physical memory; when the remaining space of the system physical memory is less than a second threshold, detecting the space of the virtual memory occupied by the application during its operation.

[0024] It should be understood that, generally speaking, applications running in the foreground may be applications that users are currently using. Directly killing them would interfere with the user's normal use. Therefore, for applications running in the foreground, the remaining space of the system's physical memory can be further detected. Only when the remaining space is less than a second threshold will the detection operation on the virtual memory occupied by the application be performed.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, when it is determined that the process corresponding to the application is a non-32-bit process, the physical memory space occupied by the application during its operation is detected; when the occupied physical memory space is greater than a third threshold, the process is killed for the application.

[0026] According to the method provided in this implementation, by further determining the physical memory space occupied by applications whose running processes are not 32-bit processes, it is possible to more accurately determine whether the application needs to be killed, thereby avoiding the decline in user experience caused by directly killing the application.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, detecting the virtual memory space occupied by the application during its operation further includes: detecting whether a triggering event occurs during the operation of the application; and when it is determined that the triggering event has occurred, detecting the virtual memory space occupied by the application during its operation.

[0028] In conjunction with the first aspect, in some implementations of the first aspect, detecting the virtual memory space occupied by the application during operation when the triggering event is determined to occur specifically includes: detecting the virtual memory space occupied by the application during operation when it is determined that the free system memory space in the electronic device is less than a fourth threshold; or, detecting the virtual memory space occupied by the application during operation when a preset period is determined to be met; or, detecting the virtual memory space occupied by the application during operation when it is determined that the rate at which the application requests the virtual memory is greater than a fifth threshold.

[0029] It should be understood that, regardless of whether the application is running in the background or in the foreground, the electronic device can perform the detection of the virtual memory used by these applications under the trigger of a triggering event. That is, the electronic device will only perform the detection of the virtual memory used by the running application and the subsequent process killing operation when a triggering event occurs.

[0030] In a second aspect, an electronic device is provided, comprising: one or more processors; one or more memories; said one or more memories storing one or more computer programs, said one or more computer programs including instructions that, when executed by said one or more processors, cause the electronic device to implement the memory management method as described in any implementation of the first aspect.

[0031] Thirdly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, the computer program including instructions that, when invoked by a computer, cause the computer to perform a memory management method as described in any implementation of the first aspect.

[0032] Fourthly, a chip system is provided, comprising: a communication interface for inputting and / or outputting information; a memory for storing a computer-executable program; and a processor for executing the computer-executable program, causing a device equipped with the chip system to perform a memory management method as described in any implementation of the first aspect.

[0033] Fifthly, a computer program product is provided, the computer program product including computer program instructions, which, when executed on a computer, cause the computer to implement the memory management method as described in any implementation of the first aspect. Attached Figure Description

[0034] Figure 1 This is a schematic flowchart illustrating a memory leak.

[0035] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0036] Figure 3 This is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application.

[0037] Figure 4 This is a schematic flowchart illustrating a memory management method provided in an embodiment of this application.

[0038] Figure 5 This is a schematic diagram of the physical memory occupied by each process in a system, provided in an embodiment of this application.

[0039] Figure 6 This is a schematic flowchart illustrating another memory management method provided in an embodiment of this application.

[0040] Figures 7A to 7D These are some graphical user interface diagrams provided in the embodiments of this application.

[0041] Figure 8 This is a schematic diagram of an application detection and removal prompt message provided in an embodiment of this application.

[0042] Figure 9 This is a schematic flowchart illustrating another memory management method provided in the embodiments of this application. Detailed Implementation

[0043] It should be noted that the terminology used in the implementation section of the embodiments of this application is only used to explain the specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more.

[0044] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0045] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0046] The technical solutions of this application embodiment can be applied to various communication systems. For example: Global System for Mobile Communication (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, LTE Frequency Division Duplex (FDD) system, LTE Time Division Duplex (TDD) system, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication system, future 5th generation (5G) systems, or new radio (NR), etc.

[0047] To better understand the memory leak management method provided in the embodiments of this application, the following section first introduces the definitions of the terms involved in the embodiments of this application.

[0048] (1) Physical memory: Physical memory is relative to virtual memory and refers to the memory space obtained through physical memory modules.

[0049] (2) Virtual memory: A memory management technique in operating systems, it is an abstraction of memory provided by the operating system. Virtual memory is not limited by physical memory space. From the perspective of the application process, the application process has a contiguous and available virtual memory space (a contiguous and complete address space). However, in reality, this virtual memory space is usually mapped to a non-contiguous address space in physical memory.

[0050] (3) System memory: including physical memory and virtual memory, its main function is to provide temporary storage for the operating system and various applications when the electronic device is running.

[0051] (4) Dynamic memory allocation function: can be used to dynamically allocate memory in the system. The size of the memory to be allocated can be specified according to the value of the allocation parameter of the function. This function can return the starting address (or memory address) of the allocated memory.

[0052] (5) Memory release function: can be used to release memory allocated by dynamic memory allocation function.

[0053] (6) Low memory killer (LMK): for Android The kernel layer has a mechanism for managing low memory by killing processes and releasing memory according to certain strategies. When the system has low memory, it will trigger the killing of some background processes and other low-priority processes.

[0054] (7) Running State: The running state of an application in the operating system can be divided into foreground running state and background running state. Foreground running state refers to the application running directly on the display window or interface of the screen, presenting the current interface of the program, allowing the electronic device to interact with the user (i.e., the user) through the displayed interface. Background running state refers to the application not displaying its running interface on the screen, but the application continues to provide services in the background. For applications with a visible display interface, they can switch from background running state to foreground running state, or vice versa, at any time.

[0055] Based on the background information, when continuous memory leaks lead to insufficient remaining system memory, the virtual machine will frequently trigger garbage collection (GC). This can cause issues such as sudden lag, slow response, display abnormalities, or even application crashes during user interaction with mobile devices, severely impacting the user experience. To better understand the memory management method provided in this application, the following example, using a 32-bit video application to watch videos, will illustrate the principle behind memory leaks.

[0056] It should be understood that an application can correspond to a process, and a process can include one or more threads. When a video application is launched, the system creates a 32-bit process for it. During the process's execution, the system also allocates a maximum of 4GB (2 to the power of 32) of virtual memory according to the process's request. The reason for 4GB is that in a 32-bit operating system, a pointer is 4 bytes long, and the addressing capability of a 4-byte pointer is from 0x00000000 to 0xFFFFFFFF, with the maximum value 0xFFFFFFFF representing a 4GB virtual memory space. There is a mapping relationship between this virtual memory address space and physical memory addresses. When the operating system performs virtual address to physical address mapping, it maps the physical address to this range. Each process can only access data in its own virtual space and cannot access data outside of this virtual memory.

[0057] For example, such as Figure 1 The diagram shown is a schematic flowchart of a memory leak. Figure 1 This example illustrates the memory allocation process when a drawing object in a video application experiences a memory leak. The process includes the following steps:

[0058] S101, launch the video application.

[0059] S102, the application's drawing object requests a graphics buffer.

[0060] During the startup or operation of a video application, the process needs to request system memory for drawing-type tasks (or threads) to store data (such as bitmap data) for that type of task. Therefore, this step is used to create memory space that can be accessed by the application.

[0061] S103 calls GraphicBufferMapper to map the graphics buffer to the application process.

[0062] In step S102, after obtaining the graphics buffer, the preset function GraphicBufferMapper can be called to lock the graphics buffer and map the locked graphics buffer to the current video application process.

[0063] S104, requesting inter-process shared use of the graphics buffer.

[0064] A drawing object of a video application (which can be used by any thread to perform a drawing-type task) can request the use of a graphics buffer, which can be used to perform at least one of the drawing-type tasks described above.

[0065] S105, memory allocation returned.

[0066] If the virtual memory currently occupied by the drawing task is small (e.g., less than 3.7G), the graphics buffer allocator can successfully return the memory it requested to the drawing object of the video application. Then, step S106 can be executed, that is, the requested graphics buffer can be normally mapped to the virtual memory of the application.

[0067] If a memory leak occurs in the drawing task, causing the virtual memory it occupies to exceed a preset value (such as 3.7GB), the graphics buffer allocator will be unable to return the requested memory to the drawing object of the video application, that is, the memory request will fail. At this time, the drawing object can execute steps S107 to S110 (or step S111) to continue to request system memory through the GraphicBufferAllocator process interface.

[0068] Taking the memory allocation failure in step S105 as an example, the process of continuing to allocate memory is described as follows:

[0069] S107, the drawing object calls the GraphicBufferAllocator process interface to request system memory from the memory manager.

[0070] S108, the GraphicBufferAllocator process interface requests system memory from the memory manager for the video application's drawing objects.

[0071] S109, the memory manager responds to the memory request and returns the requested memory.

[0072] If the memory manager successfully returns memory, the requested graphics buffer can be mapped to the application's virtual memory; if the memory manager fails to return memory, it indicates that the drawing object may be experiencing a memory leak.

[0073] Based on the above process, it should be understood that under normal circumstances, after a thread of a video application finishes running, the memory occupied by that thread is no longer needed and will be released. However, if, for some reason, the heap memory allocated to that thread by the system is not released or is not released in a timely manner (i.e., memory leak), the memory occupied by threads no longer used in the current application cycle cannot be reclaimed and reused. To ensure normal operation, the video application may request more memory in subsequent runs, causing the video application to consume more and more memory and the system's memory resources to decrease. As the video application accumulates more and more memory resources, the virtual machine will frequently trigger the garbage collection mechanism, leading to problems such as application lag and slow response speed. Then, when the virtual memory occupied by the video application accumulates to near its maximum supported virtual memory (4GB), because the process interface (graphicbufferallocator) used to continue requesting system memory is a 64-bit process, the process can still continue to request memory from the memory manager. However, the memory actually allocated to the application by the system can no longer be mapped to virtual memory, and because this memory has already been requested by the application, the system will mark the memory as being used by the application, making it impossible for the memory to be allocated to other applications. Because the application failed to acquire the requested system memory this time, it will repeat the above process to continue requesting system memory. This leads to a decrease in the actual available memory space in the system, resulting in a memory leak. Continued memory leaks may eventually exhaust the entire system's memory, causing the system to freeze.

[0074] In summary, memory leaks not only affect the normal operation of applications, but may also cause system and application crashes. In severe cases, users may need to force restart their electronic devices to restore normal use, resulting in a poor user experience.

[0075] To address memory leaks, the current approach typically involves the following: When electronic devices optimize memory, a process-killing (or process-reclaiming) mechanism is triggered whenever the available system memory falls below a certain threshold. Due to priority limitations, this mechanism usually targets background processes for killing. Taking Android as an example, the memory-reclaiming mechanism in Android is the low memory killer (LMK) mechanism. The LMK mechanism primarily uses `oom_adj` to determine the importance of a process. The smaller the `oom_adj` value, the more important the program and the lower the likelihood of it being killed. Background applications have a positive `oom_adj` value, while foreground applications have a `oom_adj` value of 0. Therefore, when Android triggers the LMK mechanism due to low system memory, it prioritizes killing background processes and typically does not kill foreground processes.

[0076] However, current memory reclamation methods that directly kill a background program do not consider the user experience of the application in the specific application scenario. For example, if a user needs to handle other matters while watching a video and temporarily switches to another application, directly killing the background video application will prevent the user from directly switching back to the previous video playback page when they want to watch the video again, resulting in a poor user experience. Furthermore, if the foreground application is the main source of memory leaks, simply killing the background application process cannot fundamentally solve the memory leak problem, and ultimately, system and application crashes will still occur.

[0077] To address the aforementioned problems in the existing technology, this application provides a memory management method. By determining whether a memory leak has occurred based on the virtual memory space occupied by an application, and combining this with multi-dimensional information such as the application's running status, the method targets and eliminates certain applications according to a preset strategy. This allows for flexible application elimination based on user needs, thereby improving the user experience.

[0078] The memory management method provided in this application can be applied to various types of electronic devices, such as mobile phones, wearable devices (e.g., smartwatches, smart bracelets, smart glasses, smart jewelry), tablets, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), smart TVs, smart screens, and other electronic devices with display screens. These electronic devices can also be other electronic devices, such as laptops with touch-sensitive surfaces (e.g., touch panels). This application does not limit the specific type of electronic device.

[0079] For example, such as Figure 2 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application.

[0080] like Figure 2As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer 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, etc.

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

[0082] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

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

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

[0085] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0086] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0087] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0088] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0089] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0090] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0091] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

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

[0093] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0094] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the terminal via the power management module 141.

[0095] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery space, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

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

[0097] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0098] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0099] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates 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. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0100] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0101] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc.

[0102] Electronic device 100 implements display functions through a GPU, display screen 194, and application processor. Display screen 194 is used to display images, videos, etc.

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

[0104] Digital signal processors (DSPs) are used to process digital signals, including digital image signals and other digital signals. For example, when electronic device 100 selects a frequency, the DSP performs Fourier transforms on the frequency energy. Video codecs are used to compress or decompress digital video. NPUs (Neural Processing Units) are neural network (NN) computing processors that, by borrowing from the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, rapidly process input information and can continuously learn on its own.

[0105] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card. The internal memory 121 can be used to store computer executable program code, which includes instructions.

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

[0107] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. Gyroscope sensor 180B can be used to determine the motion posture of electronic device 100. Magnetic sensor 180D includes a Hall sensor. Electronic device 100 can use magnetic sensor 180D to detect the opening and closing of the flip cover. Accelerometer sensor 180E can detect the magnitude of acceleration of electronic device 100 in various directions (generally three axes). When electronic device 100 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the terminal posture, applied to screen orientation switching, pedometers, and other applications. Proximity sensor 180G can include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. The LED can be an infrared LED. Electronic device 100 emits infrared light outward through the LED. Ambient light sensor 180L is used to sense ambient light brightness. Electronic device 100 can adaptively adjust the brightness of display screen 194 according to the sensed ambient light brightness. Fingerprint sensor 180H is used to collect fingerprints. Temperature sensor 180J is used to detect temperature. The touch sensor 180K, also known as the "touch panel," can be located on the display screen 194. The touch sensor 180K and the display screen 194 together form a touchscreen, also called a "touch screen." The touch sensor 180K detects touch operations applied to or near it. The bone conduction sensor 180M can acquire vibration signals.

[0108] In addition, the electronic device 100 also includes a barometric pressure sensor 180C and a distance sensor 180F. The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.

[0109] A distance sensor 180F is used to measure distance. Electronic device 100 can measure distance via infrared or laser. In some embodiments, during a shooting scene, electronic device 100 can utilize the distance sensor 180F to measure distance for rapid focusing.

[0110] For example, such as Figure 3 The diagram shown is a schematic representation of the software structure of an electronic device 100 provided in an embodiment of this application.

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

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

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

[0114] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes predefined functions such as dynamic memory allocation functions and memory deallocation functions.

[0115] like Figure 3 As shown, the Android application framework is divided into the application layer, application framework layer, system runtime library layer, and Linux kernel layer. The application framework layer includes the window manager, content provider, view system, phone manager, resource manager, and notification manager.

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

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

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

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

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

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

[0122] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0123] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

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

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

[0126] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

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

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

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

[0130] For example, in an embodiment of this application, a 2D graphics engine can be used to draw geofences for vehicles.

[0131] The Linux kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, and sensor drivers. In this embodiment, memory anomaly analysis modules, memory management modules, and memory allocation modules can be located within the Linux kernel layer.

[0132] For example, such as Figure 4 The diagram shown is a schematic flowchart illustrating a memory management method provided in an embodiment of this application. This method can be implemented by, for example... Figure 2 and Figure 3 The electronic device shown is the main body performing the process, which may include the following steps:

[0133] S401, launch the application and provide virtual memory to the application.

[0134] The application may include applications that come with the Android operating system or third-party applications, and this application embodiment does not limit this. For example, the process of an electronic device launching an application may include: the electronic device receiving an operation from a user clicking an application icon and launching the application in response to the click operation; or, the electronic device receiving an operation from a user via a voice assistant instructing the user to open an application and launching the corresponding application in response to the voice instruction. This application embodiment does not limit the specific scenario for an electronic device launching an application.

[0135] In some embodiments, during process startup, an application may request virtual memory from the operating system; in response to the application's request, the operating system may provide virtual memory to the application. Specifically, this process may include: the application requesting virtual memory from the operating system by calling a dynamic memory allocation function through the memory allocator in the electronic device; in response to the application's request, the operating system providing the corresponding virtual memory space to the application through the memory allocator of the electronic device.

[0136] It should be understood that the virtual memory available to a 32-bit process application is no more than 4GB, and therefore, under normal circumstances (i.e., without memory leaks), the virtual memory requested by the application should not exceed 4GB.

[0137] S402, detects the virtual memory space occupied by the application during its operation.

[0138] In some embodiments, an electronic device may perform an operation to detect the virtual memory space occupied by an application when preset conditions are met (hereinafter referred to as virtual memory detection). The preset conditions may be divided into a first preset condition and a second preset condition. The first preset condition may be a basic or simple condition that triggers the virtual memory detection of the electronic device, such as (1) the system memory is in a low memory state; (2) a preset detection cycle is reached, etc. The second preset condition may be an advanced or complex condition that triggers the virtual memory detection of the electronic device, such as (1) the remaining physical memory space of the electronic device is less than a second threshold, such as 200M or 300M; (2) the remaining physical memory space in the electronic device reaches a preset level; (3) the rate at which the application requests virtual memory is greater than a third threshold.

[0139] Considering that applications in different running states may have varying degrees of importance to users in practical applications, a first preset condition and / or a second preset condition can be set as the trigger conditions for virtual memory detection for applications in different running states. For example, an application running in the background (hereinafter referred to as a background application) may be an application that the user has finished using or does not currently need to use, and its importance to the user is relatively low. Therefore, the first preset condition can be used as the preset condition to trigger the electronic device to perform virtual memory detection on background applications. Specifically, when the system memory is in a low memory state, the electronic device can be triggered to perform virtual memory detection; or, when a preset detection cycle is reached, the electronic device can be triggered to perform virtual memory detection, that is, the electronic device will detect the virtual memory space occupied by the application once every certain period of time.

[0140] For example, an application running in the foreground (hereinafter referred to as a foreground application) may be an application that the user is currently using and is of high importance to the user. Therefore, the first preset condition and the second preset condition can be used together as preset conditions for detecting the virtual memory occupied by the foreground application. That is, the electronic device can sequentially check whether the first preset condition and the second preset condition are met. If both are met, the electronic device can be triggered to perform virtual memory detection on the foreground application. For example, taking the above-listed second preset conditions as examples, the process of triggering virtual memory detection on the foreground application can include the following scenarios:

[0141] In scenario one, after any of the first preset conditions are met, the electronic device can further detect the remaining physical memory space. When the remaining physical memory space is less than a second threshold, the electronic device can trigger a virtual memory check on the foreground application. The second threshold can be set to, for example, 200MB or 300MB; this application does not limit this setting. The process of the electronic device detecting whether the remaining physical memory is less than the preset threshold may include: the electronic device calling the activitymanager.getmemoryInfo interface through the memory anomaly analysis module to obtain the system's current remaining physical memory, and then comparing whether the remaining physical memory is less than the preset threshold.

[0142] In scenario two, once any of the first preset conditions are met, the electronic device can further detect the remaining physical memory space. When the remaining physical memory space in the electronic device reaches a preset level, the electronic device can be triggered to perform virtual memory detection on the foreground application.

[0143] The preset kill level here can be a process kill level preset based on the remaining system memory (such as physical memory) of the electronic device. For example, Table 1 shows the correspondence between the remaining physical memory space and its corresponding process kill level.

[0144] Table 1

[0145] Less than or equal to 100M Level 1 Greater than 100M and less than or equal to 150M Level 2 Greater than 150M and less than or equal to 200M Level 3

[0146] It should be understood that the different process killing levels in Table 1 above can correspond to different detection and killing conditions, which may include the following situations:

[0147] 1. When the process killing level is Level 1 (remaining physical memory is less than or equal to 100M), the corresponding process killing process can be as follows: After determining that the virtual memory space occupied by the application is greater than the first threshold, the electronic device detects the bitness of the process running the application. If the bitness of the running process meets the target bitness, the process killing operation is directly performed on the application to release the system memory occupied by the application.

[0148] 2. When the process killing level is the second level (the remaining physical memory is greater than 100M and less than or equal to 150M), the corresponding process killing process can be as follows: After determining that the virtual memory space occupied by the application is greater than the first threshold and the bitness of the running process meets the target bitness, further check whether the application type matches the killing type. If it matches, the process killing operation can be performed on the application to release the system memory occupied by the application.

[0149] 3. When the process killing level is level three (remaining physical memory is greater than 150M and less than or equal to 200M), the corresponding process killing process can be as follows: After determining that the virtual memory space occupied by the application is greater than the first threshold, the bitness of the running process meets the target bitness, and the type of the application matches the killing type, further determine whether the physical memory occupied by the application is greater than the preset threshold. If all conditions are met, the process killing operation can be performed on the application to release the system memory occupied by the application.

[0150] It should be understood that in this second scenario, if the remaining physical memory of the electronic device meets a certain process-killing level, a virtual memory check of the foreground application can be triggered. If a memory anomaly is found, the application can then be killed according to the killing criteria corresponding to that process-killing level. The less physical memory remaining, the simpler the corresponding killing detection can be, thus enabling efficient application killing and memory optimization.

[0151] It should also be understood that the above-described process killing procedures for different process killing levels are merely examples. In actual applications, different process killing procedures can be set for different process killing levels, or different detection items can be set before killing the process. This application embodiment does not limit this.

[0152] Scenario 3: When any of the first preset conditions are met, the electronic device can detect the rate at which the application requests virtual memory. When the rate at which the application requests virtual memory exceeds the third threshold, the electronic device can be triggered to perform virtual memory detection on the foreground application.

[0153] The process of an electronic device detecting the rate at which an application requests virtual memory can include: the electronic device can set a polling interval (e.g., every 2 minutes) to detect the virtual memory occupied by the application process PID; then, according to the polling interval, it periodically queries the VmSize (virtual memory) field of the / proc / pid / status file to find the size of the virtual memory occupied by the process PID, and returns the virtual memory sizes Vm1 and Vm2 corresponding to two time points t1 and t2 respectively through the process interface intgetProcessVssMemoryInfo; then, the memory anomaly analysis module can calculate the average rate v of the process PID requesting virtual memory during the time period t1 to t2 according to formula (1-1) based on the time points and the corresponding virtual memory sizes.

[0154]

[0155] It should be understood that the second preset condition listed above for foreground applications is merely an example. In practical applications, other conditions can also be used as triggers for the electronic device to perform memory detection on the foreground application. For example, in another implementation, when any of the first preset conditions is met, the electronic device can also detect the rate at which the application requests physical memory. If the rate at which physical memory is requested exceeds a preset threshold, the electronic device can be triggered to perform virtual memory detection on the foreground application. Similar to the description of scenario three above, in this implementation, the process by which the electronic device obtains the rate at which the application requests physical memory can include: the electronic device sets a polling time (e.g., 2 minutes per polling) for detecting the physical memory occupied by the application process pid through a timer; then, it can periodically query the size of the physical memory occupied by the process pid (physical memory) in the / proc / pid / status file according to the polling time (e.g., the physical memory occupied by each process in the system is as follows). Figure 5 As shown), and through the process interface intgetProcessRssMemoryInfo, it returns the physical memory usage sizes Vm3 and Vm4 corresponding to two time points t3 and t4, respectively; then, the memory anomaly analysis module can calculate the average rate of physical memory requested by process pid during the time period from t3 to t4 according to formula (1-2) based on the time points and their corresponding virtual memory usage sizes:

[0156]

[0157] In some embodiments, the process by which an electronic device detects the virtual memory space occupied by an application may include: when preset conditions are met, the electronic device can query the size of the virtual memory occupied by the process pid (virtual memory) of the application running through the VmSize (virtual memory) field of the / proc / pid / status file via a memory anomaly analysis module.

[0158] S403, when the space occupied by the virtual memory is greater than the first threshold, the bitness of the process running the application is detected.

[0159] In some embodiments, there is a correspondence between the first threshold and the bitness of the process running the application, the first threshold being set based on the maximum virtual memory supported by the process of the target bitness. For example, for a 32-bit process, since its maximum supported virtual memory is 4GB, the first threshold can be set to a value close to 4GB, such as 3.2GB or 3.5GB.

[0160] It should be understood that if the virtual memory usage exceeds the first threshold, it means the application may have a memory leak. However, it could also include other bit-based processes using memory normally. For example, if an application uses more than 3.5GB of virtual memory, and the application is 64-bit, then its memory usage is normal and there may not be a memory leak. Therefore, to accurately determine whether an application has a memory leak, it is possible to further check whether the process running the application is a process of the target bit-based bitness. That is, to determine whether the process running the application corresponds to the preset threshold. If so, it means that the virtual memory usage of the application has reached the corresponding virtual memory usage limit (i.e., the preset threshold), and it can be determined that the application has actually experienced a memory leak.

[0161] For example, taking 32-bit and 64-bit as examples, the process of an electronic device detecting the bitness of an application process can include the following methods: Method 1: The system will fork a child process from zygote to provide the virtual machine and runtime environment for the application. Two zygote processes will exist simultaneously in the system: zygote corresponding to a 32-bit process and zygote64 corresponding to a 64-bit process. By passing the pid to the intcheckProcessType(intpid) interface, the returned process type can be obtained, such as 10: 32-bit or 1: 64-bit, thus determining whether the current application is a 32-bit or 64-bit process. Method 2: At runtime, the memory mapping list (maps) of the native process is used to detect whether the application is a 32-bit or 64-bit process. If the application's native program is mapped to system / lib, then the application is determined to be a 32-bit process. Method 3: The application's lib library path is used to determine whether the application is a 32-bit or 64-bit process. When the application's lib library path is the path corresponding to a 32-bit process such as lib / arm, the application is determined to be a 32-bit process.

[0162] S404, based on the bitness of the process running the application, performs a process-killing operation on the application.

[0163] Killing an application process refers to removing the application's process from system memory, forcibly exiting the process, and thus freeing up system memory, which can then be reallocated by the operating system. Optionally, after freeing up the system memory occupied by the application, the application can also be restarted; this application does not limit this.

[0164] In some embodiments, when the process running the application is determined to be the target process based on the bitness of the process, a process-killing operation can be performed on the application. The target process can be, for example, a 32-bit process.

[0165] In some embodiments, the specific process of an electronic device performing a process killing operation on an application may include: calling the android.os.process.killProcess(android.os.Process.myPid) or forcestoppackage process interface to clear the memory occupied by each thread of the application in the system memory, and the cleared system memory can be used for reallocation by the memory allocation module of the electronic device.

[0166] Alternatively, after killing the application process, the application can be restarted so that it runs normally without memory leaks.

[0167] The memory management method provided in this application's embodiments detects and eliminates specific applications by combining abnormal memory usage of running applications with multi-dimensional information such as the application scenario. This optimizes system memory and improves the user experience while meeting different user needs for applications.

[0168] To better understand the memory management method provided in the embodiments of this application, the process of performing memory management on a background application and the process of performing memory management on a foreground application are described below with reference to the accompanying drawings.

[0169] For example, such as Figure 6 The diagram shown is an exemplary flowchart of memory management for an application running in the background, according to an embodiment of this application. This process can be executed by an electronic device and includes the following steps:

[0170] S601, launch the application and provide virtual memory to the application.

[0171] This step can correspond to step S401, and the relevant description can be found in the above content, which will not be repeated here.

[0172] S602, the application runs in the background.

[0173] In some embodiments, an application (such as a video application) may run in the foreground during startup or for a short period after startup, and then switch to the background after running for a period of time. For example, when a user needs to use other applications or functions on an electronic device, they may switch this application to the background.

[0174] S603, detect whether the virtual memory space occupied is greater than the first threshold.

[0175] In some embodiments, the electronic device may perform virtual memory detection of the application when preset conditions are met. The preset conditions corresponding to the background application may correspond to the first preset conditions described above, and may include, for example, (1) the system memory is in a low memory state; (2) a preset detection period has been reached, etc.

[0176] In some embodiments, when the system memory is in a low memory state, the electronic device can be triggered to perform virtual memory detection; or, when a preset detection period is reached, the electronic device can be triggered to perform virtual memory detection, that is, the electronic device will detect the virtual memory space occupied by the application once every certain period of time.

[0177] In some embodiments, the process by which an electronic device detects the virtual memory space occupied by an application may include: when preset conditions are met, the electronic device can query the size of the virtual memory occupied by the process pid (virtual memory) of the application running through the VmSize (virtual memory) field of the / proc / pid / status file via a memory anomaly analysis module.

[0178] In some embodiments, after obtaining the virtual memory space currently occupied by the background application, it is determined whether the virtual memory space is greater than a first threshold (such as 3.2GB or 3.5GB). If yes, step S604 is executed; if no, step S607 is executed, that is, the application continues to run.

[0179] S604 checks whether the process corresponding to the application is a 32-bit process.

[0180] In some embodiments, when the virtual memory occupied by the application is detected to be greater than a first threshold in step S603, the electronic device can further determine whether the application is a 32-bit process. If yes, then step S605 is executed; if no, then step S607 is executed, that is, the application continues to run.

[0181] In some embodiments, the process by which the memory anomaly analysis module determines whether an application is a 32-bit process may include the following methods: (1) The system will fork a child process from zygote to provide the virtual machine and runtime environment for the application to run; there will be two Zygote processes in the system at the same time, namely zygote corresponding to a 32-bit process and zygote64 corresponding to a 64-bit process. The electronic device can pass pid through the intcheckProcessType(intpid) interface to obtain the returned process type, such as 10: 32-bit or 1: 64-bit, so as to know whether the current application is a 32-bit process; (2) The runtime detects whether the application is a 32-bit process by the memory mapping list (maps) of the native process. If the native program is mapped to system / lib, the application is determined to be a 32-bit process; (3) The application is determined to be a 32-bit process by judging the lib library path of the application. When the path of the application's lib library is the path corresponding to a 32-bit process such as lib / arm, the application is determined to be a 32-bit process.

[0182] S605 determines whether the application type is a preset type.

[0183] It should be understood that in scenarios where applications are running in the background, due to the different types of applications, for some applications, killing them will not have much impact on the user experience, so the process of the application can be killed directly; while in other scenarios, if killing the process of certain background applications will affect the user experience, such as causing adverse effects on the user's life, work, entertainment, etc., then even if the virtual memory occupied by the application exceeds the first threshold, the application can continue to run.

[0184] In some embodiments, the default application type can refer to a background application whose process-killing operation will not affect the user experience. Examples include instant messaging applications, utility applications, shopping applications, news applications, etc. Applications not belonging to this default type may include, for example, running game applications, video or music applications that run in the background mid-play, running navigation applications, etc.

[0185] In some embodiments, whether an application of a certain type belongs to a preset application type can be preset by the user. For example, taking a mobile phone as an example, the process of user setting whether to allow applications to be detected and eliminated is described. Figures 7A to 7DThe diagram shown is a graphical user interface (GUI) diagram illustrating the process of user settings to allow applications to be detected and killed during memory management, as provided in an embodiment of this application.

[0186] like Figure 7A The image shows the current interface displayed on the phone in unlocked mode. This interface includes various applications (Apps), such as clock, calendar, gallery, notes, file manager, email, music, calculator, video, fitness tracker, weather, browser, smart home, settings, voice recorder, camera, contacts, phone, and messages. It should be understood that in some embodiments, this interface may include more than... Figure 7A The embodiments of this application do not limit the number of applications shown, whether more or fewer.

[0187] like Figure 7A As shown, when a user clicks the settings icon, the phone launches the settings application in response to the user's click and displays the following: Figure 7B The interface shown. Among them, Figure 7B The interface is a settings list interface, which may include multiple user-operable options, such as wireless and networks, Bluetooth, desktop and wallpaper, display, sound, application management, battery, storage, phone health, security and privacy, etc. It should be understood that in some embodiments, this interface may include more... Figure 7B Show more or fewer options or with Figure 7B The different types of options are not limited in this application embodiment.

[0188] like Figure 7B As shown, users can click the application management settings option. In response to the user's click, the phone can display the following: Figure 7C The application management interface is shown below. Figure 7C As shown, the application management interface can include various types of applications installed on the phone, such as video applications, shopping applications, news applications (e.g., News Application 1, News Application 2), financial applications, etc. Taking a video application as an example, when a user needs to configure the video application to not allow process termination during memory optimization, the user can click on the video application. In response to the user's click, the phone can display something like... Figure 7D The video application permission management interface shown.

[0189] like Figure 7DAs shown, the video application permission management interface can include multiple settings for permissions related to the video application, such as management of location permissions, access to the photo album permissions, access to the microphone permissions, notification push permissions, application scanning permissions, and network permissions. Users can click the toggle control in the application scanning permission management section to set whether to allow scanning of the video application. Clicking the toggle control to turn on means that scanning of the video application is allowed in the event of a memory error, while clicking the toggle control to turn off means that scanning of the video application is not allowed in the event of a memory error. It should be understood that when scanning of the video application is allowed, the video application is classified as a default application type.

[0190] It should be understood that whether an application of a certain type belongs to a preset application type, i.e., whether it will be detected and killed when the triggering conditions are met, can also be set through a default policy. For example, for a certain type of application, the default setting is the preset type; or, the application type can also be set based on the detection notification information. For example, when a background application meets the detection conditions, the electronic device can ask the user whether they agree to have the background application detected and killed. If the query information is displayed and the user agrees, then the application type is set to the preset type; if the user does not agree, then the application type is set not to the preset type. This application embodiment does not limit the specific method of setting the application type.

[0191] In some embodiments, if the type of the application matches a preset type, step S606 can be executed; if the type of the application matches a second preset type, step S607 can be executed, that is, the application continues to run.

[0192] In some embodiments, to avoid directly killing certain background applications without the user understanding the reason, a prompt message indicating that a certain application is about to be killed can be displayed to the user before the kill. For example, such as... Figure 8 As shown, when it is determined that the type of the news application 1 running in the background matches the preset type, the electronic device needs to perform a process killing operation on the application. Before performing the process killing operation, an application killing prompt message can pop up on the current interface of the electronic device (such as the main interface after the phone is unlocked). The content of the prompt message may be, for example, "The current device system memory is insufficient, and a process killing operation will be performed on the news application 1 running in the background", so that the user can know in advance the reason why the background application is interrupted or forcibly exited.

[0193] S606 performs a process-killing operation on the application.

[0194] In some embodiments, the specific process of an electronic device performing a process killing operation on an application may include: calling the android.os.process.killProcess(android.os.Process.myPid) or forcestoppackage process interface to clear the memory occupied by each thread of the application in the system memory, and the cleared system memory can be used for reallocation by the memory allocation module of the electronic device.

[0195] Alternatively, after killing the application process, the application can be restarted so that it runs normally without memory leaks.

[0196] The memory management method provided in this application's embodiments detects and eliminates specific applications by combining abnormal memory usage of running applications with multi-dimensional information such as the application scenario. This optimizes system memory and improves the user experience while meeting different user needs for applications.

[0197] It should be understood that existing LMK (Memory Management Kit) killing mechanisms kill processes based on adj priority, generally excluding applications running in the foreground. Therefore, if a foreground application experiences a memory leak leading to insufficient system memory, the mechanism cannot effectively resolve the problem. To address this, the memory management method provided in this application can also kill foreground applications. For example, as shown... Figure 9 The diagram shown is an exemplary flowchart of memory management for an application running in the foreground, according to an embodiment of this application. This process can be executed by an electronic device and includes the following steps:

[0198] S901 launches the application and provides virtual memory to the application.

[0199] This step can correspond to step S401, and the relevant description can be found in the above content, which will not be repeated here.

[0200] S902, the event triggers the electronic device to enter process killing mode.

[0201] In some embodiments, the triggering event may correspond to the electronic device meeting a first preset condition, such as the system memory being in a low memory state; or reaching a preset detection period, etc.

[0202] The process-killing mode here can include virtual memory detection, kill condition detection, and process-killing operations. When an electronic device enters process-killing mode, it means that the device begins performing operations such as virtual memory detection and process bitness detection on foreground applications.

[0203] S903 checks whether the system's physical memory is less than the second threshold.

[0204] It should be understood that the foreground application may be an application that the user is currently using and is of high importance to the user experience. Therefore, before performing virtual memory detection on the foreground application, it is necessary to check whether a second preset condition is met. This second preset condition could be, for example, that the remaining physical memory space of the electronic device is less than a second threshold, which could be, for example, 200MB or 300MB.

[0205] In some embodiments, when the electronic device detects that the remaining physical memory space is less than a second threshold, it may trigger the electronic device to execute step S904. The second threshold may be set to, for example, 200M or 300M, and this application does not limit it to this.

[0206] The process of detecting whether the remaining physical memory of an electronic device is less than a preset threshold may include: the electronic device calling the activitymanager.getmemoryInfo interface through the memory anomaly analysis module to obtain the current remaining physical memory of the system, and then comparing whether the remaining physical memory is less than the preset threshold.

[0207] S904 detects whether the virtual memory used by the application exceeds the first threshold.

[0208] In some embodiments, there is a correspondence between the first threshold and the bitness of the process running the application, the first threshold being set based on the maximum virtual memory supported by the process of the target bitness. For example, for a 32-bit process, since its maximum supported virtual memory is 4GB, the first threshold can be set to a value close to 4GB, such as 3.2GB or 3.5GB.

[0209] S905 detects whether the process corresponding to the application is a 32-bit process.

[0210] It should be understood that when the virtual memory space occupied by the foreground application is detected to be greater than the first threshold in step S904, it means that the application may have a memory leak. However, it may also include other bit-based processes that are normally occupying memory. For example, if the virtual memory occupied by the application is greater than 3.5G, but the application is 64-bit, then there may not be a memory leak. Therefore, in order to accurately determine whether the application has a memory leak, it is possible to further detect whether the process running the application is a process of the target bit-based, that is, to determine whether the process running the application corresponds to the preset threshold. If so, it means that the virtual memory occupied by the application has reached the corresponding virtual memory usage limit (i.e., the preset threshold), and it can be determined that the application has actually experienced a memory leak.

[0211] The process of detecting whether an application is a 32-bit process on an electronic device can be done by calling an interface corresponding to the application's PID, viewing the relevant file directories in the corresponding process's file system, and obtaining the application's bit type. For details, please refer to the description of the relevant content above, which will not be elaborated here.

[0212] In some embodiments, when the electronic device detects that the process running the application is a 32-bit process, it can execute step S907 to kill the application process; if it detects that the process running the application is not a 32-bit process, it executes step S906 to further determine whether the physical memory occupied by the application is greater than the fourth threshold.

[0213] S906 detects whether the physical memory used by the application exceeds the fourth threshold.

[0214] In some embodiments, the process by which an electronic device determines the physical memory occupied by an application may include: calling the activitymanager.getmemoryInfo interface through a memory anomaly analysis module to query the VmRSS (physical memory) of the application from the VmRSS (physical memory) in the / proc / pid / status file in the system database.

[0215] In some embodiments, if the physical memory occupied by the application is detected to be greater than the fourth threshold, step S906 can be executed to kill the application process; if the physical memory occupied by the application is detected to be equal to or less than the fourth threshold, step S908 can be executed, that is, the application can continue to run. For example, the fourth threshold can be 1GB or 2GB, and this application is not limited thereto.

[0216] The memory management method provided in this application's embodiments detects and eliminates specific applications by combining abnormal memory usage of running applications with multi-dimensional information such as the application scenario. This optimizes system memory and improves the user experience while meeting different user needs for applications.

[0217] For example, embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including instructions that, when invoked by a computer, cause the computer to execute the memory management method described in embodiments of this application.

[0218] This application also provides a chip system, including: a communication interface for inputting and / or outputting information; a memory for storing a computer-executable program; and a processor for executing the computer-executable program, causing a device equipped with the chip system to perform the memory management method as described in this application.

[0219] This application also provides a computer program product, which includes computer program instructions that, when executed on a computer, cause the computer to implement the memory management method described in this application.

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

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

[0222] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A memory management method, characterized in that, Applied to electronic devices, including: Launch the application and provide virtual memory to the application; Run the application in the foreground; If at least the first and second conditions are met, the process of the application running in the foreground is killed. The first condition includes: the virtual memory space occupied by the application is greater than a first threshold, and the process bit size of the application is 32 bits. The second condition includes: the remaining physical memory space in the electronic device is less than a second threshold, or the remaining physical space in the electronic device reaches a preset level, or the application requests virtual memory at a rate greater than a third threshold.

2. The method according to claim 1, characterized in that, The method further includes: When the preset detection period is reached, the virtual memory space occupied by the application during its operation is detected. Detect the remaining physical memory space in the electronic device; When the remaining physical memory space is less than the second threshold, the virtual memory space occupied by the application during its operation is detected; or, When the remaining physical memory space in the electronic device reaches a preset level, the virtual memory space occupied by the application during operation is detected; or, Detect the rate at which the application requests the virtual memory; When the rate at which the application requests virtual memory exceeds a third threshold, the amount of virtual memory occupied by the application during its operation is detected.

3. The method according to claim 1, characterized in that, The method further includes: Run the application in the background; If the application is determined to be a 32-bit process based on the number of processes it runs, the duration of the application running in the background is detected. When the application is in the background running state for a longer than a preset time, the application process is killed.

4. The method according to claim 3, characterized in that, The step of killing the application process when the application is in the background running state for a longer than a preset time specifically includes: When the duration of the application running in the background exceeds a preset duration, the type of the application is detected; When the type of the application meets the preset type, the process of the application is killed.

5. The method according to claim 4, characterized in that, The preset type of application includes at least one of the following: Applications of the communication type, applications of the tool type, applications of the shopping type, and applications of the news type.

6. The method according to claim 5, characterized in that, The method further includes: When it is determined that the application is running a non-32-bit process based on the bitness of the process, the physical memory space occupied by the application during its operation is detected. When the occupied physical memory space exceeds the fourth threshold, a process killing operation is performed on the application.

7. An electronic device, characterized in that, include: One or more processors; One or more memory units; The one or more memories store one or more computer programs, the one or more computer programs including instructions that, when executed by the one or more processors, cause the electronic device to implement the memory management method as described in any one of claims 1 to 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including instructions that, when invoked by a computer, cause the computer to perform a memory management method as described in any one of claims 1 to 6.

9. A chip system, characterized in that, include: A communication interface used for inputting and / or outputting information; Memory is used to store executable programs in a computer; A processor for executing the computer-executable program, causing a device on which the chip system is installed to perform the memory management method as described in any one of claims 1 to 6.

Images