Priority of the process lifecycle in Android

  • 2020-12-26 05:52:50
  • OfStack

The best way to learn Android is, of course, the powerful official documentation, which is detailed in section Processes and Threads1 on process lifecycle obsolescence priorities. I won't give you a repost, just put the translation, as follows:

The Android system tries to maintain the existence of processes, but resources are limited, and one part of the process is eliminated when the system is in an emergency. The proof of the elimination order is the priority of the system process, and the higher the priority, the less likely it is to be killed, and vice versa. In total, the system has five priorities for processes, as follows

1. Front-end process (a process that meets any of the following 1 conditions is a front-end process) :

1. Have an Activity that executes the onresume method and is interacting with the user (getting focus)
2. Have 1 service, which is bound to the Activity that is interacting with the user
3. Have 1 Service, which calls the startForeground() method
4. Have 1 Service executing any one of the onCreate(), onStart(), or onDestroy() methods
5. Have 1 BroadcastReceiver executing the onReceive method

2. Visible process:

1. Have one Activity that performs the onPause method but is still visible
2. Have 1 Service, which is tied to 1 visible or foreground Activity

3. Service process:

You have a process for Service that started with the startService method

4. Background process:

A process that has a background Activity (the onStop method is called)

5. Empty process:

Processes that do not have any active application components, i.e., no Service or Activity running

In addition, there are a few things to be added. When a process satisfies multiple process conditions, of course, the priority is higher. For example, if a process satisfies both the conditions of the foreground process and the service process, the process is a foreground process, which is easy to understand. In addition, the priority of the process is not 10% constant, and sometimes changes with some related factors; For example, process A satisfies the second condition of the foreground process. Process A has one service, which is bound to the Activity that is interacting with the user. When this Activity becomes visible, process A no longer satisfies the foreground process condition, and process A becomes visible because it satisfies the second condition of the visible process. In a word, after mastering the basic concepts, one needs to carefully analyze the specific situation before coming to a correct judgment.

Additional instructions on process priority

1. The system will give the process the highest priority possible. For example, if a process contains both the started service and the foreground activity, the process will be regarded as the foreground process.

2. It is possible to increase the priority of the process due to dependencies between components. If process A serves process B, then process A cannot have a lower priority than process B. For example, the process of A ContentProvider B component is the service of the process of a component, or process A service components and processes B bundle, such as a component of these cases, the process of A priority process will not lower than B (if according to the priority rules, process A B priority is below process, then the system will choose the priority to improve process A and processes the same B).

3. Since the priority of the service process is higher than that of the background process, if activity needs to perform time-consuming operations, it is better to start 1 service to complete. , of course, the promoter in activity thread to complete the lengthy operations can also, but doing so the downside is that 1 denier activity no longer visible, activity process become a background process, and insufficient memory background process is likely to be killed by the system at any time, but start service complete time-consuming operation data interaction problems, such as time-consuming operation need real-time update UI control state, service, it is not a good choice). Based on the same considerations, you should not perform time-consuming operations in BroadcastReceiver, but instead start service to do so (of course, BroadcastReceiver has too short a life cycle to perform time-consuming operations in it).


Related articles: