Process processing method and electronic device

Abstract

The present disclosure provides a process processing method and an electronic device, the method comprising: determining at least one background process; determining a target process from the background processes based on the keep-alive priority of each background process, the keep-alive priority of the background process being determined based on the removal cost of the background process and the keep-alive cost; cleaning up the target process; wherein the removal cost represents the cost of restarting after cleaning up the background process, and the keep-alive cost represents the memory pressure caused by saving the background process in the background.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the field of memory management technology, and in particular to a process processing method and electronic device. Background Technology

[0002] On embedded devices such as mobile phones and tablets, due to limited computing and storage resources, the system is prone to memory shortages when users run multiple applications simultaneously. When memory is low, memory is usually reclaimed by clearing background cached applications. However, current detection strategies are usually based on the running status of processes and do not take into account user habits or the current memory pressure on the system, resulting in a significant impact on user experience or failing to truly alleviate memory pressure. Summary of the Invention

[0003] In view of this, the present disclosure provides a process processing method and an electronic device.

[0004] One aspect of this disclosure provides a process handling method, comprising: determining at least one background process; determining a target process from the background processes based on the keep-alive priority of each background process, wherein the keep-alive priority of the background process is determined based on the clearing cost and the keep-alive cost of the background process; and cleaning up the target process; wherein the clearing cost represents the cost of restarting the background process after cleaning it up, and the keep-alive cost represents the memory pressure caused by keeping the background process in the background.

[0005] According to embodiments of this disclosure, the method further includes: selecting background processes that do not meet preset conditions as target processes, where the preset conditions indicate that the frequency of user use of the background process is greater than a preset frequency; for background processes that meet the preset conditions, selecting at least one background process with a keep-alive priority less than a priority threshold as a target process, or determining at least one target process from the background processes based on the sorting result of the keep-alive priority.

[0006] According to embodiments of this disclosure, the method further includes: for each background process, determining the delay cost of restarting the background process based on the average cold start time of the background process and a preset tolerance; determining the unrecoverability of the background process based on the type of the background process, wherein the unrecoverability characterizes the degree to which the running state of the background process cannot be recovered when it is restarted; and determining the cleanup cost based on the delay cost of restarting the background process and the unrecoverability.

[0007] According to embodiments of this disclosure, determining the unrecoverability of a background process based on its type includes: responding to a first type of background process, setting the unrecoverability of the background process to a first preset value, where the first type represents a process type where the scene data is real-time; responding to a second type of background process, setting the unrecoverability of the background process to a second preset value, where the second preset value is less than the first preset value, where the second type represents a process type where the scene data is not real-time and does not support page recovery; responding to a third type of background process, setting the unrecoverability of the background process to a third preset value, where the third preset value is less than the second preset value, where the third type represents a process type where the scene data is not real-time and supports page recovery.

[0008] According to embodiments of this disclosure, the method further includes: generating page information for each page launched during the use of a background process that supports page recovery; retaining the page information of the current page of the background process when the background process is cleaned up; and recreating and displaying the pages launched before the background process was cleaned up using the retained page information in response to the background process being launched again.

[0009] According to embodiments of this disclosure, the method further includes: obtaining current memory status information through a memory status file and calculating the current memory pressure value based on the current status information; obtaining the memory usage of background processes from the memory status file; and determining the keep-alive cost of background processes based on the current memory pressure value and the memory usage of background processes.

[0010] According to embodiments of this disclosure, the keep-alive priority of a background process is further determined based on its activity level, which represents the frequency with which the background process is used within a target time period. The method further includes: determining the activity level of the background process based on a preset initial activity level and the time interval between the moment the background process is switched to the background and the current moment.

[0011] According to embodiments of this disclosure, the method includes: for each background process, determining a ratio between the cost of erasure and the cost of keeping it alive; and determining the keep-alive priority of the background process based on the sum of the ratio and the activity level.

[0012] According to embodiments of this disclosure, the method further includes: adjusting the keep-alive priority of the background process to be less than the priority threshold in response to a background process having a keep-alive priority greater than a priority threshold and detecting that a service associated with the background process is not running. Another aspect of this disclosure provides an apparatus, including:

[0013] Another aspect of this disclosure provides an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the method described above.

[0014] Another aspect of this disclosure provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the methods described above.

