缓存机制简介
1、缓存的图片资源
原始图片(Source) :即图片源的图片初始大小和分辨率;
转换后的图片(Result) :经过尺寸缩放和大小压缩等处理后的图片;
当使用Glide加载图片时,Glide会默认根据View视图对图片进行压缩和转换,而不显示原始图。(这也是Glide加载速度高于Picasso的原因)
2、缓存机制设计
Glide的缓存功能设计成二级缓存:内存缓存和硬盘缓存。(从网络加载不属于缓存)
内存缓存:防止重复将图片读入到内存,造成内存资源浪费,只缓存转换后的图片,而不是原始图片;
磁盘缓存:防止重复从网络或其他地方下载和读取数据,可缓存原始图片和转换过后的图片,用户自行设置;
在Glide中,缓存的读取顺序为:内存缓存 –> 磁盘缓存 –> 网络 ,内存缓存和磁盘缓存相互不影响,独立配置,内存缓存是默认开启的。
Glide的缓存机制使得Glide具备非常好的图片缓存效果,从而使得具备较高的图片加载效率。
以下是Glide的相关代码:
3、 缓存类型
活动缓存(ActiveResource):存储正在使用的图片;
Lru内存缓存(LruResourceCache):图片解析完成后并最近被加载过会放到内存中;
磁盘缓存-资源类型(DiskCache - Resource):被解码后的图片写入磁盘文件中;
磁盘缓存-原始数据(DiskCache - Data):网络请求成功或在本地获取成功后,将原始数据在磁盘中缓存;
Lru(Least Recently Used):最近最少使用,它的核心思想是,当缓存满的时候,会优先淘汰最近最少使用的缓存对象。
4、内存缓存/运行时缓存
内存缓存/运行时缓存分为两部分:活动缓存(ActiveResource)和Lru内存缓存(LruResourceCache)。
LinkedHashMap继承自HashMap,在此基础上增加了双向链表的结构,每次访问数据的时候,会更新被访问的数据的链表指针。比如说从链表中删除并不是真正的删除数据,只是移动了链表的指针。
Lru内存缓存:使用LinkedHashMap来缓存资源(强引用),并设定一个缓存的大小。如果有资源被访问到,首先会在链表中删除该节点,然后再添加到链表头,这样就可以保证链表头部的节点是最近访问过的。而当缓存的数量达最大值的时候,就会将链表尾部(最近最少使用)的数据移除。
但是这样做有一个风险,就是容易将正在使用的资源回收掉。
Glide这样设计:从内存缓存(LruResourceCache)中拿到资源时候就主动添加到活动缓存(ActiveResource)中,并清理Lru内存缓存(LruResourceCache)中的资源,这样做的好处就是是保护正在使用资源不被Lru算法回收掉。
ActiveResources是一个弱引用的HashMap,用来缓存正在使用的图片,保存这个图片不会被Lru算法回收掉。图片用完之后会重新添加到Lru内存缓存中。
ActiveResources和LruResourceCache是内存缓存,属于运行时缓存且互斥(同一张图片不会同时缓存在ActiveResources和LruResourceCache中),应用被杀死后内存缓存将不存在。
5、 磁盘缓存
磁盘缓存策略:
DiskCacheStrategy.NONE:表示不缓存任何内容;
DiskCacheStrategy.RESOURCE:在资源解码后将数据写入磁盘缓存,即经过缩放等转换后的图片资源;
DiskCacheStrategy.DATA:在资源解码前将原始数据写入磁盘缓存;
DiskCacheStrategy.ALL :使用DATA和RESOURCE缓存数据;
DiskCacheStrategy.AUTOMATIC:它会尝试对本地和远程图片使用最佳的策略。当加载远程数据时,AUTOMATIC 策略仅会存储未被加载过程修改过的原始数据,因为下载远程数据相比调整磁盘上已经存在的数据要昂贵得多。对于本地数据,AUTOMATIC 策略则会仅存储变换过的缩略图,因为即使需要再次生成另一个尺寸或类型的图片,取回原始数据也很容易。默认使用这种缓存策略;
在使用Glide去加载一张图片的时候,Glide默认不会将原始图片展示出来,而是会对图片进行压缩和转换。我们既可以缓存转换过的图片,也可以缓存转换之前的原始图片。
采用LRU算法的缓存有两种:LruCache和DisLruCache,分别用于实现内粗缓存和硬盘缓存