框架

每学习一个新东西，如果能从整体架构上有一个清晰的掌握，势必事半功倍，这也是我一直所推崇的。但是很多时候大家忽略了这个重要的步骤，希望这篇文章能给大家一些帮助，少走一些弯路。

我们先来看一个标准的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);

上框架图：

框架.png

解析

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的缓存很值得称道，分成五级，虽然本质上还是内存+硬盘+远程的模式，但是细分了不同的功能，并且强大的多。五级缓存的关系如下图所示：

缓存.png

Lifecycle

Glide的生命周期管理实现的特别巧妙，有application生命周期和activity/fragment生命周期两种模式，这里关注activity/fragment生命周期模式。实现的原理是在当前的activity或fragment加入一个隐藏的RequestManagerFragment，它会监听当前activity或fragment的生命周期，并调用Request和Target的相关函数，实现生命周期的管理。