[0015] Another aspect of this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0017] The above and other objects, features and advantages of this disclosure will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 A flowchart illustrating a process processing method according to an embodiment of the present disclosure is shown schematically.

[0019] Figure 2 A flowchart illustrating a process processing method according to another embodiment of the present disclosure is shown schematically;

[0020] Figure 3 A flowchart illustrating the determination of the cleanup cost according to an embodiment of the present disclosure is shown schematically;

[0021] Figure 4 A flowchart illustrating the determination of irrecoverability according to an embodiment of this disclosure is shown schematically;

[0022] Figure 5 The diagram schematically illustrates a software architecture that can be used to implement the process processing method of the embodiments of this disclosure;

[0023] Figure 6 A schematic block diagram of an electronic device that can be used to implement the process processing method of the embodiments of the present disclosure is shown. Detailed Implementation

[0024] The embodiments of this disclosure will now be described with reference to the accompanying drawings. Various details of the embodiments of this disclosure are included to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0025] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of data (including but not limited to user personal information) comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and they do not violate public order and good morals.

[0026] On embedded devices such as mobile phones and tablets, computing and storage resources are limited, and the system is prone to memory shortages when users run multiple applications simultaneously. In some heavy-load scenarios, many applications reside in the system. When memory is scarce, clearing background cached applications to reclaim memory is a common memory reclamation method currently used on embedded devices.

[0027] The choice of which applications and processes to eliminate during this process significantly impacts the user experience. Inappropriate elimination strategies can lead to two negative outcomes. First, frequently used applications are quickly eliminated after being switched to the background, requiring the user to wait for the application to reload when switching back, resulting in the loss of previous data. Second, some applications, especially third-party applications, utilize system mechanisms to remain active in the background for extended periods, preventing memory reclamation and alleviating memory pressure.

[0028] Currently, the common approach for selecting processes to be cleaned up is to assign a priority value to each process. When system memory is low, processes are cleaned up according to their priority. This tells the system which processes should be cleaned up and which should be kept when memory is tight. The priority value ranges from -1000 to +1000, with higher numbers indicating processes are more likely to be cleaned up.

[0029] For example, cached processes typically have a priority value greater than 900. These processes have been moved to the background and can be cleared by the system when memory is low. Recently used processes typically have a priority value of 700. These are applications recently used by the user, and for a period of time after being moved to the background (the time threshold is set by the system), the system assigns them a priority value of 700. After a certain period, these processes are designated as cached processes. The user-perceived priority value range for processes is typically [200, 250]. The UI of these processes is not currently displayed on the screen, but they affect the user experience; examples include background music and navigation. Foreground processes typically have a priority value of 100, while foreground processes typically have a priority value of 0.

[0030] When a process's state changes, the system calculates and updates the process's priority value. The system process that performs memory management in the background will kill processes based on their priority values, from high to low. It will prioritize killing processes in the cached state, i.e., cached processes. In extreme cases, it will kill processes that are visible to the user or even processes running in the foreground to alleviate memory pressure.

[0031] However, this process priority setting, based on the process's current running state, does not consider user habits. After a process is switched to the background, it enters a cached state after a certain period, and its priority value becomes above 900. Processes in the cached state are prioritized for recycling by the system. For some processes switched to the background, users are more likely to switch back and use them. If priority values ​​alone are used, these frequently used processes can easily be cleared, causing user data loss and requiring data reloading upon restarting, resulting in a poor user experience.

[0032] For some applications, using the above method to keep them alive is not conducive to alleviating memory pressure. For example, some third-party applications declare services that include a foreground, so that the system assigns them a higher priority. Even if the current user does not use the foreground service, it can still reside in memory for a long time, causing memory pressure to not be relieved in time.

[0033] Therefore, selecting processes to be cleared using the above method does not fully consider the user experience. The result is that some applications that shouldn't be cleared are cleared, while those that should be cleared can remain in the system for extended periods. That is, when system memory is low, some frequently used applications are quickly cleared after being switched to the background, while some third-party applications, by increasing their priority to stay alive, remain in the system for a long time, causing them to continuously occupy memory.

[0034] Figure 1 A flowchart illustrating a process processing method according to an embodiment of the present disclosure is shown, such as... Figure 1 As shown, this embodiment includes operations S110 to S130.

[0035] In operation S110, at least one background process is identified.

