The Android process is alive
The Android system will hold on to application processes as long as possible, but in order to create new processes or run more important ones, old processes need to be cleared to reclaim memory. To determine which processes to keep or kill, the system classifies them. When needed, the system will first eliminate the least important processes, then purge the less important processes, and so on, to reclaim system resources.
1. Let’s take a look at the picture below.
Here’s the official line:
There are five levels of importance hierarchy. The following list lists processes in order of importance (the first process is most important and will be the last to be terminated) :
1. Foreground processes
Processes that are necessary for the user’s current operation. A process is considered a foreground process if it meets any of the following criteria:
- Hosting the Activity the user is interacting with (the Activity’s onResume() method has been called)
- Hosts a Service that is bound to the Activity the user is interacting with
- Host Service running “foreground” (Service called startForeground())
- Hosting a Service (onCreate(), onStart(), or onDestroy()) that is performing a lifecycle callback
- Host the BroadcastReceiver that is executing its onReceive() method
Typically, there are not many foreground processes at any given time. The system terminates them only when it is absolutely necessary that there is not enough memory to support them while still running. At this point, the device is usually paging out of memory, so some foreground processes need to be terminated to ensure that the user interface responds properly.
Note: Personally understand the foreground process is the interface that the user is interacting with, that is, using.
2. Visible process
A process that does not have any foreground components but still affects what the user sees on the screen. A process is considered visible if it meets any of the following criteria:
- Hosts an Activity (whose onPause() method has been called) that is not in the foreground but is still visible to the user. For example, this might happen if the foreground Activity starts a dialog box that allows the previous Activity to be displayed after it.
- Hosts a Service bound to a visible (or foreground) Activity.
Visible processes are considered extremely important and will not be terminated unless necessary to keep all foreground processes running at the same time.
Note: Visible process is a process in the user can not see the situation, silently operating foreground interface data changes.
3. Service process
A process that is running a service started with the startService() method and does not belong to either of the higher categories of processes described above. Although server processes are not directly related to what the user sees, they are usually performing some action that the user cares about (for example, playing music in the background or downloading data from the network). Therefore, unless there is not enough memory to keep all foreground and visible processes running at the same time, the system will leave the server processes running.
Note: I understand that a server process is an asynchronous operation.
4. Background processes
The process that contains an Activity that is currently invisible to the user (the Activity’s onStop() method has been called). These processes have no direct impact on the user experience, and the system may terminate them at any time to reclaim memory for foreground, visible, or server processes. There are usually many background processes running, so they are saved in the LRU (Least Recently used) list to ensure that the process containing the Activity the user recently viewed is the last to terminate. If an Activity implements the lifecycle method correctly and saves its current state, terminating its process does not have a significant impact on the user experience, because the Activity resumes all its visible states when the user navigates back to the Activity. See the Activity documentation for information about saving and restoring state.
Note: personally understand the background process, which is not used for the moment, may be used later, may not be used later. Just like when we use an application, press the home button to exit, it becomes a background process. The next time you come in, you can still see the previous page.
An empty process
A process that does not contain any active application components. The sole purpose of keeping such processes is to be used as a cache to reduce the startup time needed to run components in it the next time. To balance overall system resources between the process cache and the underlying kernel cache, systems often kill these processes.
Note: In my personal understanding, empty process means that the app is no longer in use after the application press exit, but the system still saves the history information related to the app in a process. When the app is started for the next time, the startup time of the app is relatively fast (compared with the first time).
2,Low Memory Killer
For the sake of experience and performance, the system does not actually kill the process when the app goes back to the background, but cache it. The more applications open, the more processes are cached in the background. When the system is running out of Memory, the system starts to determine which processes to kill based on its own process reclaiming mechanism to free up Memory for the needed APP. This process reclaiming mechanism is called Low Memory Killer.
3,oom_adj
The priority of a process is reflected by its ADJ value, which is a value assigned to each system process by the Linux kernel and used by the process reclamation mechanism to decide whether to recycle. A smaller value of ADJ indicates a higher priority for a process.
You can run cat /proc/process id/oom_adj to view the adj value of the current process. (Requires [root] permission)
The larger the ad_n, the more memory it takes up, the more it will be killed first, so it becomes a matter of reducing the value of oOM_adj, and how to make our application use the least memory.
3, the right of the Activity
Monitor the mobile phone lock screen unlock event, start a transparent Activity with 1 pixel when the screen is locked, and destroy the Activity when the user unlocks the screen. Thus achieving the effect of improving the process priority.
Defect: An Activity is not clean enough. Also need to lock the screen after the right to lift
4. Service lifting rights
Foreground processes are of the highest priority type. It is described in the official guide:
Create a foreground service to increase the app’s process priority after the home button is pressed
StartForeground (ID,Notification) : Makes Service foreground Service. The foreground service needs to display a notification icon in the notification bar:
- API level < 18: Parameter 2 sets new Notification(), the icon is not displayed.
- API level >= 18: Starts an InnerService on service A with A higher priority. Both services are startForeground and bound to the same ID. Stop the InnerService, and the notification bar icon is removed.
5. Radio pull ()
In the occurrence of a specific system event, the system will issue a broadcast, through the static registration of the corresponding broadcast listener in the AndroidManifest, can be pulled in response to the event.
However, starting with Android 7.0, broadcasting has been restricted and will become more stringent in 8.0
6, “the whole family bucket” pull work
There are multiple apps installed on the user’s device, and simply enabling one of them will activate the other apps as well. For example, there are Q, QZone, interest tribes and so on in the mobile phone. Then, after opening any app, other apps will also be woken up.
7. The system Service mechanism is activated
If a Service is set to START_STICKY, the system will automatically activate the Service if the Service fails:
- As long as targetSdkVersion is not less than 5, the default is START_STICKY.
- But some ROM systems do not pull. After the Service is killed for the first time, it restarts quickly. The second time is slower than the first time, and the third time is slower than the previous time. Once the Service is killed for four or five times in a short period of time, the system will not restart.
8. Pull accounts synchronously
There will be an “account” feature in the phone’s system Settings that allows any third-party APP to sync data to the server for a certain amount of time. When the system synchronizes the APP account, the APP process that is not started will be pulled alive. Cons: It’s possible to set the synchronization interval to 5 seconds, but Android takes into account the cost of synchronization, so this time is just a guide, not really every 5 seconds. It means the synchronization time is uncertain.
9. The JobScheduler is based on scheduler
JobScheduler allows tasks to be executed periodically in certain states and at certain intervals. It can use this feature to complete the function of keeping alive, the effect is to open a timer, and ordinary timer is different from its scheduling by the system to complete.
Also on some ROMs it may not achieve the desired effect (a meter)
10. Push and pull
Based on different terminals, Xiaomi push can be connected to Xiaomi mobile phones (including MIUI), and Huawei push can be connected to Huawei mobile phones.
11, the Native living
The Native fork child process is used to observe the survival status of the current app main process. Very low success rate for over 5.0.
A high success rate of pulling
Double process pull
This method combines the scheduled wake-up pull of JobScheduler and dual-process Service, and sets Service as the foreground Service through Notification. High success rate, including version 9.0 also available. However, some mobile phones will still fail, such as Huawei and Xiaomi. There is no guarantee of 100%, but this method has a higher success rate than other methods.