Application management method and device, electronic equipment and medium

Abstract

The invention discloses an application management method and device, electronic equipment and a medium, and relates to the technical field of terminals. The method comprises the steps that under the condition that a first application runs in the background, the background searching and killing time of the first application is determined according to first information of the first application, and the first information comprises at least one of heap memory occupation information of the first application in the foreground running process and lagging performance information of the first application in the foreground running process; the position of the first application in the background task list and the background working state information of the first application; and if the first application keeps running in the background before the background searching and killing time, stopping running the first application after the background searching and killing time is up.

Description

Technical Field

[0001] This application belongs to the field of terminal technology, specifically relating to an application management method, device, electronic device, and medium. Background Technology

[0002] Currently, when an application is launched, an electronic device can allocate a heap memory from the device's memory for the application, and the upper limit of the heap memory for a single application is fixed, such as usually 256MB or 512MB.

[0003] To ensure the normal operation of the application, the virtual machine corresponding to the application can use the garbage collection (GC) algorithm to reclaim memory, thereby releasing the memory occupied by useless objects in the heap memory for the application to continue to use.

[0004] However, as the heap memory used by applications gradually increases, the frequency of garbage collection (GC) triggered by the virtual machine also increases. Frequent GC, especially blocking GC, may cause application lag and overheating of electronic devices, thereby affecting the operating performance of electronic devices. Summary of the Invention

[0005] The purpose of this application is to provide an application management method, device, electronic device, and medium that can improve the operating performance of electronic devices by differentially detecting and eliminating applications running in the background.

[0006] In a first aspect, embodiments of this application provide an application management method, which includes: when a first application is running in the background, determining the background kill time of the first application based on first information of the first application, wherein the first information includes at least one of the following: heap memory usage information of the first application during its foreground operation, lag performance information of the first application during its foreground operation, position of the first application in the background task list, and background working status information of the first application; if the first application remains running in the background before the background kill time, then the first application is terminated after the background kill time is reached.

[0007] Secondly, embodiments of this application provide an application management device, which includes a processing module. The processing module is used to: collect heap memory usage information of a first application during its foreground operation, collect information on the lag performance of the first application during its foreground operation, collect the position of the first application in the background task list, and collect background working status information of the first application; if the first application is running in the background before the background kill time, then the first application will be terminated after the background kill time is reached.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, and when the program or instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

[0010] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.

[0012] In this embodiment of the application, when the first application is running in the background, the background killing time of the first application can be determined based on the first information of the first application. The first information includes at least one of the following: heap memory usage information of the first application during its foreground operation, lag performance information of the first application during its foreground operation, position of the first application in the background task list, and background working status information of the first application. If the first application is running in the background before the background killing time, the first application will be terminated after the background killing time is reached. In this solution, the background kill time for each background application can be dynamically determined based on at least one of the following: heap memory usage information of the background application (i.e., the application running in the background, such as the first application) during its foreground operation; lag performance information during its foreground operation; its position in the background task list; and background working status information. Therefore, on the one hand, background applications with memory leaks, lag, no background tasks, or those not used by the user in the short term can be killed as quickly as possible, effectively avoiding lag probability and device overheating of foreground applications and improving the operating performance of electronic devices. On the other hand, it can ensure that applications with normal memory usage, no lag, performing background tasks, or those that the user may use in the short term can remain in the background for a longer period, improving the continuity of user experience with applications with normal memory usage and thus improving the operating performance of electronic devices. Attached Figure Description

[0013] Figure 1 This is one of the flowcharts of the application management method provided in the embodiments of this application;

[0014] Figure 2This is the second flowchart of the application management method provided in the embodiments of this application;

[0015] Figure 3 This is a schematic diagram of the structure of the application management device provided in the embodiments of this application;

[0016] Figure 4 This is one of the structural schematic diagrams of the electronic device provided in the embodiments of this application;

[0017] Figure 5 This is the second schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0019] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0020] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0021] The following explains the nouns or terms used in the embodiments of this application.

[0022] 1. Heap memory: This is a memory area used to dynamically store objects during application runtime. The management method of heap memory (manual or automatic) depends on the programming language, but the role of heap memory is always to support flexible memory allocation. Heap memory has the following characteristics:

[0023] Dynamic allocation: Applications can request a specific amount of memory space as needed during runtime;

[0024] Automatic management: Failure to release heap memory can lead to memory leaks. In languages ​​like Java, heap memory is automatically managed by the virtual machine's garbage collection (GC) mechanism, eliminating the need for manual release.

[0025] Storage content: Primarily stores application object instances and arrays. In Java, all objects created using the `new` keyword are stored in heap memory.

[0026] Memory Structure: The application's heap memory is a non-contiguous memory region, typically managed through linked lists of free blocks, expanding towards higher memory addresses, which can potentially lead to memory fragmentation.

[0027] Flexibility and overhead: Compared to stack memory, heap memory allocation and deallocation are slower, but it offers greater flexibility and larger memory space (limited by virtual memory), making it suitable for storing data with uncertain lifecycles or large volumes.

[0028] Garbage Collection (GC) algorithm: This refers to the algorithm used by the virtual machine to automatically identify and reclaim the memory space occupied by objects in the heap that are no longer referenced (i.e., "garbage"). The Android virtual machine uses a generational garbage collection algorithm, which divides the heap into "young generation" and "old generation" based on the object's lifespan and employs different reclamation strategies to improve efficiency and reduce application pause times. In short, the GC algorithm manages the application's own heap memory, reclaims unused objects, and releases space for the application to continue using.

[0029] Memory reclamation by garbage collection algorithms may cause localized, brief pauses in the application ("Stop-The-World" pauses). It should be noted that frequent Full GC (i.e., blocking GC) will lead to significant performance degradation and heat generation.

[0030] 2. Memory Killing: The purpose of memory killing is to manage the overall resources of the system and forcibly release all memory occupied by the entire application process, such as Java heap memory, local heap memory, and graphics memory. Performing memory killing on an application is equivalent to terminating its operation; when the application is run again, a cold start is required, i.e., reloading from the initial interface.

[0031] 3. Top-tier applications: These refer to applications with a huge user base, extremely high activity levels, complex functions, massive codebases, and very high demands on system resources (such as memory and CPU). Examples include game applications, shopping applications, and short video applications.

[0032] 4. Daily active user rate of an application: This refers to the number of users who log in and use the application within a certain period of time (usually one day).

[0033] The application management method, device, electronic device, and medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0034] The application management method, apparatus, electronic device, and medium provided in this application embodiment can be applied to scenarios that optimize background application management.

[0035] Scenario 1: The header application running in the management background. The header application is used for a long time and is very prone to memory leaks or sudden high memory usage due to code defects or business load.

[0036] Scenario 2: Frequent switching between multiple applications. In this scenario, users switch between multiple applications simultaneously, such as chatting while browsing the web and occasionally watching short videos; this leads to an increase in the number of applications running in the background of the electronic device, increasing the system memory pressure.

[0037] Scenario 3: Devices with limited performance or "optimization for survival" scenarios. This includes entry-level phones with limited memory (e.g., 4GB or less), or devices that have been used for many years and have aging batteries. These devices are extremely resource-constrained, and background applications have poor retention rates. High-memory applications not only consume resources, but their frequent garbage collection (GC) further increases CPU load, leading to rapid device overheating, increased power consumption, and overall lag.

[0038] In the application management method provided in this application embodiment, when the first application is running in the background, the background killing time of the first application can be determined according to the first information of the first application. The first information includes at least one of the following: heap memory usage information of the first application during its foreground operation, lag performance information of the first application during its foreground operation, position of the first application in the background task list, and background working status information of the first application. If the first application is running in the background before the background killing time, the first application will be terminated after the background killing time is reached. In this solution, the background kill time for each background application can be dynamically determined based on at least one of the following: heap memory usage information of the background application (i.e., the application running in the background, such as the first application) during its foreground operation; lag performance information during its foreground operation; its position in the background task list; and background working status information. Therefore, on the one hand, background applications with memory leaks, lag, no background tasks, or those not used by the user in the short term can be killed as quickly as possible, effectively avoiding lag probability and device overheating of foreground applications and improving the operating performance of electronic devices. On the other hand, it can ensure that applications with normal memory usage, no lag, performing background tasks, or those that the user may use in the short term can remain in the background for a longer period, improving the continuity of user experience with applications with normal memory usage and thus improving the operating performance of electronic devices.

[0039] The application management method provided in this application embodiment is executed by an application management device, which can be an electronic device, or a functional module or entity within an electronic device. This application embodiment does not limit the specific implementation of this device. The following will use an application management device as an example to illustrate the application management method provided in this application embodiment.

[0040] This application provides an application management method, such as... Figure 1 As shown, the application management method provided in this application embodiment may include the following steps 101 and 102.

[0041] Step 101: When the application management device is running the first application in the background, it determines the background scan time of the first application based on the first information of the first application.

[0042] The aforementioned first information may include at least one of the following: heap memory usage information of the first application during its foreground operation, lag performance information of the first application during its foreground operation, position of the first application in the background task list, and background working status information of the first application.

[0043] In some embodiments of this application, the first application can be any application running in the background of the electronic device.

[0044] For example, this could be for video apps, short video apps, novel apps, map apps, shopping apps, or game apps that run in the background of electronic devices.

[0045] It is understood that the application management method provided in this application embodiment can manage the background scanning time of applications running in the background of electronic devices on an application-by-application basis.

[0046] In some embodiments of this application, when the first information includes the second information, the application management device can collect the second information of the first application while it is running in the foreground, so that after the first application switches to background operation, the background kill time of the first application can be determined based on the collected second information. The second information may include at least one of the following: heap memory usage information of the first application during foreground operation, and lag / stuttering performance information of the first application during foreground operation.

[0047] For ease of description, "heap memory usage information of the first application during its foreground operation" can be abbreviated as "first heap memory usage information," and the two have the same meaning and can be used interchangeably; similarly, "stuttering performance information of the first application during its foreground operation" can be abbreviated as "first stuttering performance information," and the two have the same meaning and can be used interchangeably. Furthermore, in the following embodiments, "foreground heap memory usage of the first application" refers to the heap memory usage or usage rate of the first application during its foreground operation.

[0048] In some embodiments of this application, the first heap memory usage information may represent the actual Java heap memory size occupied by the first application during its foreground operation.

[0049] In some embodiments of this application, the first heap memory usage information may include: the heap memory usage of the first application during its foreground operation, which can be referred to as "the foreground heap memory usage of the first application"; or, the heap memory usage rate of the first application during its foreground operation, which can be referred to as "the foreground heap memory usage of the first application".

[0050] For example, if the maximum heap memory of the first application is 256MB, and the heap memory usage of the first application is 200MB before switching to background operation, then the foreground heap memory usage of the first application is 200MB, and the foreground heap memory usage rate of the first application is ( ). (256M) * 100%.

[0051] In some embodiments of this application, the aforementioned first heap memory usage information can be the average or maximum heap memory usage information within a fourth preset time period before the first application switches to background operation. Currently, it can also be the heap memory usage information before the first application switches to background operation.

[0052] The fourth preset duration can be 5 min, 4 min, 3 min, 2 min or 1 min, depending on the actual situation, and is not limited in this application.

[0053] Understandably, the first instance of lag can indicate the lag or stuttering of the first application running in the foreground of an electronic device.

[0054] In some embodiments of this application, the first stuttering performance information of the first application may be: the number of times the first blocking GC occurs or the number of times the first frame drop event occurs within a second preset time period during the foreground operation of the first application on the electronic device.

[0055] Among them, the first blocking GC is: the duration of thread blocking in the first application is greater than or equal to the third preset duration, and the first frame drop event is the frame drop rate of the first application within the fifth preset duration is greater than or equal to the preset threshold (such as 20%).

[0056] In some embodiments of this application, the second preset duration can be 5 min, 4 min, 3 min, 2 min or 1 min, depending on the actual situation, and is not limited in this application.

[0057] In some embodiments of this application, the third preset duration and the fifth preset duration are less than the second preset duration.

[0058] In some embodiments of this application, the third preset duration can be the duration of lag that the user can perceive, such as 500ms, 400ms, 300ms, or 200ms. The third preset duration is greater than or equal to the minimum time threshold at which the user can clearly perceive the "lag," such as a third preset duration of 100ms.

[0059] In some embodiments of this application, the fifth preset duration can be the duration of lag that the user can perceive, such as 500ms, 400ms, 300ms, or 200ms. The fifth preset duration is greater than or equal to the minimum time threshold at which the user can clearly perceive the "lag," such as a fifth preset duration of 300ms.

[0060] For example, the application management device can count the number of times the first Block GC occurs within each individual time window during a second preset time period before the first application switches to background operation, and use the time window with the highest number of occurrences as the first stuttering performance information of the first application. The duration of each individual time window is the same as the aforementioned second preset time period, such as 5 minutes.

[0061] In this way, since the number of times the first application experiences the first Block GC in each individual time window can be counted within the second preset time before switching to background operation, and the highest number is used as the first lag performance information of the first application, it can be ensured that applications that create "disastrous moments" for users are prioritized for elimination. This achieves the highest recycling principle of "resource recycling driven by user experience damage", making the elimination decision highly aligned with the user's subjective feelings.

[0062] In some embodiments of this application, the background kill time of an application can indicate the time during which the application survives or remains in the background of an electronic device; thus, the user can trigger the application management device to switch the first application to the foreground before the background kill time arrives, thereby improving the user's experience with the first application.

[0063] For example, if the background detection time for a video application is 3:50 PM, it means that the video application remained running in the background until the system time of the electronic device reached 3:50 PM, as indicated by the identifier of the first application in the background application list of the electronic device.

[0064] In some embodiments of this application, the position of the first application in the background task list can be represented by the position index of the background task identifier of the first application in the background task list.

[0065] For example, assuming that the background task identifiers in the background task list are arranged from left to right, and the background task identifiers of applications that were switched to the background later are located further to the right, then the position index of the background task identifiers in the background task list increases sequentially from right to left.

[0066] As a further example, the position index can range from [1, 10]. If the background task list includes 11 background task identifiers, then the position index of both the 11th and 10th background task identifiers is 10. Of course, there is no upper limit to the position index. The position indexes of background task identifiers in a background task list arranged from top to bottom are determined in a similar manner.

[0067] In some embodiments of this application, since the application management device can display background task identifiers in the background task list according to the order in which applications are switched to background operation, the position of the background task identifier of the first application in the background task list can reflect the duration of the first application's background operation. The earlier the application is switched to background operation, the lower the probability that the user will use it again. In simpler terms, the further away the background task identifier is in the background task list, the less noticeable it is to the user during detection and removal.

[0068] In some embodiments of this application, the background working status information of the first application can indicate the current background working status of the first application. The background working status of the first application can include any of the following: active background state, inactive background state.

[0069] In some embodiments of this application, an active background state refers to an application running in the background currently performing a background task, such as downloading or playing music. An inactive background state refers to an application running in the background currently not performing a background task.

