CN114020652B

CN114020652B - Application program management method and electronic equipment

Info

Publication number: CN114020652B
Application number: CN202111157747.4A
Authority: CN
Inventors: 肖名鹏; 雒云; 李鹏
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-09-30
Filing date: 2021-09-30
Publication date: 2022-12-30
Anticipated expiration: 2041-09-30
Also published as: CN116107922A; CN114020652A

Abstract

The embodiment of the application provides a management method of an application program, which comprises the following steps: monitoring the 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 application failure, 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 value, starting a suicide recovery function of the application program to release the memory occupied by the application program, avoiding serious consequences such as system crash, deadlocking and the like caused by memory leakage, and reducing the influence on the use of a user.

Description

Application program management method and electronic equipment

Technical Field

The present application relates to the field of electronics, and in particular, to a management method for an application program and an electronic device.

Background

Memory leak (memory leak) refers to a phenomenon that a heap memory that has been dynamically allocated in an application program is not released or cannot be released in time due to some reason, resulting in waste of a system memory.

However, since the memory leak is not an error, the problems of difficult detection and difficult positioning exist at present, and finally, serious consequences such as memory overflow, abnormal operation of an application program and even system jam can be caused.

Disclosure of Invention

The application provides a management method of an application program, which can avoid the condition of system jamming caused by memory leakage at present.

In a first aspect, a method for managing an application program is provided, including: monitoring the 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 application failure, 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 value, starting a suicide recovery function of the application program.

In the running process of the application program, in order to draw an interface and store drawn data, a running process applies for a graphics buffer (graphics buffer) from a system memory.

For example, a graphics buffer shared between processes may be applied through a graphicbuffermapper, or a graphics buffer used by an application may be applied through a graphicbufferallocator process interface.

Because there is a possibility of memory leakage when applying for a graphics buffer from a memory manager, a memory application monitoring function can be started to monitor the application result of the graphics buffer when the graphics buffer application is initiated by the process of an application program.

It should be noted that the memory application monitoring function may also be started when the application program starts to run, the virtual memory usage condition of the application program may also be obtained in real time, the memory application monitoring function is started when the virtual memory usage of the application program exceeds a certain value (the value may be set according to an actual application scenario, which is not limited in this application), the memory application monitoring function may also be started when the virtual memory usage of the application program exceeds a certain value and a process of the application program initiates a graphics buffer application, and the memory application monitoring function may also be started in other situations.

For example, the monitoring of the above-mentioned open memory application 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 default starting of the memory application monitoring function.

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 the result of successful application.

When the available memory of the system is too little (the memory occupied by the applied graphic buffer area is larger than the available memory of the system), the applied memory can not be mapped to the address of the virtual memory of the process, and other abnormal conditions exist, the memory manager can return a result of failure application.

The virtual memory occupation condition of the application program can be called through a/proc/self/status function.

The preset threshold may be set according to an application program, for example, for a 32-bit application program, the preset threshold may be set to 3.7G. Of course, for a 32-bit application, the preset threshold may be set to some value lower than 3.7G, such as 3.5G, 3.2G, etc.

It can be seen from the above that, by monitoring the condition that the process of the application program applies for the graphics buffer area to the system memory, and starting the suicide recovery function when the memory application fails and the virtual memory occupies too much, the memory occupied by the application program is released, thereby avoiding serious consequences such as system crash, deadlocking and the like caused by memory leakage, and reducing the influence on the use of the user.

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 when the virtual memory occupied by the application program exceeds a preset threshold value, ending all processes of the application program.

When the virtual memory occupied by the application program exceeds the preset threshold, a command for ending all processes of the application program can be sent to the process manager, and the process manager responds to the command, ends all processes of the application program and releases the system memory occupied by the application program.

All processes currently running in the system in the process manager can release the system memory occupied by the application program by finishing all processes related to the application program name through the process manager.

The automatic checking and killing of the application program may be directly ending all processes of the application program, and at this time, the display interface of the electronic device may directly jump to a main screen interface of the electronic device, that is, the user feels that the application program is flashed off. All processes of the application program are directly finished, all the memory occupied by the application program can be released, and serious consequences such as system crash and jamming 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: when the virtual memory occupied by the application program exceeds a preset threshold value, judging whether the process applying for the graphic buffer area is a main process of the application program;

if the process applying for the graphic buffer area is the main process of the application program, finishing all processes of the application program and then re-pulling up the main process of the application program; otherwise, all processes of the application program are ended.

If the process applying for the graphic buffer area is the main process of the application program, the interface displayed by the electronic device is the main display interface of the application program, so that the main process of the application program is automatically pulled up after all processes of the application program are finished, and the display interface of the electronic device directly jumps to the main display interface of the application program.

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, so that a user cannot sense the interval time and can only feel that the display interface of the electronic equipment jumps back to the main display interface of the application program. At the moment, the user does not feel the application program flash back, so that the influence on the use of the user can be avoided 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 monitoring an application result of the graphics buffer during the running of the application program, the method further includes:

and if the application result of the graphic buffer area application is successful, mapping the applied memory to the address of the virtual memory of the process.

After the application of the graphics buffer area is successful (i.e., the system allocates the memory to the process for use), the process can display and draw the interface only when the graphics buffer area needs to be mapped into 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 further includes: and if the failure type is not the memory mapping failure, outputting an abnormal log corresponding to the failure type.

