Chapter 12 Keeping Process alive

(1) Android recycling strategy

Recycling memory in Android mainly relies on Lowmemorykiller to complete it. It is a mechanism that triggers memory recycling based on the OOM_ADJ threshold level.

For the sake of experience and performance, the system does not actually kill the process when the app returns to the background, but caches it. The more applications you open, the more background caching processes. In the case of insufficient system memory, the system begins to determine which processes to kill based on its own set of process recycling mechanisms to free up memory to supply the required apps. This mechanism of killing processes to reclaim memory is called Low Memory Killer, which is based on the OOM Killer (Out-Of-Memory killer) mechanism of the Linux kernel. oom_adj is a value assigned by the Linux kernel to each system process, representing the priority of the process. The process recycling mechanism is based on this priority to decide whether to recycle. For the role of oom_adj, you only need to remember the following points:
1. The larger the oom_adj of the process, the lower the priority of the process, and the easier it is to be recovered; the smaller, the higher the priority of the process, the less Easy to be killed and recovered
2. The oom_adj> = 0 of the ordinary app process, the oom_adj of the system process is possible <0

You can view the oom_adj of the process through the shell command

grep PackageName //获取你指定的进程信息

1.1) Process priority

The Android system will keep the application process as long as possible, but in order to create a new process or run a more important process, you will eventually need to clear the old process to reclaim memory. To determine which processes to keep or terminate, the system places each process in an "importance hierarchy" based on the components that are running in the process and the status of those components. When necessary, the system will first eliminate the process of least importance, then remove the process of lower importance, and so on, to recover system resources.

The foreground process has the highest importance, decreasing in sequence, and the empty process has the lowest importance. The following describes each level of process separately:

1. Foreground process-Foreground process

The process necessary for the user's current operation. There are usually few foreground processes at any given time. The system will only terminate them if the memory is not enough to support them while continuing to run.

2. Visible process-Visible process

There is no foreground component, but it still affects the process of what the user sees on the screen. Visible processes are regarded as extremely important processes, unless the system must be terminated in order to maintain all foreground processes running at the same time, otherwise the system will not terminate these processes.

3. Service process-Service process

Although the service process is not directly related to what the user sees, they usually perform some operations that the user cares about (for example, playing music in the background or downloading data from the network). Therefore, unless the memory is insufficient to keep all foreground processes and visible processes running at the same time, the system will keep the service process running.

4. Background process-Background process

Background processes have no direct impact on user experience, and the system may terminate them at any time to reclaim memory for use by foreground processes, visible processes, or service processes. There are usually many background processes running, so they will be saved in the LRU list to ensure that the last process containing the Activity recently viewed by the user is terminated. If an Activity correctly implements the lifecycle method and saves its current state, terminating its process will not have a significant impact on the user experience, because when the user navigates back to the Activity, the Activity will restore all its visible state.

5. Empty process-Empty process

The sole purpose of keeping such a process is to use it as a cache to reduce the startup time required to run the component in it next time. To keep overall system resources balanced between the process cache and the underlying kernel cache, the system often terminates these processes.

1.2） OOM_ADJ

The red part represents the Android process that is easier to be killed (OOM_ADJ> = 4), the green part represents the Android process that is not easy to be killed, and the other represents the non-Android process (pure Linux process). When Lowmemorykiller reclaims memory, it will preferentially kill the larger OOM_ADJ process according to the process level, and the processes with the same priority will be further affected by the memory occupied by the process and the process survival time.

1.3) The scene of the process being killed

(2) Process keep-alive plan

According to the previous article, it is nothing more than to find a way to increase the priority of the process and reduce the probability of the process being killed under insufficient memory.

2.1) Raise the process priority and reduce the probability of the process being killed

1. Use Activity to increase permissions

(1) Design idea
Monitor the unlocking event of the mobile phone lock screen, start a 1-pixel Activity when the screen is locked, and destroy the Activity when the user unlocks. Note that the Activity needs to be designed so that users are not aware of it.
Through this scheme, the priority of the process can be increased from 4 to the highest priority 1 during the screen lock time.
(2) Applicable scenarios
This solution mainly solves the problem that third-party applications and system management tools will kill background processes within a period of time (usually within 5 minutes) after detecting a lock screen event, which has achieved the purpose of saving power.
(3) Specific implementation
Step 1: First define the Activity and set the size of the Activity to 1 pixel