[0070] It's understandable that when an application experiences high heap memory usage, leading to lag, overheating, or other issues, promptly killing the application is an effective way to ensure electronic device performance and reduce power consumption. However, killing an application directly in the foreground results in a very poor user experience. A better approach is to kill the application when it's moved to the background. However, if a user triggers the application to run in the background instead of closing it (i.e., terminating its operation), it means the user may want to continue using the application for a short period. Therefore, a blanket killing of background applications will require a lengthy cold start upon restarting, thus degrading the user experience. To address this issue, this application analyzes factors such as memory usage, lag performance, the application's position after being moved to the background (i.e., the first application's position in the background task list), and whether it is in a working state (i.e., the first application's background working state information) before switching the application to the background. This dynamically determines the background detection time for each application, ensuring that applications with memory leaks or severe lag can be detected and eliminated in the background as quickly as possible. At the same time, it ensures that applications with normal memory usage can remain in the background for a longer period of time, thereby improving the continuity of user experience with applications with normal memory usage and ultimately enhancing the performance of electronic devices.

[0071] In some embodiments of this application, the application management device can determine the background scanning time of the first application based on the first information and the system time of the electronic device.

[0072] For example, referring to Table 1 below, if the first information meets condition 1, it means that the first application can be detected and removed after being inactive for more than 30 seconds. If the first information meets condition 2, it means that the first application can be detected and removed after being inactive for more than 3 minutes. If the first information meets condition 3, it means that the first application can be detected and removed after being inactive for more than 5 minutes. Referring to Table 2 below, if the first information meets condition 4, it means that the first application can be detected and removed after being inactive for more than 10 minutes. If the first information meets condition 5, it means that the first application can be detected and removed after being inactive for more than 30 minutes.

[0073] Furthermore, assuming the first application switches to background operation at 14:30 and the first information satisfies condition 2, then it can be determined that the background scanning time of the first application is: scanning after 14:33.

[0074] In some embodiments of this application, the application management device can determine the background scanning time of the first application based on the scanning delay of the first application and the system time of the electronic device, even when the first application is in an inactive background state. This can prevent the background tasks of applications running in the background, such as music playback and download tasks, from being interrupted.

[0075] In some embodiments of this application, step 101 may include step 101A.

[0076] Step 101A: When the application management device is running the first application in the background, if the first information meets the target detection condition in at least one detection condition, the background detection time of the first application is determined according to the detection strategy corresponding to the target detection condition.

[0077] In some embodiments of this application, the target condition can be one of at least one condition.

[0078] It is understandable that the first information meeting the target conditions means that the first application running in the background will cause the electronic device to heat up, cause the first application to lag after switching to the foreground, and have resources that can be released but have not been released (such as applications that have not performed background tasks or applications that have switched to the background a long time ago).

[0079] In some embodiments of this application, each of the at least one detection condition mentioned above can correspond to a detection strategy, and different detection conditions correspond to different detection strategies.

[0080] In some embodiments of this application, each of the at least one detection condition mentioned above corresponds to a risk level.

[0081] In some embodiments of this application, the detection strategy corresponding to the above-mentioned target detection conditions can be: detection and killing after the application has been inactive in the background for a period of time greater than or equal to a sixth preset duration. The sixth preset duration is negatively correlated with the risk level corresponding to the target detection conditions.

[0082] In some embodiments of this application, the detection strategy corresponding to the above-mentioned target detection conditions can be: detection and elimination after the application has been switched to background operation for a duration greater than or equal to a seventh preset duration. The seventh preset duration is negatively correlated with the risk level corresponding to the target detection conditions.

[0083] In some embodiments of this application, the higher the risk level corresponding to the above target detection conditions, the greater the potential harm that the first application is running in the background to the performance of electronic devices or user experience, and the more it should be detected and killed first.

[0084] It is understandable that the detection strategy corresponding to each detection condition is essentially a detection delay time corresponding to each detection condition. In this way, when the first piece of information meets a certain detection condition, the corresponding detection delay time can be directly used to calculate the detection time. This makes the decision on the timing of detecting background applications simple, fast and consistent, which is conducive to the system's efficient and predictable scheduling of cleanup tasks and reduces decision-making overhead.

[0085] In some embodiments of this application, the first information may differ, and the above-mentioned at least one detection condition may also differ.

[0086] Method 1: The first information is the memory usage information of the first heap, and at least one of the above detection conditions may include the condition of lag performance.

[0087] For example, the stuttering condition can be any of the following: the number of times the first blocking GC occurs is greater than or equal to the first threshold; or the number of times the first blocking GC occurs is greater than or equal to the first threshold. This means that background applications that meet the stuttering condition will be detected and killed according to the corresponding detection strategy; background applications that do not meet the stuttering condition can continue running in the background.

[0088] In some embodiments of this application, the threshold for the first count can be 2 times, 3 times or 1 time, and this application does not limit it.

[0089] In some embodiments of this application, the aforementioned lag performance conditions may include at least two first sub-conditions, each corresponding to a risk level and a detection and removal strategy. It can be understood that the higher the risk level corresponding to the first sub-condition, the shorter the detection delay time corresponding to the detection and removal strategy of the first sub-condition, i.e., the more promptly the application is detected and removed.

[0090] For example, the first instance of lag performance is defined as the number of Block GC events occurring within a unit time window. Table 1 shows the correspondence between the first sub-condition, risk level, and detection strategy.

[0091] Table 1

[0092]

[0093] As shown in Table 1, the stuttering conditions include three sub-conditions: Condition 1, Condition 2, and Condition 3. Specifically, Condition 1 is the number of times the first Block GC occurs 4 or more times within a single time window; Condition 2 is the number of times the first Block GC occurs 3 times within a single time window; and Condition 1 is the number of times the first Block GC occurs 2 times within a single time window. The risk levels corresponding to Conditions 1, 2, and 3 decrease sequentially: Critical stuttering, Medium stuttering, and Normal stuttering. The corresponding detection latency times for Conditions 1, 2, and 3 increase sequentially: 30 seconds, 3 minutes, and 5 minutes, respectively.

[0094] For example, based on Table 1 above, if the short video application experiences a maximum of 3 Block GCs (i.e., the first blocking GC) with a stuttering time exceeding 500ms within a single time window (5min) in the half hour before switching to background operation, then the background killing time of the video application can be determined according to the killing strategy corresponding to condition 2.

[0095] It should be noted that if the lag performance information of the first application in the last time window before switching to background operation meets the first condition, then there is no need to refer to the lag performance information of the first application in other time windows. Among them, the first condition is the condition with the highest risk level among the lag performance conditions, such as condition 1 in Table 1 above.

[0096] For example, based on Table 1 above, if a short video application experiences four Block GC events with a stutter time exceeding 500ms within 5 minutes before switching to background operation, then the background GC time of the video application can be determined according to the detection strategy corresponding to Condition 1. Furthermore, it is unnecessary to count the number of the first Block GC events within the remaining time window of the half hour before the short video application switches to background operation, thereby saving computing power and reducing the latency in determining the background GC time of the application.

[0097] For example, if the number of times the first application experiences a first Block GC within the last time window before switching to background operation is greater than or equal to the second threshold (i.e., the first condition is met), then the first condition can be directly used as the target condition for satisfying the first information, without needing the first application to experience a first Block GC in the remaining windows before that last time window. Here, the first threshold indicates that the first application is experiencing severe lag, such that the user can no longer use the application normally, significantly impacting the user experience. The second threshold can be greater than the first threshold; for example, the first threshold could be 2 times, and the second threshold could be 4 times.

[0098] It is understandable that if the first application's lag performance meets the lag performance criteria, it means that the current operation of the first application is affecting the user's normal use of the first application, and it needs to be "restored" or restarted in time.

[0099] Method 2: The first information is the first heap memory usage information, and at least one of the above detection conditions may include heap memory usage conditions.

[0100] For example, the first piece of information that satisfies the heap memory usage condition can include any of the following:

[0101] The foreground heap memory usage of the first application is greater than or equal to the first heap memory usage threshold.

[0102] The foreground heap memory usage of the first application is greater than or equal to the threshold for first heap memory usage.

[0103] In some embodiments of this application, the threshold for the first heap memory usage can be 70%, 72%, 73%, 75%, 80%, etc., and the specific value can be determined according to the actual situation. This application does not limit the specific value.

[0104] For example, the first heap memory utilization threshold can be 70%, and correspondingly, the first heap memory usage threshold can be 70% of the upper limit of the first application's heap memory.

[0105] It is understandable that when an application's heap memory usage approaches its heap memory limit, even without the first Block GC, the risk of memory leaks increases. Furthermore, the application's virtual machine will frequently perform parallel GC, leading to issues such as overheating and increased power consumption in electronic devices. Therefore, when the first application's heap memory usage meets the heap memory usage criteria, it should be detected and addressed as soon as possible.

[0106] For example, if the initial memory usage information of a short video app meets the heap memory usage condition after the app is switched to the background, the app should be killed within 30 minutes after it is switched to the background to avoid the app running in the background for a long time, which could cause the electronic device to overheat or consume more power.

[0107] In some embodiments of this application, the above-mentioned heap memory usage conditions may include at least two second sub-conditions, each second sub-condition corresponding to a risk level and a detection and elimination strategy; the higher the risk level corresponding to the second sub-condition, the shorter the detection and elimination delay time corresponding to the detection and elimination strategy corresponding to the second sub-condition.

[0108] For example, each second sub-condition corresponds to a risk level and a heap memory usage threshold. Table 2 shows the correspondence between the second sub-condition, risk level, and detection latency.

[0109] Table 2

[0110]

[0111] As shown in Table 1, the heap memory usage condition includes two sub-conditions: condition 4 and condition 5. Specifically, condition 4 is a heap memory usage rate greater than or equal to 85%, and condition 5 is a heap memory usage rate greater than or equal to 70% and less than 85%. The risk levels corresponding to conditions 4 and 5 decrease sequentially, namely high usage level and low usage level, respectively. Furthermore, the detection latency corresponding to the risk levels of conditions 4 and 5 gradually increases, namely 10 minutes and 30 minutes, respectively.

[0112] In some embodiments of this application, the application management device can design a set of memory detection strategies for applications with high Java heap memory usage, such as the detection strategies shown in Table 2 above, so as to ensure application performance, reduce the probability of lag and overheating, and improve battery life.

[0113] As can be understood (referring to Tables 1 and 2 above), the purpose of "using the time window with the highest number of occurrences as the first indication of lag in the first application," and classifying it as "severe" if the last window before exiting the background experiences 4 or more lag occurrences, is that the system pays particular attention to the instantaneous state of the application before it goes to the background, as this directly relates to the user's experience when switching back to the application. If the application is already severely lagging when exiting the background (e.g., the last window before exiting the background experiences 4 or more lag occurrences), then when the user switches back to the foreground, the application is highly likely to still lag. Therefore, the system must kill it as quickly as possible, essentially "resetting" the application's state, so that even if the user switches back later, it will be a smoothly restarted application. Conversely, if there is only high heap memory usage but no lag, or only normal memory usage, then the threat to the user's experience when switching back is less urgent, and longer background persistence can be allowed. Therefore, this "risk level" is essentially a ranking of the "urgency of the potential for a poor user experience when switching back to the application." It does not limit the application itself, but rather the level of experience risk to the user about to use it, as indicated by the application's current state.

[0114] Method 3, where the first information includes first heap memory usage information and first lag / stuttering behavior information, then at least one of the above detection conditions can include both the heap memory usage condition and the lag / stuttering behavior condition. Furthermore, the risk level corresponding to the lag / stuttering behavior condition is higher than the risk level corresponding to the heap memory usage condition. This reflects an application management strategy that prioritizes user experience, promptly removing noticeably lagging applications to achieve a timely "recovery" of these applications so that they can run smoothly the next time the user uses them.

[0115] It should be noted that when at least one of the above detection conditions includes at least two of the first sub-detection conditions and at least two second sub-detection conditions, the "Normal Lag" level in Table 2 is higher than the "High Utilization" level in Table 2. Furthermore, it can be seen that the detection latency of 5 minutes corresponding to the "Normal Lag" level is less than the detection latency of 10 minutes corresponding to the "High Utilization" level. That is, the risk level corresponding to meeting the lag performance condition is greater than the risk level corresponding to the heap memory utilization condition.

[0116] Method 4: When the first information includes the position of the first application in the background task list, the aforementioned at least one detection condition includes at least a background location condition. The background location condition can be: the position index of the application running in the background in the background task list is within a preset position index range. For example, the preset position index range can be [5, 10]. The smaller the application's position index, the shorter the time the application spends in the background. Furthermore, referring to the aforementioned stuttering performance condition and heap memory usage condition, multiple sub-conditions can be set for the background location condition, each corresponding to a risk level and a detection strategy.

[0117] In Method 5, when the first information includes the background working status information of the first application, at least one of the above detection conditions can include a background working status condition. The background working status condition can be: the background application is executing a background task. Furthermore, referring to the above-mentioned stuttering performance condition and heap memory usage condition, multiple sub-conditions can be set for the background location condition, each sub-condition corresponding to a risk level and a detection strategy.

[0118] In some embodiments of this application, when the first information includes at least two of the following: the heap memory usage information of the first application during its foreground operation, the lag performance information of the first application during its foreground operation, the position of the first application in the background task list, and the background working status information of the first application, the above at least one condition can be a condition corresponding to the key information in the first information.

[0119] The key information may include: information on the lag performance of the first application during its foreground operation, and information on the heap memory usage of the first application during its foreground operation.

[0120] It should be noted that methods 1 to 5 described above are merely examples of at least one of the conditions and do not constitute a limitation on this application. In actual implementation, the at least one condition can be any possible condition related to the first information. For example, the at least one condition may include:

[0121] The foreground runtime experiences a first blocking GC more than or equal to the third threshold and less than the fourth threshold within a single time window, and the foreground runtime's heap memory usage is within the first usage range.

[0122] The foreground runtime experiences more than the fourth threshold number of first blocking GC events within a single time window, and the foreground runtime heap memory usage falls within the second usage range. The first usage range is [60%, 65%], and the second usage range is [65%, 70%].

[0123] In some embodiments of this application, the application management device compares the first information against at least one of the aforementioned detection and removal conditions in a first order; the first order is the order of risk levels corresponding to the detection and removal conditions from high to low. If the first information meets any one of the aforementioned at least one detection and removal conditions, the application management device stops the comparison and uses the detection and removal strategy corresponding to that detection and removal condition to determine the detection and removal time of the first application. That is, the application management device first compares the first information against the detection and removal condition corresponding to the highest risk level among the at least one detection and removal conditions in the first order. If the first information meets the detection and removal condition corresponding to the highest risk level, the detection and removal strategy corresponding to the highest risk level detection and removal condition is used to determine the detection and removal time of the first application; if it does not meet the condition, the comparison continues with the detection and removal condition corresponding to the second highest risk level among the at least one detection and removal conditions, until the first information meets one of the at least one detection and removal conditions or it is determined that the first information does not meet the detection and removal condition with the lowest risk level.

[0124] In this way, by adopting a "short-circuit" comparison process that sorts applications by risk level in descending order, the comparison stops as soon as any detection condition is met, and the detection strategy corresponding to the detection condition of that person is used to determine the background detection time of the first application. Therefore, the highest risk of background applications can be found in a timely, priority and fast manner, ensuring that the most serious background applications in electronic devices can be identified and responded to as quickly as possible, improving the efficiency of differentiated detection of background applications, and saving the computing power of application management devices.

[0125] In some embodiments of this application, the first information mentioned above includes stuttering performance information and heap memory usage information, and the at least one detection condition mentioned above includes stuttering performance condition and heap memory usage condition; the step 101A mentioned above may include the following steps 101A1 or 101A2.

[0126] Step 101A1: When the application management device is running the first application in the background, if the lag performance information of the first application during its foreground operation meets the lag performance conditions, the background scanning time is determined according to the scanning strategy corresponding to the lag performance conditions.

[0127] Step 101A2: When the application management device is running the first application in the background, if the lag performance information of the first application during its foreground operation does not meet the lag performance conditions, and the heap memory usage information of the first application during its foreground operation meets the heap memory usage conditions, the background scanning time is determined according to the scanning strategy corresponding to the heap memory usage conditions.

[0128] For a description of heap memory usage conditions and stuttering performance conditions, please refer to the relevant descriptions of heap memory usage conditions and stuttering performance conditions in the above embodiments.

[0129] Thus, since at least one detection condition includes both stuttering performance and heap memory usage, and the former has a higher risk level, it can be ensured that stuttering issues that directly affect user experience are given the highest priority. Even if memory usage is not high, applications that frequently stutter will be detected and eliminated more quickly, thereby prioritizing the smoothness perceived by the user.

[0130] Thus, since the application management device determines the background scanning time of the first application according to the scanning strategy corresponding to the target scanning condition when the first information meets at least one of the target scanning conditions, the latency and power consumption of calculating the background scanning time can be reduced.

[0131] In some embodiments of this application, step 101 may include step 101B.

[0132] Step 101B: If the first information does not meet any of the at least one detection condition, the application management device calculates the background detection time of the first application based on the first information and the first rule.

[0133] In some embodiments of this application, the application management device calculates the background scanning time of the first application based on the first information and the first rule, which may include:

[0134] The application management device calculates the background detection time of the first application based on the third information in the first information and the first rule. The third information can be at least a part of the information in the first information. The first rule may also be different depending on the third information.

[0135] For example, taking the first information as including the heap memory usage information of the first application during its foreground operation, the lag performance information of the first application during its foreground operation, the position of the first application in the background task list, and the background working status information of the first application, the application management device can calculate the detection delay time based on the first heap memory usage information, the position of the first application in the background task list, and the first rule.

[0136] In some embodiments of this application, the application management device can calculate the background detection time of the first application based on the third information, the locking information of the first application, and the first rule. The fourth information can be the locking information of the first application, which can be used to indicate whether the first application is locked in the background.

[0137] In some embodiments of this application, when a user locks an application in the recent tasks list, it means that the user wants to keep the locked application alive, or wants to be able to quickly enter the application in recent tasks, or may use the locked application more frequently. When the application is locked, the detection delay time can be appropriately increased.

[0138] In some embodiments of this application, the first rule can be a calculation formula.

[0139] In some embodiments of this application, when calculating the background detection time of the first application based on the first information and the first rule, the detection delay duration corresponding to the background detection time is within the range of the weak detection duration of the first application. In other words, the detection delay duration corresponding to the background detection time is preferably outside the range of the strong detection duration of the first application. It should be noted that the detection delay duration corresponding to the background detection time refers to the time from the system time when the background detection time is calculated to the arrival of the background detection time.

[0140] For example, taking the range of time during which the detection of a short video application is not perceived as greater than 480 minutes, the range of time during which the detection is weakly perceived as [30, 480] minutes, and the range of time during which the detection is strongly perceived as [0, 30) minutes as an example, and taking the longer the short video application is switched to the background to run, the weaker the user's perception of the detection of the video application.

[0141] After a short video app is switched to background operation, the detection latency can be calculated by comprehensively considering factors such as the app's Java heap usage (based on foreground statistics), the app's process position index in the recent tasks list, and whether the app is locked in the recent tasks list. Specifically:

[0142] When a user locks an app in their recent tasks list, it means they want the locked app to stay active, or they want to be able to quickly access the app in recent tasks, or use the locked app more frequently. Locking an app increases its background retention time by 30 minutes.

[0143] For the other parameters shown in Table 3, different weights can be assigned according to different parameter types. The detection delay time is calculated according to the following formula 1 (i.e., the first rule). The calculated detection delay time is between [30 min, 450 min]. When the background detection time corresponding to the detection delay time arrives, if the process of the short video application is still in the background and not in a working state (i.e., in an inactive state), the short video application will be detected and killed.

[0144] In some embodiments of this application, referring to Table 3, the application management device can calculate the detection delay time using the following formula 1 based on the first heap memory usage information, the location index of the background task identifier of the first application, and the background status information of the first application.

[0145]

[0146] in, and This represents the shortest and maximum durations within the range of weak detection durations corresponding to the first application. This indicates the initial heap memory usage information for the first application. and As weight, and + , H represents the position index of the background task identifier of the first application, H is the lower limit heap memory value corresponding to the heap memory usage condition, such as the first heap memory usage threshold mentioned above, L is the heap memory usage rate when the first application is running normally, and M is the maximum position index in the background task list. This means that when the application is locked, the detection time is increased by T0. T0 is configurable, such as 30 minutes. If the application is not locked, the value is 0.

[0147] Table 3

[0148]

[0149] It is understandable that after calculating T according to Formula 1, the background scanning time of the first application can be determined by combining the time when the first application switches to the background, or by combining the current system time, or by combining the time when the first application switches to the background inactive state.

[0150] In some embodiments of this application, the maximum time interval distribution between switching to background operation and switching back to foreground operation when the first application experiences excessive heap memory usage can be obtained in advance through big data statistics. This yields the range of strong detection duration, weak detection duration, and no detection duration, so that subsequent detection actions of the application can be scheduled to be executed within the range of time periods that are imperceptible or barely noticeable to the user.

[0151] For example, taking a short video application with the first application as the header as an example, the following steps can be used to determine the detection range with strong awareness, the detection range with weak awareness, and the detection range without awareness for the corresponding short video application:

[0152] Step 1: Data collection.

[0153] For leading short video apps, we collect data on the moment when a user actively switches the app to the background (t1) and the time (t2) when the app's heap memory usage exceeds the second heap memory usage threshold. This data is used to obtain the switching interval △T, which is the "background duration". Over a sufficiently long period (e.g., one month), we collect a large number of user-generated switching intervals △T to form a dataset.

[0154] Step 2: Perform a distribution analysis on the switching time intervals in the dataset.

[0155] Typically, the distribution of switching time intervals in this dataset exhibits a clear long-tail distribution characteristic, with a large number of switching time intervals concentrated in the short term (such as within a few minutes) and a small number of intervals scattered over the long term (a few hours or even days), similar to a normal distribution.

[0156] Step 2 may include steps 2.1 to 2.3.

[0157] Step 2.1: Calculate the logarithmic transformation value of all switching time intervals in the dataset (to smooth the long-tailed data).

[0158] Step 2.2: Calculate the mean (μ) and standard deviation (σ) of all log-transformed values.

[0159] Step 2.3: Determine the main distribution interval as [μ - σ, μ + σ], which covers approximately 68% of the de-identified behavior data of mainstream users (assuming an approximately normal distribution).

[0160] Step 3: Based on the above main distribution intervals, dynamically calculate the two endpoints of the three sensing duration ranges.

[0161] Specifically, the two threshold values ​​mentioned above are: strong-weak perception threshold. and weak-insensitivity threshold .

[0162] Wherein, the strong-weak perception threshold Ta is defined as the time interval corresponding to μ-0.5σ. Users return to the application very quickly, making detection extremely easy to detect, for example, within 30 minutes. Weak-to-undetectable threshold. Defined as the time interval corresponding to μ + 2σ. A value greater than Tb indicates that the user returned to the application after an extremely long period of time, making it almost impossible for the antivirus to detect.

[0163] Step 4: Based on the two calculated endpoints above, determine the detection ranges for short video applications with strong detection, weak detection, and no detection.

[0164] Specifically, the detection and elimination duration range for strong sensing is determined as: [0, Within this range, users are highly likely to reopen the application within a short period of time (such as a few minutes). If the application is detected and killed within the corresponding time period, users will clearly feel that the application has been "forced to close", resulting in a strong sense of interruption in the experience. Therefore, within this range, try to avoid detection and killing. If detection and killing are necessary (such as when the highest risk conditions are met), you can use enhanced data storage and recovery mechanisms.

[0165] The time range for detecting and eliminating weakly perceived threats is determined to be ( , This indicates that users may not be able to reopen the application for a relatively long period of time (such as tens of minutes to several hours). Within this time frame, the causal relationship between the virus removal and the application restart is diluted over time and is less noticeable.

[0166] The minimum value of the range of time during which the virus can be detected without being detected is greater than [the minimum value]. Within this range, if a user reopens the application after a very long period of time (e.g., more than 8 hours), typically during sleep or work, the scanning and removal process will not be perceived by the user.

[0167] For example, assuming that the above steps can determine the two endpoints corresponding to the top short video application. and If the values ​​are 30 min and 480 min, then: the range of strong detection duration is [0, 30), the range of weak detection duration is [30, 480] min, and the minimum value of the range of no detection duration is greater than 480 min.

[0168] For example, referring to Table 3 above, if the two end values and For 30 minutes and 480 minutes, =30, H=70, M=10, T0=30min, then Formula 1 above can be expressed as:

[0169]

[0170] in, =30min, = =450min, which corresponds to the period of weak detection and removal.

[0171] The above formula is used to calculate the background detection time, and the application is detected and killed after a given delay. At the same time, the detection delay is updated every once in a while.

[0172] Thus, when the first information does not meet any of the at least one detection condition, the background detection time can be calculated by combining the application's first heap memory usage information, its position in the application's background task list, and whether it is locked. That is, for applications whose first information does not meet any of the at least one detection condition, the background detection time of the application can be determined by comprehensively considering the application's own resource usage and user interaction intent (such as locking indicating a willingness to keep the application alive). This allows for a personalized balance between resource recycling and respecting user habits.

[0173] Thus, since the first information does not meet any of the at least one detection condition, it indicates that the risk level of the first application running in the background is relatively low. Therefore, the first information and the first rule can more accurately calculate the background detection time of the first application, ensuring that the first application stays in the background for a longer period of time.

[0174] In some embodiments of this application, when at least one of the above conditions includes both stuttering performance and heap memory usage, it represents a shift in application management paradigm from "resource control" to "experience assurance." The priority for detecting and eliminating background applications is based on the risk of experience impairment that may be caused by the application running in the background, from high to low (stuttering > overheating / power consumption > normal memory usage). That is, applications that meet the stuttering performance condition are detected after the shortest background running time, such as after 3 minutes of inactivity in the background; applications that meet the heap memory usage condition are detected later, such as after 30 minutes of inactivity in the background; applications that do not meet the heap memory usage and stuttering performance conditions can be detected during the corresponding period of weak detection, such as after 30 minutes of inactivity in the background.

[0175] In some embodiments of this application, when determining the background kill time of the first application based on the time it switches to background operation and the first information, the application management device can start checking whether the first application is in an active background state after it switches to background operation. If it is determined that the first application is currently in an inactive background state, the background kill time of the first application is determined based on the first information. Otherwise, it continues to monitor whether the first application is in an inactive background state until it is detected that it is in an inactive background state, or the first application switches to foreground operation. That is, a polling status query mechanism is adopted.

[0176] For example, within a first preset time range after the first application is switched to background operation, the application management device can check whether the first application is in an inactive background state once every first time period. After the first preset time range, it can check once every second time period. The first time period is shorter than the second time period, for example, the first time period is 1 minute and the second time period is 5 minutes.

[0177] The first preset time range can be 30 minutes, 1 hour, 45 minutes, or 15 minutes, and is determined according to actual conditions. This application does not limit the specific time range.

[0178] Step 102: If the first application is running in the background before the background scan time, the application management device will terminate the first application after the background scan time is reached.

[0179] In some embodiments of this application, after determining the background scanning time of the first application, the application management device may adopt a polling scanning mechanism to check whether the first application can be scanned and terminate the first application when the background scanning time of the first application is reached.

[0180] For example, a polling process can be used to periodically scan the applications in the background task list for removal. If the system time is later than or equal to the background removal time of an application, then that application is removed. Otherwise, it waits for the next polling session until the system time is later than or equal to the background removal time of an application, or until an application is brought to the foreground.

[0181] In some embodiments of this application, after determining the background scanning time of the first application, the application management device can start a timer or timer, and scan and kill the application when the timer is reached.

[0182] It's understandable that, compared to timer-based scanning, polling scanning can avoid time errors introduced by prolonged sleep mode of electronic devices.

[0183] Understandably, by conducting risk assessment and classification based on multi-dimensional information such as foreground lag performance (e.g., the number of times the first Block GC occurs) and heap memory usage, a precise profile of background applications is achieved. The application management device can clearly distinguish between "applications that have caused severe lag" (i.e., meeting the lag performance criteria), "high-memory applications with high heat and power consumption risks" (e.g., meeting the heap memory usage criteria), and "normal applications with normal usage." Based on this, differentiated detection and delay strategies are applied, achieving refined governance of "rapid handling of serious problems, timely intervention of potential problems, and long-term retention of normal applications," fundamentally changing the drawbacks of the "one-size-fits-all" approach to background resource management.

[0184] Furthermore, dynamic delayed detection can achieve dual optimization of user experience and system performance. In terms of user experience: it provides a "buffer period" for abnormal applications, avoiding the most detrimental operation of crashing directly in the foreground. The user's perception changes from "sudden crash" to "quiet background reload," significantly reducing the sense of discontinuity in the experience. In terms of system performance: by setting shorter delays for high-risk applications, it ensures that memory-leaking or high-load applications do not remain in the background for extended periods, thus quickly releasing valuable memory and CPU resources. This directly reduces frequent global garbage collection (GC) caused by insufficient memory, as well as device heat and additional power consumption caused by high CPU usage, improving overall system smoothness and battery life.

[0185] In some embodiments of this application, step 102 may include step 102A.

[0186] Step 102A: If the first application is running in the background and is in an inactive state before the background kill time of the first application, the application management device will terminate the first application after the background kill time is reached.

[0187] It is understandable that if the first application switches to the foreground or enters an active background state before the background scan time of the first application, the application management device will invalidate the background scan time of the first application, that is, the scan will no longer be performed or the scan delay time and scan delay time will need to be recalculated after the next time it enters the background.

[0188] In this way, since the scanning and removal can be performed only when the first application is inactive in the background, it avoids mistakenly killing background applications that are performing background tasks required by the user (such as playing or downloading). This can improve the accuracy of application scanning and removal, ensure that the cleanup action will not interrupt the background functions that the user is using, and improve user satisfaction.

[0189] In some embodiments of this application, the time elapsed after the first application is moved to the background can be calculated based on information such as the Java heap memory usage of the first application while running in the foreground, the number of times the first Block GC occurred, the application's position after being moved to the background, and whether it is active in the background. Furthermore, before killing the first application, the first application is notified to save user data to ensure a good user experience when the first application is running in the foreground.

[0190] The application management method provided in this application embodiment will be illustrated below with reference to scenarios 1 to 3 above.

[0191] Example 1: In scenario 1 above, the application management device, following the application management method provided in this application embodiment, can accurately identify whether an application running in the background is high-risk due to frequent lag (Block GC) or sustained high memory usage. For the former, it is quickly killed after being moved to the background (e.g., after 30 seconds) to prevent continued lag when the user switches back; for the latter, a slightly longer buffer period (e.g., 30 minutes) is given, and if memory is not released during this period, it is then killed. This avoids direct crashes in the foreground and ensures that abnormal applications do not continue to "cause trouble" in the background.

[0192] Example 2: In scenario 2 above, the application management device, according to the application management method provided in this application embodiment, can assess the overall risk of background applications and prioritize the elimination of applications with low user usage probability. For example, a document application locked in the user's recent task list, even with high memory usage, will gain extra keep-alive time due to its "locked" state, avoiding being mistakenly eliminated. Meanwhile, an inactive application relegated to the end of the task list and with high memory usage will be eliminated after a calculated short delay. This achieves personalized management of "protecting what should be protected and eliminating what should be eliminated."

[0193] Example 3: In scenario 3 above, the application management device can explicitly list "high memory usage leading to heat generation and power consumption" as a high-risk behavior (i.e., meeting the heap memory usage condition). Once it detects that the memory usage of background applications is consistently higher than 70% or 85%, it will kill the application within a short period of time (e.g., 10-30 minutes), directly cutting off the source of heat generation and power consumption, effectively extending the battery life of older devices and improving basic smoothness.

[0194] In the application management method provided in this application embodiment, since the background killing time of each background application can be dynamically determined based on at least one of the following: the heap memory usage information of the background application (i.e., the background running application, such as the first application) during its foreground operation, the lag performance information during its foreground operation, its position in the background task list, and the background working status information, on the one hand, it can ensure that background applications with memory leaks, lag, no background tasks, or that the user will not use in the short term are killed as soon as possible, thereby effectively avoiding the probability of lag in foreground running applications and the phenomenon of device overheating, and improving the operating performance of electronic devices; on the other hand, it can ensure that applications with normal memory usage, no lag, performing background tasks, or that the user may use in the short term can remain in the background for a longer time, thereby improving the continuity of the user's use of applications with normal memory usage, and thus improving the operating performance of electronic devices.

[0195] In some embodiments of this application, before step 102 above, the application management method provided in the embodiments of this application may also include the following step 103, and the above step 102 may be implemented by the following step 102B.

[0196] Step 103: If the first application is running in the background before the background scan time of the first application, the application management device will send a data saving notification to the first application after the background scan time of the first application is reached.

[0197] Step 102B: If the target conditions are met, the application management device terminates the operation of the first application.

[0198] The aforementioned data saving notification can be used to notify the first application to save runtime data.

[0199] The above-mentioned conditions for meeting the preset criteria may include any of the following:

[0200] After the first preset time after sending the data save notification;

[0201] The system received a notification that the data sent by the first application has been saved successfully.

[0202] In some embodiments of this application, the aforementioned data saving notification may be a targeted broadcast.

[0203] In some embodiments of this application, the data saving notification includes third information, which may include at least one of the following: first information, first heap memory usage information and heap memory limit of the first application. The third information is used to inform the first application of the reason why the application management device terminated the first application. After receiving the data saving notification, the first application can unfreeze itself and save its runtime data, so that the first application can restore its user interface based on the saved user interface state data upon the next startup.

[0204] In some embodiments of this application, the aforementioned running data may be the state data of the user interface most recently displayed by the first application.

[0205] In some embodiments of this application, the aforementioned state data may include, but is not limited to: user interface identifiers, video playback progress, audio playback progress, novel reading progress, etc.

[0206] Understandably, the data storage mechanism enables a "seamless recovery" effect. Before the system detects and removes the application, it notifies the application to save its user interface state data and collaborates with the developers. This allows the application to accurately restore its usage scenario before termination upon the next launch (such as the original video playback progress, reading position, and unsubmitted forms). This mechanism transforms the traditionally negative event of "application being recycled by the system" into a "hot restart" that is imperceptible or minimally perceptible to the user, greatly ensuring the continuity of the application's usage flow and is a core design element for improving user satisfaction.

[0207] In this way, before killing the first application, a data saving notification can be sent to the first application, allowing it to save its runtime data. The application will then be terminated after a timeout or upon receiving completion feedback. This ensures that when the user reopens the first application after it has been terminated, the application management device can restore the most recently saved user interface based on the saved runtime data. This reduces the disruption to the user's application continuity caused by application killing, achieving a seamless restoration of the user interface and improving the user experience.

[0208] In some embodiments of this application, the application management method provided in this application may further include the following step 104.

[0209] Step 104: If the background scan time of the first application is later than the first time, and the first application was running in the background before the first time, then the application management device will terminate the first application after the first time is reached.

[0210] The first time refers to the start time of the inactivity time range corresponding to the first application.

[0211] In some embodiments of this application, the application management device can pre-analyze the inactive time periods of the first application during the day using big data. During the inactive time periods, the number of people affected by the first application is minimized, and at the same time, it can ensure that the first application can be restarted once a day.

[0212] In some embodiments of this application, the user can manually configure whether to allow forced removal of the first application.

[0213] In some embodiments of this application, the above embodiments are illustrated by combining the inactivity time range of the first application with the background detection time.

[0214] In practice, if the first application is running (either in the foreground or in the background), the application management device can forcibly kill the first application after the aforementioned inactive period, thereby restarting the first application.

[0215] For example, the application management device can first notify the first application to save the state data of the user interface, then scan and kill the first application, and after the scan and kill, restart the first application according to the saved state data so that the first application can resume operation.

[0216] Thus, since the inactive time range corresponding to the first application can represent the time range during which most users do not use the first application, killing the first application in advance within the inactive time range corresponding to the first application can not only release the resources occupied by background applications earlier, but also reduce the user's perception of killing the first application.

[0217] In some embodiments of this application, the application's corresponding weak detection duration range, strong detection duration range, and no detection duration range, the risk level corresponding to the detection conditions, the detection delay duration corresponding to the risk level corresponding to the detection conditions, and the application's corresponding inactive time period, etc., can all be analyzed and optimized through massive amounts of de-identified user behavior data; thereby enabling the detection strategy to have self-evolution capabilities.

[0218] For example, by analyzing the distribution of time intervals in which applications are reopened, "strong and weak awareness time periods" can be defined, making it more likely that detection and removal actions will occur during periods when users are less likely to notice them. This data-driven design allows system management strategies to align with real user habits, achieving personalized intelligent scheduling.

[0219] In some embodiments of this application, after determining the detection delay time and background detection time of the first application, the application management device can recalculate the detection delay time and background detection time of the first application at regular intervals before the background detection time arrives.

[0220] For example, if a video application is set to automatically download via Wi-Fi, then when the video application is running in the background, if the application management is connected to the local area network, it will automatically download the video, that is, switch from an inactive background state to an active background state. In this case, the application management device can invalidate the most recently calculated background scan time and re-determine the background scan time based on the scan delay after the video application re-enters the active background state.

[0221] For example, let's take a short video app with a default risk level and calculate the detection delay based on foreground heap memory usage and background status information. If the short video app's position or lock status changes in the background task list before the background detection time, such as the position index changing from 8 to 1, and / or the lock status changing from "locked" to "unlocked", then the detection delay can be recalculated, and thus the background detection time can be recalculated.

[0222] The following example illustrates the process of the application management method provided in this application embodiment, using a short video application as the first example.

[0223] For example, taking the first application as a leading short video application, and at least one detection condition including the five conditions shown in Tables 1 and 2 above, as an example. Figure 2 As shown, the application management method provided in this application embodiment may include the following steps:

[0224] Step 201: Switch the short video application to run in the background.

[0225] Step 202: Determine whether the short video application is active in the background.

[0226] If the short video application is currently active in the background, wait for a preset time, such as 1 minute, and then repeat step 202; if the application is currently inactive in the background, continue to step 203.

[0227] In some embodiments of this application, the check begins after the application exits the background, with a check frequency of once per minute for the first 30 minutes, and once every 5 minutes thereafter. It determines whether the application is in a working state in the background (audio playback, downloading, etc.); if so, it checks again after 1 minute. The check begins with high-risk detection conditions, progressively determining whether the conditions are met and the background exit time. If the current time corresponds to an inactive time point according to application big data statistics, the check is performed directly; otherwise, the background check time is calculated and the check is performed according to that time.

[0228] Step 203: Read the front-end Java heap records and blocking GC records of the short video application.

[0229] It can be understood that reading the foreground Java heap records and blocking GC records of the short video application is equivalent to obtaining the first heap memory usage information and the first stuttering performance information in the above embodiment.

[0230] Step 204: Determine whether the number of stacked GC occurrences in the short video application is greater than the condition for severe stuttering, such as condition 1 in Table 1 above.

[0231] The number of stacked GC occurrences is the maximum number of times the first stacked GC occurs within a single time window, such as 5 minutes, during the most recent half hour of the first application running in the foreground, or it can be the number of times the first stacked GC occurs within the most recent time window of the foreground running (when the number is greater than or equal to 4).

[0232] If the number of stacked GC occurrences meets the severe lag condition, then proceed to step 205; otherwise, proceed to step 206.

[0233] Step 205: Determine the background kill time for short video applications as follows: Kill the application if it remains inactive in the background for more than 30ms. That is, determine the background kill time for short video applications based on the kill strategy corresponding to severe lag conditions.

[0234] Step 206: Determine whether the number of times the short video application experiences the first stacked GC meets the conditions for moderate stuttering, as shown in condition 2 in Table 1 above.

[0235] If the number of times the first stacked GC occurs in the above short video application meets the medium stuttering condition, then continue to execute step 207 below; otherwise, execute step 208.

[0236] Step 207: Determine the background kill time for short video applications as follows: Applications that are inactive in the background for more than 3 minutes will be killed. That is, determine the background kill time for short video applications based on the kill strategy corresponding to moderate lag conditions.

[0237] Step 208: Determine whether the number of times the short video application experiences the first stacked GC meets the conditions for normal stuttering, such as condition 3 in Table 1 above.

[0238] If the number of times the first stacked GC occurs in the short video application meets the conditions for normal stuttering, then continue to execute step 209 below; otherwise, execute step 210.

[0239] Step 209: Determine the background kill time for short video applications as follows: If the application remains inactive in the background for more than 5 minutes, it will be killed. This follows the kill strategy corresponding to common lag conditions, determining the background kill time for short video applications.

[0240] Step 210: Determine whether the heap memory usage rate of the short video application during its foreground operation is greater than or equal to 85%, and whether it meets condition 4 in Table 2 above.

[0241] If the heap memory usage rate of the short video application during its foreground operation is greater than or equal to 85%, it means that the foreground heap memory usage rate of the short video application meets condition 4 in Table 2 above.

[0242] If the foreground heap memory usage of the above short video application meets condition 4, then continue to execute step 211 below; otherwise, execute step 212.

[0243] Step 211: Determine the background detection time for short video applications as follows: Detect and kill applications that have been inactive in the background for more than 10 minutes.

[0244] Step 212: Determine whether the heap memory usage rate of the short video application during its foreground operation meets the condition of 70% ≤ heap memory usage rate < 85%, i.e., condition 5 is met.

[0245] If the heap memory usage of the short video application during its foreground operation meets condition 5, then proceed to step 213 below; otherwise, proceed to step 214.

[0246] Step 213: Determine the background detection time for short video applications: detect applications that have been inactive in the background for more than 30 minutes.

[0247] Step 214: Based on the heap memory usage during the foreground operation of the short video application, the position index of the short video application in the background task list, the locking information of the short video application, and Formula 1, calculate the background detection time of the short video application. That is, determine the background detection time of the short video application based on the first information and the first rule.

[0248] Step 215: If the short video application is running in the background before the background scan time, then after the background scan time is reached, notify the short video application to save the user interface state data.

[0249] Step 216: Terminate the operation of the short video application.

[0250] In some embodiments of this application, before initiating a kill request, the application management device, such as the processor of a mobile phone, can send a targeted broadcast to the short video application, informing it of its heap memory usage and upper limit, thereby triggering the unfreezing of the application. Upon receiving the broadcast, the short video application can save some content (such as the video playing in the background and its playback progress) so that the previous page can be restored upon next opening, ensuring a good user experience. Simultaneously, it sends a message to the system to indicate that the saving is complete. The system timeout is 5 seconds; regardless of whether the application responds, a kill request will be initiated after 5 seconds.

[0251] In some embodiments of this application, before the background detection time of the short video application is reached, the background detection time of the short video application can be recalculated every 5 minutes, such as re-executing step 201; and it can be determined whether it is in the background inactivity period of the short video application. If it is in the background inactivity period, the short video application can be directly detected and killed, and subsequent detection time can be ignored.

[0252] In some embodiments of this application, if the short video application switches to foreground operation or terminates operation before the background detection time of the short video application is reached, the detection timer is canceled.

[0253] It should be noted that, after testing, using the application management method provided in this application embodiment, the application crash rate caused by Out Of Memory (OOM) decreased from 1.6% to 0.35%, a reduction of 78%. The incidence of high memory usage applications being forcibly terminated by the system due to potential memory leaks was reduced by 50%; this demonstrates the solution's ability to proactively identify and address potential risks.

[0254] In addition, through testing, the startup time of short video applications on electronic devices has been optimized by 3‰, the penetration rate of the main thread waiting for GC and the probability of GC waiting (wait) have been reduced by 5‰, the stuttering rate has been reduced by 0.01%, and the daily active users of short video applications have also increased.

[0255] As can be understood, the application management approach shown in the example above can not only reduce the OOM (Out of Memory) crash rate of applications on electronic devices by more than 78%, effectively curbing the spread of memory leaks, but also fundamentally reduce system-level lag and overheating. Ultimately, while ensuring efficient recovery of system resources, it maximizes the continuity of the user experience, achieving synergistic optimization of user experience and device performance.

[0256] Through the above examples, the first aspect can fundamentally reduce the risk of application crashes and resource leaks. By monitoring heap memory usage and lag performance, this solution can proactively intervene when an application experiences memory leaks or abnormally high memory usage, even after it has been moved to the background, preventing further deterioration. This directly results in: a significant reduction in the application crash rate due to insufficient memory (such as OOM) (e.g., experimental data shows a reduction from 1.6% to 0.35%); effective removal of "zombie" processes caused by potential memory leaks; and timely reclamation of system memory resources.

[0257] Secondly, it can improve system smoothness and energy efficiency. Through differentiated latency strategies, risks can be mitigated before they occur, and high-risk applications can be quickly eliminated, thus reducing foreground lag. Specifically, high-lag applications are quickly cleaned up, preventing users from experiencing a persistently poor experience when switching back; high-frequency garbage collection (GC) is one of the main causes of high CPU load and heat generation, so early elimination of high-memory applications reduces the frequency and intensity of GC triggers at the source, significantly reducing system-level GC wait time and events, thereby lowering the heat generation and power consumption caused by continuous high CPU load.

[0258] Thirdly, it can free up resources for foreground applications: the reclaimed memory and CPU resources can be immediately used for the user's current operation, ensuring the absolute smoothness of foreground tasks.

[0259] Fourthly, it enables seamless optimization of the user experience. Specifically, by delaying background process removal, unavoidable process termination is shifted from the highly noticeable foreground scenario; notifications are sent to save the state before removal, allowing the application to resume from its previous interface after restarting, transforming "removal" into "seamless restart" and ensuring the continuity of application use; for background applications with low risk of background persistence, removal decisions can be made based on data such as the background task identifier's position in the task list, its locked state, and the user's active time period, making the removal behavior more intelligent, more human-centered, and more respectful of the user's wishes, thereby improving the user experience.

[0260] Fifthly, the strategy parameters in this application (such as the strong / weak perception duration range of the application, the risk level corresponding to the detection conditions, and the detection delay duration corresponding to the risk level) can be continuously optimized based on big data analysis, so that the system management strategy can fit the behavior patterns of real user groups, achieve personalized scheduling, and maintain the best effect in the long term.

[0261] In summary, this application not only verifies its significant improvement in system stability and performance through quantitative indicators (such as OOM rate and GC events), but also achieves an excellent balance between technical execution and user experience through the "dynamic latency" and "seamless recovery" mechanisms, realizing a system management paradigm upgrade from "passive response to faults" to "proactive management of health".

[0262] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there are no contradictions, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0263] The application management method provided in this application embodiment can be executed by an application management device. This application embodiment uses the execution of the application management method by an application management device as an example to illustrate the application management device provided in this application embodiment.

[0264] This application provides an application management device, such as... Figure 3 As shown, the application management device 300 includes a processing module 301.

[0265] Processing module 301 is used for:

[0266] When the first application is running in the background, the background killing time of the first application is determined based on the first information of the first application. The first information includes at least one of the following: the heap memory usage information of the first application during its foreground operation, the lag performance information of the first application during its foreground operation, the position of the first application in the background task list, and the background working status information of the first application.

[0267] If the first application was running in the background before the aforementioned background detection time, then the first application will be terminated after the aforementioned background detection time is reached.

[0268] In one possible implementation, the processing module is specifically used to determine the background scanning time according to the scanning strategy corresponding to the target scanning condition when the first information satisfies at least one of the target scanning conditions.

[0269] In one possible implementation, the processing module is specifically used to calculate the background scanning time based on the first information and the first rule when the first information does not meet any of the scanning conditions in at least one scanning condition.

[0270] In one possible implementation, the first information mentioned above includes at least the lag performance information and the heap memory usage information mentioned above, and the at least one detection condition mentioned above includes lag performance condition and heap memory usage condition.

[0271] The above processing module is specifically used for:

[0272] If the above-mentioned lag performance information meets the above-mentioned lag performance conditions, the above-mentioned background scan time shall be determined according to the scan and removal strategy corresponding to the above-mentioned lag performance conditions.

[0273] If the above stuttering performance information does not meet the above stuttering performance conditions, but the above heap memory usage information meets the above heap memory usage conditions, the above background scanning time shall be determined according to the scanning strategy corresponding to the above heap memory usage conditions.

[0274] In one possible implementation, the application management device also includes a sending module;

[0275] The aforementioned sending module is used to send a data saving notification to the aforementioned first application before the aforementioned processing module terminates the operation of the aforementioned first application. The aforementioned data saving notification is used to notify the aforementioned first application to save the running data.

[0276] The aforementioned processing module is specifically used to terminate the operation of the first application when preset conditions are met.

[0277] Among them, meeting the preset conditions includes any one of the following:

[0278] After the first preset time period following the sending of the aforementioned data saving notification,

[0279] The system received a notification that the data sent by the first application had been saved successfully.

[0280] In the application management device provided in this application embodiment, since the background killing time of each background application can be dynamically determined based on at least one of the following: heap memory usage information of the background application (i.e., the background running application, such as the first application) during its foreground operation, lag performance information during its foreground operation, its position in the background task list, and background working status information, on the one hand, it can ensure that background applications with memory leaks, lag, no background tasks, or that the user will not use in the short term are killed as soon as possible, thereby effectively avoiding the probability of lag in foreground running applications and the phenomenon of device overheating, and improving the operating performance of electronic devices; on the other hand, it can ensure that applications with normal memory usage, no lag, performing background tasks, or that the user may use in the short term can remain in the background for a longer time, thereby improving the continuity of the user's use of applications with normal memory usage, and thus improving the operating performance of electronic devices.

[0281] The application management device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.

[0282] The application management device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0283] The application management device provided in this application embodiment can achieve... Figure 1 and Figure 2 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0284] Optionally, such as Figure 4 As shown, this application embodiment also provides an electronic device 400, including a processor 401 and a memory 402. The memory 402 stores a program or instructions that can run on the processor 401. When the program or instructions are executed by the processor 401, they implement the various steps of the above application management method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0285] It should be noted that the electronic devices in the embodiments of this application include mobile electronic devices and non-mobile electronic devices.

