Android Handler 机制深度解析：27 个核心问题详解

sendMessageDelayed 方法主要计算了消息需要被处理的时间，如果 delayMillis 为 0，那么消息的处理时间就是当前时间。

然后就是关键方法 enqueueMessage。

    boolean enqueueMessage(Message msg, long when) {
        synchronized (this) {
            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                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; 
                prev.next = msg;
            }

            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

不懂得地方先不看，只看我们想看的：

• 首先设置了 Message 的 when 字段，也就是代表了这个消息的处理时间
• 然后判断当前队列是不是为空，是不是即时消息，是不是执行时间 when 大于表头的消息时间，满足任意一个，就把当前消息 msg 插入到表头。
• 否则，就需要遍历这个队列，也就是链表，找出 when 小于某个节点的 when，找到后插入。

好了，其他内容暂且不看，总之，插入消息就是通过消息的执行时间，也就是 when 字段，来找到合适的位置插入链表。

具体方法就是通过死循环，使用快慢指针 p 和 prev，每次向后移动一格，直到找到某个节点 p 的 when 大于我们要插入消息的 when 字段，则插入到 p 和 prev 之间。或者遍历到链表结束，插入到链表结尾。

所以，MessageQueue 就是一个用于存储消息、用链表实现的特殊队列结构。

5、延迟消息是怎么实现的？

总结上述内容，延迟消息的实现主要跟消息的统一存储方法有关，也就是上文说过的 enqueueMessage 方法。

无论是即时消息还是延迟消息，都是计算出具体的时间，然后作为消息的 when 字段进程赋值。

然后在 MessageQueue 中找到合适的位置（安排 when 小到大排列），并将消息插入到 MessageQueue 中。

这样，MessageQueue 就是一个按照消息时间排列的一个链表结构。

6、MessageQueue 的消息怎么被取出来的？

刚才说过了消息的存储，接下来看看消息的取出，也就是 queue.next 方法。

    Message next() {
        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }

            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) {
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }
                if (msg != null) {
                    if (now < msg.when) {
                        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;
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // No more messages.
                    nextPollTimeoutMillis = -1;
                }
            }
        }
    }

奇怪，为什么取消息也是用的死循环呢？

其实死循环就是为了保证一定要返回一条消息，如果没有可用消息，那么就阻塞在这里，一直到有新消息的到来。

其中，nativePollOnce 方法就是阻塞方法，nextPollTimeoutMillis 参数就是阻塞的时间。

那什么时候会阻塞呢？两种情况：

• 1、有消息，但是当前时间小于消息执行时间，也就是代码中的这一句：

if (now < msg.when) {
    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
}

这时候阻塞时间就是消息时间减去当前时间，然后进入下一次循环，阻塞。

• 2、没有消息的时候，也就是上述代码的最后一句：

if (msg != null) {} 
    else {
    // No more messages.
    nextPollTimeoutMillis = -1;
    }

-1 就代表一直阻塞。

7、MessageQueue 没有消息时候会怎样？阻塞之后怎么唤醒呢？说说 pipe/epoll 机制？

接着上文的逻辑，当消息不可用或者没有消息的时候就会阻塞在 next 方法，而阻塞的办法是通过 pipe/epoll 机制

epoll 机制是一种 IO 多路复用的机制，具体逻辑就是一个进程可以监视多个描述符，当某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作，这个读写操作是阻塞的。在 Android 中，会创建一个 Linux 管道（Pipe）来处理阻塞和唤醒。

• 当消息队列为空，管道的读端等待管道中有新内容可读，就会通过 epoll 机制进入阻塞状态。
• 当有消息要处理，就会通过管道的写端写入内容，唤醒主线程。

那什么时候会怎么唤醒消息队列线程呢？

还记得刚才插入消息的 enqueueMessage 方法中有个 needWake 字段吗，很明显，这个就是表示是否唤醒的字段。

其中还有个字段是 mBlocked，看字面意思是阻塞的意思，去代码里面找找：

