4、Handler与Looper机制：Handler、MessageQueue、Looper工作原理、主线程与子线程通信、IdleHandler、同步屏障

说到Android的消息机制，Handler绝对是绕不开的核心。我刚开始做Android开发那会儿，就被各种「不能在子线程更新UI」的崩溃搞到头大。后来才明白，这一切的背后，都是Handler、Looper和MessageQueue在默默工作。

说白了，Handler机制就是一套「生产者-消费者」模型。子线程负责生产消息，主线程负责消费消息。你想想看，如果多个线程同时去操作UI，那画面得多混乱？所以Android设计了这个精巧的机制，把所有UI操作都串行化到主线程执行。

4.1 核心角色：谁在做什么？

先搞清楚三个核心角色各自的责任：

  • Looper：消息循环的发动机。它负责从MessageQueue里不断取消息，然后分发出去。每个线程最多只能有一个Looper。
  • MessageQueue：消息的「快递柜」。它用链表结构存储消息，支持按时间排序、同步屏障等高级功能。
  • Handler：消息的发送者和处理者。你通过它发送消息，它也负责最终处理消息。

嗯，这里要注意：Handler并不属于某个线程，它绑定的是该线程的Looper。我见过不少新手以为Handler属于创建它的线程，其实不对——Handler属于创建它时绑定的Looper所在的线程。

4.2 主线程的Looper是怎么启动的？

你有没有想过，为什么我们在主线程可以直接new Handler()，而在子线程却会报错？

原因很简单：主线程在启动时，ActivityThread已经帮我们调用了Looper.prepareMainLooper()和Looper.loop()。来看源码：

// 在ActivityThread.main()中
public static void main(String[] args) {
    // ...
    Looper.prepareMainLooper();
    // ...
    Looper.loop();
}

而子线程默认是没有Looper的。如果你在子线程直接new Handler()，会抛出这样的异常：

Can't create handler inside thread that has not called Looper.prepare()

解决办法？手动调用Looper.prepare()和Looper.loop()就行。我个人习惯在子线程里这样写：

class WorkerThread extends Thread {
    public Handler mHandler;

    @Override
    public void run() {
        Looper.prepare();
        mHandler = new Handler(Looper.myLooper()) {
            @Override
            public void handleMessage(Message msg) {
                // 处理消息
            }
        };
        Looper.loop(); // 这行会阻塞，让线程持续运行
    }
}
注意：Looper.loop()是一个死循环，它会一直阻塞当前线程。如果你想让子线程退出，记得调用Looper.myLooper().quit()或quitSafely()。我曾经在项目里忘记退出子线程的Looper，结果导致线程泄漏，内存一直涨——嗯，血的教训。

4.3 消息发送与处理的完整流程

一条消息从发送到处理，经历了哪些步骤？我画个流程图给你看：

  1. 调用handler.sendMessage(msg)或handler.post(runnable)
  2. Handler将消息插入到MessageQueue中（按时间排序）
  3. Looper从MessageQueue中取出消息（阻塞等待）
  4. Looper将消息分发给Handler的handleMessage()或Runnable的run()

这里有个细节：Handler发送消息时，会把自身（this）赋值给Message的target字段。这样Looper在分发时才知道该交给哪个Handler处理。

// Handler.sendMessageAtTime() 核心代码
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        return false;
    }
    msg.target = this; // 关键：绑定Handler自身
    return queue.enqueueMessage(msg, uptimeMillis);
}

4.4 主线程与子线程通信的几种姿势

实际开发中，最常见的场景就是子线程做完耗时操作，然后通知主线程更新UI。我总结了三种常用方式：

方式 代码示例 适用场景
Handler.post(Runnable) mHandler.post(() -> textView.setText("done")); 简单的一次性任务
Handler.sendMessage(Message) mHandler.sendMessage(msg); 需要携带数据、区分消息类型
View.post(Runnable) textView.post(() -> doSomething()); 在任意线程更新UI，无需持有Handler

我个人最常用的是Handler.post()，因为它写起来最简洁。但如果消息需要携带复杂数据，或者需要区分不同的消息类型，那还是用sendMessage()配合what字段更清晰。

