需要考虑哪些问题？
首先，梳理一下必要的图片加载框架的需求：
异步加载：线程池
切换线程：Handler，没有争议吧
缓存：LruCache、DiskLruCache
防止OOM：软引用、LruCache、图片压缩、Bitmap像素存储位置
内存泄露：注意ImageView的正确引用，生命周期管理
列表滑动加载的问题：加载错乱、队满任务过多问题
当然，还有一些不是必要的需求，例如加载动画等。
异步加载：
线程池，多少个？
缓存一般有三级，内存缓存、硬盘、网络。
2个，读内存和硬盘可以放在一个线程池，网络需要另外一个线程池，网络也可以采用Okhttp内置的线程池。
Glide使用了三个线程池，不考虑动画的话就是两个。
public final class GlideBuilder {
...
private GlideExecutor sourceExecutor; //加载源文件的线程池，包括网络加载
private GlideExecutor diskCacheExecutor; //加载硬盘缓存的线程池
...
private GlideExecutor animationExecutor; //动画线程池 复制
切换线程
图片异步加载成功，需要在主线程去更新ImageView，
无论是RxJava、EventBus，还是Glide，只要是想从子线程切换到Android主线程，都离不开Handler。
看下Glide 相关源码：
class EngineJob<R> implements DecodeJob.Callback<R>,Poolable {
private static final EngineResourceFactory DEFAULT_FACTORY = new EngineResourceFactory();
//创建Handler
private static final Handler MAIN_THREAD_HANDLER =
new Handler(Looper.getMainLooper(), new MainThreadCallback()); 复制
缓存
弱引用+LruCache+DiskLruCache
防止OOM
1.软引用
强引用： 普通变量都属于强引用，比如 private Context context;
软应用： SoftReference，在发生OOM之前，垃圾回收器会回收SoftReference引用的对象。
弱引用： WeakReference，发生GC的时候，垃圾回收器会回收WeakReference中的对象。
虚引用： 为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
方法1:软应用
如果一个对象只具有软引用，那么如果内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
使用场景：LeakCanary
jdk中直接内存的回收就用到虚引用，由于jvm自动内存管理的范围是堆内存，而直接内存是在堆内存之外（其实是内存映射文件，自行去理解虚拟内存空间的相关概念），所以直接内存的分配和回收都是有Unsafe类去操作，java在申请一块直接内存之后，会在堆内存分配一个对象保存这个堆外内存的引用，这个对象被垃圾收集器管理，一旦这个对象被回收，相应的用户线程会收到通知并对直接内存进行清理工作。
android中非静态handler为什么会造成内存泄漏？
当一个android主线程被创建的时候，同时会有一个Looper对象被创建，而这个Looper对象会实现一个MessageQueue(消息队列)，当我们创建一个handler对象时，而handler的作用就是放入和取出消息从这个消息队列中，每当我们通过handler将一个msg放入消息队列时，这个msg就会持有一个handler对象的引用。
因此当Activity被结束后，这个msg在被取出来之前，这msg会继续存活，但是这个msg持有handler的引用，而handler在Activity中创建，会持有Activity的引用，因而当Activity结束后，Activity对象并不能够被gc回收，因而出现内存泄漏
但是为什么为static类型就会解决这个问题呢？
因为在java中所有非静态的对象都会持有当前类的强引用，而静态对象则只会持有当前类的弱引用。
声明为静态后，handler将会持有一个Activity的弱引用，而弱引用会很容易被gc回收，这样就能解决Activity结束后，gc却无法回收的情况。
或者是activity销毁时候清空队列里的消息，即在activity的onDestroy对handler中message进行removeCallbacksAndMessages
回到图片框架，软引用的设计就是应用于会发生OOM的场景，大内存对象如Bitmap，可以通过 SoftReference 修饰，防止大对象造成OOM，看下这段代码
private static LruCache<String, SoftReference<Bitmap>> mLruCache = new LruCache<String, SoftReference<Bitmap>>(10 * 1024){
@Override
protected int sizeOf(String key, SoftReference<Bitmap> value) {
//默认返回1，这里应该返回Bitmap占用的内存大小，单位：K
//Bitmap被回收了，大小是0
if (value.get() == null){
return 0;
}
return value.get().getByteCount() /1024;
}
}; 复制
方法2:onLowMemory
当内存不足的时候，Activity、Fragment会调用onLowMemory方法，可以在这个方法里去清除缓存，Glide使用的就是这一种方式来防止OOM。
//Glide
public void onLowMemory() {
clearMemory();
}
public void clearMemory() {
// Engine asserts this anyway when removing resources, fail faster and consistently
Util.assertMainThread();
// memory cache needs to be cleared before bitmap pool to clear re-pooled Bitmaps too. See #687.
memoryCache.clearMemory();
bitmapPool.clearMemory();
arrayPool.clearMemory();
} 复制
方法3：从Bitmap 像素存储位置考虑
虚拟机的内存划分主要有5部分：
虚拟机栈
本地方法栈
程序计数器
方法区
堆
对象的分配一般都是在堆中，堆是JVM中最大的一块内存，OOM一般都是发生在堆中。
Bitmap 之所以占内存大不是因为对象本身大，而是因为Bitmap的像素数据， Bitmap的像素数据大小 = 宽 * 高 * 1像素占用的内存。
Bitmap使用 RGB_565 格式，则1像素占用 2 byte，ARGB_8888 格式则占4 byte。
Glide内存开销是Picasso的一半，就是因为默认Bitmap格式不同。
如果 BitmapFactory.Options 中指定 inJustDecodeBounds 为true，则为原图宽高，如果是false，则是缩放后的宽高。所以我们一般可以通过压缩来减小Bitmap像素占用内存。
Android 3.0到8.0 之间Bitmap像素数据存在Java堆，而8.0之后像素数据存到native堆中
主要两个步骤：
1.申请内存，创建native层Bitmap,native层的Bitmap数据（像素数据）是存在native堆中
2.创建java 层Bitmap
通过JNI创建Java层Bitmap对象
8.0 的Bitmap创建就两个点：
1.创建native层Bitmap，在native堆申请内存。
2.通过JNI创建java层Bitmap对象，这个对象在java堆中分配内存。
像素数据是存在native层Bitmap，也就是证明8.0的Bitmap像素数据存在native堆中。
7.0 像素内存的分配是这样的：
1.通过JNI调用java层创建一个数组
2.然后创建native层Bitmap，把数组的地址传进去。
由此说明，7.0 的Bitmap像素数据是放在java堆的。
说说final、finally、finalize 的关系
finalize：垃圾回收器确认这个对象没有其它地方引用到它的时候，会调用这个对象的finalize方法，子类可以重写这个方法，做一些释放资源的操作。
在6.0以前，Bitmap 就是通过这个finalize 方法来释放native层对象的。
在Bitmap构造方法创建了一个 BitmapFinalizer类，重写finalize 方法，在java层Bitmap被回收的时候，BitmapFinalizer 对象也会被回收，finalize 方法肯定会被调用，在里面释放native层Bitmap对象。
Bitmap(long nativeBitmap, byte[] buffer, int width, int height, int density,
boolean isMutable, boolean requestPremultiplied,
byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) {
...
mNativePtr = nativeBitmap;
//1.创建 BitmapFinalizer
mFinalizer = new BitmapFinalizer(nativeBitmap);
int nativeAllocationByteCount = (buffer == null ? getByteCount() : 0);
mFinalizer.setNativeAllocationByteCount(nativeAllocationByteCount);
}
private static class BitmapFinalizer {
private long mNativeBitmap;
// Native memory allocated for the duration of the Bitmap,
// if pixel data allocated into native memory, instead of java byte[]
private int mNativeAllocationByteCount;
BitmapFinalizer(long nativeBitmap) {
mNativeBitmap = nativeBitmap;
}
public void setNativeAllocationByteCount(int nativeByteCount) {
if (mNativeAllocationByteCount != 0) {
VMRuntime.getRuntime().registerNativeFree(mNativeAllocationByteCount);
}
mNativeAllocationByteCount = nativeByteCount;
if (mNativeAllocationByteCount != 0) {
VMRuntime.getRuntime().registerNativeAllocation(mNativeAllocationByteCount);
}
}
@Override
public void finalize() {
try {
super.finalize();
} catch (Throwable t) {
// Ignore
} finally {
//2.就是这里了，
setNativeAllocationByteCount(0);
nativeDestructor(mNativeBitmap);
mNativeBitmap = 0;
}
}
} 复制
6.0 之后做了一些变化，BitmapFinalizer 没有了，被NativeAllocationRegistry取代。
例如 8.0 Bitmap构造方法
Bitmap(long nativeBitmap, int width, int height, int density,
boolean isMutable, boolean requestPremultiplied,
byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) {
...
mNativePtr = nativeBitmap;
long nativeSize = NATIVE_ALLOCATION_SIZE + getAllocationByteCount();
// 创建NativeAllocationRegistry这个类，调用registerNativeAllocation 方法
NativeAllocationRegistry registry = new NativeAllocationRegistry(
Bitmap.class.getClassLoader(), nativeGetNativeFinalizer(), nativeSize);
registry.registerNativeAllocation(this, nativeBitmap);
} 复制
不管是BitmapFinalizer 还是NativeAllocationRegistry，目的都是在java层Bitmap被回收的时候，将native层Bitmap对象也回收掉。 一般情况下我们无需手动调用recycle方法，由GC去盘它即可。
Android 8.0 之后Bitmap像素内存放在native堆，Bitmap导致OOM的问题基本不会在8.0以上设备出现了（没有内存泄漏的情况下）
Fresco 的优点是：“在5.0以下(最低2.3)系统，Fresco将图片放到一个特别的内存区域(Ashmem区)” 这个Ashmem区是一块匿名共享内存，Fresco 将Bitmap像素放到共享内存去了，共享内存是属于native堆内存。
4.4以下，Fresco 使用匿名共享内存来保存Bitmap数据，首先将图片数据拷贝到匿名共享内存中，然后使用Fresco自己写的加载Bitmap的方法。
Fresco对不同Android版本使用不同的方式去加载Bitmap，至于4.4-5.0，5.0-8.0，8.0 以上，对应另外三个解码器
ImageView 内存泄露
修改也比较简单粗暴，将ImageView用WeakReference修饰就完事了。
例如在界面退出的时候，我们除了希望ImageView被回收，同时希望加载图片的任务可以取消，队未执行的任务可以移除。
Glide的做法是监听生命周期回调，看 RequestManager 这个类
public void onDestroy() {
targetTracker.onDestroy();
for (Target<?> target : targetTracker.getAll()) {
//清理任务
clear(target);
}
targetTracker.clear();
requestTracker.clearRequests();
lifecycle.removeListener(this);
lifecycle.removeListener(connectivityMonitor);
mainHandler.removeCallbacks(addSelfToLifecycle);
glide.unregisterRequestManager(this);
} 复制
在Activity/fragment 销毁的时候，取消图片加载任务
列表加载问题
图片错乱
由于RecyclerView或者LIstView的复用机制，网络加载图片开始的时候ImageView是第一个item的，加载成功之后ImageView由于复用可能跑到第10个item去了，在第10个item显示第一个item的图片肯定是错的。
常规的做法是给ImageView设置tag，tag一般是图片地址，更新ImageView之前判断tag是否跟url一致。
线程池任务过多
列表滑动，会有很多图片请求，如果是第一次进入，没有缓存，那么队列会有很多任务在等待。所以在请求网络图片之前，需要判断队列中是否已经存在该任务，存在则不加到队列去。