The failure type when the application fails may include too little available memory of the system, failure of memory mapping, other abnormal conditions, and the like, which is not limited herein.

In some embodiments, the electronic device may determine the failure type according to the application result returned by the memory manager. The failure type can be determined by analyzing the second code corresponding to the application result, for example.

Illustratively, when the application result includes two fields, wherein the first field is used for indicating whether the application is successful, the second field is used for indicating 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 the failure type is that the system available memory is too small according to the predetermined meaning corresponding to the code. For another example, if the application result is "01, 010", the content of the second field is read to be "010", and the failure type is a memory mapping failure according to the meaning corresponding to the predetermined code.

Further illustratively, when the application result only includes a field, wherein the 2 nd bit to the 4 th bit of the field are used for indicating the failure type, the codes of the second bit to the fourth bit are read, and the application result of the memory application is determined based on the codes of the second bit to the fourth bit.

For example, if the application result is "1001", the code "001" of the 2 nd bit to the fourth bit is read, and the failure type is that the system available memory is too small according to the predetermined meaning corresponding to the code. For another example, if the application result is "1010", the code "010" from the 2 nd bit to the 4 th bit is read, and the failure type is a memory mapping failure according to the predetermined meaning corresponding to the code.

For another example, when the application result is returned as error and accompanied by an error code, the failure type can be determined by the error code.

Because the failure type is not a memory mapping failure, the memory leakage basically cannot be caused, and therefore, the application program does not need to be operated, and only the abnormal log corresponding to the failure type needs to be output.

In some embodiments, the exception log may include a name of a process initiated by the application, a time when the exception occurs, and exception content, where the exception content includes a failure to apply for the graphics buffer and a failure type. For example, when the failure type is that the system available memory is too small, the exception may be that the B process of the a application fails to apply for the graphics buffer at xx because the system memory is too small.

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 above-mentioned abnormality log may be stored in a log manager, and the electronic device may read the abnormality log through the log manager.

In a possible implementation manner of the first aspect, the method for managing an application further includes: and if the virtual memory occupied by the application program does not exceed the preset threshold, outputting an abnormal log which fails in memory mapping and 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, the application program does not need to be operated, and only the abnormal log with the memory mapping failure and the virtual memory not exceeding the threshold needs to be output.

In a possible implementation manner of the first aspect, the method for managing an application further includes: and after finishing all processes of the application program, outputting an abnormal log for finishing the running of the application program due to overhigh virtual memory occupation.

And recording the abnormal condition of ending the operation of the application program due to overhigh virtual memory occupation in the form of an abnormal log, so that a user can conveniently check the abnormal condition.

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 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, an embodiment of the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the method according to any one of the first aspect is implemented.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements the method according to any one of the above first aspects.

In a fifth aspect, embodiments of the present application provide a chip system, where the chip system includes a processor, and the processor is coupled with a memory, and executes a computer program stored in the memory to implement the method according to any one of the above first aspects. The chip system can be a single chip or a chip module formed by a plurality of chips.

In a sixth aspect, embodiments of the present application provide a computer program product, which, when run on an electronic device, causes the electronic device to perform the method of any one of the above first aspects.

It is understood that the beneficial effects of the second to sixth aspects can be seen from the description of the first aspect, and are not described herein again.

Drawings

Fig. 1 is an exemplary schematic diagram illustrating an application display exception caused by a memory leak according to an embodiment of the present disclosure.

Fig. 2 is a schematic diagram of a 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 disclosure.

Fig. 4 is a schematic diagram of a graphical user interface in some application scenarios provided by an embodiment of the present application.

Fig. 5 is a schematic diagram of some graphical user interfaces in the process of starting a memory application monitoring function according to an embodiment of the present application.

Fig. 6 is a schematic implementation flowchart of an application management method according to an embodiment of the present application.

Fig. 7 is a schematic implementation flow diagram of another application management method provided in the embodiment of the present application.

Detailed Description

It is noted that the terminology used in the description of the embodiments of the present application is for the purpose of describing particular embodiments of the present application only and is not intended to be limiting of the present application. In the description of the embodiments of the present application, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" herein is merely an associative relationship describing associations, meaning that there may be three relationships, e.g., a and/or B, and may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality" means two or more than two, "at least one", "one or more" means one, two or more than two, unless otherwise specified.

In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a definition of "a first" or "a second" feature may explicitly or implicitly include one or more of the features.

Reference throughout this 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 present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

In order to better understand the embodiments of the present application, terms or concepts that may be referred to in the embodiments are described below.

1. Graphics buffer (graphics buffer)

Displaying and drawing the interface of the application program and saving the data of the displaying and drawing. In the running process of the application program, a graphic buffer area for displaying, drawing and storing display drawing data of an interface needs to be applied first, the specific graphic buffer area can be allocated from a system memory, and the graphic buffer area needs to be mapped into an address space of a virtual memory corresponding to the application program after the graphic buffer area is allocated from the system memory, so that the application program can run normally. For an application program with multiple processes, each process will firstly apply for a graphics buffer area during running, and similarly, after the graphics buffer area is successfully applied (that is, enough memory exists in the system and is allocated to the process for use), the graphics buffer area needs to be mapped into an address space of a virtual memory corresponding to the process, so that the process can run normally.

