【Android】Handler、Looper、消息队列运行机制原理解析及相关面试题

不念不忘少年蓝@ 2022-10-29 07:57 161阅读 0赞

### 文章目录 ###

*  一、Handler原理
 *   *  1. Looper和消息队列机制
     *   *  1.1 Looper
         *   *  Looper.prepare()
             *  Looper.loop()
         *  1.2 消息队列 - MessageQueue
     *  2. Handler传递消息的过程
 *  二、Handler相关问题
 *   *  1. 为什么Looper中的死循环不会阻塞主线程？
     *  2. Handler只能在主线程创建吗？如果不是，那Handler可以在任意线程创建吗？
     *  3. View.post()方法和Handler.post()是一样的吗？
     *  4. 获取Message的方式有哪些？哪种最好？
     *  5. Handler是怎样起到切换线程作用的？是怎样在子线程发送消息然后在主线程处理的？
     *  6. 消息队列的数据结构是什么？
     *  7. Handler为什么会造成内存泄漏？如何解决？

Handler及消息队列是Android中一个基本的知识点，也是Android应用建立的基石。本文介绍了Handler的运行机制，以及相关面试题的答案。

# 一、Handler原理 #

## 1. Looper和消息队列机制 ##

Handler持有了一个消息队列`MessageQueue`对象`mQueue`。这个对象是Handler实例构造的时候，通过Looper传递过来的。当使用无参构造方法时，这个Looper为`Looper.myLooper()`。

public Handler() { 
            // 。。。
            mLooper = Looper.myLooper();
            mQueue = mLooper.mQueue;
        }

而Looper类又是通过[ ThreadLocal ][ThreadLocal]来实现线程和Looper对象一一对应的。`Looper.myLooper()`即是当前线程所对应的Looper。

也就是说，Handler中的消息队列，其实是当前线程对应的**Looper**的消息队列。

那么，要理解Handler的原理，就要先理解Looper和消息队列的原理。

### 1.1 Looper ###

事情又要回到`ActivityThread`中说起，这相当于是一个Android程序的主线程，`main`方法就在其中。

*  `ActivityThread.main()`

public static void main(String[] args) { 
            // ...
            Looper.prepareMainLooper();
            Looper.loop();
            throw new RuntimeException("Main thread loop unexpectedly exited");
        }

在这里，调用了Looper的两个方法，`prepare`和`loop`，启动了主线程的Looper。Looper的结构相对来说还是比较简单的，其中最主要的就是这两个方法了。

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

在Looper内部，有一个`ThreadLocal<Looper>`类型的静态变量`sThreadLocal`。  
而prepare的过程很简单，就是将当前这个Looper对象，保存到这个`sThreadLocal`中。即：**以`sThreadLocal`为媒介，建立当前线程与当前Looper对象的对应关系。**

#### Looper.loop() ####

这是Android程序中最重要的机制之一，也是Android程序能够一直运行的原因。以下是`Looper.loop()`源码，删去了绝大部分，只保留了最关键的几行：

public static void loop() { 
            final Looper me = myLooper();
            final MessageQueue queue = me.mQueue;
            for (;;) { 
                Message msg = queue.next(); // might block
                try { 
                    msg.target.dispatchMessage(msg);
                } // ...
            }
        }

可以发现，`loop()`函数其实是一个死循环；在这个循环中，不停地从消息队列中取下一条消息，然后分发给对应的Handler（`msg.target`）进行处理。  
“Looper”就是循环的意思，这正对应了`loop()`方法中的这个死循环。在这个死循环里面，可以无限读取消息队列中的消息。使用`quit()`方法可以退出这个循环；如果在主线程的Looper退出，也就意味着程序的结束——将会得到 `java.lang.IllegalStateException: Main thread not allowed to quit.` 的报错信息。

### 1.2 消息队列 - MessageQueue ###

*  **Message**  
    Message消息是Handler传递信息的基本单位。在Handler中，不管是调用`post(Runnable)`还是`sendMessage(Message)`还是其他的什么，最终都会构建一个Message对象，并添加到消息队列`mQueue`中。Message中保存了消息的类型、参数、对应的Handler等一些少量的数据。

在**1.1**中说到，`Looper.loop()`会发起一个死循环，在消息队列中不停取值。那么，为什么这里不会卡死呢？  
**`Looper#loop()`**：

跳转到`MessageQueue.next()`，看一下消息队列是怎么取下一条消息的。这里删去了大部分代码，只剩下核心的部分，方便梳理流程：

Message next() { 
            int nextPollTimeoutMillis = 0;
            for (;;) { 
                nativePollOnce(ptr, nextPollTimeoutMillis); // 会阻塞线程直到下一个消息到来
                synchronized (this) { 
                    final long now = SystemClock.uptimeMillis();
                    Message msg = mMessages;
                    if (msg != null) { 
                        if (now < msg.when) {  // 时候未到
                            nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                        } else { 
                            mMessages = msg.next;
                            msg.next = null;
                            msg.markInUse();
                            return msg;
                        }
                    }
                }
            }
        }

