Android message mechanism Handler, it is necessary to talk about it again

In our daily development, we will inevitably use Handler. Although the Handler mechanism is not equivalent to the Android message mechanism, the Handler message mechanism has long been familiar to Android developers and is very important!

[[271774]]

Through this article, you can easily get the answers to the following questions:

1. What are the principles of Handler, Looper, Message and MessageQueue and the relationship between them?
2. What is the MessageQueue storage structure?
3. Why must the child thread call Looper.prepare() and Looper.loop()?

Simple use of Handler

I believe that everyone should know how to use Handler, right? Suppose you are processing a time-consuming task in an Activity and need to update the UI. Let's take a look at how we usually handle it.

 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContentView(R.layout.activity_main3)
 // Request network
 subThread.start()
 }
 override fun onDestroy() {
 subThread.interrupt()
 super.onDestroy()
 }
 private val handler by lazy(LazyThreadSafetyMode.NONE) { MyHandler() }
 private val subThread by lazy(LazyThreadSafetyMode.NONE) { SubThread(handler) }
 private class MyHandler : Handler() {
 override fun handleMessage(msg: Message) {
 super.handleMessage(msg)
 // Main thread processing logic, generally a weak reference is needed here to hold the Activity instance to avoid memory leaks
 }
 }
 private class SubThread(val handler: Handler) : Thread() {
 override fun run() {
 super.run()
 // Time-consuming operations such as making network requests
 // After the network request is completed, we have to notify the UI to refresh. We will directly consider the Handler processing and ignore other solutions for the time being.
 // The first method, generally this data is the content of the request result analysis
 handler.obtainMessage(1,data).sendToTarget()
 // Second method
 val message = Message.obtain() // Try to use Message.obtain() to initialize
 message.what = 1
 message.obj = data // Generally, this data is the content of the request result analysis
 handler.sendMessage(message)
 // The third method
 handler.post(object : Thread() {
 override fun run() {
 super.run()
 // Handle update operations
 }
 })
 }
 }

The above code is very simple. Because network request is a time-consuming task, we open a new thread and notify the main thread to update the UI through Handler after the network request is parsed. We simply use three methods. Careful friends may find that the first and second methods are the same. That is, Handler is used to send a Message object with content. It is worth mentioning that we should use Message.obtain() instead of new Message() to initialize Message as much as possible, mainly because Message.obtain() can reduce memory application.

In response to the suggestions made in the previous article, we will try to post as little source code as possible. You can easily find that all the above methods will eventually call this method:

 public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
 MessageQueue queue = mQueue;
 if (queue == null ) {
 RuntimeException e = new RuntimeException(
 this + " sendMessageAtTime() called with no mQueue" );
 Log.w( "Looper" , e.getMessage(), e);
 return   false ;
 }
 return enqueueMessage(queue, msg, uptimeMillis);
 }
 private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
 msg.target = this;
 if (mAsynchronous) {
 msg.setAsynchronous( true );
 }
 return queue.enqueueMessage(msg, uptimeMillis);
 }

In the above code, a MessageQueue appears, and finally the MessageQueue#enqueueMessage method is called to enqueue the message. We have to briefly talk about the basic situation of MessageQueue.

MessageQueue

As the name implies, MessageQueue is a message queue, that is, a container for storing multiple messages. It uses a one-way linked list data structure instead of a queue. Its next() points to the next Message element in the linked list.

 boolean enqueueMessage(Message msg, long when ) {
 // ... some checking code omitted
 synchronized (this) {
 // ... some checking code omitted
 msg.markInUse();
 msg.when = when ;
 Message p = mMessages;
 boolean needWake;
 if (p == null || when == 0 || when < p. when ) {
 // New head, wake up the event queue if blocked.
 msg.next = p;
 mMessages = msg;
 needWake = mBlocked;
 } else {
 // Inserted within the middle of the queue. Usually we don't have to wake
 // up the event queue unless there is a barrier at the head of the queue
 // and the message is the earliest asynchronous message in the queue.
 needWake = mBlocked && p.target == null && msg.isAsynchronous();
 Message prev;
 for (;;) {
 prev = p;
 p = p.next ;
 if (p == null || when < p. when ) {
 break;
 }
 if (needWake && p.isAsynchronous()) {
 needWake = false ;
 }
 }
 msg. next = p; // invariant: p == prev. next  
 prev.next = msg;
 }
 // We can assume mPtr != 0 because mQuitting is   false .
 if (needWake) {
 nativeWake(mPtr);
 }
 }
 return   true ;
 }