[0286] Figure 5 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0287] The electronic device 1500 includes, but is not limited to, components such as: radio frequency unit 1501, network module 1502, audio output unit 1503, input unit 1504, sensor 1505, display unit 1506, user input unit 1507, interface unit 1508, memory 1509, and processor 1510.

[0288] Those skilled in the art will understand that the electronic device 1500 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 1510 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0289] The processor 1510 is used for:

[0290] When the first application is running in the background, the background killing time of the first application is determined based on the first information of the first application. The first information includes at least one of the following: the heap memory usage information of the first application during its foreground operation, the lag performance information of the first application during its foreground operation, the position of the first application in the background task list, and the background working status information of the first application.

[0291] If the first application was running in the background before the aforementioned background detection time, then the first application will be terminated after the aforementioned background detection time is reached.

[0292] In one possible implementation, the processor 1510 is specifically used to determine the background scanning time according to the scanning strategy corresponding to the target scanning condition when the first information satisfies at least one of the target scanning conditions.

[0293] In one possible implementation, the processor 1510 is specifically used to calculate the background scanning time based on the first information and the first rule when the first information does not meet any of the scanning conditions in at least one scanning condition.

[0294] In one possible implementation, the first information mentioned above includes at least the lag performance information and the heap memory usage information mentioned above, and the at least one detection condition mentioned above includes lag performance condition and heap memory usage condition.

[0295] The aforementioned processor 1510 is specifically used for:

[0296] If the above-mentioned lag performance information meets the above-mentioned lag performance conditions, the above-mentioned background scan time shall be determined according to the scan and removal strategy corresponding to the above-mentioned lag performance conditions.

[0297] If the above stuttering performance information does not meet the above stuttering performance conditions, but the above heap memory usage information meets the above heap memory usage conditions, the above background scanning time shall be determined according to the scanning strategy corresponding to the above heap memory usage conditions.

[0298] In one possible implementation, the input unit 1504 is used to send a data saving notification to the first application before the processor 1510 terminates the operation of the first application. The data saving notification is used to notify the first application to save the running data.

[0299] The processor 1510 is specifically used to terminate the operation of the first application when preset conditions are met.

[0300] Among them, meeting the preset conditions includes any one of the following:

[0301] After the first preset time period following the sending of the aforementioned data saving notification,

[0302] The system received a notification that the data sent by the first application had been saved successfully.

[0303] In the electronic device provided in this application embodiment, since the background killing time of each background application can be dynamically determined based on at least one of the following: heap memory usage information of the background application (i.e., the background running application, such as the first application) during its foreground operation, lag performance information during its foreground operation, its position in the background task list, and background working status information, on the one hand, background applications with memory leaks, lag, no background tasks, or that the user will not use in the short term can be killed as soon as possible, thereby effectively avoiding the probability of lag in foreground running applications and the phenomenon of device overheating, and improving the operating performance of the electronic device; on the other hand, it can ensure that applications with normal memory usage, no lag, performing background tasks, or that the user may use in the short term can remain in the background for a longer time, thereby improving the continuity of the user's use of applications with normal memory usage, and thus improving the operating performance of the electronic device.