2. Garbage Collection (GC) mechanism

A mechanism to clear and reclaim unused objects to free memory. When the application is stuck and the response speed is slow (at this time, the memory usage is too high. For example, for a 32-bit application, if the memory usage exceeds 3G, it is determined that the memory usage is too high), the virtual machine triggers a Garbage Collection (GC) mechanism.

3. Low Memory Kill (LMK) mechanism

A memory cleaning mechanism of an Android system detects the memory use 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 processes with low priority through a background so as to release the memory. Specifically, the priority of the process is judged through the oom _ adj value of the process, and the smaller the oom _ adj value is, the higher the priority is, and the less the possibility that the process is killed when the LMK mechanism is triggered is. It should be noted that the value of oom _ adj of the foreground process is 0, i.e. the priority of the foreground process is the 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 capable virtual memory is 2 ³² I.e. 4G. In practical applications, the system is reserved to occupy a small portion, so for 32-bit applications, the maximum available virtual memory is 3.7G, and memory overflow is caused when the virtual memory exceeds 3.7G.

5. Memory overflow (out of memory, OOM)

The phenomenon that the memory required by the running of the application program is larger than the maximum memory which can be provided finally due to the fact that the memory which cannot be recycled or the used memory is excessive exists in the system, and the phenomenon of memory overflow is represented as 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 a memory is leaked, and further, the memory overflow of an application program is caused, so that the application program is blocked, and even the system is blocked. Memory leaks are mostly an accumulative process, with no signs until problems arise, and are therefore difficult to find and locate.

In practical applications, memory leaks may cause the following situations:

1. the application program is stuck and has a slow response speed, and a garbage collection mechanism is triggered, so that the application program has no response (ANR) or is flashed back.

2. Causing exceptions such as application display exceptions, partial functionality unavailability of the application, and the like.

For example, fig. 1 (a) is a schematic diagram of a display interface when an application a normally displays when no memory leak occurs, and as shown in fig. 1 (b), a display abnormality occurring when the application a has a memory leak may be represented as a condition of a messy code; for another example, as shown in fig. 1 (c), the display abnormality occurring when the memory leak occurs in the application a may be represented as a display incomplete condition; for example, as shown in (d) of fig. 1, the display abnormality occurring when the memory leak occurs in the application a may be represented as a case where a part of the functions is not displayed, and at this time, the part of the functions is in an abnormal state where the part of the functions is not available.

3. System crash, stuck-at, etc.

For example, when a user watches a video using a mobile phone, since a video playing application program continuously applies for a memory and does not release the memory during the process of playing the video, since the most available virtual memory of the video playing application program is fixed, the applied memory cannot be mapped into the virtual memory of the video playing application program after the upper limit of the usage of the virtual memory of the video playing application program is reached. Meanwhile, the memory allocated by the system is marked as used and cannot be allocated to other application programs (processes) for use, and the memory mapping failure can cause the application programs to continuously apply for the memory from the system, thereby causing memory leakage. However, since the video playing application program is still running in the foreground, the priority of the video playing application program is higher, so the video playing application program cannot be killed, and the occupied memory cannot be released, which finally causes the abnormal conditions of crash and jamming of the whole system. When the system crashes and the mobile phone is jammed, the user is required to forcibly restart the mobile phone to recover normal use, the operation is troublesome, and the user experience is influenced.

In practical applications, many applications are 32-bit applications, and when applying for a system memory from a system, the applications will continuously call a graphicbufferallocator process interface to apply for the memory. The maximum virtual memory that can be used by the 32-bit application program is 4G, however, since the graphicbufferallocator process is a 64-bit process, when the virtual memory of the application program exceeds 4G, the system memory can also be successfully applied to the system, and since the virtual memory of the application program already exceeds 4G, the applied memory cannot be mapped into the virtual memory, so that the system memory is applied but cannot be used, and cannot be released. And after the memory mapping fails, the application program can continue to apply for the memory by calling the graphicbufferallocator interface, so that the memory is continuously leaked, and finally, the abnormal conditions of system crash and jamming are caused.

As can be seen from the above description, the memory leak may cause various problems in case of explosion, and is not easy to reproduce, that is, the memory leak is not easy to find and solve, and the memory leak may also seriously affect the use of the user. Therefore, if the application program which possibly causes the memory leak is processed before the memory leak causes the abnormal condition, the serious abnormality such as system crash, card death and the like can be avoided, and the influence on the use of the user is reduced.

In view of the above problems and user requirements, an embodiment of the present application provides a method for managing an application program, where a situation that a process of the application program applies for a graphics buffer to a system memory is monitored, and when a memory application fails and virtual memory occupies too much, a suicide recovery function is started to end all processes of the application program, so as to release the memory occupied by the application program, thereby avoiding serious consequences such as system crash and jamming due to memory leakage, and reducing an influence on user usage.

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system architectures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application.

The execution subject of the management method of the application program may be an electronic device, and may be, for example, a mobile phone, a wearable device (such as a smart watch, a smart bracelet, smart glasses, smart jewelry, etc.), a tablet computer, an in-vehicle device, an Augmented Reality (AR)/Virtual Reality (VR) device, a notebook computer, a super-mobile personal computer (UMPC), a netbook, a Personal Digital Assistant (PDA), and other electronic devices with a network connection function.