From the implementation of enqueueMessage(), its main operation is actually the insertion operation of the singly linked list. I will not explain it too much here. We should probably pay more attention to its dequeue operation method next():

 Message next () {
 // ...
 int nextPollTimeoutMillis = 0;
 for (;;) {
 // ...
 nativePollOnce(ptr, nextPollTimeoutMillis);
 synchronized (this) {
 // Try to retrieve the next message. Return if found.
 final long now = SystemClock.uptimeMillis();
 Message prevMsg = null ;
 Message msg = mMessages;
 if (msg != null && msg.target == null ) {
 // Stalled by a barrier. Find the next asynchronous message in the queue.
 do {
 prevMsg = msg;
 msg = msg.next ;
 } while (msg != null && !msg.isAsynchronous());
 }
 if (msg != null ) {
 if (now < msg.when ) {
 // Next message is   not ready. Set a timeout to wake up when it is ready.
 nextPollTimeoutMillis = ( int ) Math. min (msg. when - now, Integer .MAX_VALUE);
 } else {
 // Got a message.
 mBlocked = false ;
 if (prevMsg != null ) {
 prevMsg.next = msg.next ;
 } else {
 mMessages = msg.next ;
 }
 msg.next = null ;
 if (DEBUG) Log.v(TAG, "Returning message: " + msg);
 msg.markInUse();
 return msg;
 }
 } else {
 // No more messages.
 nextPollTimeoutMillis = -1;
 }
 //...
 }
 //...
 // While calling an idle handler, a new message could have been delivered
 // so go back and look again for a pending message without waiting.
 nextPollTimeoutMillis = 0;
 }
 }

The next() method is actually very long, but we only posted a small part of it. You can see that it is just an infinite loop of for (;;), and a nativePollOnce(long, int) method is called inside the loop body. This is a Native method, which actually blocks the current call stack thread for nextPollTimeoutMillis milliseconds through the Native layer's MessageQueue.

The following is the blocking behavior of different nextPollTimeoutMillis values:

• Less than 0, blocked until awakened;
• Equal to 0, no blocking;
• If it is greater than 0, the longest blocking time is nextPollTimeoutMillis milliseconds. If it is awakened during this period, it will return immediately.

As you can see, the initial value of nextPollTimeoutMillis is 0, so it will not block and will directly fetch the Message object. If the Message object data is not fetched, nextPollTimeoutMillis will be set to -1 directly. At this time, if the condition of less than 0 is met, it will be blocked until another Native method nativeWake(long) is called elsewhere to wake up. If a value is fetched, the obtained Message object will be directly returned.

It turns out that the nativeWake(long) method has a call to the previous MessageQueue#enqueueMessage method, and the call is made during the process of enqueuing a message in the MessageQueue.

Now we know that Handler sends Message, MessageQueue stores it, MessageQueue#enqueueMessage is used to enqueue it, and MessageQueue#next is used to poll messages. This inevitably raises a question: who calls the MessageQueue#next method? Yes, it is Looper.

Looper

Looper plays the role of a message loop in the Android message mechanism. Specifically, it will constantly check whether there are new messages from the MessageQueue through next(). If there are new messages, they will be processed immediately, otherwise the MessageQueue will be blocked there.

Let's take a look at the most important method of Looper: loop():

 public   static void loop() {
 final Looper me = myLooper();
 if (me == null ) {
 throw new RuntimeException( "No Looper; Looper.prepare() wasn't called on this thread." );
 }
 // ...
 for (;;) {
 Message msg = queue. next (); // might block
 if (msg == null ) {
 // No message indicates that the message queue is quitting.
 return ;
 }
 //...
 try {
 // Distribute messages to handler for processing
 msg.target.dispatchMessage(msg);
 dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
 finally
 // ...
 }
 // ...
 }
 }