[0304] It should be understood that, in this embodiment, the input unit 1504 may include a graphics processing unit (GPU) 15041 and a microphone 15042. The GPU 15041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 1506 may include a display panel 15061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 1507 includes at least one of a touch panel 15071 and other input devices 15072. The touch panel 15071 is also called a touch screen. The touch panel 15071 may include a touch detection device and a touch controller. Other input devices 15072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0305] The memory 1509 can be used to store software programs and various data. The memory 1509 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 1509 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 1509 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0306] Processor 1510 may include one or more processing units; optionally, processor 1510 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 1510.

[0307] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described application management method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0308] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0309] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above application management method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0310] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0311] This application provides a computer program product that is stored in a storage medium and executed by at least one processor to implement the various processes described in the above application management method embodiments, and achieves the same technical effects. To avoid repetition, further details are omitted here.

[0312] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0313] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0314] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. An application management method, characterized in that, The method includes: When the first application is running in the background, the background killing time of the first application is determined based on the first information of the first application. The first information includes at least one of the following: the heap memory usage information of the first application during its foreground operation, the lag performance information of the first application during its foreground operation, the position of the first application in the background task list, and the background working status information of the first application. If the first application is running in the background before the background detection time, then the first application will be terminated after the background detection time is reached.

2. The method according to claim 1, characterized in that, Determining the background scanning time of the first application based on the first information of the first application includes: If the first information satisfies at least one of the target detection conditions, the background detection time is determined according to the detection strategy corresponding to the target detection condition.

