客户端缓存

   基础知识

        1) 什么是”Last-Modified”? 

        在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样： 

        Last-Modified: Fri, 12 May 2006 18:53:33 GMT 

        客户端第二次请求此URL时，根据 HTTP 协议的规定，浏览器会向服务器传送 If-Modified-Since 报头，询问该时间之后文件是否有被修改过： 

        If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT 

        如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。 

        2) 什么是”Etag”? 

        HTTP 协议规格说明定义ETag为“被请求变量的实体值” （参见 —— 章节 14.19）。 另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式： 

        ETag: "50b1c1d4f775c61:df3" 

        客户端的查询更新格式是这样的： 

        If-None-Match: W/"50b1c1d4f775c61:df3" 

        如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。本人测试Etag主要在断点下载时比较有用。
        

      

二、数据库法缓存管理
这种方法是在下载完数据文件后，把文件的相关信息如url，路经，下载时间，过期时间等存放到数据库，下次下载的时候根据url先从数据库中查询，如果查询到当前时间并未过期，就根据路径读取本地文件，从而实现缓存的效果。
从实现上我们可以看到这种方法可以灵活存放文件的属性，进而提供了很大的扩展性，可以为其它的功能提供一定的支持；
从操作上需要创建数据库，每次查询数据库，如果过期还需要更新数据库，清理缓存的时候还需要删除数据库数据，稍显麻烦，而数据库操作不当又容易出现一系列的性能，ANR问题，实现的时候要谨慎，具体作的话，但也只是增加一个工具类或方法的事情。
还有一个问题，缓存的数据库是存放在/data/data/<package>/databases/目录下，是占用内存空间的，如果缓存累计，容易浪费内存，需要及时清理缓存。
当然这种方法从目前一些应用的实用上看，我没有发现什么问题。
本文我侧重强调第二种方法，第一种方法的实现，就此掠过。 

三、文件法缓存管理
这种方法，使用File.lastModified()方法得到文件的最后修改时间，与当前时间判断是否过期，从而实现缓存效果。
实现上只能使用这一个属性，没有为其它的功能提供技术支持的可能。
操作上倒是简单，比较时间即可。本身处理也不容易带来其它问题，代价低廉。

四、文件法缓存管理的两点说明
1. 不同类型的文件的缓存时间不一样。
笼统的说，不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。
说白点，图片文件内容是不变的，直到清理，我们是可以永远读取缓存的。
配置文件内容是可能更新的，需要设置一个可接受的缓存时间。
2. 不同环境下的缓存时间标准不一样。
无网络环境下，我们只能读取缓存文件，哪怕缓存早就过期。
WiFi网络环境下，缓存时间可以设置短一点，一是网速较快，而是流量不要钱。
移动数据流量环境下，缓存时间可以设置长一点，节省流量，就是节省金钱，而且用户体验也更好。
举个例子吧，最近本人在做的一个应用在wifi环境下的缓存时间设置为5分钟，移动数据流量下的缓存时间设置为1小时。
这个时间根据自己的实际情况来设置：数据的更新频率，数据的重要性等。

五、何时刷新
开发者一方面希望尽量读取缓存，用户一方面希望实时刷新，但是响应速度越快越好，流量消耗越少越好，是一个矛盾。
其实何时刷新我也不知道，这里我提供两点建议：
1. 数据的最长多长时间不变，对应用无大的影响。
比如，你的数据更新时间为1天，则缓存时间设置为4~8小时比较合适，一天他总会看到更新，如果你觉得你是资讯类应用，再减少，2~4小时，如果你觉得数据比较重要或者比较受欢迎，用户会经常把玩，再减少，1~2小时，依次类推。
为了保险起见，你可能需要毫无理由的再次缩减一下。
2. 提供刷新按钮。
上面说的保险起见不一定保险，最保险的方法使在相关界面提供一个刷新按钮，为缓存，为加载失败提供一次重新来过的机会，有了这个刷新按钮，我们的心也才真的放下来。

应用程序在运行的过程中如果需要向手机上保存数据，一般是把数据保存在SDcard中的。

大部分应用是直接在SDCard的根目录下创建一个文件夹，然后把数据保存在该文件夹中。
这样当该应用被卸载后，这些数据还保留在SDCard中，留下了垃圾数据。
如果你想让你的应用被卸载后，与该应用相关的数据也清除掉，该怎么办呢？

通过Context.getExternalFilesDir()方法可以获取到 SDCard/Android/data/你的应用的包名/files/ 目录，一般放一些长时间保存的数据
通过Context.getExternalCacheDir()方法可以获取到 SDCard/Android/data/你的应用包名/cache/目录，一般存放临时缓存数据

如果使用上面的方法，当你的应用在被用户卸载后，SDCard/Android/data/你的应用的包名/ 这个目录下的所有文件都会被删除，不会留下垃圾信息。

而且上面二个目录分别对应 设置->应用->应用详情里面的”清除数据“与”清除缓存“选项

原文地址：http://www.eoeandroid.com/forum.php?mod=viewthread&tid=273674&page=1#pid2695014

总结一下android 中的几种目录：

1、通过Context.getExternalFilesDir()方法可以获取到 SDCard/Android/data/你的应用的包名/files/ 目录，一般放一些长时间保存的数据
通过Context.getExternalCacheDir()方法可以获取到 SDCard/Android/data/你的应用包名/cache/目录，一般存放临时缓存数据

2、Context.getFilesDir()可以获取到"/data/data/<package name>/files" 这个方法获取的目录不是在sdcard上，而是在应用安装的目录

Context.getCacheDir可以获取到"/data/data/<package name>/cache" 这个方法获取的目录不是在sdcard上，而是在应用安装的目录，这个文件里面的数据在设备内存不足的时候，会被系统删除数据。注意：你不能依赖系统帮你删除这些文件，当这个文件夹里面的数据超过1MB的时候，系统会删除这个文件夹里面的数据。