`nativePollOnce`是一个本地方法，它会阻塞线程直到下一个有消息来临。这类似于Java中的`DelayQueue`，不同点是`DelayQueue`是通过优先队列+锁实现的。  
在MessageQueue中有一个Message类型的对象`mMessage`，它保存着消息队列中最早的一条消息。当阻塞的线程被唤醒时，`next()`方法会返回`mMessage`，并且`mMessage`重新赋值为`mMessage.next`。  
很容易发现，在消息队列中，所有未读的消息是通过**链表**的形式来保存的，每一个Message都是链表中的节点，`Message#next`指向了链表中的下一个节点。

**小结**

*  Looper和拥有Looper的线程**一一对应**，通过ThreadLocal来实现。Looper和消息队列也是一一对应的。
 *  `Looper.loop()`中是一个死循环，会无限调用对应消息队列的`next()`方法来获取下一个消息。
 *  消息队列的`next()`方法会调用native方法`nativePollOnce`阻塞线程，直到有新的消息来临将其返回。
 *  消息队列实质上是以`Message`为节点的单向链表，其头节点为`mMessage`。链表是按照Message的触发时间，即`msg.when`，从早到晚排序的。

## 2. Handler传递消息的过程 ##

从发送消息开始。使用Handler的`post(runnalbe)`、`sendMessage(msg)`、`sendMessageDelayed(msg, delay)`、Message的`sendToTarget()`等等许多方法都可以发送消息。最终，这些方法都会进入`Handler#enqueueMessage`方法。

*  **Handler\#enqueueMessage(MessageQueue, Message, long)**

`enqueueMessage`方法的作用是将Message的target设置为本Handler，然后调用MessageQueue的`enqueueMessage`方法。

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

这个`queue`即是`Looper.mQueue`，即当前线程的消息队列。在这里，会使用`msg.target = this`将Message与当前Handler绑定。  
这里的`uptimeMillis`是Message预定送达的时间，如果没有设置延迟，那么这个时间是`SystemClock.uptimeMillis()`。

*  **MessageQueue\#enqueueMessage(Message, long)**

顾名思义，`enqueueMessage`表示将新到来的消息入队。  
删去了部分，只保留关键代码：