Message next() {
        for (;;) {
            synchronized (this) {
                if (msg != null) {
                    if (now < msg.when) {
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // Got a message.
                        mBlocked = false;
                        return msg;
                    }
                } 
                if (pendingIdleHandlerCount <= 0) {
                    // No idle handlers to run.  Loop and wait some more.
                    mBlocked = true;
                    continue;
                }
            }
        }
    }

在获取消息的方法 next 中，有两个地方对 mBlocked 赋值：

• 当获取到消息的时候，mBlocked 赋值为 false，表示不阻塞。
• 当没有消息要处理，也没有 idleHandler 要处理的时候，mBlocked 赋值为 true，表示阻塞。

好了，确实这个字段就表示是否阻塞的意思，再去看看 enqueueMessage 方法中，唤醒机制：

    boolean enqueueMessage(Message msg, long when) {
        synchronized (this) {
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                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; 
                prev.next = msg;
            }

            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

• 当链表为空或者时间小于表头消息时间，那么就插入表头，并且设置是否唤醒为 mBlocked。

再结合上述的例子，也就是当有新消息要插入表头了，这时候如果之前是阻塞状态（mBlocked=true），那么就要唤醒线程了。

• 否则，就需要取链表中找到某个节点并插入消息，在这之前需要赋值 needWake = mBlocked && p.target == null && msg.isAsynchronous()

也就是在插入消息之前，需要判断是否阻塞，并且表头是不是屏障消息，并且当前消息是不是异步消息。也就是如果现在是同步屏障模式下，那么要插入的消息又刚好是异步消息，那就不用管插入消息问题了，直接唤醒线程，因为异步消息需要先执行。

• 最后一点，是在循环里，如果发现之前就存在异步消息，那就还是设置是否唤醒为 false。

意思就是，如果之前有异步消息了，那肯定之前就唤醒过了，这时候就不需要再次唤醒了。

最后根据 needWake 的值，决定是否调用 nativeWake 方法唤醒 next() 方法。

8、同步屏障和异步消息是怎么实现的？

其实在 Handler 机制中，有三种消息类型：

• 同步消息。也就是普通的消息。
• 异步消息。通过 setAsynchronous(true) 设置的消息。
• 同步屏障消息。通过 postSyncBarrier 方法添加的消息，特点是 target 为空，也就是没有对应的 handler。

这三者之间的关系如何呢？

• 正常情况下，同步消息和异步消息都是正常被处理，也就是根据时间 when 来取消息，处理消息。
• 当遇到同步屏障消息的时候，就开始从消息队列里面去找异步消息，找到了再根据时间决定阻塞还是返回消息。

Message msg = mMessages;
if (msg != null && msg.target == null) {
      do {
      prevMsg = msg;
      msg = msg.next;
      } while (msg != null && !msg.isAsynchronous());
}

也就是说同步屏障消息不会被返回，他只是一个标志，一个工具，遇到它就代表要去先行处理异步消息了。

所以同步屏障和异步消息的存在的意义就在于有些消息需要'加急处理'。

9、同步屏障和异步消息有具体的使用场景吗？

使用场景就很多了，比如绘制方法 scheduleTraversals。

    void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            // 同步屏障，阻塞所有的同步消息
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            // 通过 Choreographer 发送绘制任务
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        }
    }

    Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
    msg.arg1 = callbackType;
    msg.setAsynchronous(true);
    mHandler.sendMessageAtTime(msg, dueTime);

在该方法中加入了同步屏障，后续加入一个异步消息 MSG_DO_SCHEDULE_CALLBACK，最后会执行到 FrameDisplayEventReceiver，用于申请 VSYNC 信号。

10、Message 消息被分发之后会怎么处理？消息怎么复用的？

再看看 loop 方法，在消息被分发之后，也就是执行了 dispatchMessage 方法之后，还偷偷做了一个操作——recycleUnchecked。

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

            try {
                msg.target.dispatchMessage(msg);
            } 

            msg.recycleUnchecked();
        }
    }

//Message.java
    private static Message sPool;
    private static final int MAX_POOL_SIZE = 50;

    void recycleUnchecked() {
        flags = FLAG_IN_USE;
        what = 0;
        arg1 = 0;
        arg2 = 0;
        obj = null;
        replyTo = null;
        sendingUid = UID_NONE;
        workSourceUid = UID_NONE;
        when = 0;
        target = null;
        callback = null;
        data = null;

        synchronized (sPoolSync) {
            if (sPoolSize < MAX_POOL_SIZE) {
                next = sPool;
                sPool = this;
                sPoolSize++;
            }
        }
    }

