目录
从零实现ImageLoader（一）—— 架构
从零实现ImageLoader（二）—— 基本实现
从零实现ImageLoader（三）—— 线程池详解
从零实现ImageLoader（四）—— Handler的内心独白
从零实现ImageLoader（五）—— 内存缓存LruCache
从零实现ImageLoader（六）—— 磁盘缓存DiskLruCache
前言
众所周知，由于移动设备的特殊性，图片加载一直是Android知识体系里的重点。由于网络的限制，我们需要对图片进行缓存，避免无谓的流量消耗。由于内存的限制，我们又需要对图片进行缩放，防止触发OOM。这些都是一个优秀的图片加载框架所需要考虑的。
Android发展到现在，各种图片加载框架也是层出不群。从刚开始的Android-Universal-Image-Loader，到后来Google推出的Volley，再到现在的Fresco，Picasso，Glide百花齐放，总有一款适合你。
可是，身为一个优秀的程序员我们不应该只满足于使用别人已经写好的框架，也有必要对其中的知识点深入理解。这次的系列文章就是从实现一个图片加载框架开始，对其中碰到的问题加以突破，之后再对目前的几个图片加载框架加以分析，领略优秀的框架所包含的设计理念。
预期效果
在开始之前我们先看一下我们将要实现的代码效果：
ImageLoader.with(this).load(URL).into(imageView);
没错，就只有短短这么一行代码。熟悉Picasso或者Glide的同学想必已经发现了，这不就是Picasso的调用方式吗？之所以选择这种链式的调用方式就是由于他可以做到极简，这也是Picasso和Glide之所以如此受欢迎的原因之一。
架构
接下来我们看一下ImageLoader的架构图：
这次我们只实现网络数据的加载，通过ImageLoader类的load(String url)方法进行处理。而本地图片、项目资源图片等等其他数据的加载都大同小异，就不再涉及了。
加载方式我们实现了同步加载和异步加载，分别由Dispatcher类的get()方法和into(ImageView imageView)方法给出。这里就牵扯到了线程池的使用，线程间通信等知识。
当然也少不了基本上每个图片加载框架都有的内存缓存和磁盘缓存，我们这次分别选择了LruCache类和Jake Wharton大神的DiskLruCache类，后面也会对这两个类的源码进行深入的分析。
缓存
下面详细介绍一下缓存策略的实现：
为什么要使用缓存
在介绍缓存策略之前，我们先来回答一个问题：为什么要使用缓存？
移动设备在使用网络时往往面临一个问题，那就是流量是需要收费的，这就需要软件开发者在开发时应当尽量避免流量的消耗，而流量消耗的大头就是图片。这时候本地缓存就是一个很好的解决方式。而且移动设备用户所处的网络环境也是不可知的，如果用户处于弱网络环境下，那图片加载所要消耗的时间将是不可忍受的，这也是使用本地缓存的原因之一。
同时，移动设备的内存是有限的，如果一个应用包含大量的图片，全部放到内存中必然会触发OOM，可如果每次都要重新从本次磁盘加载的话，性能就会有很大的消耗。而且本地加载虽然比网络要快但也是需要时间的，这也往往造成界面的卡顿。这时候一个好的内存缓存策略就是不可或缺的。
缓存原理
明白了为什么使用，接下来就要考虑怎么实现了。大家先看一张图，这是我仿照Android-Universal-Image-Loader的图片加载流程图画的：
一图胜千言，相信这张图片已经很能说明问题了。
首先，程序会在内存缓存中查找Bitmap，如果命中则直接显示，如果没有就会去本地磁盘缓存中查找缓存文件；如果在磁盘缓存中命中就将缓存文件转换为Bitmap再进行显示，这个过程中会将Bitmap加入内存缓存中；如果本地磁盘中没有就会从网络上进行下载，并且缓存在磁盘和内存中。
总结
这篇文章对ImageLoader的架构已经介绍完毕，接下来就要开始具体的实现了，敬请期待。
