Android processes and threads (2) 5 processes classified by importance

The Android system will maintain a program process for as long as possible, but when the system resources are insufficient, after all, the system will kill some old processes for some new or more important processes to release the memory. The system determines the importance of each process based on the running status of components in the process, so as to determine which process needs to be killed and which process needs to be maintained. The least important process is most likely to be killed first, and the least important process will be killed first until the system recovers the required resources.
Since the system determines the survival of a process based on the importance of the process, we will introduce five different processes based on the Importance classification (the importance from high to low ).
1. foreground process, foreground process
The frontend process is the process required by the user to complete the current work. The judgment conditions are as follows (only one of them can be met ):
-An Activity in the process is interacting with the user (the onResume () method of the Activity is called)
-Bind to the process of the Service of the activity that is interacting with the current user
-A Service in the process is running on the frontend, that is, the startForeground () method of the service is called.
-A Service in the process is executing the lifecycle callback method (for example, onCreate (), onStart (), or onDeatroy ())
-The BroadcastReceiver in the process is executing the onReceive () method.
Generally, there are only a few front-end processes at a specific time. These front-end processes are of the highest importance. When the system memory is low so that they cannot continue running, the system will kill these processes. In this case, the system has reached a limit edge, so in order to make the UI continue to respond, the system has to kill some foreground processes.
2. visible process-visible process
A visible process is a process that does not run on the front-end, but still affects the content displayed on the screen. Processes that meet the following conditions can be regarded as visual processes:
-The Activity that the process runs is not in the foreground, but is still visible (the onPause () method is called ). This may be the case. A dialog box is started for the Activity that is running on the foreground. This dialog box is suspended on this activity, but is still partially visible.
-The Service in the process is bound to a visible (or foreground) activity (this activity has called the onPause () method ).
The visible process is also a very important process. It will only kill the visible process when the system has to kill the visible process to keep the foreground process running.
3. service process-service process
The so-called service process refers to the process of starting a service in addition to the preceding two processes. Although such service processes are irrelevant to what users see, the work they do is also of interest to users (such as playing music in the background or downloading resources on the Internet ), the system will keep the service process, unless the system has to kill the service process for the frontend process and visible process to run.
4. background process-background process
Background process indicates that the activity in the process is invisible to the user currently (this activity calls the onStop () method ). Background processes do not affect user experience, and the system can kill background processes when foreground processes, visual processes, and services inherit memory resources. There are usually many background processes running, and these background processes are stored in a recently used list. The advantage of doing so is to ensure that the process recently seen by the user is finally killed. If an activity has correctly implemented the lifecycle method and saved the current state, the system will not affect the visible effect of killing these background processes, because when the user returns, the activity has saved all the visible states.
5. empty process-empty process
A blank process does not have any program components. The only reason for the existence of the system to keep the process empty is for cache consideration. This is mainly to increase the startup time of the component. The system often kills these empty processes to maintain a balance between the entire system resources and the kernel cache.
Android divides processes based on the most important components running in processes. For example, if a process contains a visible activity and a service, this process should be a visible process rather than a service process.
In addition, the importance level of a process may be increased because it depends on other processes of the process-the importance of a process serving other processes is not lower than that of the process being served. For example, A content provider in process A is serving the customer in process B, or A service in process A is bound to A component in process B, the importance of process A is considered at least the same as that of process B.
Because the process of a running service is more important than the process of a background activity, if an activity needs to execute an operation that takes a long time to run, this activity is better to start a new service for this operation, rather than just creating a worker thread, especially when the worker thread runs for a longer time than the activity. For example, if an activity uploads an image to a website, the activity should start a service to complete the upload operation, the advantage is that the upload service will continue even if the user leaves the current activity. Use a service to ensure that a process has at least the priority of the service process, without worrying about what will happen to the activity. This is exactly why the broadcast receiver should use the service instead of putting time-consuming operations in a thread.

From android development of yaozq