CN116107922A - Application management method and electronic device - Google Patents
Application management method and electronic device Download PDFInfo
- Publication number
- CN116107922A CN116107922A CN202211578199.7A CN202211578199A CN116107922A CN 116107922 A CN116107922 A CN 116107922A CN 202211578199 A CN202211578199 A CN 202211578199A CN 116107922 A CN116107922 A CN 116107922A
- Authority
- CN
- China
- Prior art keywords
- application
- memory
- application program
- failure
- virtual memory
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
- G06F12/0646—Configuration or reconfiguration
- G06F12/0684—Configuration or reconfiguration with feedback, e.g. presence or absence of unit detected by addressing, overflow detection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the application provides a management method of an application program, which comprises the following steps: monitoring an application result of the graphic buffer area in the running process of the application program; if the application result of the image buffer area is that the application fails, analyzing the failure type according to the application result; if the failure type is memory mapping failure, acquiring the virtual memory occupation condition of the application program; if the virtual memory occupied by the application program exceeds a preset threshold, starting the suicide recovery function of the application program to release the memory occupied by the application program, avoiding serious consequences such as system breakdown, blocking and the like caused by memory leakage, and reducing the influence on the use of a user.
Description
The present application is a divisional application, the filing number of the original application is 202111157747.4, the filing date of the original application is 2021, 09, 30, and the entire contents of the original application are incorporated herein by reference.
Technical Field
The present disclosure relates to the field of electronics, and in particular, to a method for managing an application program and an electronic device.
Background
Memory leak (memory leak) refers to a phenomenon that the heap memory that has been dynamically allocated in an application program is not released or cannot be released in time for some reason, resulting in waste of system memory.
However, since the memory leak is not an error, the current problems of difficult detection and difficult positioning will eventually lead to serious consequences such as memory overflow, abnormal operation of application programs and even system locking.
Disclosure of Invention
The application program management method can avoid the situation that a system is blocked due to memory leakage at present.
In a first aspect, there is provided a method for managing an application program, including: monitoring an application result of the graphic buffer area in the running process of the application program; if the application result of the image buffer area is that the application fails, analyzing the failure type according to the application result; if the failure type is memory mapping failure, acquiring the virtual memory occupation condition of the application program; and if the virtual memory occupied by the application program exceeds a preset threshold, starting the suicide recovery function of the application program.
In the running process of the application program, in order to draw an interface and save drawn data, the running process applies a graphic buffer (graphic buffer) to the system memory.
The graphics buffer shared between processes can be applied through a graphics buffer, and the graphics buffer used by an application program can be applied through a graphics buffer allocation process interface.
Because there is a possibility of memory leakage when the memory manager applies for the graphics buffer, when the process of the application program initiates the graphics buffer application, the memory application monitoring function can be started to monitor the application result of the graphics buffer.
It should be noted that, the memory application monitoring function may be started when the application program starts to run, the virtual memory occupation condition of the application program may also be obtained in real time, when the virtual memory occupation of the application program exceeds a certain value (this value may be set according to an actual application scenario, which is not limited in the present application), the memory application monitoring function may be started, or the memory application monitoring function may be started when the virtual memory occupation of the application program exceeds a certain value and the process of the application program initiates the graphics buffer zone application, or the memory application monitoring function may be started under other conditions.
For example, the above-mentioned open memory application monitoring may include: the method comprises the steps of actively starting a memory application monitoring function by a user, automatically starting the memory application monitoring function by the electronic equipment and starting the memory application monitoring function by default.
The application result of the graphic buffer area application comprises application success and application failure.
When the system available memory meets the application and the applied memory can be mapped to the address of the virtual memory of the process, the memory manager returns a successful application result.
When the available memory of the system is too small (the memory occupied by the applied graphic buffer area is larger than the available memory of the system), the applied memory cannot be mapped to the address of the virtual memory of the process, and other abnormal conditions exist, the memory manager returns the result of the application failure.
Wherein, the virtual memory occupation condition of the application can be called out through the/proc/self/status function.
The preset threshold may be set according to an application program, for example, for a 32-bit application program, and may be set to 3.7G. Of course, for 32-bit applications, the preset threshold may be set to some value lower than 3.7G, such as 3.5G, 3.2G, etc.
The above can be seen that, by monitoring the situation that the process of the application program applies for the graphics buffer to the system memory, when the memory application fails and the virtual memory is too occupied, the suicide recovery function is started to release the memory occupied by the application program, so as to avoid serious consequences such as system crash, blocking and the like caused by memory leakage, and reduce the influence on the use of users.
In a possible implementation manner of the first aspect, the starting the suicide recovery function if the virtual memory occupied by the application program exceeds a preset threshold includes: and ending all processes of the application program when the virtual memory occupied by the application program exceeds a preset threshold value.
When the virtual memory occupied by the application program exceeds a preset threshold, the process manager can respond to the command by sending the command for ending all the processes of the application program to the process manager, so that all the processes of the application program can be ended, and the system memory occupied by the application program is released.
All processes in the process manager, which are currently running in the system, can release the system memory occupied by the application program by integrating all processes related to the application program name through the process manager.
The automatic checking and killing of the application program can be that all processes of the application program are directly ended, and at the moment, the display interface of the electronic device can directly jump to the main screen interface of the display electronic device, namely, the user perceives that the application program flashes back. All processes of the application program are directly ended, so that all memory occupied by the application program can be released, and serious consequences such as system crash and blocking caused by memory leakage are avoided.
In a possible implementation manner of the first aspect, the starting the suicide recovery function if the virtual memory occupied by the application program exceeds a preset threshold includes: judging whether the process applying the graphic buffer area is a main process of the application program or not when the virtual memory occupied by the application program exceeds a preset threshold value;
if the process applying the graphic buffer area is the main process of the application program, restarting the main process of the application program after finishing all the processes of the application program; otherwise, ending all the processes of the application program.
If the process of applying the graphic buffer area is the main process of the application program, the interface displayed by the electronic equipment is the main display interface of the application program, so that the main process of the application program is automatically pulled up after all the processes of the application program are ended, and the display interface of the electronic equipment can jump to the main display interface of the application program directly.
Because the interval time for pulling up the main process of the application program again after finishing the process of the application program is short, the user does not feel the interval time, and only can feel the display interface of the electronic equipment and jump back to the main display interface of the application program. At this time, the user does not feel that the application program flashes back, so that the user can be prevented from being influenced by the use of the user while the system memory occupied by the application program is released, and the user experience is improved.
In a possible implementation manner of the first aspect, after the monitoring the application result of the graphics buffer during the running process of the application program, the method further includes:
if the application result of the graphics buffer is that the application is successful, the applied memory is mapped to the address of the virtual memory of the process.
After the graphics buffer is applied successfully (i.e. the system allocates the memory to the process for use), the process can perform display drawing of the interface only by mapping the graphics buffer to the address space of the virtual memory corresponding to the process.
In a possible implementation manner of the first aspect, the method for managing an application program further includes: if the failure type is not the memory mapping failure, outputting an exception log corresponding to the failure type.
The failure types when the application fails may include, but are not limited to, insufficient available memory of the system, memory mapping failure, other abnormal conditions, etc.
In some embodiments, the electronic device may determine the failure type according to the application result returned by the memory manager. The failure type may be determined, for example, by analyzing the code of two corresponding to the application result.
For example, when the application result includes two fields, a first field is used to indicate whether the application was successful, a second field is used for the failure type, indicating that the code of the second field is read, and the memory application result can be determined based on the code of the second field.
For example, if the application result is "01, 001", the content "001" of the second field is read, and according to the predetermined meaning corresponding to the code, the failure type is that the available memory of the system is too small. For example, if the application result is "01, 010", the content of the second field read is "010", and the failure type is a memory mapping failure according to the meaning corresponding to the predetermined code.
Also, for example, when the application result includes only one field, where the 2 nd to 4 th bits of the field are used to indicate the failure type, the codes of the second to fourth bits are read, and the application result of the memory application is determined based on the codes of the second to fourth bits.
For example, if the application result is "1001", the codes "001" of the 2 nd bit to the fourth bit are read, and according to the predetermined meaning corresponding to the codes, the failure type is that the available memory of the system is too small. For another example, if the application result is "1010", the codes "010" of the 2 nd bit to the 4 th bit are read, and according to the predetermined meaning corresponding to the codes, the failure type is the memory mapping failure.
Also for example, when the application result is returned as error and an error code is attached, the failure type may be determined by the error code.
Because the failure type is not memory mapping failure, the situation of memory leakage is basically not caused, and therefore, the application program does not need to be subjected to any operation, and only the exception log corresponding to the failure type needs to be output.
In some embodiments, the exception log may include a process name initiated by the application, a time when the exception occurs, and contents of the exception, where the contents of the exception include a failure to apply for the graphics buffer and a failure type. For example, when the failure type is that the available memory of the system is too little, the exception may be that the B process of the a application fails to apply for the graphics buffer at xx time due to the too little system memory.
In some embodiments, the electronic device may initiate an LMK mechanism based on the exception log when the failure type is too little system memory.
In some embodiments, the exception log may be stored in a log manager, and the electronic device may read the exception log through the log manager.
In a possible implementation manner of the first aspect, the method for managing an application program further includes: if the virtual memory occupied by the application program does not exceed the preset threshold, outputting an abnormal log that the memory mapping fails and the virtual memory does not exceed the threshold.
Because the virtual memory occupied by the application program does not exceed the preset threshold, that is, the memory leakage is not caused, no operation is required to be performed on the application program, and only the exception log that the memory mapping fails and the virtual memory does not exceed the threshold is required to be output.
In a possible implementation manner of the first aspect, the method for managing an application program further includes: and after all the processes of the application program are finished, outputting an abnormal log for ending the running of the application program due to the fact that the occupation of the virtual memory is too high.
And recording the abnormal condition of ending the running of the application program due to overhigh virtual memory occupation in the form of an abnormal log, so that the user can check the abnormal condition conveniently.
In a second aspect, an embodiment of the present application provides an electronic device, including:
the monitoring module is used for monitoring the application result of the graphic buffer area in the running process of the application program;
the analysis module is used for analyzing the failure type according to the application result if the application result of the image buffer area is the application failure;
the acquisition module is used for acquiring the virtual memory occupation condition of the application program if the failure type is memory mapping failure;
and the suicide recovery module is used for starting the suicide recovery function of the application program if the virtual memory occupied by the application program exceeds a preset threshold value.
In a third aspect, embodiments of the present application provide an electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing a method according to any one of the first aspects described above when the computer program is executed by the processor.
In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program which, when executed by a processor, implements a method as in any of the first aspects described above.
In a fifth aspect, embodiments of the present application provide a chip system, the chip system including a processor, the processor being coupled to a memory, the processor executing a computer program stored in the memory to implement a method as described in any one of the first aspects. The chip system can be a single chip or a chip module composed of a plurality of chips.
In a sixth aspect, embodiments of the present application provide a computer program product for, when run on an electronic device, causing the electronic device to perform the method of any one of the first aspects.
It will be appreciated that the advantages of the second to sixth aspects may be found in the relevant description of the first aspect, and are not described here again.
Drawings
Fig. 1 is an exemplary schematic diagram of an abnormal display of an application program caused by a memory leak according to an embodiment of the present application.
Fig. 2 is a schematic hardware structure of a mobile phone according to an embodiment of the present application.
Fig. 3 is a schematic diagram of a software system architecture of a mobile phone according to an embodiment of the present application.
Fig. 4 is a schematic diagram of a graphical user interface in some application scenarios provided in embodiments of the present application.
Fig. 5 is a schematic diagram of a graphical user interface during some processes of starting a memory application monitoring function according to an embodiment of the present application.
Fig. 6 is a schematic implementation flow chart of an application management method according to an embodiment of the present application.
Fig. 7 is a schematic flowchart of another implementation of an application management method according to an embodiment of the present application.
Detailed Description
It should be noted that the terms used in the implementation section of the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. In the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; "and/or" herein is merely an association relationship describing a relationship, meaning that there may be three relationships, e.g., a and/or B, may mean: a exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present application, unless otherwise indicated, "a plurality" means two or more, and "at least one", "one or more" means one, two or more.
The terms "first" and "second" are used below for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a definition of "a first", "a second" feature may explicitly or implicitly include one or more of such features.
Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.
For a better understanding of embodiments of the present application, terms or concepts that may be referred to in the embodiments are described below.
1. Graphic buffer (graphic buffer)
Display rendering for an interface of an application and saving data of the display rendering. In the running process of the application program, the application program needs to apply for the graphic buffer area for displaying drawing of the interface and storing the display drawing data, the specific graphic buffer area can be distributed from the system memory, and after the graphic buffer area is distributed from the system memory, the graphic buffer area needs to be mapped into the address space of the virtual memory corresponding to the application program, so that the application program can run normally. For multi-process application programs, each process applies for a graphics buffer firstly during running, and likewise, after the graphics buffer is applied successfully (i.e. enough memory exists in the system to be allocated to the process for use), the graphics buffer needs to be mapped into the address space of the virtual memory corresponding to the process, so that the process can run normally.
2. Garbage collection (garbage collection, GC) mechanism
And (3) clearing and recycling unused objects to release a mechanism of the memory. When the application program is stuck and the response speed is slow (when the memory occupancy is too high, for example, for a 32-bit application program, the memory occupancy exceeding 3G is determined to be too high), the virtual machine triggers a Garbage Collection (GC) mechanism.
3. Low memory lookup (low memory killer, LMK) mechanism
A memory cleaning mechanism of an Android system is used for detecting the memory service condition of an application program at regular time, and when the available memory of the system is low, an LMK mechanism is triggered to kill a process with low priority through a background so as to release the memory. Specifically, the priority of a process is determined by the oom _adj value of the process, the smaller the oom _adj value, the higher the priority, and the less likely the process will be killed when the LMK mechanism is triggered. Note that, the oom _adj value of the foreground process is 0, i.e., the priority of the foreground process is highest.
4. Virtual memory (virtual set size, VSS)
The size of all memory space addresses that a process can access. Theoretically, for 32-bit applications, the most available virtual memoryIs 2 32 I.e. 4G. In practical applications, the system is reserved to occupy a small portion, so that for 32-bit applications, a virtual memory that can be used at most is 3.7G, and exceeding 3.7G causes memory overflow.
5. Memory overflow (out of memory, OOM)
The system has the phenomenon that the memory which cannot be recovered or is used too much, and finally the memory used for running the application program is larger than the maximum memory which can be provided, and the memory overflow is represented by abnormal interface display of the application program or flash back of the application program.
In a software system, due to improper use of resources such as pictures, objects, threads, files, views and the like, the resources are not released in time, so that memory leakage is caused, and further, memory overflow of an application program is caused, and the application program is blocked, even the system is blocked. Memory leaks are in most cases an accumulated process that is not symptomatic before a problem occurs and therefore is difficult to find and locate.
In practical applications, memory leaks can lead to the following situations:
1. the application program is blocked, the response speed is slow, and a garbage collection mechanism is triggered, so that the application program is unresponsive (application not responding, ANR) or the application program is flashed back.
2. Causing an abnormality in display of the application program, unavailability of a part of functions of the application program, and the like.
For example, in fig. 1 (a), a schematic diagram of a display interface when the application program a displays normally is shown when no memory leak occurs, and as shown in fig. 1 (b), the display abnormality occurring when the application program a generates the memory leak may be represented as a condition that a messy code occurs; as shown in fig. 1 (c), for example, the abnormal display occurring when the application program a causes a memory leak may be represented as an incomplete display; as shown in fig. 1 (d), for example, the abnormal display occurring when the application program a causes a memory leak may be represented by a case where a part of the functions is not displayed, and the part of the functions is in an abnormal state where the part of the functions is not available.
3. Abnormal system breakdown, jamming, etc.
When a user watches a video by using a mobile phone, the video playing application program can continuously apply for the memory and does not release the memory in the video playing process, and the application program can not map the applied memory into the virtual memory of the video playing application program after reaching the upper use limit of the virtual memory of the video playing application program because the virtual memory which can be used most by the video playing application program is fixed. At the same time, the memory allocated by the system is marked as used, and cannot be reallocated to other application programs (processes) for use, and the failure of the memory mapping can cause the application program to continuously apply the memory to the system, thereby causing memory leakage. The available memory of the system is low, so that an LMK mechanism is triggered, but the video playing application program is operated in the foreground, so that the priority of the video playing application program is higher, the video playing application program cannot be killed, the occupied memory cannot be released, and finally the whole system is crashed and blocked. When the system crashes and is blocked, the user is required to forcibly restart the mobile phone to recover normal use, the operation is troublesome, and the user experience can be influenced.
In practical applications, many application programs are 32-bit application programs, and when applying for system memory to a system, the application programs apply for memory by continuously calling a graphicbufferallor process interface. The maximum virtual memory available for the 32-bit application is 4G, however, since the graphicbufferfllotor process is a 64-bit process, when the virtual memory of the application exceeds 4G, the system memory can be successfully applied to the system memory, and since the virtual memory of the application exceeds 4G, the applied memory cannot be mapped to the virtual memory, so that the system memory is applied but cannot be used and cannot be released. And after the mapping of the memory fails, the application program can also continuously apply for the memory by calling the graphicbufferfllotor interface, so that the memory is continuously leaked, and finally, the abnormal conditions of system crash and blockage are caused.
As can be seen from the above description, once the memory leak has exploded, the situation caused is various and is not easily reproduced, that is, the memory leak is not well found and solved, and the memory leak also seriously affects the use of the user. Therefore, if the application program which can cause the memory leakage can be processed before the occurrence of the abnormal condition caused by the memory leakage, serious abnormalities such as system breakdown, blocking and the like can be avoided, and the influence on the use of a user is reduced.
Aiming at the problems and the user demands, the embodiment of the application provides a management method of an application program, wherein the condition that a process of the application program applies a graphic buffer area to a system memory is monitored, and when the memory application fails and the occupation of virtual memory is excessive, a suicide recovery function is started to finish all processes of the application program so as to release the memory occupied by the application program, so that serious consequences such as system breakdown, blocking and the like caused by memory leakage are avoided, and the influence on the use of a user is reduced.
In the following description, for purposes of explanation and not limitation, specific details are set forth such as the particular system architecture, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application, in order to provide a more thorough understanding of the embodiments of the present application.
The execution subject of the application management method may be an electronic device, such as a mobile phone, a wearable device (e.g., a smart watch, a smart bracelet, a smart glasses, a smart jewelry, etc.), a tablet computer, a vehicle-mounted device, an augmented reality (augmented reality, AR)/Virtual Reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (personal digital assistant, PDA), and other electronic devices with network connection functions.
Exemplary embodiments of the above-described electronic device include, but are not limited to, piggy-backHong Mongolian System (Harmony OS) or other operating system devices. The electronic device may also be other electronic devices such as a laptop computer with a touch-sensitive surface (e.g., a touch panel)A machine (laptop), etc., the embodiment of the application does not limit the specific type of the electronic device.
Taking the electronic device as a mobile phone as an example, as shown in fig. 2, a schematic structural diagram of the mobile phone is provided in an embodiment of the present application.
Fig. 2 shows a schematic structure of the mobile phone 100. The handset 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 11, an antenna 12, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.
It should be understood that the structure illustrated in the embodiments of the present invention is not limited to the specific embodiment of the mobile phone 100. In other embodiments of the present application, the handset 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components may be provided. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.
The controller may be a neural center or a command center of the mobile phone 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.
A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.
For example, the software system of the mobile phone 100 may employ a layered architecture, an event driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the invention, taking an Android system with a layered architecture as an example, a software structure of the mobile phone 100 is illustrated. Fig. 3 is a software configuration block diagram of the mobile phone 100 according to the embodiment of the present application.
The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.
The application layer may include a series of application packages. As shown in fig. 3, the application package may include camera, gallery, calendar, talk, map, navigation, WLAN, bluetooth, video, instant chat, etc. applications.
The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions. As shown in FIG. 3, the application framework layer may include a window manager, a content provider, a view system, a process manager, a notification manager, a suicide recovery management module, and the like.
The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.
The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.
The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.
The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.
The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in a status bar, a prompt tone is emitted, the terminal vibrates, and an indicator light blinks.
The suicide recovery management module is an application management mechanism for starting automatic searching and killing of the application to release the memory when detecting that the running application meets the suicide recovery condition mentioned in the embodiment of the application.
In this embodiment of the present application, the suicide recovery condition may be a memory application failure, the failure type is a virtual memory mapping failure, and virtual memory occupied by the application program exceeds a preset threshold.
In this embodiment of the present application, the automatic searching and killing of the application program may be that all processes of the application program are directly ended, and at this time, the display interface of the mobile phone 100 may jump to the main screen interface of the display mobile phone 100 directly, that is, the user perceives that the application program is flashing back; the automatic checking and killing of the application program may be that the main process of the application program is automatically pulled up after all the processes of the application program are finished, and the display interface of the mobile phone 100 may jump to the main display interface of the application program directly. Because the interval time for pulling up the main process of the application program again after the process of the application program is finished is short, the user does not feel the interval time, and only can feel the display interface of the mobile phone 100 and jump back to the main display interface of the application program.
In some embodiments of the present application, the suicide recovery management module further has a memory application monitoring function, which can be automatically started when the application program issues a memory application to the system memory, so as to monitor whether the memory application is successful.
Android run time includes a core library and virtual machines. Android run time is responsible for scheduling and management of the Android system.
The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.
The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of target life cycle management, stack management, thread management, security and exception management, garbage collection and the like.
The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.
The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.
The application program management method provided by the embodiment of the application program can be operated on the application program framework layer, namely the application program management method can be realized through the suicide recovery management module in the application program framework layer.
The application program management method provided by the embodiment of the application program can be suitable for various use scenes with memory leakage. For example, the application management method provided by the embodiment of the application can be applied to a scene that a user views a video by using an electronic device or views a push article by using instant chat software.
For example, when a user views a push article (which may be a news push article/video, etc.) using instant chat software, the application program process applies a graphics buffer to system memory for display rendering of the interface and for saving data of the display rendering. When the process of the application program initiates a graphic buffer application to the system memory, the mobile phone starts a memory application monitoring function, and when the instant chat software is monitored to meet the suicide recovery condition (at this time, the graphic buffer application fails, the failure type is virtual memory mapping failure, and virtual memory occupied by the application program exceeds a preset threshold), suicide recovery is started, so that the application program releases the memory, and the situation that the whole mobile phone system is crashed and blocked is avoided.
Exemplary, as shown in fig. 4, is a schematic diagram of some graphical user interfaces (graphical user interface, GUI) that may be involved in an application scenario one.
In some embodiments, the interface of the instant chat software includes a main display area 10 ("information" corresponding interface), and other functional areas 20 (e.g., "address book", "dynamic" in fig. 4 (a)), sub-dialogs 30. The main display area 10 will display a plurality of sub-dialogs 30, which may specifically be displayed as in (a) of fig. 4. When the user wants to view an article pushed by a certain sub-dialogue, the user can click on a control corresponding to the sub-dialogue (for example, the sub-dialogue of the contact 1) to make the display interface of the instant chat software jump to the display interface corresponding to the sub-dialogue (as shown in (b) in fig. 4).
In some embodiments, as shown in fig. 4 (c), when an application program is running, for example, when a user clicks on a sub-session to check a session, the process corresponding to the sub-session needs to apply for a graphic buffer area, the mobile phone may display a prompt message to prompt the user whether to start a memory application monitoring function of the mobile phone, where the prompt message is, for example, "the operation may cause a memory leak, whether to start a memory application monitoring function, so as to ensure that the system is running normally? ". When the mobile phone receives the operation of confirming to start the function of the memory application monitoring function (for example, the user clicks the "confirm" icon shown in (c) of fig. 4), the mobile phone can start the function of the memory application monitoring, and monitor the process of applying for the graphic buffer zone by the process.
In some embodiments, after obtaining the application result of the image buffer area, if the application is successful, the application program continues to run normally; if the application fails, the reason of the application failure is further analyzed, if the reason of the application failure is that the virtual memory mapping fails, the size of the virtual memory occupied by the application program can be further obtained, and when the size of the virtual memory occupied by the application program exceeds a preset threshold, the suicide recovery function is started.
In some embodiments, when the mobile phone starts the suicide recovery function, all the processes of the application program may be directly ended, and at this time, the display interface of the mobile phone jumps back to the main screen interface of the mobile phone (such as the interface shown in (d) of fig. 4).
Or when the mobile phone starts the suicide recovery function, the main process of the application program can be automatically pulled up after all the processes of the application program are finished, so that the display interface of the mobile phone displays the main display interface (such as the interface shown in (a) of fig. 4) of the application program.
It can be understood that the interface shown in fig. 4 is merely an example, and the specific content (such as the specific content of the prompt information) displayed on the interface, the display position of the prompt information, and the like in the embodiment of the present application are not limited. For example, in order not to affect the user's viewing of information, the prompt information displayed in fig. 4 may also be configured to prompt in a status bar, and display an information identification to prompt the user that relevant information is available for viewing. When the user needs to view, the relevant information can be clicked by the drop-down status bar to view. Or, the related information can be displayed in the form of a small window at the position of the right lower corner or the right upper corner of the instant chat interface, so that the user is prompted, the shielding of chat content is reduced, and the influence on the user is reduced.
It should be noted that, the method for starting the memory application monitoring function by the mobile phone may include: the method comprises the steps of actively starting a memory application monitoring function by a user, automatically starting the memory application monitoring function by a mobile phone and starting the memory application monitoring function by default.
Exemplary, as shown in fig. 5, some graphical user interface diagrams involved in the process of starting the memory application monitoring function according to the embodiments of the present application are shown. Here, the electronic device is a mobile phone.
In some embodiments, when an application program starts to run, the mobile phone can prompt the user to start the memory application monitoring function when the process initiates an application for creating a graphic buffer to the system memory. The manner of prompting the user may be, for example, a manner of displaying a prompting message through an interface (as shown in (c) of fig. 4), or a voice manner; or the prompt information is displayed through an interface to be combined with a voice mode, etc.
Exemplary, as shown in fig. 5 (a), is a schematic diagram of a home screen interface of a mobile phone. The home screen interface may include an application icon display area 51 for displaying various types of application (App) icons, such as clock icons, calendar icons, gallery icons, memo icons, file management icons, email icons, music icons, calculator icons, recorder icons, sports health icons, instant chat icons, browser icons, setup icons, and the like. Under the plurality of application icons may be a page indicator display region 52 that includes page indicators for indicating the positional relationship of the currently displayed page to other pages. A tray application icon display area 53 may be displayed below the page indicator for displaying a plurality of tray application icons, such as camera application icons, address book application icons, telephone dialing application icons, information application icons, and the like. In other embodiments, the cell phone home screen interface may include more or less application icons or tray application icons than illustrated, as this application is not limiting. Above the home screen interface, a status bar 54 may also be displayed, the status bar 54 may include: one or more signal strength indicators of a mobile communication signal (or cellular signal), a power indicator of a handset, a time indicator, etc.
In some embodiments, the mobile phone may receive a click operation of the user on the setting icon; in response to a click operation by the user, the mobile phone may display a setting detail interface as shown in (b) of fig. 5.
As shown in (b) of fig. 5, the setup detail interface may include management fields for a plurality of services, such as a wireless and network management field, a bluetooth management field, a desktop and wallpaper management field, a display management field, a sound management field, an application management field, a battery management field, a storage management field, a security and privacy management field, and the like. In practical applications, the setup interface may also include more or fewer types of management bars than illustrated, which is not limited in this application.
In some embodiments, the mobile phone may receive a click operation of the user on the application management bar; in response to a click operation by the user, the mobile phone may display an application management interface as shown in (c) of fig. 5.
By way of example, the application interface may include a plurality of business management bars, including, for example: system application settings, application monitoring management, application double-opening, authorization management, and the like. After each service name, a next page indicator corresponding to the service may be displayed.
In some embodiments, as shown in fig. 5 (c), the handset may receive a click operation of the next page indicator in the application monitoring management column. In response to a click operation by the user, the mobile phone may display an application monitoring management interface as shown in (d) of fig. 5.
For example, as shown in (d) of fig. 5, the application monitoring management interface may include an explanation content of the memory application monitoring function, a switch control, and a personalized setting area for each application program under the memory application monitoring function. The description of the memory application monitoring function is used for introducing the memory application monitoring function so that the user can more clearly understand the function of the memory application monitoring function. The description may be, for example, "after the switch turns on the memory application monitoring function, the system monitors the result of the running application program applying for the system memory, and discovers the memory leak in time. In some embodiments, the lower area introduced by the memory application monitoring function may display a switch control corresponding to the memory application monitoring function, so as to enable a user to turn on or off the memory application monitoring function.
It should be understood that the control for controlling the switch of the memory application monitoring function can be set independently for different application programs, so that the user can selectively and more fit the requirement to use the memory application monitoring function by combining the characteristics of the application programs. By the method, on the basis of considering different service characteristics, the function is more reasonably applied, and the interference or interruption of the memory application monitoring function to the process of certain application programs is avoided, so that the use experience of a user is ensured.
Mode 2, mobile phone automatically opens memory application monitoring function
In one possible implementation manner, when an application program starts to run, the mobile phone can automatically start the memory application monitoring function, or when the process of the application program initiates a memory application (applies for a graphics buffer zone) to the system memory, the mobile phone automatically starts the memory application monitoring function to monitor the condition of the memory application.
Optionally, when the mobile phone starts the memory application monitoring function, a prompt message may be displayed to inform the user that the mobile phone will currently execute the application monitoring function. Alternatively, query information may be displayed to query the user as to whether or not to confirm that the cell phone performs the memory application monitoring function (as shown in fig. 4 (c)). For example, the prompt information or the query information may be displayed in a status bar of the mobile phone or in a current interface of the mobile phone, which is not limited in this application.
It should be understood that the process of automatically starting the memory application monitoring function by the mobile phone in this manner may be imperceptible to the user. By the memory application monitoring function in the mode, the influence on the currently running application can be avoided, such as video suspension and the like, and user experience is ensured.
Mode 3, default on memory application monitoring function
In one possible implementation manner, before the mobile phone leaves the factory, the memory application monitoring function can be set to a default on state, so that monitoring and management of the memory application can be performed at any time in the process of using the mobile phone by a subsequent user.
In combination with the above-described exemplary opening manner, the method for monitoring the memory application provided in the embodiment of the present application may be performed in a form that the user has a sense (for example, the user actively opens the memory application or displays related information to the user), or may also be performed in a form that the user does not have a sense, which is not limited in this embodiment of the present application.
The application scenario, the opening mode of the corresponding function, and the like to which the application program management method provided in the embodiment of the present application is applicable are described above with reference to the accompanying drawings. For a better understanding of the method for predicting signal strength provided in the embodiments of the present application, the following description will exemplarily describe a specific implementation process with reference to the accompanying drawings.
Exemplary, as shown in fig. 6, an interaction flow diagram in a system of an electronic device in a process of executing a management method of an application program provided by an embodiment of the present application is provided for the electronic device provided by the embodiment of the present application. The method specifically comprises the following steps:
S601, in the running process of the application program, the process of the application program applies a graphic buffer area to a memory manager.
The application program may be a multi-process application program or a single-process application program. In practical applications, in order to increase the running rate and reduce the redundancy of the application, the application is usually a multi-process application, and the processes may be in a master-slave relationship.
In the running process of the application program, in order to draw an interface and save drawn data, the running process applies a graphic buffer (graphics buffer) to the memory manager, and taking an Android system as an example, the process applies the graphic buffer to the memory manager in the following manner:
mode 1: and applying for the shared graph buffer among the processes through the graphicbuffermapper.
The Android system provides a graphicbuffermapper tool class that provides an interface for upper access hardware abstraction layers (graphoc modules).
When the application program in the user space uses the graphic buffer area, the application program in the user space needs to load the gralloc module first, acquire a gralloc device and an fb device, after the gralloc device is available, the application program in the user space can apply for distributing a graphic buffer area, and map the graphic buffer area into the address space of the application program so as to write the content of the picture to be drawn into the address space. Finally, the application program in the user space renders the prepared graphic buffer area into the frame buffer area through the fb equipment, namely, draws the content of the graphic buffer area into the display screen, and realizes the interface display of the application program.
Mode 2: and applying a graphics buffer used by the application program through a graphicbufferallor process interface.
The Android system also provides a graphicbufferallor process interface, and the graphicbufferallor process interface is universal and can be applied to an image buffer zone.
S602, the suicide recovery management module starts a memory application monitoring function.
After the memory application monitoring function is started, the suicide recovery management module sends an instruction for acquiring an application result of the graphic buffer application to the memory manager.
In some embodiments, the suicide recovery management module may start the memory application monitoring function when the application program starts to run, or may restart the memory application monitoring function when the process of the application program initiates the graphics buffer application to the system memory, or may acquire the virtual memory occupation condition of the application program in real time, and when the virtual memory occupation of the application program exceeds a certain value (this value may be set according to an actual application scenario, which is not limited in this application), the memory application monitoring function may be started, or may start the memory application monitoring function when the virtual memory occupation of the application program exceeds a certain value and the process of the application program initiates the graphics buffer application, or may start the memory application monitoring function under other conditions, which is not repeated in this application.
The above method for starting the memory application monitoring function may refer to the above related content, and is not repeated here for avoiding repetition.
Here, the application result of the graphics buffer application includes application success and application failure.
The application result may be expressed in the form of binary codes. For example, the application result may include two fields, one for indicating whether the application was successful and one for indicating the corresponding error type when the application failed. Illustratively, the field for indicating whether the application was successful includes 2 bits, where 00 indicates that the application was successful and 01 indicates that the application was failed; the corresponding failure type used to indicate that the application failed includes 3 bits, where 001 indicates that the system is too little memory available, 010 indicates that the memory mapping failed, 011 indicates other exceptions, etc. (the corresponding second field is 000 when the first field is 00).
Of course, the application result may include only one field, which may indicate whether the application is successful or not, or may indicate the corresponding failure type when the application fails. For example, the field includes 4 bits, where the first bit is used to indicate whether the application was successful, the second through fourth bits are used to indicate the corresponding failure type when the application failed, e.g., 0000 indicates that the application was successful, 1001 indicates that the application failed and the failure type is that little memory is available to the system, 1010 indicates that the application failed and the failure type is that the memory map failed, 1011 indicates that the application failed and the failure type is other exceptions.
Of course, when the application is successful, no_error may be returned; when the application fails, error can be returned, and an error code is attached, and the failure type is indicated by the error code.
It will be appreciated that the foregoing is merely an example of an application result, and the application result may also include other contents, such as a return time, etc., which is not limited in this application.
S603, the memory manager responds to the instruction for obtaining the application result of the image buffer application, and sends the application result of the image buffer application to the suicide recovery management module.
Specifically, when a process of an application program sends an image buffer area application to a system memory, when the available memory of the system meets the application and the applied memory can be mapped to an address of a virtual memory of the process, a memory manager sends a result of successful application to a suicide recovery management module.
When the available memory of the system is too small (the memory occupied by the applied graphic buffer area is larger than the available memory of the system), the applied memory cannot be mapped to the address of the virtual memory of the process, and other abnormal conditions exist, the memory manager sends the result of the failed application to the suicide recovery management module.
It should be noted that, if the process of the application program applies for the graphics buffer area through the mode 2 in S601, that is, applies for the graphics buffer area used by the application program through the graphics buffer allocation process interface, although the application of the graphics buffer area fails for the process, the memory manager actually allocates the memory required by the graphics buffer area applied by the memory manager to the process, and the application will continue to be initiated after the process fails to apply for the process, so that the more the memory allocated by the system (which is not actually used) will be accumulated, the insufficient memory of the system will be finally caused, and the situation that the whole machine crashes and dies will occur.
S604, the suicide recovery management module detects that the application result of the received graphic buffer application is that the application is successful, and then the suicide recovery management module sends a mapping instruction to the application program.
S605, the application program responds to the mapping instruction and maps the applied memory to the address of the virtual memory of the process of the application program.
After the suicide recovery management module receives the application result sent by the memory manager, whether the application of the graphic buffer area is successful or not can be determined by analyzing the binary code corresponding to the application result. For example, when the application result includes two fields, wherein the first field is used to indicate whether the application was successful, the code of the field is read, and the graphics buffer application result can be determined based on the code of the field.
For example, if the application result received by the suicide recovery management module is "00, 000", the content "00" of the first field is read, and according to the predetermined meaning corresponding to the code, the application result is that the application is successful. For example, if the application result is "01, 010", the content of the first field read is "01", and the application result is the application failure according to the meaning corresponding to the predetermined code.
Also, for example, when the application result includes only one field, where bit 1 of the field is used to indicate whether the application is successful, the code of the bit is read, and the application result of the memory application is determined based on the code of the bit.
For example, if the application result is "0000", the code "0" of the first bit is read, and according to the predetermined meaning corresponding to the code, the application result is that the application is successful. For another example, if the application result is "1010", the code "1" of the first bit is read, and according to the predetermined meaning corresponding to the code, the application result is the application failure.
The memory mapping process of the application program mapping the applied memory to the address of the virtual memory of the process is a common memory management method, and the specific memory mapping process can be implemented in a conventional manner, which is not described herein in detail.
S606, the suicide recovery management module analyzes the failure type according to the application result after detecting that the application result of the received graphic buffer application is the application failure.
The process of determining that the application result of the memory application is the application failure by the suicide recovery management module may be described in S604, and in order to avoid repetition, details are not repeated here.
The failure type when the application fails may include, but is not limited to, insufficient available memory of the system, memory mapping failure, other abnormal conditions, and the like.
In some embodiments, the suicide recovery management module may determine the failure type according to the application result returned by the memory manager. The failure type may be determined, for example, by analyzing the code of two corresponding to the application result.
For example, when the application result includes two fields, a first field is used to indicate whether the application was successful, a second field is used for the failure type, indicating that the code of the second field is read, and the memory application result can be determined based on the code of the second field.
For example, if the application result is "01, 001", the content "001" of the second field is read, and according to the predetermined meaning corresponding to the code, the failure type is that the available memory of the system is too small. For example, if the application result is "01, 010", the content of the second field read is "010", and the failure type is a memory mapping failure according to the meaning corresponding to the predetermined code.
Also, for example, when the application result includes only one field, where the 2 nd to 4 th bits of the field are used to indicate the failure type, the codes of the second to fourth bits are read, and the application result of the memory application is determined based on the codes of the second to fourth bits.
For example, if the application result is "1001", the codes "001" of the 2 nd bit to the fourth bit are read, and according to the predetermined meaning corresponding to the codes, the failure type is that the available memory of the system is too small. For another example, if the application result is "1010", the codes "010" of the 2 nd bit to the 4 th bit are read, and according to the predetermined meaning corresponding to the codes, the failure type is the memory mapping failure.
Also for example, when the application result is returned as error and an error code is attached, the failure type may be determined by the error code.
S607, the suicide recovery management module sends a first abnormal log output instruction to the log manager under the condition that the failure type is determined not to be the memory mapping failure.
The relevant content of the failure type may be referred to the description of S606, and will not be described herein.
S608, the log manager responds to the first abnormal log output instruction to generate and store an abnormal log corresponding to the failure type.
Here, the first exception log output command instructs the log manager to generate and store an exception log corresponding to the failure type.
Since the failure type is not a memory mapping failure, no memory leakage is basically caused, no operation is needed to be performed on the application program, and only the log manager needs to be controlled to generate and store an exception log corresponding to the failure type, so that a user can know the failure type of the application failure of the graphics buffer, and other relevant information (such as application time, application subject (i.e. application submitted by which process of which application program), and the like).
In some embodiments, the exception log may include a process name initiated by the application, a time when the exception occurs, and contents of the exception, where the contents of the exception include a failure to apply for the graphics buffer and a failure type. For example, when the failure type is that the available memory of the system is too little, the exception may be that the B process of the a application fails to apply for the graphics buffer at xx time due to the too little system memory.
In some embodiments, the electronic device may initiate an LMK mechanism based on the exception log when the failure type is too little system memory.
In some embodiments, the exception log may be stored in a log manager, and the electronic device may read the exception log through the log manager.
S609, the suicide recovery management module obtains the virtual memory occupation condition of the application program under the condition that the failure type is determined to be memory mapping failure.
When the failure type is memory mapping failure, the virtual memory of the application program is too much occupied, which easily causes the leakage of the system memory, so as to determine whether the virtual memory is too much occupied, the virtual memory service condition of the application program can be acquired at this time, and then whether the risk of memory leakage exists is analyzed.
In some embodiments, the suicide recovery management module may call out the virtual memory footprint of the application through a/proc/self/status function. After determining that the memory application fails and the failure type is memory mapping failure, automatically calling/proc/self/status functions to acquire the current virtual memory occupation condition of the application.
S610, the suicide recovery management module judges whether the virtual memory occupied by the application program exceeds a preset threshold.
The preset threshold may be set according to an application program, for example, for a 32-bit application program, and may be set to 3.7G. Of course, for 32-bit applications, the preset threshold may be set to some value lower than 3.7G, such as 3.5G, 3.2G, etc.
S611, the suicide recovery management module sends a second abnormal log output instruction to the log manager under the condition that the virtual memory occupied by the application program is not determined to exceed the preset threshold value.
S612, the log manager responds to the second abnormal log output instruction to generate and store an abnormal log that the memory mapping fails and the virtual memory does not exceed the threshold value.
Here, the first exception log output instruction is configured to instruct the log manager to generate and store an exception log that the memory mapping fails and the virtual memory does not exceed a threshold value.
Here, since the virtual memory occupied by the application program does not exceed the preset threshold, that is, this does not cause memory leakage, no operation is required to be performed on the application program, and only an exception log that the memory mapping fails and the virtual memory does not exceed the threshold needs to be generated and stored by the log manager.
S613, the suicide recovery management module sends an instruction for starting a suicide recovery function to the process manager under the condition that the virtual memory occupied by the application program is determined to exceed a preset threshold value.
S614, the process manager responds to the instruction for starting the suicide recovery function to end all the processes of the application program.
In some embodiments, when the virtual memory occupied by the application program exceeds a preset threshold, the suicide recovery management module may send an instruction to the process manager to start a suicide recovery function, where the instruction is used to instruct the process manager to end all the processes of the application program, and release the system memory occupied by the application program.
All processes in the process manager, which are currently running in the system, can release the system memory occupied by the application program by integrating all processes related to the application program name through the process manager.
In some embodiments, when the electronic device starts the suicide recovery function, all processes of the application program may be directly ended, and at this time, the display interface of the electronic device may jump back to the main screen interface of the electronic device, i.e. the user perceives that the application program is flashing back.
In some embodiments, the process manager may also generate and save an exception log that ends the running of the application due to the virtual memory being too high after ending all of the processes of the application.
According to the application program management method provided by the embodiment of the application program, the situation that the process of the application program applies for the graphic buffer area to the memory manager is monitored, the suicide recovery function is started under the condition that the memory application fails and the occupation of virtual memory is excessive, all processes of the application program are ended, so that the memory occupied by the application program is released, serious consequences such as system crash and blocking caused by memory leakage are avoided, and the influence on the use of a user is reduced.
In order to reduce the influence on the use of the user, another embodiment of the application further provides an application management method, as shown in fig. 7, which is a schematic diagram of another interaction flow in the system of the electronic device in the process of executing the application management method provided in the embodiment of the application. The method specifically comprises the following steps:
the contents of S701 to S712 can be referred to the contents of S601 to S612, and in order to avoid repetition, the description is omitted here.
S713, the suicide recovery management module judges whether the process initiating the application of the graphic buffer is a main process or not under the condition that the virtual memory occupied by the application program is determined to exceed a preset threshold value.
Here, the suicide recovery management module may determine whether the process (currently running process) that initiated the graphic buffer application is a master process through the ID of the process.
Each process has its own ID, and the ID of the main process is significantly different from the ID of the sub-process, so that it can be determined whether it is the main process or the sub-process by the ID of the process.
S714, the suicide recovery management module sends an instruction for ending all the processes of the application program to the process manager when determining that the process for initiating the application of the graphic buffer is not a main process.
S715, the process manager responds to the instruction for ending all the processes of the application program, and ends all the processes of the application program.
Because the process of initiating the application of the graphic buffer is not the main process, the interface displayed by the electronic device is not the display interface of the main process of the application program, and may be a page which is entered after a plurality of operations by the user, and the electronic device cannot reproduce the page, so the electronic device only ends all the processes of the application program through the process manager to release the system memory occupied by the application program.
The implementation process of ending all the processes of the application program may be referred to as S614, and will not be described herein in detail to avoid repetition.
S716, the suicide recovery management module sends an instruction of restarting the main process of the application program after finishing all the processes of the application program to the process manager under the condition that the process of initiating the graphic buffer application is determined to be the main process.
In S717, the process manager responds to the instruction to restart the main process of the application program after ending all the processes of the application program, and restarts the main process of the application program after ending all the processes of the application program.
Because the process of initiating the application of the graphic buffer is the main process of the application program, the interface displayed by the electronic equipment is the main display interface of the application program, so that the main process of the application program is automatically pulled up after all the processes of the application program are ended, and the display interface of the electronic equipment can jump to the main display interface of the application program directly.
Because the interval time for pulling up the main process of the application program again after finishing the process of the application program is short, the user does not feel the interval time, and only can feel the display interface of the electronic equipment and jump back to the main display interface of the application program. At this time, the user does not feel that the application program flashes back, so that the user can be prevented from being influenced by the use of the user while the system memory occupied by the application program is released, and the user experience is improved.
Embodiments also provide a computer readable storage medium having instructions stored therein, which when run on a computer or processor, cause the computer or processor to perform one or more steps of any of the methods described above.
Embodiments of the present application also provide a computer program product comprising instructions. The computer program product, when run on a computer or processor, causes the computer or processor to perform one or more steps of any of the methods described above.
The embodiment of the application also provides a chip system containing the instruction. The instructions, when executed on a computer or processor, cause the computer or processor to perform one or more steps of any of the methods described above.
In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted across a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.
Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.
The foregoing is merely a specific implementation of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the embodiments of the present application should be covered by the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.
Claims (12)
1. A method for managing an application program, comprising:
running a first application in the foreground;
the first application applies for a graphic buffer at a first point in time;
ending the process of the first application at a second point in time;
when the process of the first application is finished, the first application applies for the graphic buffer area failure, the failure type is memory mapping failure, and the virtual memory occupied by the first application exceeds a preset threshold;
Wherein the second point in time is later than the first point in time.
2. The method of managing an application program according to claim 1, wherein at the second point in time, the process of the first application is ended based on at least the following conditions: the first application applies for the graphic buffer area failure, the failure type is memory mapping failure, and the virtual memory occupied by the first application exceeds a preset threshold value.
3. The method of managing an application program according to claim 1, wherein the first application and the second application are executed after the second point in time;
the first application applies for a graphic buffer at a third point in time;
ending the process of the second application at a fourth point in time;
and when the process of the second application is finished, the first application fails to apply for the graphic buffer area, and the failure type is insufficient system memory.
4. The method of managing an application program according to claim 1, wherein the failure type is judged between a first time point and a second time point;
when the failure type is memory mapping failure, acquiring virtual memory occupation conditions of the application program;
judging whether the virtual memory occupied by the application program exceeds a preset threshold value.
5. The method for managing an application program according to claim 4, wherein when the virtual memory occupied by the application program exceeds a preset threshold, all the processes of the application program are ended.
6. The method for managing an application program according to claim 4, wherein when a virtual memory occupied by the application program exceeds a preset threshold, determining whether a process applying the graphics buffer is a main process of the application program;
if the process applying the graphic buffer area is the main process of the application program, restarting the main process of the application program after finishing all the processes of the application program; otherwise, ending all the processes of the application program.
7. The method according to claim 4, wherein if the failure type is not a memory mapping failure, an exception log corresponding to the failure type is output;
if the virtual memory occupied by the application program does not exceed the preset threshold, outputting an abnormal log that the memory mapping fails and the virtual memory does not exceed the threshold.
8. The method according to any one of claims 4 to 7, wherein after ending all processes of the application, an exception log for ending the running of the application due to the virtual memory occupation is output.
9. The method for managing an application program according to claim 4, wherein when a process of the application program initiates a graphics buffer application, a memory application monitoring function is started to obtain an application result of the graphics buffer.
10. An electronic device comprising a processor and a memory, the processor and memory coupled, the memory for storing a computer program that, when executed by the processor, causes the electronic device to perform the steps of the method of any one of claims 1 to 9.
11. A computer readable storage medium, characterized in that the computer readable storage medium comprises a computer program which, when run on a computer, causes the computer to perform the steps of the method according to any one of claims 1 to 9.
12. A chip comprising a processor, the processor being coupled to a memory for storing computer program instructions that, when executed by the processor, cause the chip to perform the steps of the method of any of claims 1 to 9.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211578199.7A CN116107922A (en) | 2021-09-30 | 2021-09-30 | Application management method and electronic device |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111157747.4A CN114020652B (en) | 2021-09-30 | 2021-09-30 | Application program management method and electronic equipment |
CN202211578199.7A CN116107922A (en) | 2021-09-30 | 2021-09-30 | Application management method and electronic device |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111157747.4A Division CN114020652B (en) | 2021-09-30 | 2021-09-30 | Application program management method and electronic equipment |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116107922A true CN116107922A (en) | 2023-05-12 |
Family
ID=80055410
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211578199.7A Pending CN116107922A (en) | 2021-09-30 | 2021-09-30 | Application management method and electronic device |
CN202111157747.4A Active CN114020652B (en) | 2021-09-30 | 2021-09-30 | Application program management method and electronic equipment |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111157747.4A Active CN114020652B (en) | 2021-09-30 | 2021-09-30 | Application program management method and electronic equipment |
Country Status (1)
Country | Link |
---|---|
CN (2) | CN116107922A (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115309547B (en) * | 2022-07-31 | 2023-08-29 | 荣耀终端有限公司 | Method and device for processing asynchronous binder call |
CN115543864A (en) * | 2022-09-30 | 2022-12-30 | 荣耀终端有限公司 | Memory garbage recycling method and electronic equipment |
CN116737358B (en) * | 2022-10-28 | 2024-05-17 | 荣耀终端有限公司 | Memory refreshing method and electronic equipment |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7484065B2 (en) * | 2004-04-20 | 2009-01-27 | Hewlett-Packard Development Company, L.P. | Selective memory allocation |
CN103324500B (en) * | 2013-05-06 | 2016-08-31 | 广州市动景计算机科技有限公司 | A kind of method and device reclaiming internal memory |
CN105893269B (en) * | 2016-03-31 | 2018-08-21 | 武汉虹信技术服务有限责任公司 | EMS memory management process under a kind of linux system |
CN106339250B (en) * | 2016-08-19 | 2019-09-27 | 郭笃刚 | A kind of management method of computer virtual memory |
CN107329892B (en) * | 2017-06-07 | 2020-09-11 | 珠海市杰理科技股份有限公司 | Drive test method, device, storage medium and computer equipment thereof |
US11656985B2 (en) * | 2020-01-31 | 2023-05-23 | Kove Ip, Llc | External memory as an extension to local primary memory |
CN111274060B (en) * | 2020-02-10 | 2023-07-28 | 广州虎牙科技有限公司 | Method, device, equipment and storage medium for determining memory exception |
CN112162818B (en) * | 2020-09-16 | 2023-04-07 | Oppo(重庆)智能科技有限公司 | Virtual memory allocation method and device, electronic equipment and storage medium |
CN113010279A (en) * | 2021-02-20 | 2021-06-22 | 北京字节跳动网络技术有限公司 | Application program process processing method and device for mobile terminal and electronic equipment |
CN115809139A (en) * | 2021-06-16 | 2023-03-17 | 荣耀终端有限公司 | Memory management method and electronic equipment |
-
2021
- 2021-09-30 CN CN202211578199.7A patent/CN116107922A/en active Pending
- 2021-09-30 CN CN202111157747.4A patent/CN114020652B/en active Active
Also Published As
Publication number | Publication date |
---|---|
CN114020652B (en) | 2022-12-30 |
CN114020652A (en) | 2022-02-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP4145286A1 (en) | Memory management method and electronic device | |
EP3893118A1 (en) | Recovery from application anomaly | |
CN116107922A (en) | Application management method and electronic device | |
CN111966492B (en) | Memory recycling method and device, electronic equipment and computer readable storage medium | |
CN114489917B (en) | Processing method for abnormal exit of application program, electronic equipment and readable storage medium | |
CN112732434A (en) | Application management method and device | |
CN115016631B (en) | Process scheduling method and terminal equipment | |
CN115904761A (en) | System on chip, vehicle and video processing unit virtualization method | |
CN105760226A (en) | Method and device for rapidly starting mobile terminal camera and mobile terminal | |
CN116541180B (en) | Memory allocation method, electronic equipment and storage medium | |
CN110704157B (en) | Application starting method, related device and medium | |
CN116737404B (en) | Method and terminal device for application connection | |
CN116700813B (en) | Method for loading widget, electronic device and readable storage medium | |
CN117827709B (en) | Method, device, equipment and storage medium for realizing direct memory access | |
CN116661645B (en) | Method for displaying application card, electronic device and readable storage medium | |
CN116088955B (en) | Process processing method and terminal equipment | |
CN117130627B (en) | Fitting upgrading method and electronic equipment | |
CN116719466B (en) | Method for displaying multi-task interface, electronic equipment and storage medium | |
CN117094876B (en) | Data processing method, electronic device and readable storage medium | |
CN116361012B (en) | Memory page allocation method and electronic equipment | |
WO2024230268A1 (en) | Memory management method, terminal device and computer-readable storage medium | |
CN114625428B (en) | Application exception processing method and electronic equipment | |
CN114254233A (en) | Popup task processing method and device, storage medium and electronic equipment | |
CN117707718A (en) | Process management method, electronic device and readable storage medium | |
CN118277120A (en) | Method for managing system service and related device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |