Handler, Looper and MessageQueue source code analysis

In Android, Handler can be used to update the changes of UI in the main thread. The UI can only be updated in the main thread. In order to allow other threads to control UI changes, Android provides a mechanism for Handler, Looper and MessageQueue to work together to achieve the purpose of updating UI in other threads.

Generally, we define a Handler in the main thread by the following method

 private Handler mHandler = new Handler() {
 @Override
 public void handleMessage(Message msg) {
            tv.setText( "mHandler change UI" );
            super.handleMessage(msg);
 }
 };

Looper and MessageQueue are not usually seen, so where are they called and how do they collaborate? Looper is not called explicitly in the main thread but is called by default in the ActivityThread.main method.

 public   static void main(String[] args) {
         Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain" );
        SamplingProfilerIntegration.start(); 
  
        // CloseGuard defaults to   true   and can be quite spammy. We
        // disable it here, but selectively enable it later (via
        // StrictMode) on debug builds, but using DropBox, not logs.
        CloseGuard.setEnabled( false ); 
  
        Environment.initForCurrentUser(); 
  
        // Set the reporter for event logging in libcore
        EventLogger.setReporter(new EventLoggingReporter()); 
  
        // Make sure TrustedCertificateStore looks in the right place for CA certificates
        final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
         TrustedCertificateStore.setDefaultUserDirectory(configDir); 
  
        Process.setArgV0( "<pre-initialized>" ); 
  
 Looper.prepareMainLooper();//Create Looper 
  
        ActivityThread thread = new ActivityThread();
        thread.attach( false ); 
  
        if (sMainThreadHandler == null ) {
            sMainThreadHandler = thread.getHandler();
 } 
  
 if ( false ) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread" ));
 } 
  
 // End   of event ActivityThreadMain.
         Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
 Looper.loop(); //Open Looper loop 
  
        throw new RuntimeException( "Main thread loop unexpectedly exited" );
 }

As shown in the above code, the Looper.prepareMainLooper() method is called to create a Looper in the main thread. If you don’t believe it, let’s check what this method does.

Looper

prepare

 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)); //Create Looper and assign it to sThreadLocal
 } 
  
 /**
     * Initialize the current thread as a looper, marking it as an
     * application's main looper. The main looper for your application
     * is created by the Android environment, so you should never need
     * to call this function yourself. See also: {@link # prepare ()}
 */
 public   static void prepareMainLooper() {
 prepare ( false );
        synchronized (Looper.class) {
            if (sMainLooper != null ) {
                throw new IllegalStateException( "The main Looper has already been prepared." );
 }
            sMainLooper = myLooper();
 }
 } 
      
 public   static @Nullable Looper myLooper() {
 return sThreadLocal.get();
 }

In the prepareMainLooper method, prepare is called. Through prepare, you will find that it actually creates a Looper and assigns it to sThreadLocal. At the same time, you can get the Looper in the current thread through the myLooper method. Let's take a look at what new Looper(quitAllowed) initializes

 private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
 }

Here we finally see MessageQueue, which creates a MessageQueue. This message queue is used to save subsequent Messages. Going back to the ActivityThread.main method, we find that it calls Looper.loop() to start the Looper loop and listen to the messages in the message queue MessageQueue.

loop

Let's look at the source code of Looper.loop():

 public   static void loop() {
 final Looper me = myLooper(); //Get Looper
 if (me == null ) {
            throw new RuntimeException( "No Looper; Looper.prepare() wasn't called on this thread." );
 }
 final MessageQueue queue = me.mQueue; //Get the message queue 
  
        // Make sure the identity of this thread is that of the local process,
        // and keep track of what that identity token actually is .
        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 ;
 } 
  
            // This must be in a local variable, in   case a UI event sets the logger
            final Printer logging = me.mLogging;
            if (logging != null ) {
                logging.println( ">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
 } 
  
            final long traceTag = me.mTraceTag;
            if (traceTag != 0) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
 }
 try {
 msg.target.dispatchMessage(msg); //Distribute messages through Handler
 finally
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
 }
 } 
  
            if (logging != null ) {
                logging.println( "<<<<< Finished to " + msg.target + " " + msg.callback);
 } 
  
            // Make sure that during the course of dispatching the
            // identity of the thread wasn't corrupted.
            final long newIdent = Binder.clearCallingIdentity();
            if (ident != newIdent) {
                Log.wtf(TAG, "Thread identity changed from 0x"  
                        + Long.toHexString(ident) + " to 0x"  
                        + Long.toHexString(newIdent) + " while dispatching to "  
                        + msg.target.getClass().getName() + " "  
                        + msg.callback + " what=" + msg.what);
 } 
  
            msg.recycleUnchecked();
 }
 }

In the loop, we first get the Looper of the current thread, and also get the MessageQueue in the Looper, which means that the Looper has been bound to the current thread. Then we start a for infinite loop, and find that it is constantly taking messages from the message queue, and finally passing them to msg.target to call its dispatchMessage method. So what is target? Let's go into Message

Message

 /*package*/ int flags; 
 
 /*package*/ long when ; 
     
 /*package*/ Bundle data; 
     
    /*package*/ Handler target; 
     
    /*package*/ Runnable callback; 
     
    // sometimes we store linked lists of these things
    /*package*/ Message next ;

We find that it is the Handler we are familiar with, which means that the dispatchMessage method in the Handler is called to distribute the message. In this way, the Handler contacts the thread bound to the Looper through the Looper, which is the main thread.

Handler

 public Handler(Callback callback, boolean async) {
        if (FIND_POTENTIAL_LEAKS) {
            final Class<? extends Handler> klass = getClass();
            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                    (klass.getModifiers() & Modifier. STATIC ) == 0) {
                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                    klass.getCanonicalName());
 }
 } 
  
        mLooper = Looper.myLooper();
        if (mLooper == null ) {
            throw new RuntimeException(
 "Can't create handler inside thread that has not called Looper.prepare()" );
 }
        mQueue = mLooper.mQueue;
 mCallback = callback;
        mAsynchronous = async;
 }

Through the initialization of Handler, it obtains the Looper of the thread it is in, and also obtains the message queue in the Looper. Of course, if the Looper of the thread is empty, an exception will be thrown, which explains why when creating a Handler in a non-main thread, you need to call Looper.prepare and Looper.loop respectively, but the main thread does not need to, because it has been called by default.

dispatchMessage

 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();
 }

Back to the front, for the processing of dispatchMessage, first determine whether msg.callback is empty. Here, callback should be known as a Runnable through the above Message. If it is not empty, directly call the run method of Runnable. Otherwise, call the handleMessage method of Handler. I believe everyone is already familiar with this method. The processing of events is performed in this method. Because we already know that the Handler has contacted the main thread, the processing in handleMessage is naturally relative to the main thread, and the UI can be updated naturally. Through this, we can compare Looper to a bridge to connect the communication between the thread where the Looper is located and the Handler, and manage the messages in the message queue MessageQueue. So how is the previous Runnable not empty? There are two ways to use Handler. One is to directly create a Handler and rewrite its handleMessage method, and the other can be used through Handler.post(Runnable), so that the processing of events is naturally implemented in the run method.

The above describes how the Handler contacts the thread that needs to be operated and how the message is retrieved and processed. Next, let's talk about how the message is put into the MessageQueue in the Looper.

sendMessageAtTime

There are many ways to send messages through Handler, such as sendMessage, sendEmptyMessage and sendMessageDelayed, but in fact, they all call the sendMessageAtTime method. So let's take a look at the implementation of the sendMessageAtTime 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);
 }

And sendMessageAtTime calls the enqueueMessage operation. From the name of this method, you can tell that it is an enqueue operation.

enqueueMessage

 private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
 msg.target = this;
 if (mAsynchronous) {
            msg.setAsynchronous( true );
 }
 return queue.enqueueMessage(msg, uptimeMillis);
 }

As expected, queue.enqueueMessage(msg, uptimeMillis) in MessageQueue is directly called to add the message to the message queue. At the same time, this code msg.target = this assigns the current Handler to msg.target, which is the Handler called in the Looper.loop method mentioned earlier. In this way, the message is placed in the MessageQueue, and then the message is taken out through the loop mentioned earlier for corresponding processing, thus forming the entire system for processing messages. This is also the principle of using Handler inside. Well, these are basically the connections between Handler, Looper and MessageQueue. I also drew a simple picture and hope it will be helpful.

Summarize

Let's summarize the process between them. First, create a Handler. There must be a Looper in the thread where the Handler is located. If it is implemented by default in the main thread, other threads must call Looper.prepare to create a Looper and call Looper.loop to start processing messages. Each Looper has a MessageQueue, which is used to store Messages. The Handler puts the message into the message queue through a series of operations such as post or send.., and the Looper keeps listening to the message processing by starting a continuous loop, constantly taking messages from the MessageQueue, and handing them over to the dispatchMessage of the handler bound to the current Looper for distribution. ***According to the situation, the run method of Runnable or the HandlerMessage method of Handler is called to ***process the message.

Other sharing: https://idisfkj.github.io/arc...