boolean enqueueMessage(Message msg, long when) { 
            synchronized (this) { 
                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;
        }

这里做了两件事：  
一、将这个Message按照传达时间的顺序插入到消息队列中；  
二、如果消息队列当前是阻塞的，并且这个消息的传达时间成为了消息队列中最早的一个，那么就将线程唤醒。

当消息入队之后，消息发送的过程就已经完毕了，接下来就是等待取出消息了。

*  **MessageQueue\#next()**
 *  **Looper\#loop()**

第1小节提到了，Looper会无限循环从MessageQueue中读取消息。

public static void loop() { 
            for (;;) { 
                Message msg = queue.next(); // might block
                try { 
                    msg.target.dispatchMessage(msg);
                } // ...
            }
        }

当一个消息`msg`到达指定时间并被读取到之后，会调用`msg.target.dispatchMessage()`方法；而这个`target`对象就是上面`Handler#enqueueMessage()`方法中传递进去的Handler。  
也就是说，消息被读取到之后，会调用对应Handler的`dispatchMessage`方法。

*  **Handler\#dispatchMessage()**

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

这里的逻辑很简单，如果这个Handler设置了`Callback`的话，就调用`handleCallback`回调，否则就调用`handleMessage`回调。可以看到，如果设置了Callback的话，Handler的`handleMessage`就不生效了，这一点很容易证实。  
此时，就完成了从消息发送到消息处理的流程。

**小结**

1.  Handler消息的传递流程：  
    \-> `Handler#enqueueMessage(MessageQueue, Message, long)` 所有发送消息最终调用该方法  
    \-> `MessageQueue#enqueueMessage(Message, long)` 消息入队  
    \-> `MessageQueue#next()` 等待消息到时，取出消息  
    \-> `Handler#dispatchMessage(msg)` 发送消息到对应Handler  
    \-> `Handler#handleMessage(msg)`或`Handler.Callback#handleCallback(msg)`：处理消息
2.  Handler相当于一个前台的工具人，只做了发送消息和接收消息的工作，消息处理的主要传递和分发过程都交给了Looper和MessageQueue。

# 二、Handler相关问题 #

## 1. 为什么Looper中的死循环不会阻塞主线程？ ##

回到标题中的问题。  
从上面的分析中，可以看到，在`Looper.loop()`的死循环中，**主线程的确是被阻塞了**；并且如果没有消息，将会一直阻塞下去——这一点毫无疑问。所以这个问题本身就是不严谨的：得先问是不是，再问为什么。

这个问题正确的问法是，为什么主线程Looper中的死循环不会造成ANR/卡顿？

虽然这个问题仍然没有什么逻辑性——死循环和ANR/卡顿似乎并没有什么太大的联系，并且可以说是完全没有关系。要回答这个问题，首先要分析ANR/卡顿的原因，这是一个综合性的问题。

**首先要明确的是，卡顿和ANR不是一回事儿。**  
卡顿指手机不能在肉眼无法察觉的时间内完成一帧的绘制。对于一个60hz的屏幕，每一帧需要在16ms内完成绘制，否则就会丢帧。丢帧越多，卡顿就越严重。**卡顿的主要原因是主线程干了太多的事情，导致了16ms之内无法完成一帧的绘制**，可能是布局层次太深导致绘图耗费时间长，可能是进行了复杂的运算，还有可能是频繁GC引发卡顿……总之，就是主线程负担太重了。  
ANR指的是Application Not Responding，也就是应用无响应。这里ANR特指输入无响应ANR，也就是应用对触摸屏幕或者按键的响应时间超过5秒。也就是说，**ANR的发生的必要条件是，需要有输入，也就是用户点击了屏幕之类的，否则是不会发生ANR的**。ANR产生的原理比较复杂，当用户点击了屏幕，InputManagerService会通过epoll机制在硬件层面读取到这个事件后，会使用InputDispatcher通过Socket通知对应的ViewRootImple。而ANR是在InputDispatcher.cpp中的`handleTargetsNotReadyLocked`函数检测的，在这里，当一个事件分发下去之后，会设置一个超时时间，也就5秒之后；在下一个事件到来时，如果时间大于超时时间，并且上一个事件还没有处理完毕的话，就要走ANR流程了。  
当然，究其根本原因，造成ANR的原因很大程度上大致与卡顿是相似的，但是二者是完全不同性质的两个事件。

回到问题上，**卡顿是因为出于某种原因导致的绘制时间过长，而ANR的原因是对用户的操作响应超时。**  
而Looper中的死循环是为了读取消息，要知道Android应用本质上是消息驱动的，不管是卡顿还是ANR，**本质上都是对应Handler或者Handler.Callback的`handleMessage()`处理消息方法的执行时间太长**；而Looper中的死循环是在体系之外的，不在某个Handler的`handleMessage()`方法体之中，自然也就不会引起卡顿和ANR了。

## 2. Handler只能在主线程创建吗？如果不是，那Handler可以在任意线程创建吗？ ##

否。  
Handler的作用是作为一个终端发送和处理消息，需要配套的消息队列才能发挥作用。**所以，Handler只能在调用了`Looper.prepare()`的线程中使用，并且在最后加上`Looper.loop()`使其生效**。如果在没有调用`Looper.prepare()`的线程创建Handler，会出现 “*Can’t create handler inside thread that has not called Looper.prepare()*” 的错误。  
同时，这个线程的所有代码都要写在`Looper.prepare()`和`Looper.loop()`之间，因为`Looper.loop()`会阻塞线程，后面的代码没法执行到。

## 3. View.post()方法和Handler.post()是一样的吗？ ##

**`View#post()`方法本质上也是调用了`Handler#post()`**，这个Handler保存在View的`mAttachInfo`中，通过父容器调用View的`dispatchAttachedToWindow(attachInfo, visibility)`方法传递过来。  
这个Handler最终是指向\*\*ViewRootImpl中的`mHandler`\*\*对象，类型是继承自Handler类的`ViewRootHandler`。这个类中定义了一系列View需要用到的消息并进行了处理，如`INVALIDATE`等。

## 4. 获取Message的方式有哪些？哪种最好？ ##

1.  直接new
2.  调用`Message.obtain()`或者`Handler#obtain()`

第二种方法好，因为使用了消息池复用。因为Message类本身就可以作为一个链表的节点，所以消息池的数据结构是一个链表，每次复用取出头节点。

## 5. Handler是怎样起到切换线程作用的？是怎样在子线程发送消息然后在主线程处理的？ ##

Handler发送消息的过程仅仅只是把消息放进消息队列里，这是在子线程里完成的。  
主线程的Looper是一直在主线程运行的，当发现有新消息之后，就会提取出来，然后再在主线程把消息传递给Handler进行处理；这样就完成了线程切换。

## 6. 消息队列的数据结构是什么？ ##

链表。  
MessageQueue类中的`mMessage`对象为链表的头节点。

## 7. Handler为什么会造成内存泄漏？如何解决？ ##

内存泄漏的原因是类成员的生命周期大于类对象的生命周期，换句话说就是一个需要销毁的对象由于成员被外部引用而无法销毁。  
比如，一个Activity中有一个Handler成员对象。如果这个Handler发送了一个延时很长的消息，那么这个Handler在很长一段时间内都不能销毁，因为发送的消息的Message引用了这个Handler（`msg.target`），而这个Message还在消息队列中存活。这样，即使finish了这个Activity，它仍然会在内存中存活，造成内存泄漏。  
解决方式一是使用static修饰Handler。如果Handler需要引用Activity，那么使用WeakReference弱引用。二是在Activity销毁的时候，在`onDestroy()`回调中清除Handler的所有回调。但是注意如果发送的消息周期的确是应该长于本Activity的，那么就不能使用方法二了。

[ThreadLocal]: https://www.jianshu.com/p/124f46f56ea4