框架
每学习一个新东西，如果能从整体架构上有一个清晰的掌握，势必事半功倍，这也是我一直所推崇的。但是很多时候大家忽略了这个重要的步骤，希望这篇文章能给大家一些帮助，少走一些弯路。
我们先来看一个标准的Glide使用：
Glide.with(activity)
.load("https://www.baidu.com/img/bd_logo1.png")
.apply(RequestOptions.placeholderOf(R.drawable.ic_launcher_background))
.thumbnail(0.5f)
.into(imageView);
上框架图：
解析
Glide框架很简单，主要组件和大致流程与普通的图片加载类似，比较容易理解。
框架主要包括七个部分：
Registry
注册器，注册了Glide所支持的所有ModelLoader、Decoder、Encoder和Transcoder，是所有具体功能实现的核心组件。如果想要自定义一些ModelLoader和Decoder等，需要注册在Registry里面。值得一提的是，对于同一种数据，ModelLoader、Decoder和Transcoder等并不是唯一的，或许同时存在多种实现方式，这个时候注册的顺序就是优先级，会按照注册顺序依次调用，直到成功。
Request
请求，也是我们接触最多的一部分，如果不想要深入了解Glide的实现原理，只是想应用的话，把这部分搞明白就足够了。实际上，我们平时所用的Glide语句，除了with()方法外，其他的都是在构造Request。Request封装了请求的所有选项和参数，以及目标target。
Engine
Engine是所有Job的管理类，Request交付给Engine并以EngineJob来实现。Engine持有一级和二级缓存和所有的EngineJob，当一二级缓存没有获取到资源时，会以EngineJob结合DecodeJob继续获取数据。
Job
这里的Job包含EngineJob和DecodeJob，EngineJob负责管理DecodeJob，DecodeJob是具体加载功能实现的实体，主要有加载、解码、转换和转码四种操作，是数据加载的核心。DecodeJob继承与Runnable，运行在线程池，并且与三四五级缓存交互。这里有一点需要注意，三四五级缓存拿到的数据，并不是可以直接显示在图片上的数据，需要继续经过加载、解码、转码等操作。
Target
最终资源的接收方，主要有两种，一种是ViewTarget，内部一般持有ImageView，会将收到的数据显示在Imageview上，另一种是SimpleTarget，一般不持有具体的view，更关注拿到的数据，比如PreloadTarget。
缓存
Glide的缓存很值得称道，分成五级，虽然本质上还是内存+硬盘+远程的模式，但是细分了不同的功能，并且强大的多。五级缓存的关系如下图所示：
Lifecycle
Glide的生命周期管理实现的特别巧妙，有application生命周期和activity/fragment生命周期两种模式，这里关注activity/fragment生命周期模式。实现的原理是在当前的activity或fragment加入一个隐藏的RequestManagerFragment，它会监听当前activity或fragment的生命周期，并调用Request和Target的相关函数，实现生命周期的管理。
