The best way to learn Android is of course a powerful official document, which has a detailed introduction to process lifecycle elimination priority in the Processes and Threads section. I won’t repost it to everyone, just post the translation, as follows:
The Android system will try its best to maintain the existence of processes, but after all, resources are limited, and some processes will be eliminated when the system resources are in a hurry. The credentials for the order of elimination are the priority of the system process. The higher the priority, the less likely it is to be killed, and vice versa. The system has five priorities for the process in total, as follows
1. Foreground process (the process meets any of the following conditions, which is the foreground process):
1. Have an Activity that executes the onresume method that is interacting with the user (get focus)
2. Have a service, which is bound to the activity that is interacting with the user.
3. Have a Service, which calls the startForeground() method
4. Have a Service that is executing any one of the onCreate(), onStart() or onDestroy() methods
5. Have a BroadcastReceiver that is executing the onReceive method
2. Visible process:
1. Have an activity that executes the onPause method but is still visible
2. Have a Service, which is bound to a visible or front-end Activity
3. Service process:
Have a process that starts Service through the startService method
4. Background process:
A process with a background activity (onStop method is called)
V. Empty process:
There is no process with any active application components, that is, no Service and Activity are running
In addition, there are some things that need to be added. When a process meets multiple process conditions, of course, the priority is higher. For example, a process meets the conditions of both the foreground process and the service process. This process is a foreground process, which is easy to understand. In addition, the priority of the process is not static, and sometimes it changes with some related factors; for example, a certain process A meets the second condition of the foreground process, and process A has a service, which is bound to the activity that is interacting with the user; when this activity becomes visible, process A no longer meets the conditions of the foreground process, and then because the second condition of the visible process is met, process A becomes a visible process. In short, after mastering the basic concepts, you need to carefully analyze the specific situation in order to make a correct judgment.
Additional description of process priorities
1. The system will give the process the highest priority as possible. For example, if a process contains both a service that has been started and a foreground activity, then this process will be regarded as a foreground process.
2. Due to the dependence between components, the priority of the process may be increased. If process A serves process B, the priority of process A cannot be lower than process B. For example, the ContentProvider component of process A is serving a component of process B, or the service component of process A is bound to a component of process B, etc. In these cases, the priority of process A will not be lower than process B (if according to the priority rule, process A is indeed lower than process B, the system will choose to increase the priority of process A to the same as process B).
3. Since the priority of the service process is higher than that of the background process, if the activity needs to perform time-consuming operations, it is best to start a service to complete it. Of course, it is also possible to start a child thread in the activity to complete time-consuming operations. However, the disadvantage of this is that once the activity is no longer visible, the process where the activity is located becomes a background process, and the background process may be killed by the system at any time when the memory is insufficient (but starting the service to complete time-consuming operations will bring about data interaction problems. For example, if the time-consuming operation requires real-time update of the status of the UI control, service is not a good choice). Based on the same consideration, time-consuming operations should not be performed in BroadcastReceiver, but should be started to complete it (of course, the life cycle of BroadcastReceiver is too short, which also determines that time-consuming operations cannot be performed in it).