Exemplary embodiments of the above-described electronic device include, but are not limited to, a mount

A hong meng system (Harmony OS) or other operating system. The electronic device may also be other electronic devices, such as a laptop computer (laptop) with a touch-sensitive surface (e.g., a touch panel), and the specific type of the electronic device is not limited in any way in the embodiments of the present application.

Taking the above-mentioned electronic device as a mobile phone as an example, as shown in fig. 2, a schematic structural diagram of a mobile phone provided in the embodiment of the present application is shown.

Fig. 2 shows a schematic structural diagram 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 (USB) interface 130, a charging 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, a button 190, a motor 191, an indicator 192, a camera 193, a display 194, a Subscriber Identity Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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 is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the mobile phone 100. In other embodiments of the present application, the handset 100 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors.

Wherein the controller may be a neural center and a command center of the cell phone 100. The controller can generate an operation control signal according to the instruction operation code and the time sequence signal 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 have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

Illustratively, the software system of the handset 100 may employ a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. The embodiment of the present invention uses an Android system with a layered architecture as an example to exemplarily illustrate a software structure of the mobile phone 100. Fig. 3 is a block diagram of a software configuration of the mobile phone 100 according to the embodiment of the present application.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages. As shown in fig. 3, the application packages may include camera, gallery, calendar, phone, map, navigation, WLAN, bluetooth, video, instant chat, etc. applications.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program 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 obtain 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 it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, 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, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, 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, text information is prompted in the status bar, a prompt tone is given, the terminal vibrates, and an indicator light flashes.

The suicide recovery management module is an application management mechanism that starts automatic killing of the application to release the memory when detecting that the running application satisfies the suicide recovery condition mentioned in the embodiments of the present application.

In this embodiment of the present application, the suicide recovery condition may be that a memory application fails, where the failure type is a virtual memory mapping failure, and a virtual memory occupied by the application program exceeds a preset threshold.

In the embodiment of the present application, the automatic checking and killing of the application program may be directly ending all processes of the application program, at this time, the display interface of the mobile phone 100 may directly jump to the main screen interface of the mobile phone 100, that is, the user feels that the application program is flashed off; the automatic searching and killing of the application program may also be automatically pulling up the main process of the application program after all processes of the application program are finished, and at this time, the display interface of the mobile phone 100 may directly jump to the main display interface of the application program. Since the interval time for pulling up the main process of the application again after the process of the application is finished is short, the user cannot perceive the event, and can only feel that the display interface of the mobile phone 100 jumps back to the main display interface of the application.

In some embodiments of the present application, the suicide recovery management module further has a memory application monitoring function, and can automatically start the memory application monitoring function when the application program sends a memory application to the system memory, so as to monitor whether the memory application is successful.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises 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. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of target life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), and the like.

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 management method of the application program provided by the embodiment of the application program can be operated in the application program framework layer, namely, the management method of the application program can be realized through a suicide recovery management module in the application program framework layer.

The management method of the application program provided by the embodiment of the application program can be suitable for various use scenes with memory leakage. For example, the management method of the application program provided by the embodiment of the application program can be applied to scenes that a user watches videos by using an electronic device or looks up pushed articles by using instant chat software and the like.

For example, when a user views a pushed article (which may be a newsfeed article/video, etc.) using instant chat software, the process of the application applies for a graphics buffer to the system memory for display rendering of the interface and saving data of the display rendering. When the process of the application program initiates a graphic buffer area 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 the moment, the graphic buffer area application fails, the failure type is the virtual memory mapping failure, and the virtual memory occupied by the application program exceeds a preset threshold), the suicide recovery is started, so that the application program releases the memory, and the condition that the whole mobile phone system is crashed and jammed is avoided.

Illustratively, as shown in fig. 4, a diagram of some Graphical User Interfaces (GUIs) that may be involved in application scenario one is shown.

In some embodiments, the interface of the instant chat software includes a main display area 10 ("information" corresponding interface), other functional areas 20 (e.g., "address book", "dynamic", etc. in fig. 4 (a)), and sub-conversations 30. The main display area 10 displays a plurality of sub-dialogs 30, and specifically, may be displayed in the form as in (a) of fig. 4. When a user wants to view an article pushed by a certain sub-conversation, the user can click a control corresponding to the sub-conversation (for example, the sub-conversation of contact 1), so that the display interface of the instant chat software jumps to the display interface corresponding to the sub-conversation (as shown in (b) in fig. 4).

In some embodiments, as shown in fig. 4 (c), when an application program is in an operating process, for example, a user clicks a sub-dialog to check a dialog, and a process corresponding to the sub-dialog needs to apply for a graphics buffer, 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, "can a memory leak be caused by the operation, and whether to start a memory application monitoring function so as to ensure that a system operates normally? ". When the mobile phone receives an operation that the user confirms to start the memory application monitoring function (for example, the user clicks a "confirmation" icon shown in (c) of fig. 4), the memory application monitoring function can be started to monitor the process of applying for the graphic buffer area by the process.

In some embodiments, after the mobile phone obtains the application result of the image buffer area, if the application is successful, the application program continues to operate normally; if the application fails, the reason of the application failure is further analyzed, if the reason of the application failure is the virtual memory mapping failure, 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 value, a suicide recovery function is started.

In some embodiments, when the mobile phone starts the suicide recovery function, all processes of the application program may be directly ended, and the display interface of the mobile phone may jump back to the main screen interface of the mobile phone (the interface shown in fig. 4 (d)).

Or when the mobile phone starts the suicide recovery function, the main process of the application program may be automatically pulled up after all processes of the application program are ended, so that the display interface of the mobile phone displays the main display interface of the application program (e.g., the interface shown in fig. 4 (a)).

It should be understood that the interface shown in fig. 4 is only an example, and the embodiment of the present application does not limit the specific content (e.g., the specific content of the prompt message) displayed on the interface, the display position of the prompt message, and the like. For example, the prompt message shown in fig. 4 may be set to prompt in the status bar, and the message identifier is displayed to prompt the user that the relevant information is available for viewing, so as not to affect the user to view the information. When the user needs to check, the status bar can be pulled down to click the relevant information for checking. Or, the related information can be displayed in a small window form at the position of the instant chat interface, such as the lower right corner or the upper right corner, so that the user is prompted, the shielding of the 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 default starting of the memory application monitoring function.

Mode 1, the user actively starts the memory application monitoring function

For example, as shown in fig. 5, a schematic view of some graphical user interfaces involved in the process of starting the memory application monitoring function provided in the embodiment of the present application is provided. Here, the electronic device is a mobile phone as an example.

In some embodiments, when the application program starts running and the process initiates an application for creating a graphics buffer to the system memory, the mobile phone may prompt the user to start a memory application monitoring function. The manner of prompting the user may be, for example, a manner of displaying a prompt message through an interface (as shown in fig. 4 (c)), or a manner of voice; or the prompt information is displayed through an interface and combined with a voice mode and the like.

Illustratively, as shown in fig. 5 (a), it 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 icons, such as a clock icon, a calendar icon, a gallery icon, a memo icon, a file management icon, an e-mail icon, a music icon, a calculator icon, a recorder icon, an exercise health icon, an instant chat icon, a browser icon, a setting icon, and the like. Beneath the plurality of application icons may be a page indicator display area 52 that includes a page indicator to indicate the positional relationship of the currently displayed page to other pages. A tray application icon display area 53 for displaying a plurality of tray application icons, such as a camera application icon, a contact list application icon, a phone dial application icon, an information application icon, and the like, may be displayed below the page indicator. In other embodiments, the cell phone home screen interface may include more or fewer application icons or tray application icons than those shown, which are not limited in this application. A status bar 54 may also be displayed above the home screen interface, the status bar 54 may include: one or more signal strength indicators for mobile communication signals (or cellular signals), power level indicators for handsets, time indicators, etc.

In some embodiments, the mobile phone may receive a click operation of a user for setting an icon; in response to the user's click operation, the cellular phone may display a setting detail interface as shown in (b) in fig. 5.

As shown in (b) of fig. 5, the setting detail interface may include management columns for a plurality of services, such as a wireless and network management column, a bluetooth management column, a desktop and wallpaper management column, a display management column, a sound management column, an application management column, a battery management column, a storage management column, a security and privacy management column, and the like. In practical applications, the setting interface may further include more or fewer types of management columns than those shown in the drawings, which is not limited in this application.

In some embodiments, the mobile phone may receive a click operation of a user on the application management bar; in response to the click operation by the user, the cellular phone may display an application management interface as shown in (c) of fig. 5.

Illustratively, the application interface may include a plurality of service management fields, including, for example: system application setting, application monitoring management, application double opening, authorization management and the like. The next page indicator corresponding to each service can be displayed behind the name of each service.

In some embodiments, as shown in fig. 5 (c), the handset may receive a click operation of a next page indicator in the application monitoring management bar. In response to the click operation of the user, the mobile phone may display an application monitoring management interface as shown in (d) in fig. 5.

For example, as shown in fig. 5 (d), the application monitoring management interface may include description contents 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 content of the memory application monitoring function is used for introducing the memory application monitoring function, so that a user can more clearly understand the function of the function. The description content may be, for example, "after the switch turns on the memory application monitoring function, the system will monitor the result of applying for the system memory for the running application program, and sometimes find the case of memory leak". In some embodiments, the switch control corresponding to the memory application monitoring function may be displayed in a lower area where the memory application monitoring function is introduced, 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 memory application monitoring function switch can be independently set for different application programs, so that a user can selectively and more appropriately use the memory application monitoring function according to 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 on the processes of certain application programs is avoided, so that the use experience of a user is guaranteed.

Mode 2, the mobile phone automatically starts the memory application monitoring function

In a possible implementation manner, when the application program starts to run, the mobile phone may automatically start the memory application monitoring function, or when the application program initiates a memory application (application graphics buffer) to the system memory, the mobile phone automatically starts the memory application monitoring function to monitor the memory application condition.

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 execute the application monitoring function currently. Alternatively, query information may be displayed to ask the user whether to confirm that the mobile phone executes the memory application monitoring function (as shown in fig. 4 (c)). For example, the prompt message or the query message 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, in this manner, the process of the mobile phone automatically starting the memory application monitoring function may be imperceptible to the user. By applying the monitoring function to the memory in the mode, the influence on the currently running application can be avoided, such as video pause and the like, so that the user experience is ensured.