3. The method according to claim 1 or 2, characterized in that, Determining the background scanning time of the first application based on the first information of the first application includes: If the first information does not meet any of the at least one detection condition, the background detection time is calculated based on the first information and the first rule.

4. The method according to claim 2, characterized in that, The first information includes the lag performance information and the heap memory usage information, and the at least one detection condition includes lag performance conditions and heap memory usage conditions; When the first information satisfies at least one target detection condition among the detection conditions, determining the background detection time according to the detection strategy corresponding to the target detection condition includes: If the lag performance information meets the lag performance conditions, the background scanning time is determined according to the scanning strategy corresponding to the lag performance conditions. If the lag performance information does not meet the lag performance conditions, but the heap memory usage information meets the heap memory usage conditions, the background scanning time is determined according to the scanning strategy corresponding to the heap memory usage conditions.

5. The method according to claim 1, characterized in that, Before terminating the operation of the first application, the method further includes: Send a data save notification to the first application, the data save notification being used to notify the first application to save the running data; The termination of the first application includes: If the preset conditions are met, the first application will be terminated. The preset conditions include any one of the following: After the first preset time period following the sending of the data saving notification, The system receives a notification that the data has been saved successfully from the first application.

6. An application management device, characterized in that, The device includes: Processing module, used for: When the first application is running in the background, the background killing time of the first application is determined based on the first information of the first application. The first information includes at least one of the following: the heap memory usage information of the first application during its foreground operation, the lag performance information of the first application during its foreground operation, the position of the first application in the background task list, and the background working status information of the first application. If the first application is running in the background before the background detection time, then the first application will be terminated after the background detection time is reached.

