Android Process Priority

Processes in Android

By default, all component in the same application run under the same Linux process. When starting a component A, if component B already exists in the running state and A and B belong to the same application, then component A will run under the process where component B is located. Otherwise a new Linux process will be created for a.

Developers can also specify different running processes for component in application. <activity> in manifest.xml file;, <service>, <receiver>, <provider> tags support android:process properties, With this property, you can specify the running process for component. The <application> tag also supports setting the Android:process property to specify the default run process for all component under application.

Process priority

When the system is running low on memory, the Android system will kill some less important processes based on the process priority selection. The process priority is from high to low, respectively:

1. Foreground process. The following process is the foreground process:

A. The process contains activity that is in the foreground interacting with the user;

B. The process contains the service bound to the foreground activity;

C. The process contains a service that invokes the Startforeground () method;

D. The process contains a service that is executing the oncreate (), OnStart (), or OnDestroy () method;

E. The process contains a broadcastreceiver that is executing the onreceive () method.

The number of foreground processes in the system is small, and the foreground process is almost never killed. Killing a foreground process is only selected if the memory is low to ensure that all foreground processes are running concurrently.

2. Visual process. The following processes are visual processes:

A. The process contains activity that is not in the foreground but is still visible (the OnPause () method of the activity is called, but the OnStop () method is not called). Typically, a dialog box pops up while the activity is running, but it is still visible when the activity is not the foreground activity.

B. The process contains the service that is bound to the visible activity.

The visual process will not be killed by the system unless it is necessary to ensure that the foreground process is running.

3. Service process. The process contains the service that was started.

4. Background process. The process contains invisible activity (activity after the OnStop () method call). Background processes do not directly affect the user experience, and in order to keep the foreground process/visual process/service process running, it is possible for the system to kill a background process at any time. A correct implementation of the life cycle method of activity in the background is killed by the system, you can restart it when the user to restore the previous running state.

5. Empty process. A process that does not contain any active processes is an empty one. The system often kills empty processes, which does not cause any impact. The only reason an empty process exists is to cache some boot data so that it can start faster next time.

Additional Instructions for process prioritization

1. The system gives the process the highest possible priority. For example, if a process contains both the service that is started and the foreground activity, the process is considered a foreground process.

2. Due to the dependencies 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 a service component of process A and a component binding of process B, in which case the priority of process A is no lower than that of process B (if you follow the precedence rules, The priority of process A is indeed lower than process B, then the system chooses to increase the priority of process A to the same as process B.

3. Because the service process has a higher priority than the background process, it is a good idea to start a service if the activity needs to take a time-consuming action. Of course, it is also possible to start a child thread in the activity for a time-consuming operation, but the disadvantage of doing so is that once the activity is no longer visible, the activity's process becomes a background process, and the background process is likely to be killed by the system at any time when the memory is low ( However, the time-consuming operation of starting a service can lead to problems with data interaction, such as a time-consuming operation that needs to update the state of the UI control in a timely way, and the service is not a good choice. Based on the same considerations, the time-consuming operation should not be performed in Broadcastreceiver, but the service should be started (of course, the Broadcastreceiver life cycle is too short and the time-consuming operation cannot be performed).

Threads in Android

The system does not start a new thread for each component in the process, and all components in the process are instantiated in the UI thread. For the multithreading mechanism in Android, please refer to my other blog post http://www.2cto.com/kf/201205/132323.html

Always remember:

1. Do not block the UI thread. Blocking or time-consuming operations in the UI thread can cause the UI thread to fail to respond to user requests.

2. You cannot update the UI in a non-UI thread (also known as a worker thread) because Android UI controls are thread insecure.

As mentioned above, developers often start working threads to complete time-consuming or blocking operations, and if they need to update the UI state during the execution of a worker, the UI thread should be notified.

Inter-thread communication

Take a look at the following code:

Java code
public void OnClick (View v) {
New Thread (New Runnable () {
public void Run () {
Bitmap B = loadimagefromnetwork ("Http://up.2cto.com/2012/0519/20120519094618735.png");
Mimageview.setimagebitmap (b);
}
}). Start ();
}
The above code is wrong and Mimageview.setimagebitmap (b) violates the second guideline-the UI cannot be updated in the worker thread.

Inter-thread communication solves the problem of how a worker thread notifies the UI thread to update the control. Android offers 3 ways to communicate between threads:

1. Call the following methods:

Activity.runonuithread (Runnable)

View.post (Runnable)

View.postdelayed (Runnable, long)

If you call these 3 methods in a worker thread, the actions encapsulated by the runnable parameter in the method are executed in the UI thread.

Use this method to correct the error in the example:

Java code
public void OnClick (View v) {
New Thread (New Runnable () {
public void Run () {
Final Bitmap Bitmap = loadimagefromnetwork ("Http://up.2cto.com/2012/0519/20120519094618735.png");
Mimageview.post (New Runnable () {
The Run method executes in the UI thread
public void Run () {
Mimageview.setimagebitmap (bitmap);
}
});
}
}). Start ();
}
2. Handler mechanism. The handler mechanism allows the developer to invoke the SendMessage () method of the handler object bound to the UI thread in a worker thread to send a message to the UI thread's message queue, and the UI thread will take the message out of the message queue and finish processing when appropriate.

3. Use the Asynctask class. Create a subclass of the Asynctask class and optionally overwrite OnPreExecute (), Doinbackground (), Onprogressupdate (), OnPostExecute () method as needed. Refer to the documentation for the specific use of the Asynctask class, here are some general explanations:

A. The Asynctask class is a generic class that has 3 generic parameters. The first parameter specifies the parameter type of the Execute method, the second parameter specifies the parameter type of the Onprogressupdate () method, the third parameter specifies the return value type of the Doinbackground () method, and the parameter type of the OnPostExecute () method .

B. Execution process: Call the Execute method of the Asynctask class in the UI thread (only the step is controlled by the programmer)-The system calls OnPreExecute (), which is done in the UI thread-- The system calls the Doinbackground () method, which executes in the worker thread, and every time the Publishprogress () method is called in the Doinbackground () method, Once the Onprogressupdate () method is executed in the UI thread once the-->doinbackground () method executes, the system calls the OnPostExecute () method and Doinbackground ()  The return value of the method is passed to the formal parameter of the OnPostExecute () method. The OnPostExecute () method executes in the UI thread.

In this way, you can also correct the errors in the example:

Java code
public void OnClick (View v) {
New Downloadimagetask (). Execute ("Http://up.2cto.com/2012/0519/20120519094618735.png");
}
Private class Downloadimagetask extends Asynctask<string, Void, bitmap> {
Protected Bitmap doinbackground (String ... urls) {
Return Loadimagefromnetwork (Urls[0]);
}

protected void OnPostExecute (Bitmap result) {
Mimageview.setimagebitmap (result);
}
}

Android Process Priority