图片加载框架Glide

为什么要用Glide

1. 链式调用，兼容系统控件imageView，使用非常简单。不必像Fresco那样得用SimpleDrawableView

  Glide.with(this)
            .load(data.teacher_image)
            .placeholder(R.drawable.recommend_teacher_icon)
            .error(R.drawable.recommend_teacher_icon)
            .apply(RequestOptions.circleCropTransform())
            .diskCacheStrategy(DiskCacheStrategy.ALL)
            .into(ivTIcon)

2. 可以感知activity和fragment的生命周期做图片加载的控制。
   实现原理:通过 Glide.with(this)函数，传入当前的context对象。进行相应的判断转化，拿到当前fragmentManager。然后RequestManagerRetriever创建出来一个没有布局的fragment，并且把RequestManager和ActivityFragmentLifecycle相关联，实现生命周期的监控和图片网络请求的处理，防止内存泄露。
3. 通过DefaultConnectivityMonitor注册网络变化广播感知网络变化监听，RequestManager处理图片请求。
4. 采用内存缓存和磁盘缓存减少流量消耗，加快响应速度。
5. 内存缓存，采用Lrucache算法，防止存储的内存过大，OOM。

假如让你实现个图片加载框架，会考虑哪些问题

1. 图片网络请求，异步加载，需要线程池
2. 切换到主线程更新UI：Handler
3. 缓存：LruCache
4. 防止OOM: 软引用(map) ， LruCache， 图片压缩处理（按比例压缩inSampleSize,压缩图片质量，RGB-565）
5. 防止内存泄露，通过对生命周期的管理
6. 列表滑动加载问题 （通过给imageView设置tag,防止图片错乱）

LruCache小结

• LruCache 内部用LinkHashMap存取数据，设置的accessOrder为true,即按照访问顺序排序。添加和删除元素不影响迭代顺序，获取元素会导致重新排序，获取到的元素排到队尾。当容量达到上限时，删除最近最少使用的元素也就是队列头部的元素。

代码示例：

//put和remove元素后不影响迭代顺序
Map<Integer, String> linkedHashMap = new LinkedHashMap<Integer, String>(16, 0.75f, true);
linkedHashMap.put(3, "order3");
linkedHashMap.put(1, "order1");
linkedHashMap.put(2, "order2");

linkedHashMap.get(3); //此时顺序为 1->2->3
linkedHashMap.remove(1);//此时顺序为 2->3
linkedHashMap.put(4, "order4");//此时顺序为 2->3->4

linkedHashMap.forEach((key, value) -> System.out.println(key + "-->" + value));
输出结果：
2-->order2
3-->order3
4-->order4

参考文章

1. 图解LinkedHashMap原理
2. LinkedHashMap解析
3. 面试官：简历上最好不要写Glide，不是问源码那么简单