小技巧：如果你在子线程里想更新UI，但又不想持有Activity的Handler引用（防止内存泄漏），可以用view.post()。它内部会通过View的AttachInfo拿到主线程的Handler，非常方便。

4.5 IdleHandler：当消息队列空闲时

IdleHandler是个容易被忽略但很有用的东西。它会在消息队列空闲时被回调。什么叫空闲？就是当前MessageQueue里没有消息要处理了。

我曾在项目里用它来做「延迟初始化」——比如启动页加载完成后，等主线程闲下来再去预加载一些非关键数据：

Looper.myLooper().getQueue().addIdleHandler(new MessageQueue.IdleHandler() {
    @Override
    public boolean queueIdle() {
        // 在这里做非关键的初始化工作
        preloadData();
        // 返回false表示只执行一次，返回true会持续监听
        return false;
    }
});

注意queueIdle()的返回值：

  • 返回true：保留IdleHandler，下次空闲时继续回调
  • 返回false：执行完后自动移除，只执行一次

嗯，这里有个坑：不要在IdleHandler里做耗时操作。因为它是在主线程执行的，如果阻塞太久，会影响后续消息的处理。我曾经在IdleHandler里做了个数据库查询，结果导致界面卡顿——后来改成异步线程才解决。

4.6 同步屏障：让紧急消息插队

同步屏障是Handler机制里比较高级的特性，平时用得不多，但理解它对深入理解Android渲染机制很有帮助。

先说说什么是同步屏障。正常情况下，MessageQueue里的消息是按时间排序的，先到先处理。但有些消息非常紧急，比如VSync信号触发的UI刷新消息，它需要尽快执行，不能等前面的普通消息都处理完。

这时候就需要同步屏障了。它的工作原理是这样的：

  1. 往MessageQueue里插入一个「屏障消息」（target为null的特殊消息）
  2. 屏障消息之后的普通同步消息都会被阻塞，无法执行
  3. 但异步消息不受影响，可以正常执行
  4. 当异步消息处理完后，移除屏障，恢复普通消息的执行

来看个简化的代码理解一下：

// 插入同步屏障（系统内部使用，应用层不开放）
MessageQueue queue = Looper.myLooper().getQueue();
int token = queue.postSyncBarrier();

// 发送异步消息（需要设置标志）
Message msg = Message.obtain();
msg.setAsynchronous(true); // 标记为异步消息
mHandler.sendMessage(msg);

// 移除屏障
queue.removeSyncBarrier(token);
重点：同步屏障和异步消息是Android UI渲染流畅的关键。每次VSync信号到来时，系统会插入同步屏障，优先处理Choreographer的异步消息，从而保证UI及时刷新。这就是为什么你的动画能保持在60fps的原因之一。

不过说实话，应用层开发者很少需要直接操作同步屏障。系统内部（比如ViewRootImpl、Choreographer）已经帮我们封装好了。你只需要知道：当你用Handler.post()更新UI时，系统会通过同步屏障机制确保你的UI更新请求被优先处理。

4.7 避坑指南：我踩过的那些坑

最后分享几个我在项目中实际遇到的Handler相关坑：

  • 内存泄漏：非静态内部Handler持有外部Activity的引用，如果消息还没处理完Activity就销毁了，会导致Activity无法被GC。解决方案：使用静态内部类+弱引用，或者在onDestroy()里移除所有消息。
  • 消息积压：如果主线程Looper处理不过来，消息会堆积在MessageQueue里，导致界面卡顿。我曾经在列表快速滑动时发了大量消息，结果UI直接卡死——后来改用批量处理才解决。
  • HandlerThread的正确关闭：调用quit()后，Looper会立即退出，未处理的消息全部丢弃。而quitSafely()会等当前消息处理完再退出。根据场景选择合适的退出方式。

Handler机制看似简单，但背后涉及的知识点其实不少。理解了它，你也就理解了Android为什么能保证UI线程安全，以及系统是如何保证界面流畅的。嗯，下一章我们会深入分析Handler的源码实现，到时候你会看到更多有趣的细节。

← 上一章 📖 返回目录 下一章 →