Android 中图片的三级缓存及Glide缓存机制

什么是三级缓存？

• 内存缓存，优先加载，速度最快
• 本地缓存，次优先加载，速度快
• 网络缓存，最后加载，速度慢，浪费流量

为什么要进行三级缓存

三级缓存策略，最实在的意义就是减少不必要的流量消耗，增加加载速度。

如今的 APP 网络交互似乎已经必不可少，通过网络获取图片再正常不过了。但是，每次启动应用都要从网络获取图片，或者是想重复浏览一些图片的时候，每次浏览都需要网络获取，消耗的流量就多了，在如今的流量资费来说，肯定会容易影响用户数量。

还有就是网络加载图片，有时候会加载很慢，影响了用户体验。

另外从开发角度来说，Bitmap 的创建非常消耗时间和内存，可能导致频繁GC。而使用缓存策略，会更加高效地加载 Bitmap，减少卡顿，从而减少读取时间。

而内存缓存的主要作用是防止应用重复将图片数据读取到内存当中，硬盘缓存则是防止应用重复从网络或其他地方重复下载和读取数据。

三级缓存的原理

• 首次加载的时候通过网络加载，获取图片，然后保存到内存和 SD 卡中。

• 之后运行 APP 时，优先访问内存中的图片缓存。

• 如果内存没有，则加载本地 SD 卡中的图片。

具体的缓存策略可以是这样的：内存作为一级缓存，本地作为二级缓存，网络加载为最后。其中，内存使用 LruCache ，其内部通过 LinkedhashMap 来持有外界缓存对象的强引用；对于本地缓存，使用 DiskLruCache。加载图片的时候，首先使用 LRU 方式进行寻找，找不到指定内容，按照三级缓存的方式，进行本地搜索，还没有就网络加载。

关于Glide的缓存

事实上，现在已经很少自己封装一个三级缓存策略，在众多的图片框架中都加入缓存策略，实现起来更简单。这里以 Glide 为例。

Glide 的使用基本就是一行代码就解决了。像下面这样

// 加载本地图片
File file = new File(getExternalCacheDir() + "/image.jpg");
Glide.with(this).load(file).into(imageView);

// 加载应用资源
int resource = R.drawable.image;
Glide.with(this).load(resource).into(imageView);

// 加载二进制流
byte[] image = getImageBytes();
Glide.with(this).load(image).into(imageView);

// 加载Uri对象
Uri imageUri = getImageUri();
Glide.with(this).load(imageUri).into(imageView);

当然应用到项目里面最好二次封装一下。这些不是这次文章的主题。我们回到缓存上面来。

Glide 的内存缓存

Glide 是默认开启了内存缓存的，只要你通过 Glide 加载一张图片，他就会缓存到内存中，只要他还没被从内存中清理之前，下次使用 Glide 都会从内存缓存中加载。大大提升了图片加载的效率。

当然如果你有特殊要求，可以添加一行代码把默认开启的内存缓存关闭掉。

Glide.with(this)
     .load(url)
     .skipMemoryCache(true)//关闭内存缓存
     .into(imageView);

Glide 的内存缓存实际上和我们上面说的差别不大，使用的也是LruCache算法，不过他还结合了一种弱引用机制，共同完成了内存缓存功能。

详情可以看文末参考文章郭霖大神关于Glide源码的解析。

Glide 的硬盘缓存

关于 Glide 硬盘缓存使用也是十分简单。

Glide.with(this)
     .load(url)
     .diskCacheStrategy(DiskCacheStrategy.RESULT)
     .into(imageView);

一个 diskCacheStrategy( ) 方法就可以调整他的硬盘缓存策略。其中可以传入的参数有四种：

• DiskCacheStrategy.NONE： 表示不缓存任何内容。
• DiskCacheStrategy.SOURCE： 表示只缓存原始图片。
• DiskCacheStrategy.RESULT： 表示只缓存转换过后的图片（默认选项）。
• DiskCacheStrategy.ALL ： 表示既缓存原始图片，也缓存转换过后的图片。

Glide 的硬盘缓存是默认将图片压缩转换后再缓存到硬盘中，这种处理方式再避免OOM的时候会经常看见。

如果需要改变硬盘缓存策略只需要改变其传入的参数即可。

由于工作中经常要处理图片的加载缓存的问题，所以需要理清系统缓存的问题，否则经常会出现OOM问题。防止多图OOM的解决技术是使用LruCache和DiskLruCache两种技术。

• 一 LruCache内存缓存

在Android中，这个LruCache类专门用做图片缓存处理的。当缓存的图片达到预先设置的值得时候，那么近期使用次数最少的图片就会被回收掉。

有些人可能还会使用软引用这种方式。所谓“软引用”就是只要有足够的内存，就一直保持对象，知道发现内存吃紧且没有Strong Ref时才回收对象。但是现在已经不再推荐使用这种方式了，因为从Android2.3开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得更加不可靠。另外，Android3.0中，图片的数据会存储在本地的内存中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并奔溃。

如何使用LruCache呢？可以参考http://blog.csdn.net/gf771115/article/details/30269159文档。

• 二 DiskLruCache硬盘缓存

LruCache只是管理了内存中图片的存储与释放，如果图片从内存中被移除，那么又要重新加载一次图片，这样就会非常耗时。对此，google又提供了一套硬盘缓存的方案——disklrucache。

在我们经常看到的应用，例如网易新闻、Twitter等，都是使用这种技术。可以查看客户端的包名，找到缓存地址，

会发现有一个名字为journal的文件，这个文件时disklrucache的一个日志文件，看到这个文件就说明改程序使用了这种技术。disklrucache中使用了一个redundantopcount变量来记录用户的操作次数，没执行一次写入、读取或移除缓存的操作，这个变量值都会加1，当变量值达到2000的时候就会触发重构journal的事件，这是会自动把journal中的一些多余的、不必要的记录全部清除掉，保证journal文件大小始终保持在一个合理的范围内。