Learning summary – Android messaging mechanism to break down

Handler provides a series of send() and post() methods, and each of the post() methods eventually calls the send() method to send a message. In a series of the send () method in addition to sendMessageAtFrontOfQueue () method, other methods of sending a message and call to sendMessageAtTime () method, But eventually the enqueueMessage() method of the Handler itself is called. Take a look at these methods:

    // Handler.sendMessageAtTime()
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);
   }
// Handler.sendMessageAtFrontOfQueue()
   public final boolean sendMessageAtFrontOfQueue(Message msg) {
       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, 0);
   }
// Handler.enqueueMessage()
   private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
       msg.target = this;
       if (mAsynchronous) {
           msg.setAsynchronous(true);
       }
       return queue.enqueueMessage(msg, uptimeMillis);
   }Copy the code

The enqueueMessage() method first stores the current handler object: MSG. Target = this, then call MessageQueue’s enqueueMessage() method to queue the message, which sends the message via Handler.

When looper.loop () is called, the message is sent out of the queue, and the final message is handed by Looper to Handler, which calls Handler’s dispatchMessage() method. The dispatchMessage() method is implemented as follows:

public void dispatchMessage(Message msg) { if (msg.callback ! = null) { handleCallback(msg); } else { if (mCallback ! = null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); }}Copy the code

First check if Message’s callback (msg.callback) is null. If not, the Message is processed via handleCallback(). MSG. Callback is a Runnable object, which is essentially a Runnable argument passed through the Handler’s POST method. The logic of the handleCallback() method is also simple:

private static void handleCallback(Message message) {
    message.callback.run();
}Copy the code

So sending a message via post() could be written like this:

Handler handler = new Handler(); Handler.post (new Runnable() {@override public void run() {handler.post(new Runnable() {@override public Void run() {// do UI operations here}}); }; }).start();Copy the code

This gives you a better understanding of the handleCallback() method. Return to the dispatchMessage() method to determine whether mCallback is null. If not, McAllback.handlemessage () is called to process the message.

public interface Callback {
    public boolean handleMessage(Message msg);
}Copy the code

Callback is an interface that can be used to create an instance of Handler without subclassing Handler. Here’s the most intuitive example:

class callback implements Handler.Callback { @Override public boolean handleMessage(Message msg) { // 3. Return false; } } Handler handler = new Handler(new callback()); new Thread(new Runnable() { @Override public void run() { // 1. // 2. Send messages through a series of handler methods}}).start();Copy the code

McAllback.handlemessage () also clears this up. Then dispatchMessage() finally calls Handler’s handlerMessage() method to process the message.

The Handler is now used to send messages and process messages. MessageQueue’s enqueueMessage() method is used to queue messages.

Looper acts as a message loop within the Android messaging mechanism. Specifically, it constantly checks for new messages from MessageQueue and processes them immediately if there are new messages, otherwise it will remain blocked. Here is the loop() method:

public static void loop() { final Looper me = myLooper(); if (me == null) { throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } final MessageQueue queue = me.mQueue; Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); for (;;) { Message msg = queue.next(); // might block if (msg == null) { // No message indicates that the message queue is quitting. return; }... msg.target.dispatchMessage(msg); . }}Copy the code

First determine the return value of myLooper(). If the return value is null, an exception is thrown, meaning that the thread does not already have Looper, otherwise proceed.

This is followed by an infinite loop calling Queue.next (), so MessageQueue’s next() method is called from there. Every time a message is sent out of the queue, it is passed to the dispatchMessage() method of msg.target, which we already mentioned is actually a Handler, Messages sent through this Handler are then returned to its own dispatchMessage() method.

The only time to break out of the loop is when MessageQueue’s next() method returns NULL. Looper provides two ways to quit() and quitSafely() to quit a Looper. The quitSafely() method, on the other hand, simply sets an exit marker and exits safely when all the existing messages in the message queue run out.

When Looper’s quit() or quitSafely() method is called, MessageQueue’s quit() method is called internally to tell the MessageQueue to quit, MessageQueue’s next() method returns NULL. Therefore, it is recommended to terminate Looper when no longer needed by using the quit() or quitSafely() method.

Having said myLooper(), now look at the myLooper() method:

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

What is sthreadlocal.get ()? Keep reading:

The result, of course, is predictable, because it’s been tried out before, and that’s the wonder of ThreadLocal. With that in mind, let’s look at its internal implementation, starting with the set() method:

public void set(T value) {
    Thread currentThread = Thread.currentThread();
    Values values = values(currentThread);
    if (values == null) {
        values = initializeValues(currentThread);
    }
    values.put(this, value);
}Copy the code

This method is neat: it first fetches the current thread, and then fetches ThreadLocal data for the current thread through values(). Why do you say that? Let’s start with the values() method:

Values values(Thread current) {
    return current.localValues;
}Copy the code

What are localValues? Private Object[] table, which is the real data structure. ThreadLocal is stored in this table array. So values() actually gets the localValues object, and the table array inside localValues actually owns ThreadLocal’s data.

Back in set(), if we get values that are null, we initialize them, and then we store them through put(). Moving on to the put() method:

void put(ThreadLocal key, Object value) { cleanUp(); int firstTombstone = -1; for (int index = key.hash & mask;; index = next(index)) { Object k = table[index]; if (k == key.reference) { table[index + 1] = value; return; } if (k == null) { if (firstTombstone == -1) { table[index] = key.reference; table[index + 1] = value; size++; return; } table[firstTombstone] = key.reference; table[firstTombstone + 1] = value; tombstones--; size++; return; } if (firstTombstone == -1 && k == TOMBSTONE) { firstTombstone = index; }}}Copy the code

Focusing on the storage rules for the PUT () method, you can see that the value of ThreadLocal is located next to reference in the table array. For example, if the index of reference in the table array is index, the value of ThreadLocal will be stored at the index + 1 position in the table array.

After looking at the set() method, let’s look at the get() method:

@SuppressWarnings("unchecked") public T get() { // Optimized for the fast path. Thread currentThread = Thread.currentThread(); Values values = values(currentThread); if (values ! = null) { Object[] table = values.table; int index = hash & values.mask; if (this.reference == table[index]) { return (T) table[index + 1]; } } else { values = initializeValues(currentThread); } return (T) values.getAfterMiss(this); }Copy the code

The get() method also fetches the current localValues object, and if the object is not null, fetches its table array and finds the location of reference in the table array. Select * from ThreadLocal; select * from ThreadLocal; select * from ThreadLocal; The initial value is returned if the localValues object is null, which is null by default.

ThreadLocal’s set() and get() methods operate on the current thread’s table array, thus confirming the description of ThreadLocal. Once you understand ThreadLocal, you’ll have a better understanding of how Looper works.

I’ve almost walked through Android’s messaging mechanism here, and finally posted a sequence diagram to understand the process (I’m just starting to learn how to use sequence diagrams) :

It is clear from this sequence diagram that a thread corresponds to a Looper object, and a Looper object corresponds to a MessageQueue object. Why is it possible to manipulate the UI using asynchronous message processing? This is because the Handler is always attached to the thread on which it was created. So a time-consuming operation in the child thread sends a message through the Handler, which eventually goes to the main thread for UI operations in the Handler’s handlerMessage() method.