Mode 3, default memory opening application monitoring function

In a possible implementation manner, before the mobile phone leaves the factory, the memory application monitoring function may be set to a default on state, so that the memory application may be monitored and managed at any time in the process of using the mobile phone by a subsequent user.

In combination with the above-described exemplary starting manner, the method for monitoring the memory application provided in the embodiment of the present application may be performed in a form that a user has perception (for example, the user actively starts, or displays related information to the user, or the like), or may also be performed in a form that the user does not perceive, which is not limited in the embodiment of the present application.

In the foregoing, with reference to the accompanying drawings, an application scenario to which the management method for an application program provided in the embodiment of the present application is applied, a starting manner of a corresponding function, and the like are described. In order to better understand the method for predicting the signal strength provided by the embodiments of the present application, specific implementation procedures thereof are exemplarily described below with reference to the accompanying drawings.

Exemplarily, as shown in fig. 6, a schematic view of an interaction flow in a system of an electronic device in the process of executing a management method of an application program for the electronic device provided in the embodiment of the present application is provided. The method specifically comprises the following steps:

s601, in the running process of the application program, the process of the application program applies for a graphic buffer area from the 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 speed and reduce the redundancy of the application program, the application program is usually a multi-process application program, and a master-slave relationship may be established among a plurality of processes.

In the running process of the application program, in order to draw an interface and store drawn data, a running process applies for a graphics buffer (graphics buffer) from a memory manager, and taking an Android system as an example, the following method may be used for applying for the graphics buffer from the memory manager by the process:

mode 1: and applying for the graphics buffer area shared among the processes through the graphics buffer mapper.

The Android system provides a grapicbuffermapper tool class that provides an interface in the upper access hardware abstraction layer (the gralloc module).

When an application program in a user space uses a graphics buffer, a granloc module needs to be loaded first, and a granloc device and a fb device are obtained, after the granloc device is available, the application program in the user space can apply for allocating a graphics buffer, and map the graphics buffer to an address space of the application program, so that the content of a picture to be drawn can be written into the graphics buffer. Finally, the application program in the user space renders the prepared graphic buffer area to the frame buffer area through the fb device, that is, the content of the graphic buffer area is drawn to the display screen, so as to realize the interface display of the application program.

Mode 2: and applying for a graphic buffer area used by the application program through a graphic buffer manager process interface.

The Android system also provides a graphicbufferallocator process interface, and the graphicbufferallocator process interface can be universally used for applying to the image buffer area.

S602, the suicide recovery management module starts a memory application monitoring function.

Here, after the suicide restoration management module starts the memory application monitoring function, an instruction for acquiring an application result of the graphics buffer application is sent to the memory manager.

In some embodiments, the suicide recovery management module may start the memory application monitoring function when the application program starts running, or may start the memory application monitoring function when the process of the application program initiates a graphics buffer application to the system memory, and the suicide recovery management module may further obtain the virtual memory occupancy of the application program in real time, and start the memory application monitoring function when the virtual memory occupancy of the application program exceeds a certain value (which may be set according to an actual application scenario, which is not limited in the present application), or start the memory application monitoring function when the virtual memory occupancy of the application program exceeds a certain value and the process of the application program initiates a graphics buffer application, or certainly start the memory application monitoring function in other situations, which is not described in the present application.

The above-mentioned manner for starting the memory application monitoring function may refer to the above-mentioned related contents, and is not described herein again in order to avoid repetition.

Here, the application result of the graphics buffer application includes application success and application failure.

The application result may be represented in the form of a binary code. 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 is successful or not includes 2 bits, where 00 indicates success of the application and 01 indicates failure of the application; the corresponding failure type for indicating that the application fails includes 3 bits, where 001 indicates that the available memory of the system is too low, 010 indicates that the memory mapping fails, 011 indicates other abnormal conditions, etc. (when the first field is 00, the corresponding second field is 000).

Of course, the application result may include only one field, and the field may indicate whether the application is successful or not, and may also indicate a corresponding failure type when the application fails. Illustratively, the field includes 4 bits, where the first bit is used to indicate whether the application is successful, the second to fourth bits are used to indicate corresponding failure types when the application fails, for example, 0000 indicates that the application is successful, 1001 indicates that the application fails and the failure type is that the system has too little available memory, 1010 indicates that the application fails and the failure type is that the memory mapping fails, 1011 indicates that the application fails and the failure type is other abnormal conditions.

Of course, when the application is successful, no _ error may be returned; when the application fails, error can be returned and accompanied by an error code, and the failure type is indicated by the error code.

It should be understood that the above is only an example of the application result, and the application result may also include other contents, such as the time returned, and the like, which is not limited in this application.

S603, the memory manager responds to the instruction for obtaining the application result of the image buffer area application, and sends the application result of the image buffer area application to the suicide restoration management module.

Specifically, when a process of an application program sends an image buffer application to a system memory, and when a system available memory 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 successful application result to a suicide restoration management module.

