https://www.jianshu.com/p/89ab4f415bf8
implementation 'com.github.bumptech.glide:glide:3.7.0'
RequestOptions requestOptions =
new RequestOptions()
.centerCrop()
.placeholder(R.mipmap.ic_drawer)
.error(R.mipmap.ic_drawer)
.diskCacheStrategy(DiskCacheStrategy.DATA);
Glide.with(this)
.load(R.mipmap.btn_repeat_shutter_default)
.apply(requestOptions)
.skipMemoryCache(true)
.into(mImageView);
with()方法
从RequestManagerRetriever类中拿到RequestManager对象，RequestManagerRetriever类中有很多get重写方法，传入context、activity、fragment等参数，实际上就是两种，Application类型和非Application类型，Application类型的话Glide并没有做特殊处理，它自动和应用程序的声明周期同步，非Appliction类型会在当前activity中添加一个隐藏的fragment，因为glide没办法知道activity的生命周期，但是fragment的生命周期和activity生命周期是同步的，activity被销毁的话fragment可以监听到，这样glide就可以捕获这个事件并进行相应的生命周期逻辑处理。
load方法
load重写方法很多，可以load String，uri，文件，url，bitmap，drawable，resId,byte[]数组等，会返回一个RequestBuilder对象。
通过asDrawable方法里的as方法new一个RequestBuilder对象。最终调用了RequestBuilder里的loadGeneric方法。
Glide缓存分为内存缓存和硬盘缓存。
内存缓存的主要作用是防止应用重复将图片数据读取到内存当中
而硬盘缓存的主要作用是防止应用重复从网络或其他地方重复下载和读取数据。
Glide内存缓存的实现使用的LruCache算法结合弱引用的机制，共同完成了内存缓存功能
DiskCacheStrategy硬盘缓存策略
DiskCacheStrategy.ALL 缓存原始图片和转换过的图片
DiskCacheStrategy.NONE 不缓存任何内容
DiskCacheStrategy.DATA 在解码之前，将检索到的数据直接写入磁盘缓存（缓存原始图片）
DiskCacheStrategy.RESOURCE 将资源解码后写入磁盘（缓存转换过后的图片）
DiskCacheStrategy.AUTOMATIC 默认模式 智能选择最优策略
图片框架 UIL、Picasso 、Glide、Fresco。
Glide对比其他框架的优缺点
共性：
1.都支持占位图和加载错误图。
2.都支持图像变换，如裁剪，尺寸修改，方向旋转等。
3.可配置度高，图片缓存的内存缓存，本地缓存，线程池，缓存算法等大都可轻松配置。
4.自适应程度高，根据系统性能初始化缓存配置、系统信息变更后动态调整策略。比如根据 CPU 核数确定最大并发数，根据可用内存确定内存缓存大小，网络状态变化时调整最大并发数等。
5.多级缓存，都至少有二级缓存，提高图片的加载速度。
6.支持多种数据源，如本地，网络，Assets等。
7.支持多种Displayer，支持自定义的 Displayer 概念。
8.支持可配置图片格式，如ARGB_8888,RGB_565
此图由上到下数据访问速度在逐层降低。
图片格式
不论采用哪个框架，同一张图片其显示质量取决于图片在内存中的格式，与框架无关
ARGB_8888 >RGB_565 > ARGB_4444 >ALPHA_8
A代表透明度，R 红色 G 绿色 B 蓝色
ARGB_8888 代表像素既有透明度信息，也有颜色信息，其中A占用8bit，R占用8bit，G占用8bit，B占用8bit，一像素大小为8+8+8+8=32bit 相当于4个字节。
RGB_565 代表像素只有颜色信息，没有透明度信息，其中R占用5bit，G占用6bit，B占用5bit，一个像素大小为5+6+5=16bit，即2个byte。
ARGB_4444 代表像素既有透明度信息，也有颜色信息，其中A占用4bit，R占用4bit，G占用4bit，B占用4bit，一像素大小为4+4+4+4=16bit 相当于2个字节。
ALPHA_8 代表像素只有透明度信息，没有颜色信息， 一个像素占8bit 相当于1byte。
ARGB_4444 虽然设计理念是为了保留透明度的同时又节省内存，但由于其显示的图像质量太差而遭到弃用。RGB_565 和 ARGB_8888 是最为通用的两种图片格式，可以按需选取。如果必须保留图片的透明度信息，则建议使用 ARGB_8888， 如果APP 内存吃紧同时对透明度没有要求的话，可使用 RGB_565。
Glide和Fresco采用的是图片格式默认RGB_565,UIL和Picasso采用的是ARGB_8888.
包体积
UIL 和 Picasso 包体积较小，对安装包影响不大。
Glide 包体积略大，其功能十分强大，内部实现及其复杂，其方法数较多，使用时可能会遇到 65k 问题。
Fresco 包体积很大，若按照正确步骤使用了 Fresco，引入后发布包的体积应当不会增加 500Kb。用户可以根据自己需求有选择的添加动画依赖库和 WebP 支持包，这种模块化机制使得基础 Fresco 库很轻，增加一个库大约包体积会增加 100 KB。
生命周期集成
通过设置绑定生命周期，我们可以更加高效的使用Glide提供的方式进行绑定，这样可以更好的让加载图片的请求的生命周期动态管理起来。
如何选择：
UIL：建议弃用。
Picasso：不建议使用，Glide 是 Picasso 的加强版，可以说它的目的就是为了取代 Picasso。
Glide vs Fresco：这两个框架性能不分伯仲，都可以减少 OOM 的发生。Glide 注重于平滑的滚动，善于处理大型的图片流，Glide还支持播放短视频，有此需求的话 Glide 为不二之选，另外 Glide 还有一个隐藏的优点，它是 Google 官方推荐的框架，所以相对于后期维护成本来说更低一些。Fresco 的优点是内存管理，尤其是在 5.0 以下的系统中优化做的非常好，将图片放在 ASM 中。其缺点也很明显，包的体积太大，其在图片多的应用中更能体现其价值。Fresco 对代码的侵入性可能会更高一些，由于所有的View 组件需要继承自一个基类 DraweeView ，需指定明确尺寸或者用 match_parent 来布局（为了更好的用户体验，解决占位图和真实图尺寸大小不匹配导致UI跳跃的问题），如果你是一个新项目，可以考虑用 Fresco。
总结：框架只在Glide 和 Fresco 中选择，Glide 是 Google 官方推荐的框架，是开发者的首选。如果你对包体积没有要求，且图片需求特别多的情况推荐使用 Fresco。
