Details about non-UI threads in Android that cannot operate UI threads

 

In Android development, non-UI threads cannot operate controls in the UI thread, that is, the UI is non-thread-safe.

As I said in the previous article:

It is non-UI secure, that is, it does not accept modification requests from non-UI threads. When we modify it through another thread (non-main thread or non-original thread,

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

CalledFromWrongThreadException is literally understood, that is, the request comes from the wrong thread.

Only the original thread that created a view hierarchy can touch its views can be accessed Only by the thread that originally created the view hierarchy.

Some friends may not quite understand this explanation. Today I wrote another example. Let's take a look.

To facilitate the test, I only have one TextView in the layout, And I modify the value displayed above it through a non-UI thread.

Print?

@ Override

Public void onCreate (Bundle savedInstanceState ){

Super. onCreate (savedInstanceState );

SetContentView (R. layout. main );

 

New Thread (new MyThread (). start ();

}

 

Class MyThread implements Runnable {

 

@ Override

Public void run (){

TextView txtMsg = (TextView) findViewById(R.id.txt Msg );

TxtMsg. setText ("Modify ");

}

 

}

Many friends may modify the value above TextView normally, so they are skeptical and puzzled about this non-UI thread to modify the UI thread, because it is clear that we have successfully modified it through a non-UI thread.

This involves a multi-threaded relationship. We know that a process has two or more threads and we can call it multi-threaded. Multiple Threads can work simultaneously. Let me give an example,

 

I went to the canteen for dinner, and the master did his best to cook in the window. There were two threads. Then I ordered a TextView containing Modify. Finally, I got the TextView and returned to the seat to eat it.

In this example, everything is normal, so nothing is abnormal. Then I went to the canteen the next day. I don't know if it was because I went early or the master was a little slow.

I went to the dining room for dinner. I was shocked when my master was cooking at XXX. Then he sent the fried TextView to the end. I threw out a nausea and nausea exception and escaped and never again went to the dining room.

 

In these two examples, I reported an error, but it was actually because when I arrived at the canteen, whether the master had prepared the food, as shown in the above example, the UI thread and MyThead thread are executed almost simultaneously,

However, the latter's work volume is too small, and the text above TextView is changed. Here, the UI thread shows the UI, and everything is normal. But what if we want MyThead to sleep for a few seconds before running?

Or is it possible to get a button and click the button before MyThead starts? In this way, after the UI thread is loaded, it is modified through a non-UI thread and an error is reported!

This is multi-threaded programming. Sometimes you run it several times and the result is correct, it does not indicate that your logic is correct. We must follow the code specifications to maintain a clear thinking.

 

From column A_Mean

 

Didn't you see any of those workshops? Non-staff members are not allowed to enter the room !!!