[0036] In this embodiment of the disclosure, a background process can refer to a process that runs in the background, is not displayed in the foreground, and does not directly interact with the user. Specifically, when a stress event is detected, at least one background process can be identified. For example, if insufficient memory resources, excessive memory usage, or available memory is detected below a preset threshold, at least one background process can be identified from a list of currently running processes.

[0037] In operation S120, the target process is determined from the background processes based on the keep-alive priority of each background process. The keep-alive priority of the background process is determined based on the clearing cost and keep-alive cost of the background process.

[0038] In this embodiment of the disclosure, the cleanup cost represents the cost of restarting the background process after it has been cleaned up, and the keep-alive cost represents the memory pressure caused by keeping the background process in the background.

[0039] In this embodiment of the disclosure, after determining at least one background process, the cleanup cost and keep-alive cost of each background process are calculated. The cleanup cost may refer to the cost of restarting, loading wait, and data loss caused by restarting the background process after it has been cleaned up. The keep-alive cost may refer to the memory pressure caused by keeping the background process in the background due to the memory resources it occupies.

[0040] After calculating the cleanup cost and keep-alive cost of each background process, the keep-alive priority of each background process can be determined based on the cleanup cost and keep-alive cost. The higher the keep-alive priority, the more likely it should be kept alive. Therefore, the target processes that can be cleaned up first can be determined from the background processes based on the keep-alive priority.

[0041] Operation S130 cleans up the target process.

[0042] In this embodiment of the disclosure, cleaning up the target process may refer to terminating the process to reclaim memory and alleviate memory pressure.

[0043] The embodiments disclosed herein determine the keep-alive priority of background processes by considering the cleanup cost and the keep-alive cost, and perform background cleanup based on the keep-alive priority. This allows for a more reasonable selection of target processes to be cleaned up, thereby reducing the impact on user experience while relieving memory pressure.

[0044] According to embodiments of this disclosure, the method further includes: selecting background processes that do not meet preset conditions as target processes, where the preset conditions indicate that the frequency of user use of the background process is greater than a preset frequency; for background processes that meet the preset conditions, selecting at least one background process with a keep-alive priority less than a priority threshold as a target process, or determining at least one target process from the background processes based on the sorting result of the keep-alive priority.

[0045] In this embodiment, user usage records can be obtained, which may include information such as events in which each background process is used. Based on these records, the frequency of user usage of each background process in the recent period can be determined. A preset condition is set to the user's usage frequency of the background process being greater than a preset frequency. If a background process does not meet the preset condition, it indicates that the background process is not frequently used by the user and can be prioritized for cleanup, i.e., the background process is selected as the target process. If the memory pressure is still relatively high after cleaning up background processes that do not meet the preset condition, it indicates that at least one more background process needs to be cleaned up.

[0046] For example, the preset conditions may include at least one of the following: the application is launched an average of three times or more per day, the average usage time per session is greater than or equal to ten minutes, and the cumulative usage time per day is greater than or equal to thirty minutes. When the user's usage record meets at least one of the above preset conditions, the process corresponding to the application can be considered to be a process frequently used by the user.

[0047] For background processes that meet preset conditions, two methods can be used to determine the target process. For example, a keep-alive priority threshold can be set, and the keep-alive priority can be compared with the threshold; background processes with a keep-alive priority lower than the threshold can be selected as target processes. Alternatively, the keep-alive priorities can be sorted, and at least one background process can be selected as the target process based on the sorting result.

[0048] This disclosure takes into account the user's usage of background processes, prioritizes cleaning up background processes that the user does not use frequently, and then calculates the priority of background processes that the user uses frequently and selects one or more to clean up, thereby improving the rationality of application keep-alive and the continuity of user use, and minimizing the impact of background cleanup on the user.

[0049] According to embodiments of this disclosure, the method further includes: for each background process, determining the delay cost of restarting the background process based on the average cold start time of the background process and a preset tolerance; determining the unrecoverability of the background process based on the type of the background process, wherein the unrecoverability characterizes the degree to which the running state of the background process cannot be recovered when it is restarted; and determining the cleanup cost based on the delay cost of restarting the background process and the unrecoverability.

[0050] In this embodiment of the disclosure, if a background process is cleared and the user needs to switch back to that process, the user must wait for the process to restart. Under heavy load scenarios, system resources are scarce, and increased process startup time means further increased waiting time for the user, leading to a further decrease in user satisfaction.

