Android之Handler浅析

共计 3501 个字符，预计需要花费 9 分钟才能阅读完成。

Handler 相信每个从事 Android 开发的小伙伴都非常熟悉了，最常用的场景就是在子线程中进行数据操作然后通过 handler 消息机制通知到 UI 线程来更新 UI，地球人都知道在子线程中更新 UI，一般情况下都会报错。每每出去面试被问到“handler 原理”，“消息是怎么从子线程发送到主线程的”等等 handler 底层的实现，就懵逼了。

虽然网上关于分析 handler 的博客问丈夫非常多，已经有很多大佬分析的非常清晰了。这里分析主要是为了让自己加深理解，另一方面就是想分享所学知识。

Android 消息循环流程图如下所示：

主要涉及的角色如下所示：

Message：消息。
MessageQueue: 消息队列，负责消息的存储于管理，负责管理由 handler 发过来的 Message，读取会自动删除消息，单链表维护，插入和删除上有优势。在其 next() 方法中会无限循环，不短判断是否有消息，有就返回这条消息并移除。
Looper: 消息循环器，负责关联线程以及消息的分发，在该线程下从 MessageQueue 获取 Message，分发给 handler，Looper 创建的时候会创建一个 MessageQueue，调用 loop() 方法的时候消息循环开始，其中会不断调用 MessageQueue 的 next() 方法，有消息就处理，否则就阻塞在 MessageQueue 的 next() 方法中，当 Looper 的 quit() 被调用的时候会调用 MessageQueue 的 quit(), 此时的 next() 会返回 null，然后 loop() 方法也就跟着退出。
Handler: 消息处理器，负责发送并处理消息，面向开发则，提供 API，并隐藏背后实现的细节。

整个消息循环流程还是比较清晰的，具体来说：

1.Handler 通过 sendMessage() 发送消息 Message 到队列 MessageQueue.
2.Looper 通过 loop() 不断提取触发条件的 Message，并将 Message 交给对应的 target handler 来处理。
3.target handler 调用自身的 handleMessage（）方法来处理 Message。

事实上，在整个消息循环的流程中，并不止只有 Java 层参与，很多重要的工作都是在 C ++ 层来完成，我们来看看下图的这些类的调用它关系。

注：虚线表示关联关系，实现表示调用关系。

在这些类中 MessageQueue 是 Java 层与 C ++ 层维系的桥梁，MessageQueue 与 Looper 相关功能都通过 MessageQueue 的 Native 方法来完成，而其他虚线连接的类只有关联关系，并没有直接调用的关系，它们发生关系的桥梁是 MessageQueue.

总结：

Handler 发送的消息由 MessageQueue 存储管理，并由 Looper 负责回调消息到 handlerMessage（）
线程的切换由 Looper 完成，handlerMessage() 所在线程由 Looper.loop() 调用者所在线程决定。

Handler 允许我们发送延迟消息，如果在延时期间内用户关闭了 activity，那么该 activity 会泄漏。这个泄漏是因为 Message 会出油 Handler，而又因为 Java 的特性，内部类会持有外部类，使得 activity 会被 Handler 持有，这样最终就会导致 activity 泄漏了。

解决的办法就是：将 Handler 定义为静态的内部类，在内部持有 activity 的弱引用，并在 activity 的 ondestroy() 中调用 handler.removeCallbacksAndMessage(null) 及时移除所有消息。

private static class SafeHandler extends Handler {

    private WeakReference<HandlerActivity> ref;

    public SafeHandler(HandlerActivity activity) {this.ref = new WeakReference(activity);
    }

    @Override
    public void handleMessage(final Message msg) {HandlerActivity activity = ref.get();
        if (activity != null) {activity.handleMessage(msg);
        }
    }
}

并且再在 Activity.onDestroy() 前移除消息，加一层保障：

@Override
protected void onDestroy() {safeHandler.removeCallbacksAndMessages(null);
  super.onDestroy();}

通常我们认为 ActivityThread 就是主线程，事实上它并不是一个线程，而是主线程操作的管理者。在 ActivityThread.main() 方法中调用了 Looper.prepareMainLooper() 方法创建了主线程的 looper, 并且调用了 loop() 方法，所有我们就可以直接使用 Handler 了。

因此我们可以利用 Callback 这个拦截机制来拦截 Handler 的消息，如大部分插件化框架中的 Hook ActivityThread.mH 的处理。

主线程不允许退出，退出就意味 APP 要挂了。

Handler.Callback 有优先处理消息的权利，当一条消息被 Callback 处理并拦截（返回 true），那么 Handler 的 handleMessage(msg) 方法就不会被调用了；如果 Callback 处理了消息，但是并没有拦截，那么就意味着一个消息可以同时被 Callback 以及 Handler 处理。

为了节省开销，Android 给 Message 设计了回收机制，所以我们在使用的时候尽量复用 Message，减少内存的消耗：

通过 Message 的静态方法 Message.obtain（）
通过 Handler 的共有方法 handler.obtainMessage()

本质上是因为 Toast 的实现依赖于 Handler，按子线程使用 Handler 的要求修改即可，同理的还有就是 dialog。

new Thread(new Runnable() {
  @Override
  public void run() {Looper.prepare();
    Toast.makeText(MainActivity.this, "不会崩溃啦！", Toast.LENGTH_SHORT).show();
    Looper.loop();}
}).start();

将 Runnable post 到主线程执行
利用 Looper 判断当前线程是否是主线程

public final class MainThread {private MainThread() { }

    private static final Handler HANDLER = new Handler(Looper.getMainLooper());

    public static void run(@NonNull Runnable runnable) {if (isMainThread()) {runnable.run();
        }else{HANDLER.post(runnable);
        }
    }

    public static boolean isMainThread() {return Looper.myLooper() == Looper.getMainLooper();}

}

并不是，这里就涉及到 Linux pipe/epoll 机制，简单说就是在主线程的 MessageQueue 没有消息时，便阻塞在 loop 的 queue.next() 中的 nativePollOnce() 方法里，此时主线程会释放 CPU 资源进入休眠状态，直到下个消息到达或者有事务发生，通过往 pipe 管道写端写入数据来唤醒主线程工作。这里采用的 epoll 机制，是一种 IO 多路复用机制，可以同时监控多个描述符，当某个描述符就绪 (读或写就绪)，则立刻通知相应程序进行读或写操作，本质是同步 I /O，即读写是阻塞的。所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量 CPU 资源。

Android 之 Handler 浅析

下面来列举我们几个工作中或许都会遇到的问题。

Handler 引起的内存泄漏原因以及最佳解决方案

为什么我们能在主线程直接使用 Handler，而不需要创建 Looper?

主线程的 Looper 不允许退出

Handler 里藏着 Callback 能干什么？

创建 Message 实例的最佳方式

子线程里弹 Toast 的正确姿势

妙用 Looper 机制

主线程的死循环一直运行是不是特别消耗 CPU 资源呢？

Just My Socks（注册教程内含优惠码）