7. The apparatus according to claim 6, characterized in that, The processing module is specifically used to determine the background scanning time according to the scanning strategy corresponding to the target scanning condition when the first information satisfies the target scanning condition among at least one scanning condition.

8. The apparatus according to claim 6 or 7, characterized in that, The processing module is specifically used to calculate the background scanning time based on the first information and the first rule when the first information does not meet any of the scanning conditions in at least one scanning condition.

9. The apparatus according to claim 7, characterized in that, The first information includes at least the lag performance information and the heap memory usage information, and the at least one detection condition includes lag performance conditions and heap memory usage conditions; The processing module is specifically used for: If the lag performance information meets the lag performance conditions, the background scanning time is determined according to the scanning strategy corresponding to the lag performance conditions. If the lag performance information does not meet the lag performance conditions, but the heap memory usage information meets the heap memory usage conditions, the background scanning time is determined according to the scanning strategy corresponding to the heap memory usage conditions.

10. The apparatus according to claim 6, characterized in that, The device also includes a transmitting module; The sending module is used to send a data saving notification to the first application before the processing module terminates the operation of the first application. The data saving notification is used to notify the first application to save the running data. The processing module is specifically used to terminate the operation of the first application when preset conditions are met; The preset conditions include any one of the following: After the first preset time period following the sending of the data saving notification, The system receives a notification that the data has been saved successfully from the first application.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the application management method as described in any one of claims 1-5.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the application management method as described in any one of claims 1-5.

Images