The method omits a lot of code and only retains the core logic. As you can see, the Looper object is first obtained through the myLooper() method. If the Looper returns empty, an exception is thrown directly. Otherwise, it enters a for (;;) loop and calls the MessageQueue#next() method to obtain the Message object in turn. If the obtained Message object is empty, it exits the loop() method directly. Otherwise, the Handler object is obtained directly through msg.target and the Handler#dispatchMessage() method is called.

Let's first look at the Handler#dispatchMessage() method implementation:

 public void dispatchMessage(Message msg) {
 if (msg.callback != null ) {
 handleCallback(msg);
 } else {
 if (mCallback != null ) {
 if (mCallback.handleMessage(msg)) {
 return ;
 }
 }
 handleMessage(msg);
 }
 }
 private static void handleCallback(Message message) {
 message.callback.run();
 }

The code is relatively simple. If the Message has a callback set, it directly calls message.callback.run(). Otherwise, it checks whether the message has been initialized.

Let's take a look at the myLooper() method:

 public   static @Nullable Looper myLooper() {
 return sThreadLocal.get();
 }

Let's take a look at what sThreadLocal is:

 static final ThreadLocal sThreadLocal = new ThreadLocal();

What is this ThreadLocal?

ThreadLocal

Regarding ThreadLocal, we directly adopt the content in Yan Zhenjie's article.

The first impression of seeing ThreadLocal is that this class is related to threads, which is indeed the case, but it should be noted that it is not a thread, otherwise it should be called LocalThread.

ThreadLocal is used to store data of a specified thread. When the scope of some data is the specified thread and the data needs to run through all execution processes of the thread, ThreadnLocal can be used to store data. When a thread uses ThreadnLocal to store data, only the thread can read the stored data, and other threads except this thread cannot read the data.

Some readers may still not understand the role of ThreadLocal after reading the above paragraph. Let's take an example:

 ThreadLocal<Boolean> local = new ThreadLocal<>();
 // Set the initial value to true .
 local . set ( true );
 Boolean bool = local .get();
 Logger.i( "The value read by MainThread is: " + bool);
 new Thread() {
 @Override
 public void run() {
 Boolean bool = local .get();
 Logger.i( "The value read by SubThread is: " + bool);
 // Set the value to false .
 local . set ( false );
 }
 }.start():
 // The main thread sleeps for 1 second to ensure that the upper sub-thread is executed before executing the following code.
 Thread.sleep(1000);
 Boolean newBool ​​= local .get();
 Logger.i( "The new value read by MainThread is: " + newBool);

There is nothing much to say about the code. You will see the following printed log:

• The value read by MainThread is: trueThe value read by SubThread is: nullThe value read by MainThread is: true

The first log is unquestionable because the value is set to true, and there is nothing to say about the printed result. For the second log, according to the above introduction, the data stored in a thread using ThreadLocal can only be read by the thread, so the result of the second log is: null. Then the value of ThreadLocal is set to false in the child thread, and then the third log will be printed. The principle is the same as above. The value of ThreadLocal set in the child thread does not affect the data of the main thread, so the print is true.

The experimental results confirm that even for the same ThreadLocal object, the operations of the set() and get() methods of any thread are independent of each other and do not affect each other.

Looper.myLooper()

Let's go back to Looper.myLooper():

 static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

Let's see where sThreadLocal is operated.

 public   static void prepare () {
 prepare ( true );
 }
 private static void prepare (boolean quitAllowed) {
 if (sThreadLocal.get() != null ) {
 throw new RuntimeException( "Only one Looper may be created per thread" );
 }
 sThreadLocal.set ( new Looper(quitAllowed));
 }

So you know, this is why you must call Looper.prepare() before using Handler in the child thread.

You may wonder, when I use it in the main thread, I don't require Looper.prepare().

It turns out that we have explicitly called Looper.prepareMainLooper() in ActivityThread:

 public   static void main(String[] args) {
 // ...
 Looper.prepareMainLooper();
 // ...
 if (sMainThreadHandler == null ) {
 sMainThreadHandler = thread.getHandler();
 }
 //...
 Looper.loop();
 // ...
 }

Let's look at Looper.prepareMainLooper():

 public   static void prepareMainLooper() {
 prepare ( false );
 synchronized (Looper.class) {
 if (sMainLooper != null ) {
 throw new IllegalStateException( "The main Looper has already been prepared." );
 }
 sMainLooper = myLooper();
 }
 }