自从Android诞生以来，Bitmap的管理就一直是大问题，为了更好的管理它，不同的图片加载框架不断的被推出，从刚开始的ImageLoader，到Picasso，再到现在的Fresco和Glide，可谓百花齐放。然而前两者现在都已经不再维护了，同时我们公司的项目目前也已经从Fresco切换到Glide了，之前之所以用Fresco是因为他在Android5.0以下系统中能从native层“偷”内存，但后面由于Android对于Bitmap内存管理方式的改变，这个功能不再生效，相比于Glide来说，Fresco就显得侵入性太强，而且可扩展性没有glide强。而Glide之所以扩展性如此强，就在于它 优秀的架构设计 ，这也是我们今天要讨论的。
1. 总体架构
首先我们看下Glide总体架构图：
从架构图上，我们可以看出，glide并没有着眼于bitmap，而是进行了高度的抽象，所以我们不应该将glide看成一个图片加载框架，而是一个资源从不同形态之间转换的框架，从url到bitmap只是其中一种，所以我们不难理解glide甚至能从视频加载第一帧，因为它没有对输入类型做任何限制，都是统一抽象成的Request。
2. 从Request到Data的设计——资源加载模块设计
首先我们看下总体过程：
这里以从url到inputstream二进制流为例，之所以这里有三条分路，这和glide的缓存策略有关。首先有一点要澄清，这里从Request到Data其实是跳过了内存缓存的介绍，毕竟如果内存中已有bitmap缓存，我们直接取用就可以了，无需这么麻烦（详细的缓存方案后续文章会介绍）。因此，这里有三条路径主要是磁盘缓存和网络缓存，而磁盘缓存有两种：
- DataCache 从原始Request加载到的二进制流直接缓存，比如从url加载的原图缓存
- ResourceCache 将从Request获取的Data数据处理后缓存，比如将一个url的原图进行压缩后又缓存起来，glide能够缓存不同尺寸的图片的原因就在于这一步。
而SourceGenerator就是跳过缓存直接从原始Request获取请求了。
2.1 Request是如何被加载的
由于glide的这种高度抽象，现在我们面临着一个问题：如此多类型的Request和如此多的Data，具体怎么去加载它呢？比如说Request有url、uri、File、资源id、视频等等，不同的Request肯定有不同的加载方式,同一个Request既可能从网络加载，也可能从磁盘加载，可能性太多，那么我们怎么去加载呢？if-else去判断吗？ 一个优秀的框架肯定不会干这种low到爆的事。这里我们介绍一些新的角色：
这里，针对每一种Request，我们都有对应的ModelLoader,当一个Request进来时，我们可以遍历所有的ModelLoader,通过handles()方法判断这个ModelLoader能否处理这种Request，这样我们就能解决第一个问题，即不同的Request如何管理加载，有了ModelLoader机制，如果我们想增加一种Request，我们只要开发对应的ModelLoader即可。
有了ModelLoader，其实是不够的，它只是用来判断这个Request是否能否处理，为了能真正的加载请求，Glide引入了DataFetcher,不同的方式对应一个不同的DataFetcher，两者职责分离，这是因为同一种Request其实有很多加载方式，比如从网络加载，从磁盘加载等等，非常复杂，所以这里独立出一个DataFetcher。其中LoadData只是对DataFetcher的一种包装，多包含了一些信息而已。
2.2 小结
现在，我们根据传入的请求具体类型（比如url还是file还是字节数组），通过遍历所有的ModelLoader判断该ModelLoader能否处理这种请求，然后用该ModelLoader中的DataFetcher去具体加载这个请求。
3. 从Data到Resource的设计——解码和转码模块设计
有了ModelLoader和DataFetcher机制，Glide已经能方便的将一个原始请求从不同的地方加载到内存中了，这个时候这份数据还只是单纯的二进制数据（携带了格式数据）而已，我们称其为Data，现在需要进行解码过程，剔除原始的格式信息，然后拿原始信息重新编码，将其转化成不同的格式，比如将一个jpg先解码然后转码成Bitmap，或者转码成Gif，解码以及转码后的数据我们称其为Resource。现在面临的问题还是一样的：
由于框架的设计决定了需要解码的格式是不定的，要转码的格式也是不定的，如何高效的组织这个过程呢？
这个和Request被加载的过程类似，这里采用的是模板方法设计模式：
可以看到，这里我们能从Registry中获取所有的ResourceDecoder和ResourceTranscoder，然后判断哪个解码器或转码器适合当前格式，直接调用相关的decode和transcode方法就可以了。
以这种方式，我们能随意扩展不同格式的解码和转码了。
4. 从Resource到Resource的设计——资源变换操作
资源解码并转码后，由于某些特殊的需求，我们是不能直接使用的，比如有圆角需求，透明度需求等等，完成这步转换的，就是Transformation。由于这一步转换是可选的，和上面两步都不同必须进过的步骤不同，这里的Transformation就不能存在一个地方主动去取，必须是得构建这整个流程的时候指定使用哪个Transformation，这里没有什么复杂的架构，大家了解下Transformation的大致情况即可：
5. 从Resource到显示在Target上的设计——资源显示操作
现在我们走到了最后一步，需要将符合条件的Resource显示在指定的Target上，当然具体如何显示细节本文不讨论，我们主要关注的是显示时候的动画操作，也就是经过Transition的 transition()。这一步和上面一步类似，是否需要使用Transition和使用哪个Transition都是由请求时用户决定的，因此这里也没有复杂架构，大家看下Transition的组成即可：
6. 总结
其实从总体架构上来说，Glide的设计无疑是非常完美的，每一个步骤都是面对接口编程，可以随意新增或修改其中的某一步，扩展性非常强，这虽然让架构变的更加复杂，但这点代价是值得的。以这个架构来说，只要Android不死，Glide都能一直用下去。
最后，本文只是简单的给大家一个Glide的大致流程，每个流程是怎么回事，让大家有个概念，甚至连最复杂的缓存都没提到，更不用说每一步的具体流程了，针对这些，我将会继续写一系列的文章，希望能将Glide说清楚。最后的最后，文章都是我个人的理解，如果有错误，恳请大家指正！
