目录
从零实现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通过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的原理探索：
