Android thread handler Learning

The android UI is single-threaded. To avoid dragging the GUI, some time-consuming objects should be handed over to independent threads for execution. If the background thread executes the UI object, Android sends an error message calledfromwrongthreadexception.

 

Message Queue

 

In the single-thread model, Android designs a message queue to solve similar problems. The message queue can be used between threads to exchange information with handler and logoff components. They are described as follows:

 

1. MessageMessage message, which is understood as information exchanged between threads. When the background thread for data processing needs to update the UI, the message contains some data to the UI thread. 2. HandlerHandler is the main handler of the message, responsible for sending the message and executing the message content. The background thread uses the passed handler object reference to sendmes sage (Message ). When handler is used, the handlemessage (Message) method of implement class is required. It is the operation content for processing these messages, such as update UI. It is usually necessary to subclass handler to implement the handlemessage method. 3. Message QueueMessage Queue is a message queue used to store messages published by handler and run first-in-first-out. Each message queue has a corresponding handler. Handler sends a message to the message queue in two ways: sendmessage or post. Both messages are inserted at the end of the message queue and executed first-in-first-out. However, messages sent using the two methods are executed in a slightly different way: a message object is sent using sendmessage, which will be processed by the handlemessage () function of handler; the post method sends a runnable object, which is executed by itself. 4. LogoffLogoff is the manager of the message queue in each line. Android does not have a global message queue, while Android automatically creates a message queue for the main thread (ui thread), but no message queue is created in the Child thread. Therefore, the logoff value of the main thread obtained by calling logoff. getmainlogoff () is not null, but the logoff value of the current thread may be null by calling logoff. mylogoff.

 

The API Doc provides the correct method for using logoff for sub-threads:

Class looperthread extends thread {public handler mhandler; Public void run () {loid. prepare (); // create the Logoff of this thread and create a messagequeue mhandler = new handler () {public void handlemessage (Message MSG) {// process incoming messages here }}; logoff. loop (); // start logoff and listen to message queue }}

The general process of this message mechanism:

1. After the logoff. Loop () method starts running, the non-null message in the message queue is retrieved cyclically in the receiving order.

2. At the beginning, all messages in the message queue are null. When handler. sendmessage (Message) is sent to message queue, this function sets the target attribute of the message object to the current handler object. Then logoff retrieves the message, and calls the dispatchmessage function of the hander to which the target of the message points to process the message.

In the dispatchmessage method, the user determines how to process the message. The priority ranges from high to low:

1) callback in the message, an object that implements the runnable interface, where the run function is used for processing;

2) The mcallback in handler points to an object that implements the callback interface, which is processed by the handlemessage;

3) the classes corresponding to the handler object for processing messages inherit and implement the handlemessage function. The handlemessage function is used to process messages.

We can see that the handlemessage method we implemented has the lowest priority!

3. After handler processes the message (update UI), logoff sets the message to NULL for recycling!