"Original" Source angle analysis Android message mechanism series (i)--android message mechanism overview

ι Copyright Notice: This article for Bo Master original article, without Bo Master permission not reproduced.

1. Why Android message mechanism is required

Because Android does not allow access to the UI in child threads, the Android system does not allow the UI to be updated in child threads.

Why is it not allowed to update the UI in a child thread? Because Android controls are not thread-safe. Since it is non-thread-safe, UI control can be in an unpredictable state if it is accessed concurrently in multiple child threads. Some readers might say, why not lock the UI controls? Locking will reduce the efficiency of UI access, because after locking, if you want to run the code of the synchronized, the thread to get the permission to execute this code, Java inside also get a lock of a synchronization object, but an object has only one lock, If the lock of the synchronization object is taken away by another thread at this point, the thread can only wait in the waiting queue, and when the thread holding the object lock finishes executing, releasing the object lock does not necessarily wake the thread, and the thread waits for an unknown time. This will result in a very inefficient access to the UI.

The Android messaging mechanism was created to address the problem of accessing the UI in a child thread.

2. What is Android's messaging mechanism

The message mechanism of Android mainly refers to the operating mechanism of handler.

When it comes to handler, it is necessary to mention another three concepts, namely, message, MessageQueue, Looper. The relationship between the four is often a question that Android developers are often asked about in job interviews. Let's start with a brief explanation of the roles and relationships of the four, and we'll cover them in detail in the next blog post.

M Essage: A message that contains the necessary description and property data when a message is defined. Common properties: arg1 , arg2, what, obj, target , and so on, where arg1 and Span style= "font-size:14px" > ARG2 can hold integer data, what can be used to identify a message,obj can hold an object type of arbitrary objects, target is to process a message handler. In general, the message does not need to be new, and you can call handler's Obtainmessage () method to get a message.

< Span>messagequeue : Message Queuing, It internally maintains a set of messages that provide both insert and read operations in the form of queues. Although the name is Message Queuing, its interior is not a real queue, but rather a single-linked list of data structures to store the message lists.

< Span>looper: Loop, in which the message loop, Looper is not a simple loop, but can handle the message. Looper will be infinite loop to find out whether there is a new message, if any, then processing the message, otherwise, has been waiting. There is a special concept in looper, that is, threadlocal, which is not a thread, but is used to store data in each thread. The thread defaults to no looper, but when Activitythread (the main thread, the UI thread) is created, the Looper is initialized.

Handler: You can switch a task to a specified thread to execute, and you can generally update the UI with it. Handler is created using the current thread's looper to construct the message circulatory system, handler through Threadlocal can get to the current thread looper, and because Activitythread is created when the initialization of Looper, Therefore, the handler can be used by default in the main thread.

< Span>handler operation requires MessageQueue and Looper support, and when Hanler is created, its internal looper and MessageQueue can work together with handler. HANDLR can send a message in two ways: ① between different threads, can be sent by send, ② at some time in the future, you can use post, post method to send a runnable to handler internal Looper to deal with, In fact, the Post method is finally done by the Send method.

After the handler send method is called, MessageQueue's enqueuemessage will put this message in the message queue, Looper detects that a new message has arrived, and will process it. The Handlermessage method of the runnable or Handller in the final message is called and the message is processed. The Looper is running in the thread that created the handler, so that the business logic in handler is switched to the thread where the handler was created to execute. We can create handler in the main thread, and when we are working on a child thread and need to update the UI, we can send the message through handler and go back to the main thread to update the UI.

"Original" Source angle analysis Android message mechanism series (i)--android message mechanism overview