[0051] The average cold start time of a background process can refer to the average cold start time of the application corresponding to that background process recorded in the system. Specifically, it can be calculated based on the time required for each cold start. The preset tolerance can refer to the user's usual tolerance for the application's startup time. Specifically, it can be a preset value, and this value can be a general value applicable to different applications.

[0052] For example, the delay cost of restarting the background process can be determined according to formula (1).

[0053] Formula (1)

[0054] in, This indicates the latency cost of restarting the background process. This indicates the average cold start time of the application as recorded by the system. This indicates the preset tolerance level, which can be set to 3 seconds. If the average startup time of a process is >= This indicates that the process is... High. This process should be prioritized for survival.

[0055] Different types of background processes have different levels of unrecoverability. Unrecoverability indicates whether the process can return to its previous state after restarting and whether user data can be retained. For example, in games, which are usually real-time, the in-game scene data will change after being cleared. Therefore, the unrecoverability of such processes is relatively high, meaning that the background process cannot be restored to its original running state after being cleared. On the other hand, music players have a relatively low level of unrecoverability, meaning that the background process can be restored to its original running state after being cleared.

[0056] After determining the delay cost and irrecoverability of restarting the background process, the clearing cost can be determined according to formula (2).

[0057] Formula (2)

[0058] in, Indicates the cost of elimination. This indicates the latency cost of restarting the background process. Indicates the degree of irrecoverability.

[0059] The embodiments disclosed herein can more reasonably calculate the clearing cost based on startup time and irrecoverability, which is more in line with the user's actual experience, thereby improving the accuracy of priority calculation.

[0060] According to embodiments of this disclosure, determining the unrecoverability of a background process based on its type includes: responding to a first type of background process, setting the unrecoverability of the background process to a first preset value, where the first type represents a process type where the scene data is real-time; responding to a second type of background process, setting the unrecoverability of the background process to a second preset value, where the second preset value is less than the first preset value, where the second type represents a process type where the scene data is not real-time and does not support page recovery; responding to a third type of background process, setting the unrecoverability of the background process to a third preset value, where the third preset value is less than the second preset value, where the third type represents a process type where the scene data is not real-time and supports page recovery.

[0061] In this embodiment of the disclosure, the first preset value, the second preset value, and the third preset value can be set to 2, 1, and 0, respectively. The higher the value of the irrecoverability, the worse its recoverability, and the greater the impact on user experience. Therefore, it should be prioritized to keep the user alive.

[0062] The first type includes games. Many mainstream games involve multiple players online simultaneously. Once a process is deleted, user data cannot be saved. Even if it could be saved, the real-time nature of games means the data at the time of deletion will differ from the data after restarting, significantly impacting the user experience. Therefore, if a game is a frequently used process, it should be prioritized for preservation. Thus, the irrecoverability of this process is set to the first preset value, which is 2.

[0063] If the background process is not a game or a first-type process, it can be further determined whether the process supports page recovery. If it does not support recovery, that is, the process type is second-type, then the unrecoverability level is set to the second preset value, i.e., 1. If it supports recovery, that is, the process type is third-type, then the unrecoverability level is set to the third preset value, i.e., 0.

[0064] This embodiment of the disclosure distinguishes processes with different recovery capabilities in a fine-grained manner and configures different unrecoverable levels for different process types, which can prevent processes with high unrecoverable levels from being mistakenly cleaned up.

[0065] According to embodiments of this disclosure, the method further includes: generating page information for each page launched during the use of a background process that supports page recovery; retaining the page information of the current page of the background process when the background process is cleaned up; and recreating and displaying the pages launched before the background process was cleaned up using the retained page information in response to the background process being launched again.

[0066] In this embodiment of the disclosure, the user interface can be implemented through page components. For each launched page, the system generates page information, which includes relevant information required to launch the page. Page information for multiple pages launched within a single process is stored in the record information associated with that process. When the system launches an application, if it finds that the record information associated with that application already exists, it will reuse the page information stored in that record and launch the corresponding page.

[0067] For processes slated for cleanup, the system analyzes the page information displayed when the process exits to determine if it can return to the previous page upon restarting. If so, the application can be indirectly kept alive through the page restoration process.

[0068] For example, when the process is cleared, the page information of the application is retained on the page management server. When the application is restarted, the page information of the process that was previously retained is used to recreate and start the corresponding page, so that you can return to the page where you were when you exited the application.

[0069] This embodiment of the disclosure can quickly alleviate memory pressure by dynamically identifying and eliminating applications that support page recovery when system memory is low. At the same time, when the user restarts the application, they can return to the previously accessed page, reducing the impact on user experience.

[0070] According to embodiments of this disclosure, the method further includes: obtaining current memory status information through a memory status file and calculating the current memory pressure value based on the current status information; obtaining the memory usage of background processes from the memory status file; and determining the keep-alive cost of background processes based on the current memory pressure value and the memory usage of background processes.

[0071] In this embodiment, the memory status file records current memory status information, such as the usage of total available memory, free memory, cache memory, and swap partition. Then, based on the relevant built-in modules and memory status information, the current memory pressure value can be calculated to indicate the current level of memory strain. The memory usage of background processes specifically refers to the actual amount of physical memory occupied by the background processes. After determining the current memory pressure value and the memory usage of background processes, the keep-alive cost of the background processes can be determined based on these two data points.

[0072] For example, the cost of keeping alive can be determined based on formula (3).

[0073] Formula (3)

[0074] in, represents the keep-alive cost, This represents the current system memory pressure value, calculated by the system's built-in module. The value can be in the range of (0,1), with a larger value indicating greater memory pressure. This represents the memory pressure index, specifically an integer constant between 2 and 4. RSS represents the size of the resident memory set of the current application process, in MB. RSSToleranceValue is a constant that defines an acceptable memory value. Different values ​​can be set based on the device's memory size; for example, for devices with 4-6GB of memory, this constant can be set to 500MB, and for devices with more than 8GB of memory, it can be set to 700MB.

[0075] This embodiment of the disclosure calculates the keep-alive cost by combining the current memory usage of the system and the memory usage of background processes, and can accurately calculate the memory pressure caused by keeping the background process in the background.

[0076] According to embodiments of this disclosure, the keep-alive priority of a background process is further determined based on its activity level, which characterizes the frequency of use of the background process within a target time period. The method further includes: determining the activity level of the background process based on a preset initial activity level and the time interval between the moment the background process is switched to the background and the current moment.

[0077] In this embodiment of the disclosure, the target time period can refer to a recent period of time, such as the past five minutes or half an hour. The activity level can be used to measure whether a user switches back to a background process after it has been switched to the background. Specifically, it can be calculated by the time the process stays in the background. The longer the process stays in the background after the user has last used the process and switched to the background, the lower the score for this item.

[0078] For example, activity can be determined based on formula (4).

[0079] Formula (4)

[0080] in, Indicates activity level. This indicates the activity level of the process at the initial moment, which is defined as the moment when the application switches from the foreground to the background. It can be a constant, and its value can be set to 5. It can be defined as the device's current system time, in milliseconds. Defined as the moment when the application switches from foreground to background, in milliseconds. The value range is [0, 5].

[0081] If a user quickly switches back to a process after it has been switched to the background, the process's activity level will remain at a high value. Conversely, if a user does not switch back to a process after it has been switched to the background, the process's activity level will continue to decrease as the time it remains in the background increases, eventually reaching 0.

[0082] If some applications that were previously assigned a high keep-alive priority value are switched to the background for a period of time and the user does not switch back to that process to continue using it, their keep-alive priority will be reduced during the recalculation, and they can be cleared. This can prevent some processes that users no longer use from residing in the system for a long time and consuming memory.

[0083] The embodiments of this disclosure calculate the activity level by the time the background process resides in the background, which can reflect the probability that the user will use the background process again. Based on the activity level, the keep-alive priority is determined, which can avoid cleaning up processes that the user may use again, and also avoid processes that the user no longer uses occupying memory for a long time.

[0084] According to embodiments of this disclosure, the method includes: for each background process, determining a ratio between the cost of erasure and the cost of keeping it alive; and determining the keep-alive priority of the background process based on the sum of the ratio and the activity level.

[0085] In this embodiment, the keep-alive priority is described by a numerical value, which is greater than 0. The larger the value, the higher the keep-alive priority of the process, and the more likely it should be kept alive. Calculating the priority based on the cost of erasure, the cost of keep-alive, and the activity level allows for a comprehensive and dynamic evaluation from multiple dimensions of whether a process should be kept alive in a current memory-constrained scenario.

