What is UI thread in Android

I think you shouldn't be too familiar with threads. A thread is an entity in this process. Its life cycle: 1. Rebuilt 2. Ready 3. Running 4. Blocking 5. Death.

When the Android UI program we wrote runs, the system creates a thread called "main". We can watch it in debug mode:

This main thread is also the main thread, which is also known as the UI thread in the Android system.

It is responsible for distributing events to components, including drawing events. For example, when you touch a button on the screen, the UI thread sends a touch event to the component.

The component then goes into the "Pressed" state and sends a request to the event queue. The UI thread queue receives the request and notifies the component to draw itself.

It is not UI safe, meaning it will not accept change requests from non-UI threads. If we change it through other threads (not main thread or non-primitive thread),

This exception is thrown: android.view.ViewRoot $ CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.

CalledFromWrongThreadException is taken literally. This means that the request is from the wrong thread.

Only the original thread that created a view hierarchy can touch its views. Only the original thread that created a view hierarchy can touch its views.

In other words, the related views and controls in Android are not thread safe. We can use the following methods:

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

Among them, runOnUiThread is the simplest and most useless in my opinion. Just give it a runnable and it will run on UIThread without any problems. But because of this ease, our problems also arose.

Since it runs on the UI thread that is presented to the user and runs for the user, the thread goes into a blocked state when we use it to perform some operations. If the blocked state exceeds 5 seconds, the system will do so

We will remind you that this gives users a very bad experience as shown below:

At this point we need to use the other methods introduced above to deal with this. Here is the next most common handler used.

Using the handler:

1 Have messages and executable files run later.

2 Activate the action to prepare for execution in another thread. Communication between threads can realize this.

For example, if you create a child thread, you can get the handler object created in the parent thread in your child thread and then use that object to send messages to the parent thread's message queue.

Since Android requires that the interface be updated in the UI thread, this method can be used to update the interface in other threads.

You can find the full code below. You can skip debugging the breakpoint behind me.

Package com.hm; import android.app.Activity; code> import android.os.Bundle; android.os.Handler import; import android.os.Message; import android.widget.ProgressBar; import android.widget.TextView; public class AutoActivity extends activity {private ProgressBar bar; private TextView textView; private MyHandler myHandler; @Override protected void onCreate (Bundle savedInstanceState) {super.onCreate (savedInstanceState); setContentView (R.layout.loading); myHandler = new MyHandler (); // Create a new handle that belongs to the UI thread bar = (ProgressBar) findViewById (R.id.progressBar); textView = (TextView) findViewById (R.id.textView); new thread (new MyThread ()). begin (); // New A child thread and the execution} class MyThread implements Runnable {@Override public void run () {while (bar.getProgress () The status changes for this thread at this point are: 1. Newly created 2. Ready 3. Running.

Then we find the handler object myHandler that was created on the parent thread in the child thread, and then we send a message to it. In this message we can pass all the data we want to pass.

I have nothing to share here so I just made a new one. Then myHandler receives this message and enters the handleMessage method. In the method I add 10 to the progress of the ProgressBar every time.

When you view it in Text View, you can clearly see the changes in Text View, which indicates that the UI thread is not in a blocked state and the UI is not suspended. Eventually ProgressBar's progress reached 100%,

This is the instruction System.out.println ("used for breakPoint"). If the statement is not executed, the newly created thread will still exist. When the statement ends, that is, after the thread's execution method has ended,

The task of this thread is also done, at this point it is about to enter the fifth state death. But it doesn't die instantly, it is recycled as small garbage by the system. When the system finishes performing the related memory releases,

This thread ends automatically and we can see in Debug that the virtual machine can no longer find this process

So far the thread has died.

I've explained the use of Handle throughout the thread's lifecycle. If you think what I said is wrong or have any questions, please leave me a message. Thanks for your advice.