Step 2: From the AndroidManifest, the following attributes are used to exclude the display of the Activity in the RecentTask

Step 3: Control the Activity to be transparent

Step 4: The Activity starts and Control of timing of destruction

2. Use Notification to elevate permissions

(1) Design idea
The priority of Service in Android is 4, the background Service can be set to the foreground Service through the setForeground interface, so that the priority of the process is increased from 4 to 2, so that the priority of the process is only lower than the user is currently interacting with The process has the same priority as the visible process, which greatly reduces the probability of the process being killed.
(2) Implementation challenge
When calling setForeground from Android 2.3 to set the background service to the foreground service, a notification must be sent in the notification bar of the system, that is, the foreground service is bound to a visible notification.
For applications that do not require a resident notification bar, this solution is good, but it is user-aware and cannot be used directly.
Solution to the challenge of the solution: By implementing an internal Service, send a Notification with the same ID in both LiveService and its internal Service, and then end the internal Service. With the end of the internal Service, Notification will disappear, but the system priority remains at 2.
(3) Concrete realization

2.2) After the process is killed, pull live

1. Use the system to broadcast live

(1) Design idea
When a specific system event occurs, the system will send a response broadcast. By registering the corresponding broadcast listener "statically" in AndroidManifest, it can be activated when a response event occurs.
Commonly used broadcast events include:

(2) Scope
1. The broadcast receiver is disabled by the management software and system software through the "self-start management" function. The broadcast cannot be received and the self-start cannot be received.
2. The system broadcast event is uncontrollable, and it can only guarantee that the process is activated when the event occurs, but cannot guarantee that the process will be activated immediately after the process hangs up.
Therefore, the program is mainly used as a backup method.

2. Use third-party applications to broadcast live

(1) Design idea
The overall design idea of ​​this solution is similar to that of receiving system broadcasts. The difference is that this solution is for receiving third-party top application broadcasts. Access to a third-party SDK will also wake up the corresponding app process, such as WeChat SDK will wake up WeChat, Alipay SDK will wake up Alipay.
Through decompilation of third-party Top applications, such as mobile QQ, WeChat, Alipay, UC browser, etc., as well as SDKs such as Youmeng, Pigeon, and personal push, find out their outgoing broadcasts and monitor them in the application. When the application broadcasts, it will bring our application to life.
(2) Scope of application
1. Uncontrollable as the system broadcast
2. Limited by the degree of the third-party application analyzed by decompilation
3. The broadcast of the third-party application belongs to the application. It may be removed or changed to not outgoing.

3. Use the system Service mechanism to pull live

(1) Design idea
Set Service to START_STICKY, and use the system mechanism to automatically pull the service after the Service hangs up

(2) Scope of use: The following two situations cannot be activated
1. The Service will be killed within 5 seconds after being killed for the first time Restart within 2 seconds, the second killing will restart within 10 seconds, and the third time will restart within 20 seconds. Once the Service is killed 5 times in a short time, the system will no longer be pulled up.
2. The management tool or system tool whose process is rooted is stopped by forestop and cannot be restarted.

4. Use the Native process to pull live

The life cycle of all processes and system components in Android is managed by ActivityManagerService. Moreover, the process created by Linux's fork mechanism is a pure Linux process, and its life cycle is not managed by Android.
Use the fork mechanism in Linux to create a Native process, monitor the survival of the main process in the Native process, and when the main process hangs, immediately pull the main process in the Native process.

5. Use the JobScheduler mechanism to activate

After Android5.0, the system has strengthened the management of the Native process, and the Native pull method is invalid. The system provides the JobScheduler interface in Android5.0 and above, and the system will periodically call the process to make the application perform some logical operations.

6. Use the account synchronization mechanism to activate

The account synchronization mechanism of the Android system will periodically synchronize accounts, and the purpose of this solution is to use the synchronization mechanism to pull the process. The code for adding an account and setting the synchronization cycle is as follows:

This solution requires the account authorization and synchronization service to be defined in AndroidManifest.