[0086] The cost of removal can be quantified in two ways: the latency of restarting the background process and the degree of irreversibility, which determine the impact of an application being removed by the system on the user experience. The cost of keeping the application alive can be comprehensively and dynamically assessed by considering the memory occupied by the application while it resides in the system, combined with the current system's memory pressure (custom metrics, such as memory pressure index). Activity level can consider the length of time the application resides in the background, preventing applications that are not used by users from remaining in memory for extended periods, thus avoiding unrelieved system pressure.

[0087] For example, the survival priority can be calculated based on formula (5).

[0088] Formula (5)

[0089] in, Indicates the priority of keeping the user alive. Indicates the cost of elimination. represents the keep-alive cost, Indicates activity level.

[0090] This disclosure considers both the impact of application deletion on user experience and the impact of applications remaining in memory on the system. Therefore, it prioritizes the deletion of applications that have a smaller impact on user experience while also alleviating system memory pressure. Furthermore, the calculation of keep-alive priority is a dynamic process. The same application will be assigned different keep-alive priorities under different memory pressure scenarios and different background persistence durations, achieving a good balance between ensuring user experience and alleviating memory pressure.

[0091] According to embodiments of this disclosure, the method further includes: in response to a background process having a keep-alive priority greater than a priority threshold and detecting that a service associated with the background process is not running, adjusting the keep-alive priority of the background process to be less than the priority threshold.

[0092] In this embodiment of the disclosure, for background processes whose keep-alive priority is determined to be greater than the priority threshold, such as user-perceptible processes, such as music players, it is determined whether their related foreground services are running. If they are not running, it means that the keep-alive priority of the background process needs to be adjusted to be less than the priority threshold in order to avoid such processes occupying memory for a long time.

[0093] This embodiment of the disclosure can prevent processes that are not currently being used by the user from being given high priority, remaining in memory for a long time, and being unable to be cleared by detecting whether background process-related services are running.

[0094] Figure 2 A flowchart illustrating a process processing method according to another embodiment of this disclosure is shown, such as Figure 2 As shown, this embodiment includes operations S210 to S270.

[0095] In operation S210, at least one background process is identified upon detecting a memory pressure event.

[0096] In this embodiment of the disclosure, a memory pressure event can refer to insufficient memory resources, excessive memory usage, or available memory falling below a preset threshold. When a memory pressure event is detected, at least one background process can be identified by obtaining a list of currently running processes in the system.

[0097] In operation S220, determine whether there are background processes whose usage frequency is less than or equal to the preset frequency.

[0098] In this embodiment of the disclosure, it can be determined whether there are background processes that the user does not use frequently by judging whether there are background processes that are used less than or equal to a preset frequency.

[0099] If it exists, execute operation S230; otherwise, execute operation S250.

[0100] In operation S230, clear background processes whose usage frequency is less than or equal to the preset frequency.

[0101] In this embodiment of the disclosure, processes that are not frequently used by the user can be cleared first to ensure the user experience.

[0102] In operation S240, determine whether it is necessary to delete background processes that are used more frequently than a preset frequency.

[0103] In this embodiment of the disclosure, it can be determined whether to delete frequently used processes by the user by detecting whether memory pressure events still exist.

[0104] If deletion is required, execute operation S250; otherwise, execute operation S270.

[0105] When operating S250, priority is calculated for background processes that are used more frequently than a preset frequency.

[0106] In this embodiment of the disclosure, for processes that users frequently use, the clearing cost, keep-alive cost, and activity level of each process can be calculated separately, and the keep-alive priority can be calculated.

[0107] When operating S260, at least one background process is selected for cleanup based on keep-alive priority.

[0108] In this embodiment of the disclosure, one or more background processes can be selected for cleanup by sorting the keep-alive priority, or one or more background processes can be selected for cleanup by determining whether the keep-alive priority is less than the priority threshold.

[0109] S270 operation completed.

[0110] Figure 3 A flowchart illustrating the determination of a cleanup cost according to an embodiment of the present disclosure is shown, such as Figure 3 As shown, this embodiment includes operations S310 to S330.

[0111] In operation S310, the average cold start time of the application is calculated based on the time required for each cold start of the application corresponding to the background process, and the delay cost of restarting the application corresponding to the background process is determined based on the average cold start time and the preset tolerance.

[0112] In this embodiment of the disclosure, for each application corresponding to a background process, the system records the time required for each cold start, and calculates the average cold start time of the application based on the time required for each cold start. For example, the average cold start time of the application corresponding to the background process can be calculated based on the time required for each cold start and the number of cold starts within a recent period, such as a month.

[0113] The preset tolerance can represent the user's tolerance for the application's startup time. For example, setting it to 3 seconds means that if the user waits for the application to start for more than 3 seconds, it will result in a poor user experience. After determining the average cold start time and the preset tolerance, the delay cost of restarting the background process can be determined based on the above formula (1).

[0114] When operating S320, the unrecoverability of a background process is determined based on its type and the correspondence between the type and its unrecoverability.

[0115] In this embodiment, the type of background process can be determined based on whether the scenario data of the background process is real-time and whether the background process supports page recovery. Furthermore, this embodiment pre-sets a correspondence between the type and the degree of unrecoverability; that is, for different types, a corresponding degree of unrecoverability is pre-set. Therefore, the unrecoverability of the background process can be determined based on the type of the background process and the correspondence between the type and the degree of unrecoverability.

[0116] When operating S330, the cleanup cost is determined based on the delay cost and irrecoverability of restarting the background process.

[0117] For example, the delay cost of restarting the background process and the unrecoverability can be added together, and the sum can be used as the cost of clearing the background process.

[0118] Figure 4 A flowchart illustrating the determination of irrecoverability according to embodiments of the present disclosure is shown, such as... Figure 4 As shown, this embodiment includes operations S410 to S450.

[0119] When operating the S410, determine whether the scenario data of the background process is real-time.

[0120] In this embodiment of the disclosure, the scene data is real-time in a background process such as a game. Specifically, the real-time nature of the scene data in a background process can be determined by whether the scene data changes while the background process is running in the foreground and the user is not interacting with it.

[0121] For example, a list of processes with real-time scene data can be maintained in the system. This list can include processes with real-time scene data, such as games where multiple people participate online at the same time. The real-time nature of the scene data of a background process can be determined by checking whether it is in the list.

[0122] If the scene data of the background process is real-time, then proceed to step S420; if the scene data of the background process is not real-time, then proceed to step S430.

[0123] When operating S420, the irrecoverability is set to the first preset value.

[0124] For example, the first preset value can be set to 2. The higher the unrecoverability, the worse the recoverability of the process, and the greater the impact on user experience. Therefore, it should be prioritized to keep the process alive.

[0125] When operating the S430, determine whether the background process supports page recovery.

[0126] In this embodiment of the disclosure, it can be determined whether the background process supports page recovery by determining whether the page information of the background process can be obtained.

[0127] Specifically, for background processes that support page recovery, page information is generated for each page launched while the background process is in use by the user. Therefore, when the background process is cleared, because the system saves the page information of the pages displayed at the time of clearing, the pages displayed at the time of clearing can be recreated based on this page information when the application corresponding to the background process is launched again, thus reducing the impact on user experience.

[0128] If the background process does not support page recovery, then execute operation S440; if the background process does support page recovery, then execute operation S450.

[0129] When operating S440, the irrecoverability is set to the second preset value.

[0130] The second preset value can be set to a value less than the first preset value. For example, if the first preset value is set to 2, the second preset value can be set to 1.

[0131] When operating S450, set the irrecoverability to the third preset value.

[0132] The third preset value can be set to a value less than the second preset value. For example, if the second preset value is set to 1, the third preset value can be set to 0.

[0133] Figure 5 The diagram illustrates a software architecture that can be used to implement the process processing method of the embodiments of this disclosure.

[0134] like Figure 5 As shown, when pressure blocking information 510 is detected, pressure blocking information trigger 520 sends a pressure event to management thread 530, indicating that the current memory is relatively tight.

[0135] Upon receiving the stress event, management thread 530 sends a signal to the memory cleanup component, indicating that memory needs to be cleaned up. Upon receiving this signal, memory cleanup component 540 obtains current memory statistics from memory file 550, calculates the current system memory pressure value, and publishes the calculated memory pressure value to memory pressure module 570 in shared memory for reference by other modules in the system. Simultaneously, memory cleanup component 540 sends the MPI value to cleanup strategy component 560, which determines the target processes to be cleaned up. The management thread 530, memory cleanup component 540, and cleanup strategy component 560 together constitute the service layer for implementing this embodiment of the present disclosure.