在 recycleUnchecked 方法中，释放了所有资源，然后将当前的空消息插入到 sPool 表头。

这里的 sPool 就是一个消息对象池，它也是一个链表结构的消息，最大长度为 50。

那么 Message 又是怎么复用的呢？在 Message 的实例化方法 obtain 中：

    public static Message obtain() {
        synchronized (sPoolSync) {
            if (sPool != null) {
                Message m = sPool;
                sPool = m.next;
                m.next = null;
                m.flags = 0; // clear in-use flag
                sPoolSize--;
                return m;
            }
        }
        return new Message();
    }

直接复用消息池 sPool 中的第一条消息，然后 sPool 指向下一个节点，消息池数量减一。

11、Looper 是干嘛呢？怎么获取当前线程的 Looper？为什么不直接用 Map 存储线程和对象呢？

在 Handler 发送消息之后，消息就被存储到 MessageQueue 中，而 Looper 就是一个管理消息队列的角色。Looper 会从 MessageQueue 中不断的查找消息，也就是 loop 方法，并将消息交回给 Handler 进行处理。

而 Looper 的获取就是通过 ThreadLocal 机制:

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

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

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

通过 prepare 方法创建 Looper 并且加入到 sThreadLocal 中，通过 myLooper 方法从 sThreadLocal 中获取 Looper。

12、ThreadLocal 运行机制？这种机制设计的好处？

下面就具体说说 ThreadLocal 运行机制。

//ThreadLocal.java
    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

从 ThreadLocal 类中的 get 和 set 方法可以大致看出来，有一个 ThreadLocalMap 变量，这个变量存储着键值对形式的数据。

• key 为 this，也就是当前 ThreadLocal 变量。
• value 为 T，也就是要存储的值。

然后继续看看 ThreadLocalMap 哪来的，也就是 getMap 方法：

    //ThreadLocal.java
    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

    //Thread.java
    ThreadLocal.ThreadLocalMap threadLocals = null;

原来这个 ThreadLocalMap 变量是存储在线程类 Thread 中的。

所以 ThreadLocal 的基本机制就搞清楚了：

在每个线程中都有一个 threadLocals 变量，这个变量存储着 ThreadLocal 和对应的需要保存的对象。

这样带来的好处就是，在不同的线程，访问同一个 ThreadLocal 对象，但是能获取到的值却不一样。

挺神奇的是不是，其实就是其内部获取到的 Map 不同，Map 和 Thread 绑定，所以虽然访问的是同一个 ThreadLocal 对象，但是访问的 Map 却不是同一个，所以取得值也不一样。

这样做有什么好处呢？为什么不直接用 Map 存储线程和对象呢？

打个比方：

• ThreadLocal 就是老师。
• Thread 就是同学。
• Looper（需要的值）就是铅笔。

现在老师买了一批铅笔，然后想把这些铅笔发给同学们，怎么发呢？两种办法：

• 1、老师把每个铅笔上写好每个同学的名字，放到一个大盒子里面去（map），用的时候就让同学们自己来找。

这种做法就是 Map 里面存储的是同学和铅笔，然后用的时候通过同学来从这个 Map 里找铅笔。

这种做法就有点像使用一个 Map，存储所有的线程和对象，不好的地方就在于会很混乱，每个线程之间有了联系，也容易造成内存泄漏。

• 2、老师把每个铅笔直接发给每个同学，放到同学的口袋里（map），用的时候每个同学从口袋里面拿出铅笔就可以了。

这种做法就是 Map 里面存储的是老师和铅笔，然后用的时候老师说一声，同学只需要从口袋里拿出来就行了。

很明显这种做法更科学，这也就是 ThreadLocal 的做法，因为铅笔本身就是同学自己在用，所以一开始就把铅笔交给同学自己保管是最好的，每个同学之间进行隔离。

13、还有哪些地方运用到了 ThreadLocal 机制？

比如：Choreographer。

