[Android] process and threads (thread)

When one of the components of the application (four components: Activity,service,broadcastreceiver,contentprovider) starts and the application does not have other components running, that is, when the first component of the application is started, The Android system opens a new Linux process for this application, which contains a thread. By default, all components of an app run under the same thread in the same process, which is called the main thread. However, different components can be artificially arranged in different processes, while additional threads can be created for a process.

Process

By default, all components of an app run in the same process, and most applications do not require additional processes. But if you need to manually control the different components running in different processes, you can do this by editing the manifest file.

Manifest files in each class of components,, <activity> <service> <receiver> , and<provider>都支持android:process属性，这个属性指明这个组件运行在某一个特定的进程中。通过设置android:process，可以让每一个组件运行在自己的进程中，或者一些组件共享同一个进程而其他组件共享另一个进程。甚至可以让不同应用的组件运行在同一个进程中，当然需要这些应用有相同的Linux ID并且签名相同。

The Android system may terminate some processes when system memory is low and other applications require memory. The components that run in these processes are also destroyed at the same time. The process also restarts when these components are restarted.

The Android system decides which process to terminate based on the relationship between the process and the user. For example, in a process where the activities is not visible to the user, and the activity in the other process is visible to the user, the previous process is more likely to be terminated.

Process life cycle

The Android system will maintain the application process for as long as possible, but eventually the system needs to terminate the process to start a more important process. In order to decide which process to terminate, the system evaluates and ratings each process in an important way. The least significant process is terminated first, and then the second-lowest importance level.

The process is divided into 5 levels according to the degree of importance:

1. Foreground process

Processes that are interacting with the user, a process called a foreground process needs to meet these conditions:

The process has a activity,activity that is interacting with the user. (The activity's Onresume () method is called)

The process has a service,service bound to the foreground activity

The process has a foreground service,service called the Startforeground () function

The process has a service,service is executing the life cycle function

The process has a broadcastreceiver,broadcastreceiver executing the onreceive () function.

In general, only a few foreground processes exist at a time. They will be terminated only in very extreme cases.

2. Visible processes

A visible process refers to a process that is not a foreground process but still affects what the user observes. A visible process usually refers to a process such as the following.

The process has a activity,activity that is not the foreground activity but is still visible to the user (OnPause () is called but does not call OnStop ()). Usually refers to the situation where the foreground activity is covered by a dialog box

The process has a service,service bound to the visible activity.

Visible processes are considered important and are generally not terminated unless it is absolutely necessary to ensure that all foreground processes are running.

3. Service Process

The process has service,service called StartService (), but it does not belong to the foreground process and the visible process. Although the service process is not directly related to the user interface, they are also doing what users care about, such as playing background music, downloading the web, etc. So the system does not terminate them unless the system does not have enough memory to make the service process coexist with the foreground process, the visible process.

4. Background process

The process has activity, but activity is not visible to the user (the activity's OnStop () method is called). These processes have no direct impact on the user experience, and the system can terminate them at any time to provide sufficient memory for foreground processes, visible processes, and service processes. Often there are many background processes in the system, which are stored in an LRU (least recently used) table. If the activity correctly implements the life cycle approach, terminating the background process will have no effect on the user.

5. Empty process

Processes that do not own the components of any activity, the system process terminates those processes.

The Android system always ratings the process according to the highest level the process can reach. For example, the process has a service and a visible activity, which is evaluated as a visible process, not a service process.

The application process has a service that has a higher rating than the background activity, so for long operations, the service will have an advantage over the worker threads created in the activity.

Thread

When the app starts, the system creates an execution thread for the app, called the main thread. This thread is primarily responsible for distributing events to the appropriate user interface components and drawing the interface. The main thread is also the threads of the system operating UI control, so the main thread is also called the UI thread.

The system does not create a new thread for each component, and all components run in the main thread. System calls for each component are distributed in the main thread. So functions that respond to system calls (such as onkeydown () respond to user clicks back buttons) are always running in the UI thread.

A single thread behaves poorly when the app executes a high-intensity, time-consuming project. Specifically, if everything happens in the UI thread, long-time operations such as network connections, database queries will block the entire UI thread. From the user's point of view, the system seems to be stuck. Even worse, if the UI thread is blocked for a few seconds (currently about 5 seconds), the user will see the application not responding window. The user may be able to launch the app.

In addition, the Android UI control is not thread-safe, so UI controls cannot be manipulated in other threads. All UI actions must be in the UI thread. So the two simplest rules about Android threading are:

1. Do not block the UI thread

2. Do not manipulate UI controls outside of the UI thread (referring to other threads).

Worker threads

If you need to perform long-time behavior, these behaviors need to be performed in other threads, called background threads or worker threads.

For example, here's an example: Download a picture in a worker thread and display it in ImageView.

 Public void OnClick (View v) {    new Thread (new  Runnable () {        publicvoid  Run () {            = loadimagefromnetwork ("http://example.com/image.png");            Mimageview.setimagebitmap (b);        }    }). Start ();}

This code is actually problematic because it violates the second rule: do not manipulate UI controls outside of the UI thread (referring to other threads). The code modifies the state of the ImageView in the worker thread, which results in indeterminate behavior.

To solve this problem, Android provides some ways to manipulate the UI thread in work now, such as:

• Activity.runOnUiThread(Runnable)
• View.post(Runnable)
• View.postDelayed(Runnable, long)

For example, you can use View.post (Runnable) to fix the above code:

 Public voidOnClick (View v) {NewThread (NewRunnable () { Public voidrun () {FinalBitmap Bitmap =Loadimagefromnetwork ("Http://example.com/image.png"); Mimageview.post (NewRunnable () { Public voidrun () {mimageview.setimagebitmap (bitmap);        }            }); }}). Start ();}

Now the implementation is thread-safe, the network operation is done in the worker thread, and the ImageView is changed in the UI thread.

However, as the complexity of operations increases, such code becomes responsible and difficult to maintain. In order to handle more complex behavior in a worker thread, using handler in the UI thread to pass information to the UI thread can be a good behavior, and using Asynctask might be the best solution.

[Android] process and threads (thread)