[0136] Figure 6 A schematic block diagram of an electronic device that can be used to implement the methods of embodiments of the present disclosure is shown.

[0137] like Figure 6 As shown, an electronic device 600 according to an embodiment of this disclosure includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this disclosure.

[0138] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 performs various operations of the method flow according to embodiments of this disclosure by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also implement the methods provided in embodiments of this disclosure by executing programs stored in said one or more memories.

[0139] According to embodiments of this disclosure, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0140] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0141] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0142] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this disclosure.

[0143] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0144] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0145] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0146] It should be noted that the collection, storage, use, processing, transmission, provision, disclosure, and application of user personal information in this disclosed technical solution comply with relevant laws and regulations, necessary confidentiality measures have been taken, and it does not violate public order and good morals. In this disclosed technical solution, user authorization or consent has been obtained before acquiring or collecting user personal information.

[0147] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on a user's computing device, partially on a user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0148] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0149] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined and / or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0150] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A process processing method, the method comprising: Identify at least one background process; Based on the keep-alive priority of each background process, the target process is determined from the background processes, and the keep-alive priority of the background processes is determined based on the clearing cost and keep-alive cost of the background processes. Clean up the target process; Wherein, the clearing cost represents the cost of restarting the background process after clearing it, and the keep-alive cost represents the memory pressure caused by keeping the background process in the background.

2. The method according to claim 1, further comprising: Background processes that do not meet the preset conditions are selected as target processes. The preset conditions indicate that the frequency of user use of the background process is greater than the preset frequency. For background processes that meet the preset conditions, at least one background process with a keep-alive priority less than the priority threshold is selected as the target process, or at least one target process is determined from the background processes based on the sorting result of the keep-alive priority.

3. The method according to claim 1, further comprising: For each background process, the latency cost of restarting the background process is determined based on the average cold start time of the background process and a preset tolerance. Based on the type of the background process, the unrecoverability of the background process is determined. The unrecoverability represents the degree to which the running state of the background process cannot be recovered when it is restarted. The cleanup cost is determined based on the delay cost and irrecoverability of restarting the background process.

4. The method according to claim 3, wherein determining the unrecoverability of the background process based on its type includes: In response to the background process being of type 1, the unrecoverability of the background process is set to a first preset value, where the first type represents the process type where the scene data has real-time characteristics; In response to the background process being of the second type, the unrecoverability of the background process is set to a second preset value, which is less than the first preset value. The second type represents a process type where the scene data is not real-time and does not support page recovery. In response to the background process being of type three, the unrecoverability of the background process is set to a third preset value, which is less than the second preset value. The third type represents a process type where the scene data is not real-time and supports page recovery.

5. The method according to claim 4, further comprising: For each page launched while the background process supporting page recovery was in use, generate page information; When cleaning up the background processes, the page information of the current page of the background process is retained; In response to the background process being restarted, the page that was started before the background process was cleared is recreated and displayed using the retained page information.

6. The method according to claim 1, further comprising: The current memory status information is obtained from the memory status file, and the current memory pressure value is calculated based on the current status information. Obtain the memory usage of the background process from the memory status file; The cost of keeping the background process alive is determined based on the current memory pressure value and the memory usage of the background process.

7. The method according to claim 1, wherein the keep-alive priority of the background process is further determined based on activity level, the activity level representing the frequency of use of the background process within a target time period, the method further comprising: The activity level of the background process is determined based on a preset initial activity level and the time interval between the moment the background process is switched to the background and the current moment.

8. The method according to claim 7, wherein the method comprises: For each background process, determine the ratio between the cleanup cost and the keep-alive cost; The keep-alive priority of the background process is determined based on the sum of the ratio and the activity level.

9. The method according to claim 2, further comprising: In response to the background process having a keep-alive priority greater than the priority threshold and the detection that a service associated with the background process is not running, the keep-alive priority of the background process is adjusted to be less than the priority threshold.

10. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors perform the following method: determine at least one background process; determine a target process from the background processes based on the keep-alive priority of each background process, wherein the keep-alive priority of the background process is determined based on the clearing cost and the keep-alive cost of the background process; and clean up the target process; wherein the clearing cost represents the cost of restarting the background process after cleaning it up, and the keep-alive cost represents the memory pressure caused by keeping the background process in the background.

Images