public final class Choreographer {

    // Thread local storage for the choreographer.
    private static final ThreadLocal<Choreographer> sThreadInstance =
            new ThreadLocal<Choreographer>() {
        @Override
        protected Choreographer initialValue() {
            Looper looper = Looper.myLooper();
            if (looper == null) {
                throw new IllegalStateException("The current thread must have a looper!");
            }
            Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
            if (looper == Looper.getMainLooper()) {
                mMainInstance = choreographer;
            }
            return choreographer;
        }
    };

    private static volatile Choreographer mMainInstance;

Choreographer 主要是主线程用的，用于配合 VSYNC 中断信号。

所以这里使用 ThreadLocal 更多的意义在于完成线程单例的功能。

14、可以多次创建 Looper 吗？

Looper 的创建是通过 Looper.prepare 方法实现的，而在 prepare 方法中就判断了，当前线程是否存在 Looper 对象，如果有，就会直接抛出异常：

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

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

所以同一个线程，只能创建一个 Looper，多次创建会报错。

15、Looper 中的 quitAllowed 字段是啥？有什么用？

按照字面意思就是是否允许退出，我们看看他都在哪些地方用到了：

    void quit(boolean safe) {
        if (!mQuitAllowed) {
            throw new IllegalStateException("Main thread not allowed to quit.");
        }

        synchronized (this) {
            if (mQuitting) {
                return;
            }
            mQuitting = true;

            if (safe) {
                removeAllFutureMessagesLocked();
            } else {
                removeAllMessagesLocked();
            }
        }
    }

哦，就是这个 quit 方法用到了，如果这个字段为 false，代表不允许退出，就会报错。

但是这个 quit 方法又是干嘛的呢？从来没用过呢。还有这个 safe 又是啥呢？

其实看名字就差不多能了解了，quit 方法就是退出消息队列，终止消息循环。

• 首先设置了 mQuitting 字段为 true。
• 然后判断是否安全退出，如果安全退出，就执行 removeAllFutureMessagesLocked 方法，它内部的逻辑是清空所有的延迟消息，之前没处理的非延迟消息还是需要取处理，然后设置非延迟消息的下一个节点为空（p.next=null）。
• 如果不是安全退出，就执行 removeAllMessagesLocked 方法，直接清空所有的消息，然后设置消息队列指向空（mMessages = null）

然后看看当调用 quit 方法之后，消息的发送和处理：

//消息发送
    boolean enqueueMessage(Message msg, long when) {
        synchronized (this) {
            if (mQuitting) {
                IllegalStateException e = new IllegalStateException(
                        msg.target + " sending message to a Handler on a dead thread");
                Log.w(TAG, e.getMessage(), e);
                msg.recycle();
                return false;
            }
        }

当调用了 quit 方法之后，mQuitting 为 true，消息就发不出去了，会报错。

再看看消息的处理，loop 和 next 方法：

    Message next() {
        for (;;) {
            synchronized (this) {
                if (mQuitting) {
                    dispose();
                    return null;
                } 
            }  
        }
    }

    public static void loop() {
        for (;;) {
            Message msg = queue.next();
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
        }
    }

很明显，当 mQuitting 为 true 的时候，next 方法返回 null，那么 loop 方法中就会退出死循环。

那么这个 quit 方法一般是什么时候使用呢？

• 主线程中，一般情况下肯定不能退出，因为退出后主线程就停止了。所以是当 APP 需要退出的时候，就会调用 quit 方法，涉及到的消息是 EXIT_APPLICATION，大家可以搜索下。
• 子线程中，如果消息都处理完了，就需要调用 quit 方法停止消息循环。

16、Looper.loop 方法是死循环，为什么不会卡死（ANR）？

我大致总结下：

• 1、主线程本身就是需要一只运行的，因为要处理各个 View，界面变化。所以需要这个死循环来保证主线程一直执行下去，不会被退出。
• 2、真正会卡死的操作是在某个消息处理的时候操作时间过长，导致掉帧、ANR，而不是 loop 方法本身。
• 3、在主线程以外，会有其他的线程来处理接受其他进程的事件，比如 Binder 线程（ApplicationThread），会接受 AMS 发送来的事件
• 4、在收到跨进程消息后，会交给主线程的 Handler 再进行消息分发。所以 Activity 的生命周期都是依靠主线程的 Looper.loop，当收到不同 Message 时则采用相应措施，比如收到 msg=H.LAUNCH_ACTIVITY，则调用 ActivityThread.handleLaunchActivity() 方法，最终执行到 onCreate 方法。
• 5、当没有消息的时候，会阻塞在 loop 的 queue.next() 中的 nativePollOnce() 方法里，此时主线程会释放 CPU 资源进入休眠状态，直到下个消息到达或者有事务发生。所以死循环也不会特别消耗 CPU 资源。

17、Message 是怎么找到它所属的 Handler 然后进行分发的？

在 loop 方法中，找到要处理的 Message，然后调用了这么一句代码处理消息：

msg.target.dispatchMessage(msg);

所以是将消息交给了 msg.target 来处理，那么这个 target 是啥呢？

找找它的来头：

//Handler
    private boolean enqueueMessage(MessageQueue queue,Message msg,long uptimeMillis) {
        msg.target = this;

        return queue.enqueueMessage(queue, msg, uptimeMillis);
    }

在使用 Hanlder 发送消息的时候，会设置 msg.target = this，所以 target 就是当初把消息加到消息队列的那个 Handler。

18、Handler 的 post(Runnable) 与 sendMessage 有什么区别

Hanlder 中主要的发送消息可以分为两种：

• post(Runnable)
• sendMessage

    public final boolean post(@NonNull Runnable r) {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }
    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

通过 post 的源码可知，其实 post 和 sendMessage 的区别就在于：

post 方法给 Message 设置了一个 callback。

那么这个 callback 有什么用呢？我们再转到消息处理的方法 dispatchMessage 中看看：

    public void dispatchMessage(@NonNull 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();
    }

这段代码可以分为三部分看：

• 1、如果 msg.callback 不为空，也就是通过 post 方法发送消息的时候，会把消息交给这个 msg.callback 进行处理，然后就没有后续了。
• 2、如果 msg.callback 为空，也就是通过 sendMessage 发送消息的时候，会判断 Handler 当前的 mCallback 是否为空，如果不为空就交给 Handler.Callback.handleMessage 处理。
• 3、如果 mCallback.handleMessage 返回 true，则无后续了。
• 4、如果 mCallback.handleMessage 返回 false，则调用 handler 类重写的 handleMessage 方法。

所以 post(Runnable) 与 sendMessage 的区别就在于后续消息的处理方式，是交给 msg.callback 还是 Handler.Callback 或者 Handler.handleMessage。

19、Handler.Callback.handleMessage 和 Handler.handleMessage 有什么不一样？为什么这么设计？

接着上面的代码说，这两个处理方法的区别在于 Handler.Callback.handleMessage 方法是否返回 true：

• 如果为 true，则不再执行 Handler.handleMessage
• 如果为 false，则两个方法都要执行。

那么什么时候有 Callback，什么时候没有呢？这涉及到两种 Handler 的 创建方式：

    val handler1= object : Handler(){
        override fun handleMessage(msg: Message) {
            super.handleMessage(msg)
        }
    }

    val handler2 = Handler(object : Handler.Callback {
        override fun handleMessage(msg: Message): Boolean {
            return true
        }
    })

常用的方法就是第 1 种，派生一个 Handler 的子类并重写 handleMessage 方法。而第 2 种就是系统给我们提供了一种不需要派生子类的使用方法，只需要传入一个 Callback 即可。

20、Handler、Looper、MessageQueue、线程是一一对应关系吗？

• 一个线程只会有一个 Looper 对象，所以线程和 Looper 是一一对应的。
• MessageQueue 对象是在 new Looper 的时候创建的，所以 Looper 和 MessageQueue 是一一对应的。
• Handler 的作用只是将消息加到 MessageQueue 中，并后续取出消息后，根据消息的 target 字段分发给当初的那个 handler，所以 Handler 对于 Looper 是可以多对一的，也就是多个 Handler 对象都可以用同一个线程、同一个 Looper、同一个 MessageQueue。

总结：Looper、MessageQueue、线程是一一对应关系，而他们与 Handler 是可以一对多的。

21、ActivityThread 中做了哪些关于 Handler 的工作？（为什么主线程不需要单独创建 Looper）

主要做了两件事：

• 1、在 main 方法中，创建了主线程的 Looper 和 MessageQueue，并且调用 loop 方法开启了主线程的消息循环。

public static void main(String[] args) {

        Looper.prepareMainLooper();

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

• 2、创建了一个 Handler 来进行四大组件的启动停止等事件处理

final H mH = new H();

class H extends Handler {
        public static final int BIND_APPLICATION        = 110;
        public static final int EXIT_APPLICATION        = 111;
        public static final int RECEIVER                = 113;
        public static final int CREATE_SERVICE          = 114;
        public static final int STOP_SERVICE            = 116;
        public static final int BIND_SERVICE            = 121;

22、IdleHandler 是啥？有什么使用场景？

之前说过，当 MessageQueue 没有消息的时候，就会阻塞在 next 方法中，其实在阻塞之前，MessageQueue 还会做一件事，就是检查是否存在 IdleHandler，如果有，就会去执行它的 queueIdle 方法。

    private IdleHandler[] mPendingIdleHandlers;

    Message next() {
        int pendingIdleHandlerCount = -1;
        for (;;) {
            synchronized (this) {
                //当消息执行完毕，就设置 pendingIdleHandlerCount
                if (pendingIdleHandlerCount < 0
                        && (mMessages == null || now < mMessages.when)) {
                    pendingIdleHandlerCount = mIdleHandlers.size();
                }

                //初始化 mPendingIdleHandlers
                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                //mIdleHandlers 转为数组
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }

            // 遍历数组，处理每个 IdleHandler
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; // release the reference to the handler

                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }

                //如果 queueIdle 方法返回 false，则处理完就删除这个 IdleHandler
                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            // Reset the idle handler count to 0 so we do not run them again.
            pendingIdleHandlerCount = 0;
        }
    }

当没有消息处理的时候，就会去处理这个 mIdleHandlers 集合里面的每个 IdleHandler 对象，并调用其 queueIdle 方法。最后根据 queueIdle 返回值判断是否用完删除当前的 IdleHandler。

然后看看 IdleHandler 是怎么加进去的：

Looper.myQueue().addIdleHandler(new IdleHandler() {  
    @Override  
    public boolean queueIdle() {  
        //做事情
        return false;    
    }  
});

    public void addIdleHandler(@NonNull IdleHandler handler) {
        if (handler == null) {
            throw new NullPointerException("Can't add a null IdleHandler");
        }
        synchronized (this) {
            mIdleHandlers.add(handler);
        }
    }

ok，综上所述，IdleHandler 就是当消息队列里面没有当前要处理的消息了，需要堵塞之前，可以做一些空闲任务的处理。

常见的使用场景有：启动优化。

我们一般会把一些事件（比如界面 view 的绘制、赋值）放到 onCreate 方法或者 onResume 方法中。但是这两个方法其实都是在界面绘制之前调用的，也就是说一定程度上这两个方法的耗时会影响到启动时间。

所以我们可以把一些操作放到 IdleHandler 中，也就是界面绘制完成之后才去调用，这样就能减少启动时间了。

但是，这里需要注意下可能会有坑。

如果使用不当，IdleHandler 会一直不执行，比如在 View 的 onDraw 方法里面无限制的直接或者间接调用 View 的 invalidate 方法。

其原因就在于 onDraw 方法中执行 invalidate，会添加一个同步屏障消息，在等到异步消息之前，会阻塞在 next 方法，而等到 FrameDisplayEventReceiver 异步任务之后又会执行 onDraw 方法，从而无限循环。

23、HandlerThread 是啥？有什么使用场景？

直接看源码：

public class HandlerThread extends Thread {
    @Override
    public void run() {
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
    }

哦，原来如此。HandlerThread 就是一个封装了 Looper 的 Thread 类。

就是为了让我们在子线程里面更方便的使用 Handler。

这里的加锁就是为了保证线程安全，获取当前线程的 Looper 对象，获取成功之后再通过 notifyAll 方法唤醒其他线程，那哪里调用了 wait 方法呢？

    public Looper getLooper() {
        if (!isAlive()) {
            return null;
        }

        // If the thread has been started, wait until the looper has been created.
        synchronized (this) {
            while (isAlive() && mLooper == null) {
                try {
                    wait();
                } catch (InterruptedException e) {
                }
            }
        }
        return mLooper;
    }

就是 getLooper 方法，所以 wait 的意思就是等待 Looper 创建好，那边创建好之后再通知这边正确返回 Looper。

24、IntentService 是啥？有什么使用场景？

老规矩，直接看源码：

public abstract class IntentService extends Service {

    private final class ServiceHandler extends Handler {
        public ServiceHandler(Looper looper) {
            super(looper);
        }

        @Override
        public void handleMessage(Message msg) {
            onHandleIntent((Intent)msg.obj);
            stopSelf(msg.arg1);
        }
    }

    @Override
    public void onCreate() {
        super.onCreate();
        HandlerThread thread = new HandlerThread("IntentService[" + mName + "]");
        thread.start();

        mServiceLooper = thread.getLooper();
        mServiceHandler = new ServiceHandler(mServiceLooper);
    }

    @Override
    public void onStart(@Nullable Intent intent, int startId) {
        Message msg = mServiceHandler.obtainMessage();
        msg.arg1 = startId;
        msg.obj = intent;
        mServiceHandler.sendMessage(msg);
    }

理一下这个源码：

• 首先，这是一个 Service
• 并且内部维护了一个 HandlerThread，也就是有完整的 Looper 在运行。
• 还维护了一个子线程的 ServiceHandler。
• 启动 Service 后，会通过 Handler 执行 onHandleIntent 方法。
• 完成任务后，会自动执行 stopSelf 停止当前 Service。

所以，这就是一个可以在子线程进行耗时任务，并且在任务执行后自动停止的 Service。

25、BlockCanary 使用过吗？说说原理

BlockCanary 是一个用来检测应用卡顿耗时的三方库。

上文说过，View 的绘制也是通过 Handler 来执行的，所以如果能知道每次 Handler 处理消息的时间，就能知道每次绘制的耗时了？那 Handler 消息的处理时间怎么获取呢？

再去 loop 方法中找找细节：

public static void loop() {
    for (;;) {
        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<<<< Finished to " + msg.target + " " + msg.callback);
        }
    }
}

可以发现，loop 方法内有一个 Printer 类，在 dispatchMessage 处理消息的前后分别打印了两次日志。

那我们把这个日志类 Printer 替换成我们自己的 Printer，然后统计两次打印日志的时间不就相当于处理消息的时间了？

    Looper.getMainLooper().setMessageLogging(mainLooperPrinter);

    public void setMessageLogging(@Nullable Printer printer) {
        mLogging = printer;
    }

这就是 BlockCanary 的原理。

26、说说 Handler 内存泄露问题。

这也是常常被问的一个问题，Handler 内存泄露的原因是什么？

"内部类持有了外部类的引用，也就是 Handler 持有了 Activity 的引用，从而导致无法被回收呗。"

其实这样回答是错误的，或者说没回答到点子上。

我们必须找到那个最终的引用者，不会被回收的引用者，其实就是主线程，这条完整引用链应该是这样：

主线程 —> threadlocal —> Looper —> MessageQueue —> Message —> Handler —> Activity

27、利用 Handler 机制设计一个不崩溃的 App？

主线程崩溃，其实都是发生在消息的处理内，包括生命周期、界面绘制。

所以如果我们能控制这个过程，并且在发生崩溃后重新开启消息循环，那么主线程就能继续运行。

Handler(Looper.getMainLooper()).post {
        while (true) {
            //主线程异常拦截
            try {
                Looper.loop()
            } catch (e: Throwable) {
            }
        }
    }

总结

大家应该可以发现，有一个问题常被问，但是全篇都没有提，那就是：

Handler 机制的运行原理。

之所以不提这个问题，是因为要回答好这个问题需要大量知识储备，希望屏幕前的你在读完这篇之后，再结合自己的知识库，形成自己的完美答案。