缓存管理的适用环境：
1. 提供网络服务的应用
2. 数据更新不需要实时更新，哪怕是3-5分钟的延迟也是可以采用缓存机制。
3. 缓存的过期时间是可以接受的(类似网易的新闻阅读,支持离线离线阅读)
这样所带来的好处：
1. 减小服务器的压力
2. 提高客户端的响应速度(本地数据提取嘛)
3. 一定程度上支持离线浏览(可以参考网易的那个新闻应用,个人感觉离线阅读做得非常棒。)
一、缓存管理的方法
缓存管理的原理很简：通过时间的设置来判断是否读取缓存还是重新下载；断网下就没什么好说的，直接去缓存即可。如图：
里面会有一些细节的处理，后面会详细阐述。基于这个原理，目前个人用过的两种比较常见的缓存管理方法是:数据库和文件(txt)。
二、数据库(SQLite)缓存方式
这种方法是在下载完数据文件后，把文件的相关信息如url，路经，下载时间，过期时间等存放到数据库，当然我个人建议把url作为唯一的标识。下次下载的时候根据url先从数据库中查询，如果查询到当前时间并未过期，就根据路径读取本地文件，从而实现缓存的效果。
从实现上我们可以看到这种方法可以灵活存放文件的属性，进而提供了很大的扩展性，可以为其它的功能提供一定的支持。
从操作上需要创建数据库，每次查询数据库，如果过期还需要更新数据库，清理缓存的时候还需要删除数据库数据，稍显麻烦，而数据库操作不当又容易出现一系列的性能，ANR问题，指针错误问题，实现的时候要谨慎，具体作的话，但也只是增加一个工具类或方法的事情。
还有一个问题，缓存的数据库是存放在/data/data/<package>/databases/目录下，是占用内存空间的，如果缓存累计，容易浪费内存，需要及时清理缓存。
当然这种方法从目前一些应用的实用上看，我没有发现什么问题,估计使用的量还比较少吧。
本文本人不太喜欢数据库，原因操作麻烦，尤其是要自己写建表那些语句，你懂的。我侧重文件缓存方式。
三、文件缓存方式
这种方法，使用File.lastModified()方法得到文件的最后修改时间，与当前时间判断是否过期，从而实现缓存效果。
实现上只能使用这一个属性，没有为其它的功能提供技术支持的可能。操作上倒是简单，比较时间即可，而且取的数据也就是文件里的JSON数据而已。本身处理也不容易带来其它问题，代价低廉。
四、文件法缓存方式的两点说明
1. 不同类型的文件的缓存时间不一样。
笼统的说，不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。说白点，图片文件内容是不变的，一般存在SD卡上直到被清理，我们是可以永远读取缓存的。配置文件内容是可能更新的，需要设置一个可接受的缓存时间。
2. 不同环境下的缓存时间标准不一样。
无网络环境下，我们只能读取缓存文件，为了应用有东西显示，没有什么过期之说了。
WiFi网络环境下，缓存时间可以设置短一点，一是网速较快，而是流量不要钱。
3G流量环境下，缓存时间可以设置长一点，节省流量，就是节省金钱，而且用户体验也更好。
GPS就别说更新什么的，已经够慢的了。缓存时间能多长就多长把。
当然，作为一款好的应用，不会死定一种情况，针对于不同网络变换不同形式的缓存功能是必须有的。而且这个时间根据自己的实际情况来设置：数据的更新频率，数据的重要性等。
五、何时刷新
开发者一方面希望尽量读取缓存，用户一方面希望实时刷新，但是响应速度越快越好，流量消耗越少越好(关于这块，的确开发中我没怎么想到，毕竟接口就是这么多，现在公司的产品几乎点一下就访问一下，而且还有些鸡肋多余的功能。慢慢修改哈哈)，是一个矛盾。
其实何时刷新我也不知道，这里我提供两点建议：
1. 数据的最长多长时间不变，对应用无大的影响。
比如，你的数据更新时间为4小时，则缓存时间设置为1~2小时比较合适。也就是更新时间/缓存时间=2,但用户个人修改、网站编辑人员等一些人为的更新就另说。一天用户总会看到更新，即便有延迟也好，视你产品的用途了；如果你觉得你是资讯类应用，再减少，2~4小时，如果你觉得数据比较重要或者比较受欢迎，用户会经常把玩，再减少，1~2小时，依次类推。
当然类似这个界面的数据我认为更新时间能多长就多长了，尽可能长。如果你拿后边那个有多少数据会变动来搪塞。我会告诉你：这个只是一个引导性的界面，你有多少款游戏跟用户半毛钱关系都没有，10亿也跟他没关，他只要确定这里能找到他要找的 汤姆猫 就行。否则你又失去了一个用户。
2. 提供刷新按钮。
必要时候或最保险的方法使在相关界面提供一个刷新按钮，或者当下流行的下拉列表刷新方式。为缓存，为加载失败提供一次重新来过的机会。毕竟喝骨头汤的时候，我也不介意碗旁多双筷子。
总而言之，一切用户至上，为了更好的用户体验，方法也会层出不穷。期待更好的办法
