Android 缓存

二级缓存机制：
一级缓存（内存）、二级缓存（磁盘文件）

为什么要缓存

通过对图像的缩放，我们做到了对大图的异步加载优化，但是现在的App不仅是高清大图，更是高清多图，动不动就是图文混排，以图代文，如果这些图片都加载到内存中，必定会OOM。因此，在用户浏览完图像后，应当立即将这些废弃的图像回收，但是，这又带来了另一个问题，也就是当用户在浏览完一次图片后，如果还要返回去再进行重新浏览，那么这些回收掉的图像又要重新进行加载，保不准就要那些无聊到蛋疼的人在那一边看你回收GC，一边看你重新加载。这两件事情，肯定是互相矛盾的，也是影响性能的一个很重要的原因。

内存缓存

针对这样一个非常需要找到一个彼此平衡点的问题，Google提供了一套内存缓存技术。内存缓存技术对那些大量占用应用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache 。这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。LruCache 是在support-v4中才引入的，在引入LruCache 之前，Google建议的是使用软引用或弱引用 (SoftReference or WeakReference)来进行内存缓存。但是从Android 2.3开始，GC算法修改，软引用与弱引用同样会优先被GC回收，所以这种方法也就没有太高的使用价值了，现在网上很多还在继续使用SoftReference 和WeakReference的文章，大多都是过时的文章，建议大家跟上党的步伐，与时俱进。

内存缓存方案

软引用，弱引用加快 - - -不用的对象让GC赶紧回收
Lru算法：期最少使用算法
- - -只保留近期浏览的，太远的抛弃（可以设置保留最近100次）

为什么要使用磁盘缓存

数据更新不需要实时更新，哪怕是3-5分钟的延迟也是可以采用缓存机制。
缓存的过期时间是可以接受的(类似网易的新闻阅读,支持离线离线阅读)

磁盘缓存带来的好处

减小服务器的压力
本地提取数据，提高客户端的响应速度
一定程度上支持离线浏览

磁盘缓存原理/方法

通过时间的设置来判断是否读取缓存还是重新下载；断网直接去缓存即可。

数据库方式

这种方法是在下载完数据文件后，把文件的相关信息如url，路经，下载时间，过期时间等存放到数据库，当然我个人建议把url作为唯一的标识。下次下载的时候根据url先从数据库中查询，如果查询到当前时间并未过期，就根据路径读取本地文件，从而实现缓存的效果。

从实现上我们可以看到这种方法可以灵活存放文件的属性，进而提供了很大的扩展性，可以为其它的功能提供一定的支持。

从操作上需要创建数据库，每次查询数据库，如果过期还需要更新数据库，清理缓存的时候还需要删除数据库数据，稍显麻烦，而数据库操作不当又容易出现一系列的性能，ANR问题，指针错误问题，实现的时候要谨慎，具体作的话，但也只是增加一个工具类或方法的事情。

还有一个问题，缓存的数据库是存放在/data/data//databases/目录下，是占用内存空间的，如果缓存累计，容易浪费内存，需要及时清理缓存。

文件方式

文件缓存方式

这种方法，使用File.lastModified()方法得到文件的最后修改时间，与当前时间判断是否过期，从而实现缓存效果。

实现上只能使用这一个属性，没有为其它的功能提供技术支持的可能。操作上倒是简单，比较时间即可，而且取的数据也就是文件里的JSON数据而已。本身处理也不容易带来其它问题，代价低廉。

文件法缓存方式的两点说明

不同类型的文件的缓存时间不一样。笼统的说，不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。说白点，图片文件内容是不变的，一般存在SD卡上直到被清理，我们是可以永远读取缓存的。配置文件内容是可能更新的，需要设置一个可接受的缓存时间。

不同环境下的缓存时间标准不一样

无网络环境下，我们只能读取缓存文件，为了应用有东西显示，没有什么过期之说了。

WiFi网络环境下，缓存时间可以设置短一点，一是网速较快，而是流量不要钱。

3G流量环境下，缓存时间可以设置长一点，节省流量，就是节省金钱，而且用户体验也更好。

GPS就别说更新什么的，已经够慢的了。缓存时间能多长就多长把。

当然，作为一款好的应用，不会死定一种情况，针对于不同网络变换不同形式的缓存功能是必须有的。而且这个时间根据自己的实际情况来设置：数据的更新频率，数据的重要性等。

何时刷新

开发者一方面希望尽量读取缓存，用户一方面希望实时刷新，但是响应速度越快越好，流量消耗越少越好(关于这块，的确开发中我没怎么想到，毕竟接口就是这么多，现在公司的产品几乎点一下就访问一下，而且还有些鸡肋多余的功能。慢慢修改哈哈)，是一个矛盾。

数据的最长多长时间不变，对应用无大的影响。 比如，你的数据更新时间为4小时，则缓存时间设置为1~2小时比较合适。也就是更新时间/缓存时间=2,但用户个人修改、网站编辑人员等一些人为的更新就另说。一天用户总会看到更新，即便有延迟也好，视你产品的用途了；如果你觉得你是资讯类应用，再减少，2~4小时，如果你觉得数据比较重要或者比较受欢迎，用户会经常把玩，再减少，1~2小时，依次类推。

当然类似这个界面的数据我认为更新时间能多长就多长了，尽可能长。如果你拿后边那个有多少数据会变动来搪塞。我会告诉你：这个只是一个引导性的界面，你有多少款游戏跟用户半毛钱关系都没有，10亿也跟他没关，他只要确定这里能找到他要找的 汤姆猫 就行。否则你又失去了一个用户。

提供刷新按钮。
必要时候或最保险的方法使在相关界面提供一个刷新按钮，或者当下流行的下拉列表刷新方式。为缓存，为加载失败提供一次重新来过的机会。毕竟喝骨头汤的时候，我也不介意碗旁多双筷子。