Glide解析-cache

上一篇博客Glide源码解析-概述中介绍了Glide的整体框架，有了整体认识之后，我们再来各个击破，今天介绍的是Glide关于cache的处理。首先我们要带着疑问去看源码，图片是如何做到复用的？图片缓存一共有几级？分别是哪几级？图片是何时被缓存，又是何时被加载的？图片加载是如何优化的，怎么做到大图片不OOM？好了，有了这些问题，看起来就带劲了。

一般缓存模型

既然要理解Glide的缓存模型，那就要先知道一般的缓存模型。

如果直接看模型图不是很清晰的话，可以看下一般的图片请求流程图。

上图简单地介绍了一般的图片加载流程图，需要获取一张网络图片，就先去memory中去获取，如果获取到了，就直接返回，如果获取不到，再去disk中去获取，如果获取到了，就返回，还是获取不到，就去网络中请求过来。从网络中获取到后，将会分别缓存到memory和disk中，方便下次使用。

Glide缓存模型

看了一般的缓存模型，现在来看看Glide的缓存模型

persistent

从上图中可以看出来，Glide在persisitent持久化模块基本是没什么变化，都是从网络获取到图片，然后缓存到disk中。

memory

Glide缓存机制中优化的部分就是memory缓存部分。在Glide中多了一个activeResource缓存。整体的网络图片资源获取过程是这样的：
1.刚开始的时候，active, memory和disk中肯定都是没有数据的，显然是要去网络中获取。
2.从网络中获取到图片后，就把图片保存到disk和active中，然后再把图片显示出来。
3.第二次读取相同图片，并且加载到相同大小的imageview中去时，会先去memory中获取，如果没有，再去active中获取。根据之前的结论，memory任然为空，active中有数据，就把active中数据显示出来。
4.图片加载成功后，这个时候如果所有该图片都被回收（activity执行到了onStop()什么周期），那么这个时候，active中的资源将会被保存到memory中，active中的改资源被回收。
5.此时再次加载该图片，到相同大小imageview中去，根据之前提到的规则，将会从memory中获取到资源，入后再丢入active中，并将memory中的对应资源回收。这个时候资源就又进入到了active中。

根据源码可以看到，activeResources是一个以弱引用资源为value, 的map, memory是使用LruResourceCache实现的。就是activeResources是一个随时有可能被回收资源。它存在的意义在于，memory的强引用的频繁读写也有可能造成内存激增频繁GC, 而造成内存抖动。资源在使用的过程中将会保存在activeResources中，而activeResources是弱引用的，可以随时被系统回收，不会造成内存泄漏和过多的使用。

根据上面讲的，确实对内存抖动问题有很好的帮助。然后它还在很多地方都做了优化：

1. Glide会根据imageView的width和height来加载图片，不管原始图片有多大，都只会加载imageView需要的大小。但是也因为这个，统一原始图片，加载到不同大小的imageView中，需要再次缓存。
2. 图片模式使用的是RGB_565, 这种模式占用的内存比较小。
3. 还可以自己override控制需要加载的图片大小。

这里我没有把源码的执行过程贴出来，因为我觉得，对于分享，理解它的思路是关键，只要有了思路和一些关键字，然后带着问题再去撸源码，就会变得熟悉而轻松。大家源码上有什么问题，可以一起讨论一下。现在再看下最开始定的问题，看有没有解决呢。
整体思路都是从源码中得出的，要是想真正了解Glide, 还是那句话，“read the fucking source code”。