从零实现ImageLoader（四）—— Handler的内心独

目录

从零实现ImageLoader（一）—— 架构
从零实现ImageLoader（二）—— 基本实现
从零实现ImageLoader（三）—— 线程池详解
从零实现ImageLoader（四）—— Handler的内心独白
从零实现ImageLoader（五）—— 内存缓存LruCache
从零实现ImageLoader（六）—— 磁盘缓存DiskLruCache

前情回顾

在上一篇文章里，我们实现了ImageLoader的异步加载功能，探索了线程池的原理，不过却遗留了一个问题，也就是这一句代码：

ImageLoader.HANDLER.post(() -> imageView.setImageBitmap(image));

上一篇文章里只是简单的提了一下这句代码将imageView.setImageBitmap(image)切换到了主线程执行，可这是怎么做到的呢？要知道，用户可以在主线程使用我们的ImageLoader，同样也可以在子线程使用，我们甚至都不知道自己处于什么线程。

而这句代码可以成功的关键就在于HANDLER的初始化：

public class ImageLoader {
    static final Handler HANDLER = new Handler(Looper.getMainLooper());
}

看到这句代码，有的同学可能已经有了答案，也有同学可能依然一头雾水，不管你看没看懂，今天的这篇文章一定会让你对Handler的运行机制有一个更加清晰的理解。

原理

Handler这个我们平时开发时常见的老朋友，他的作用应该已经不必多说了，大多数的同学应该也对MessageQueue、Looper和Message这几个类有所了解，可他们之间是怎么协同工作的呢？让我们先来看一张图：

Handler原理图

很明显，这是一个典型的生产者-消费者模型，Handler通过sendMessage()方法将消息放入阻塞队列MessageQueue中，而Looper.loop()方法则会一直检测MessageQueue中是否有可用的消息，得到消息后，Looper就会调用Handler.dispatchMessage()，进而通过handleMessage()处理消息。

需要注意的是，这只是一个线程里的结构，如果是多线程的话，每个使用Handler线程都应该有一个这样的结构，所以准确一点的图应该是这样：

准确一点的图

那有人就要问了，按照上面的说法，消息在同一个线程里转来转去有什么意义呢？说好的线程间通信呢？

Java里的堆内存是线程间共享的，所以理论上来说在一个线程里可以拿到另一个线程的任意对象（其实对象都在一个地方，也就不分哪个线程了，这么说只是为了方便理解），我们这里需要的只是Handler，他就是开启线程间通信大门的钥匙，拿到了哪个线程的Handler也就可以向哪个线程发送消息。而我们平时也就是这么使用的：

public class MainActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        new Thread(() -> {
            //在子线程中使用主线程的Handler向主线程发送消息
            mHandler.sendMessage(Message.obtain());
        }).start();
    }

    private Handler mHandler = new MyHandler();

    static class MyHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            doSomething();
        }
    }
}

Looper的线程独立性

明白了Handler的工作原理，我们再来学习源码加深一下印象。

要想明白Handler是怎么实现的，就得先知道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();
}

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

可以看到这里使用ThreadLocal实现了每个线程都拥有独立的Looper，而MessageQueue作为Looper的成员变量也同时做到了线程的独立。

Handler与Looper的联系

那Handler又是如何和Looper联系到一起的呢？这就要看Handler的构造方法了：

public Handler(Callback callback, boolean async) {
    ...

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

public Handler(Looper looper, Callback callback, boolean async) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

就在这里Handler确认了自己的归属，默认当然是属于创建自己的线程，而通过Looper参数手动指定归属线程也未尝不可，这也就是我们文章一开头所做的。

消息入列

Handler所有的sendMessage()方法最终都调用了enqueueMessage()：

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

很明显Handler通过queue.enqueueMessage()方法将消息放入了消息队列。

消息出列

消息的出列自然是在Looper.loop()方法中了：

public static void loop() {
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;

    for (;;) {
        Message msg = queue.next(); // 由于MessageQueue是阻塞队列，这里有可能阻塞住
        if (msg == null) {
            // 如果msg为空证明消息队列已经退出了
            return;
        }

        ...

        msg.target.dispatchMessage(msg);

        ...
    }
}

loop()中的代码看起来很多实际上大多数都是一些log代码，而删去log代码剩下的这些相信已经一目了然了，loop()中的for循环会一直尝试从消息队列中取出Message，之后根据Message.target调用Handler.dispatchMessage()方法。而dispatchMessage()又会调用Message.handleMessage()，最终完成消息的处理。

时序图

最后我们让以一个时序图来结束今天Handler的原理探索：