The relationship between Handler, loopermessagequeue, and loopermessagequeue

The relationship between Handler, loopermessagequeue, and loopermessagequeue

Summarize the relationships between Handler and logoff, MessageQueue, and customize Handler related to sub-threads.

1. Relationship between Handler and logoff and MessageQueue

The relationships between them are described as follows:

(1) Logoff: equivalent to the message carrier

• There is a message queue in it, that is, MessageQueue. All messages sent by Handler will go to the message queue.

• Its logoff. loop method is an endless loop that constantly extracts messages from MessageQueue in the message queue. If a message exists, it is processed; otherwise, it is blocked.

(2) MessageQue: A Message Queue that can be used to add and process messages.

(3) Handler is actually the encapsulation of the sent message processing message. It is associated with the logoff, that is, the logoff can be found inside the Handler, and the corresponding message queue can be found after finding the logoff. Therefore, all messages sent by Handler go to MessageQueue.

Make a summary of the above three notes:

Handler is responsible for sending messages and receiving messages sent by logoff, and processing the messages according to the corresponding logic.
Logoff is responsible for receiving the message sent by Handler and returning the message to Handler.
While MessageQueue is just equivalent to a message container

After the above instructions, I should have a general understanding of the Handler Message Processing Mechanism in android. So you must still have doubts, why do you need to strictly process messages like this? This problem is actually why the UI cannot be updated in the Child thread. The following is the reason.

Why cannot I update the UI in a child thread?

We suppose we can update the UI in the subthread, so this will happen: One of the subthreads has not completed the update interface, and the other sub-threads have updated the UI, this will cause confusion on the sub-UI. Then you may say that we can implement the locking mechanism so that the code for updating the UI cannot be executed concurrently. If each sub-thread is locked, the performance of the program will undoubtedly be greatly reduced. Therefore, the main reasons are summarized as follows:

(1) In order to prevent UI disorder

(2) To prevent program performance degradation

Therefore, android does not allow updating the UI in child threads. To solve this problem, android has designed a message processing mechanism like this, so that we don't have to worry about multithreading even though we send messages to update the UI in the Child thread. Poll for update in the message queue of the main thread.

Ii. Customize Handler associated with the sub-Thread

After learning about Handler, logoff, and MessageQueue, we can implement a Custom Handler, which is associated with the sub-thread (note that the default Handler we created is associated with the main thread, that is, the UI thread is associated. Because logoff is not specified, Handler cannot be created if logoff does not exist ). Next we will simply implement this Custom Handler. To create a project, you only need to modify its MainActiivty Code as follows:

1 package com. example. handldertest; 2 3 import android. app. activity; 4 import android. OS. bundle; 5 import android. OS. handler; 6 import android. OS. logoff; 7 import android. util. log; 8 import android. widget. textView; 9 10 public class ThreadHandlerActivity extends Activity {11 12 13 // create a subthread 14 class MyThread extends Thread {15 private Handler handler; // Handler 16 public void run () {17 18 logoff associated with this subthread. prepare (); // create the Looper19 handler = new Handler () {// by default, it is associated with the current thread by 20 public void handleMessage (android. OS. message msg) {21 Log. d ("the current sub-Thread is ----->", Thread. currentThread () + ""); 22}; 23}; 24 25 logoff. loop (); // The message 26} 27} 28 29 private TextView TV; 30 private MyThread thread can be retrieved cyclically after this method is called; 31 32 private Handler mHandler = new Handler () {33 public void handleMessage (android. OS. message msg) {34 Log. d ("the current main Thread is ----->", Thread. currentThread () + ""); 35}; 36}; 37 38 protected void onCreate (Bundle savedInstanceState) {39 super. onCreate (savedInstanceState); 40 TV = new TextView (this); 41 TV. setText ("Handler experiment"); 42 setContentView (TV); 43 44 thread = new MyThread (); 45 thread. start (); // do not forget to enable this Thread 46 try {47 Thread. sleep (2000); // The Master thread sleeps for 2 seconds 48} catch (InterruptedException e) {49 e. printStackTrace (); 50} 51 // The following uses the Handler of the sub-thread to send the message 52 thread. handler. sendEmptyMessage (1); 53 // The following is the message 54 mHandler sent by the main thread. sendEmptyMessage (1); 55} 56 57}

In the MyThread class of the program, we first create our own logoff, and then use the Handler's no-parameter Constructor (the no-parameter constructor is associated with the current thread by default ). In the end, remember to call the logoff. loop method so that the message queue can be round-robin (that is, an endless loop ). Then, in the onCreate method, let the main thread sleep for 2 seconds (mainly to facilitate viewing results) and then let the handler of the sub-thread send messages. Of course, I have observed the difference, we also set up a Hander of the main thread, that is, mHandler, and let it send messages. The output is as follows:

 

By printing the results, we find that the ID of the printed thread is different. It fully indicates that handler is associated with the created sub-thread. To sum up.

The Handler associated with the sub-thread must be:

1. You must first create a logoff and call the logoff. prepare method.
2. instantiate Handler and associate it with it
3. Call the logoff. loop Method to continuously read messages cyclically.

The above three steps should be written in the run method.