When the available memory of the system is too little (the memory occupied by the applied graphic buffer area is larger than the available memory of the system), the applied memory cannot be mapped into 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 applies for the graphics buffer by means of the mode 2 in S601, that is, when the process applies for the graphics buffer used by the application through the graphics bufferlocker process interface, although the application of the graphics buffer fails for the process, the memory manager actually allocates the memory required by the graphics buffer applied for the process to the process, and the process continues to initiate the application after the application fails, so that the more the memory allocated for the process by the system (actually not used) is accumulated, the more the system memory is accumulated, and finally the situation that the system memory is insufficient and the whole machine crashes and dies is caused.

S604, the suicide recovery management module detects that the received application result of the graphics buffer application is successful, and then the suicide recovery management module sends a mapping instruction to the application program.

S605, in response to the mapping instruction, the application maps the applied memory to the address of the virtual memory of the process of the application.

After the suicide restoration management module receives the application result sent by the memory manager, whether the application of the graphic buffer area is successful can be determined by analyzing the binary code corresponding to the application result. Illustratively, when the application result includes two fields, wherein the first field is used to indicate whether the application is successful, the encoding of the field is read, and the graphics buffer application result can be determined based on the encoding of the field.

For example, if the result of the application received by the suicide restoration management module is "00, 000", the content "00" of the first field is read, and the result of the application is successful according to the predetermined meaning corresponding to the code. For example, if the application result is "01, 010", the content of the first field is read as "01", and the application result is application failure as understood from the meaning corresponding to the predetermined code.

For another example, when the application result only includes one field, where the 1 st bit 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 the application result is successful according to the predetermined meaning corresponding to the code. For another example, if the application result is "1010", the code "1" of the first bit is read, and the application result is application failure, as can be seen from the predetermined meaning corresponding to the code.

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 may be implemented in the existing manner, which is not described herein again.

And S606, the suicide recovery management module analyzes the failure type according to the application result if detecting that the application result of the received graphic buffer area application is application failure.

The process of determining that the application result of the memory application is an application failure by the suicide recovery management module may refer to the description of S604, and is not described herein again to avoid repetition.

The failure type when the application fails may include too little system available memory, failure of memory mapping, other abnormal conditions, and the like, which is not limited herein.

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 can be determined by analyzing the second code corresponding to the application result, for example.

For another example, when the application result only includes one field, wherein the 2 nd bit to the 4 th bit of the field are used to indicate the failure type, the codes of the second bit to the fourth bit are read, and the application result of the memory application is determined based on the codes of the second bit to the fourth bit.

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 related content of the failure type determination may be referred to in the description of S606, which is not described herein.

S608, the log manager generates and saves an exception log corresponding to the failure type in response to the first exception log output instruction.

Here, the first exception log output command is used to instruct the log manager to generate and save an exception log corresponding to the failure type.

