Android Glide数据更新及内存缓存、硬盘缓存清理

[转] 原文 

 

                                        Android Glide数据更新及内存缓存、硬盘缓存清理

Android的Glide在加载图片时候内部默认使用了缓存机制，Glide的缓存机制分为两级，第一级是内存缓存，而后第二级是硬盘缓存。缓存的过程首先是在内存中缓存，而后将加载的图片资源缓存到硬盘，这样就能够在随后的再次加载中使用缓存了，Glide使用缓存时候首先要检查内存这一层级是否缓存了相应的缓存，若是有，则直接使用，若是没有，则深刻到硬盘缓存中检查是否有，若是有，则加载之，若是到这一步骤尚未，那么就只能做为一个全新的资源加载了。
从这个过程当中，Glide使用缓存无疑大大提升了上层代码的性能，可是，有些状况下，这种缓存策略则可能并不适用。好比，APP中有一个头像，该头像是从一个固定连接http://xxx.xxx.jpg读取，假设代码第一次读取后，缓存到了本地。然而，几分钟后该图片更新了，可是连接仍然是http://xxx.xxx.jpg。随后，假设，三小时或三天或三十天后一样的连接http://xxx.xxx.jpg读取，此时Glide加载时候检查缓存，发现针对http://xxx.xxx.jpg的资源已经缓存，那么Glide再也不从服务器读取，而是直接加载本地缓存使用，这样就形成了Glide加载出来的图片资源不是最新的。
总结：Glide的缓存机制虽然提高了性能，可是若是针对固定资源路径的请求，将致使请求获得的资源是缓存的，这样就不能保证最新。换句话说，若是给定资源地址下的资源的频繁更新的，而资源地址是固定，则Glide此时的缓存策略就显得不太合适。
致使这种问题的缘由有二：
一， Glide自己使用了缓存。
二， Glide在缓存资源使用<K,V>键值对模型，若是每次都使用http://xxx.xxx.jpg这个URL，那么键相同，意味着Glide匹配键时候，永远能够从缓存中返回键对应的值。

针对这个问题的解决方案：
解决方案1：
从Glide提供的缓存键值对<K,V>结构模型入手，重写缓存的<K,V>键值策略，就能够避免相同资源地址下资源更新问题了，可是这种方案实现比较复杂，也无十分必要。不推荐，除非必需。

解决方案2：
Glide.get(this).clearMemory();
清理内存中的缓存。

Glide.get(this).clearDiskCache();
清理硬盘中的缓存。

以上两个方法清除全局的内存缓存和硬盘缓存，虽然能够一劳永逸的解决缓存致使的资源陈旧问题，可是将严重影响全局性能，因此慎用，除非是在APP总体要作全新的开始或者恢复原始状态，不然尽可能避免使用。

解决方案3（推荐）：
代码形如：

[java]  view plain  copy

1. ImageView image= (ImageView) findViewById(R.id.image);  
2.         Glide.with(this).load("http://avatar.csdn.net/9/7/A/1_zhangphil.jpg")  
3.                 .skipMemoryCache(true)  
4.                 .diskCacheStrategy(DiskCacheStrategy.NONE)  
5.                 .into(image);  

关键代码：skipMemoryCache(true).diskCacheStrategy(DiskCacheStrategy.NONE)
skipMemoryCache(true) ，跳过内存缓存。
diskCacheStrategy(DiskCacheStrategy.NONE) ，不要在disk硬盘中缓存。

这两个函数同时联合使用，使得Glide针对这一次的资源加载放弃内存缓存和硬盘缓存，至关于一次全新的请求。这样就迫使Glide从给定的资源地址发起全新的数据加载，而非从旧有的缓存中取缓存使用。

附录：
1，《Android图片加载与缓存开源框架：Android Glide》连接：http://blog.csdn.net/zhangphil/article/details/45535693 
2，《Android Glide加载图片时转换为圆形、圆角、毛玻璃等图片效果》连接：http://blog.csdn.net/zhangphil/article/details/52806374