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”。

©️2020 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值