Because the failure type is not a memory mapping failure, the memory leakage is not caused basically, and therefore, any operation is not required to be performed on the application program, and only the log manager needs to be controlled to generate and store the abnormal log corresponding to the failure type, so that the user can know the failure type of the application failure of the graphics buffer, and other related information (for example, 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 name of a process initiated by the application, a time when the exception occurs, and exception content, where the exception content includes a failure to apply for the graphics buffer and a failure type. For example, when the failure type is that the system available memory is too small, the exception may be that the B process of the a application fails to apply for the graphics buffer due to the system memory being too small in xx time.

In some embodiments, when the failure type is too little system memory, the electronic device may initiate an LMK mechanism based on the exception log.

S609, the suicide recovery management module acquires the virtual memory occupation condition of the application program under the condition that the failure type is determined to be the memory mapping failure.

When the failure type is memory mapping failure, the virtual memory of the application program is occupied too much, which is likely to cause system memory leakage.

In some embodiments, the suicide recovery management module may invoke the virtual memory usage 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 a/proc/self/status function to obtain the current virtual memory occupation condition of the application program.

S610, the suicide recovery management module judges whether the virtual memory occupied by the application program exceeds a preset threshold value.

S611, the suicide recovery management module sends a second abnormal log output instruction to the log manager when determining that the virtual memory occupied by the application program does not exceed the preset threshold.

S612, the log manager responds to the second abnormal log output instruction, and generates and stores an abnormal log in which the memory mapping fails and the virtual memory does not exceed the threshold.

Here, the first exception log output instruction is used to instruct the log manager to generate and store an exception log in which the memory mapping fails and the virtual memory does not exceed a threshold.

Here, since the virtual memory occupied by the application program does not exceed the preset threshold, that is, this does not cause memory leak, it is only necessary to generate and store an exception log in which the memory mapping fails and the virtual memory does not exceed the threshold, by the log manager, without performing any operation on the application program.

S613, the suicide recovery management module sends an instruction to start the suicide recovery function to the process manager when it is determined that the virtual memory occupied by the application exceeds the preset threshold.

S614, the process manager responds to the instruction for starting the suicide recovery function, and all processes of the application program are ended.

In some embodiments, when the virtual memory occupied by the application program exceeds the preset threshold, the suicide recovery management module may release the system memory occupied by the application program by sending, to the process manager, an instruction for starting the suicide recovery function, where the instruction is used to instruct the process manager to end all processes of the application program.

All processes currently running in the system in the process manager are finished through the process manager, and the system memory occupied by the application program can be released.

In some embodiments, when the electronic device starts the suicide resume 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, that is, the user feels that the application program is flashed off.

In some embodiments, after the process manager finishes all processes of the application program, the log manager may further generate and store an exception log for finishing the running of the application program due to the over-high virtual memory usage.

According to the application program management method provided by the embodiment of the application program, the condition 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 virtual memory occupies too much, all processes of the application program are finished to release the memory occupied by the application program, serious consequences such as system crash, jamming and the like caused by memory leakage are avoided, and the influence on the use of a user is reduced.

In order to alleviate the influence on the use of the user, another embodiment of the present application further provides an application management method, as shown in fig. 7, which is another schematic interaction flow diagram in a system of an electronic device in a process of executing the management method of the application provided by the embodiment of the present application for the electronic device provided by the embodiment of the present application. The method specifically comprises the following steps:

the contents of S701 to S712 can refer to the contents of S601 to S612, and are not described herein again to avoid repetition.

S713, the suicide recovery management module judges whether the process initiating the graphic buffer application is the main process under the condition that the virtual memory occupied by the application program is determined to exceed the preset threshold value.

Here, the suicide recovery management module may determine whether the process (currently running process) that initiated the graphics buffer application is the host process by 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 finishing all processes of the application program to the process manager under the condition that the process for initiating the graphic buffer application is determined not to be the main process.

S715, the process manager responds to the instruction for ending all processes of the application program, and ends all processes of the application program.

Since the process initiating the graphic buffer application is not the host process, the interface displayed by the electronic device is not the display interface of the host process of the application at this time, and may be a page that is entered after a plurality of operations by the user, and the electronic device cannot reproduce the page, so that the electronic device only ends all processes of the application through the process manager to release the system memory occupied by the application.

The implementation process of ending all processes of the application program may refer to the description of S614, and is not described herein again to avoid repetition.

S716, the suicide recovery management module sends an instruction for re-pulling the main process of the application program to the process manager after all processes of the application program are finished under the condition that the process initiating the graphic buffer application is determined to be the main process.

S717, the process manager responds to the instruction for re-pulling up the main process of the application program after finishing all the processes of the application program, and re-pulling up the main process of the application program after finishing all the processes of the application program.

Since the process initiating the graphic buffer application is the main process of the application program, the interface displayed by the electronic device is the main display interface of the application program at this time, and therefore, after all processes of the application program are finished, the main process of the application program is automatically pulled up, and at this time, the display interface of the electronic device can directly jump to the main display interface of the application program.

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, so that a user cannot sense the interval time and can only feel that the display interface of the electronic equipment jumps back to the main display interface of the application program. At this time, the user does not feel the application program flash back, so that the influence on the use of the user can be avoided while the system memory occupied by the application program is released, and the user experience is improved.

Embodiments of the present application also provide a computer-readable storage medium having stored therein instructions, which when executed on a computer or processor, cause the computer or processor to perform one or more steps of any one of the methods described above.

Embodiments of the present application further provide a computer program product containing 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, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, it 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, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in or transmitted over a computer-readable storage medium. The computer instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optics, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), among others.

One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

The above description is only a specific implementation of the embodiments of the present application, but the 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 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

1. A method for managing an application program, comprising:

monitoring the 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 application failure, 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 value, starting a suicide recovery function of the application program.

2. The method for managing an application according to claim 1, wherein if the virtual memory occupied by the application exceeds a preset threshold, the method for starting a suicide recovery function includes:

and when the virtual memory occupied by the application program exceeds a preset threshold value, ending all processes of the application program.

3. The method for managing application programs according to claim 1, wherein if the virtual memory occupied by the application program exceeds a preset threshold, the method for starting suicide recovery function comprises:

when the virtual memory occupied by the application program exceeds a preset threshold value, judging whether the process applying for the graphic buffer area is a main process of the application program;

if the process applying for the graphic buffer area is the main process of the application program, finishing all the processes of the application program and then re-pulling up the main process of the application program; otherwise, all processes of the application program are ended.

4. The method for managing an application program according to claim 1, wherein after monitoring the application result of the graphics buffer during the running of the application program, the method further comprises:

5. A method for managing an application program according to any one of claims 1 to 4, further comprising:

and if the failure type is not the memory mapping failure, outputting an abnormal log corresponding to the failure type.

6. A method for managing an application program according to claim 1, further comprising:

and if the virtual memory occupied by the application program does not exceed the preset threshold, outputting an abnormal log which fails in memory mapping and does not exceed the threshold.

7. A method for managing an application program according to claim 2 or 3, further comprising:

and after finishing all processes of the application program, outputting an abnormal log for finishing the operation of the application program due to overhigh virtual memory occupation.

8. The method for managing application programs according to claim 1, wherein the monitoring of the application result of the graphics buffer during the running of the application program comprises:

when the process of the application program initiates the application of the graphic buffer area, the memory application monitoring function is started to obtain the application result of the graphic buffer area.

9. An electronic device, comprising a processor and a memory, the processor and the memory being coupled, the memory being configured to store a computer program which, when executed by the processor, causes the electronic device to carry out the steps of the method of any one of claims 1 to 8.

10. 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 carry out the steps of the method according to any one of claims 1 to 8.