Android缓存：
採用缓存，能够进一步大大缓解数据交互的压力，又能提供一定的离线浏览。下边我简略列举一下缓存管理的适用环境：
1. 提供网络服务的应用
2. 数据更新不须要实时更新。哪怕是3-5分钟的延迟也是能够採用缓存机制。
3. 缓存的过期时间是能够接受的(类似网易的新闻阅读,支持离线离线阅读)
这样所带来的优点：
1. 减小server的压力
2. 提高client的响应速度(本地数据提取嘛)
3. 一定程度上支持离线浏览(能够參考网易的那个新闻应用,个人感觉离线阅读做得很棒。
)
一、缓存管理的方法
缓存管理的原理非常简：通过时间的设置来推断是否读取缓存还是又一次下载；断网下就没什么好说的，直接去缓存就可以。如图：
里面会有一些细节的处理。后面会具体阐述。
基于这个原理，眼下个人用过的两种比較常见的缓存管理方法是:数据库和文件(txt)。
这样的方法是在下载完数据文件后。把文件的相关信息如url，路经，下载时间。过期时间等存放到数据库，当然我个人建议把url作为唯一的标识。下次下载的时候依据url先从数据库中查询，假设查询到当前时间并未过期。就依据路径读取本地文件，从而实现缓存的效果。
从实现上我们能够看到这样的方法能够灵活存放文件的属性，进而提供了非常大的扩展性，能够为其他的功能提供一定的支持。
从操作上须要创建数据库。每次查询数据库，假设过期还须要更新数据库，清理缓存的时候还须要删除数据库数据，稍显麻烦，而数据库操作不当又easy出现一系列的性能，ANR问题。指针错误问题，实现的时候要慎重。详细作的话，但也仅仅是添加一个工具类或方法的事情。
另一个问题，缓存的数据库是存放在/data/data/<package>/databases/文件夹下，是占用内存空间的，假设缓存累计。easy浪费内存，须要及时清理缓存。
当然这样的方法从眼下一些应用的有用上看。我没有发现什么问题,预计使用的量还比較少吧。
本文本人不太喜欢数据库，原因操作麻烦，尤其是要自己写建表那些语句，你懂的。我側重文件缓存方式。
三、文件缓存方式
这样的方法，使用File.lastModified()方法得到文件的最后改动时间。与当前时间推断是否过期，从而实现缓存效果。
实现上仅仅能使用这一个属性。没有为其他的功能提供技术支持的可能。
操作上倒是简单，比較时间就可以。并且取的数据也就是文件中的JSON数据而已。
本身处理也不easy带来其他问题，代价低廉。
四、文件法缓存方式的两点说明
1. 不同类型的文件的缓存时间不一样。
笼统的说。不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。说白点，图片文件内容是不变的，一般存在SD卡上直到被清理。我们是能够永远读取缓存的。配置文件内容是可能更新的，须要设置一个可接受的缓存时间。
2. 不同环境下的缓存时间标准不一样。
无网络环境下。我们仅仅能读取缓存文件。为了应用有东西显示。没有什么过期之说了。
WiFi网络环境下，缓存时间能够设置短一点，一是网速较快，而是流量不要钱。
3G流量环境下，缓存时间能够设置长一点。节省流量。就是节省金钱，并且用户体验也更好。
GPS就别说更新什么的，已经够慢的了。
缓存时间能多长就多长把。
当然。作为一款好的应用。不会死定一种情况，针对于不同网络变换不同形式的缓存功能是必须有的。并且这个时间依据自己的实际情况来设置：数据的更新频率，数据的重要性等。
五、何时刷新
开发人员一方面希望尽量读取缓存，用户一方面希望实时刷新。可是响应速度越快越好，流量消耗越少越好(关于这块。的确开发中我没怎么想到。毕竟接口就是这么多。如今公司的产品差点儿点一下就訪问一下，并且还有些鸡肋多余的功能。慢慢改动哈哈)，是一个矛盾。
事实上何时刷新我也不知道，这里我提供两点建议：
1. 数据的最长多长时间不变，相应用无大的影响。
比方，你的数据更新时间为4小时，则缓存时间设置为1~2小时比較合适。也就是更新时间/缓存时间=2,但用户个人改动、站点编辑人员等一些人为的更新就另说。
一天用户总会看到更新。即便有延迟也好，视你产品的用途了；假设你认为你是资讯类应用，再降低，2~4小时，假设你认为数据比較重要或者比較受欢迎，用户会常常把玩，再降低，1~2小时，依次类推。
当然类似这个界面的数据我觉得更新时间能多长就多长了。尽可能长。
假设你拿后边那个有多少数据会变动来搪塞。我会告诉你：这个仅仅是一个引导性的界面。你有多少款游戏跟用户半毛钱关系都没有，10亿也跟他没关，他仅仅要确定这里能找到他要找的 汤姆猫 即可。
否则你又失去了一个用户。
2. 提供刷新button。
必要时候或最保险的方法使在相关界面提供一个刷新button。或者当下流行的下拉列表刷新方式。
为缓存，为载入失败提供一次又一次来过的机会。毕竟喝骨头汤的时候。我也不介意碗旁多双筷子。
总而言之，一切用户至上，为了更好的用户体验，方法也会层出不穷。期待更好的办法
（參考代码：http://blog.csdn.net/lnb333666/article/details/8460159）
图片缓存：
译文：
载入一个Bitmap(位图)到你的UI界面是很easy的，可是假设你要一次载入一大批，事情就变得复杂多了。在大多数的情况下(如ListView、GridView或者ViewPager这种组件)。屏幕上的图片以及立即要在滚动到屏幕上显示的图片的总量。在本质上是不受限制的。
像这种组件在子视图移出屏幕后会进行视图回收，内存使用仍被保留。
但如果你不保留不论什么长期存活的引用。垃圾回收器也会释放你所载入的Bitmap。这自然再好只是了，可是为了保持流畅且高速载入的UI，你要避免继续在图片回到屏幕上的时候又一次处理。使用内存和硬盘缓存通常能解决问题，使用缓存同意组件高速载入并处理图片。
这节课将带你使用内存和硬盘缓存Bitmap，以在载入多个Bitmap的时候提升UI的响应性和流畅性。
使用内存缓存
以牺牲宝贵的应用内存为代价。内存缓存提供了高速的Bitmap訪问方式。
LruCache类(能够在Support Library中获取并支持到API Level 4以上，即1.6版本号以上)是很适合用作缓存Bitmap任务的，它将近期被引用到的对象存储在一个强引用的LinkedHashMap中，而且在缓存超过了指定大小之后将近期不常使用的对象释放掉。
注意：曾经有一个非常流行的内存缓存实现是SoftReference(软引用)或者WeakReference(弱引用)的Bitmap缓存方案，然而如今已经不推荐使用了。
自Android2.3版本号(API Level 9)開始。垃圾回收器更着重于对软/弱引用的回收。这使得上述的方案相当无效。此外，Android 3.0(API Level 11)之前的版本号中，Bitmap的备份数据直接存储在本地内存中并以一种不可预測的方式从内存中释放，非常可能短暂性的引起程序超出内存限制而崩溃。
为了给LruCache选择一个合适的大小，要考虑到非常多原因，比如：
其它的Activity(活动)和(或)程序都是非常耗费内存的吗？
屏幕上一次会显示多少图片？有多少图片将在屏幕上显示？
设备的屏幕大小和密度是多少？一个超高清屏幕(xhdpi)的设备如Galaxy Nexus，相比Nexus S(hdpi)来说，缓存相同数量的图片须要更大的缓存空间。
Bitmap的尺寸、配置以及每张图片须要占用多少内存？
图片的訪问是否频繁？有些会比其它的更加被频繁的訪问到吗？假设是这样，或许你须要将某些图片一直保留在内存中，甚至须要多个LruCache对象分配给不同组的Bitmap。
你能平衡图片的质量和数量么？有的时候存储大量低质量的图片更加实用，然后能够在后台任务中载入还有一个高质量版本号的图片。
对于设置缓存大小，并没有适用于全部应用的规范，它取决于你在内存使用分析后给出的合适的解决方式。缓存空间太小并无益处。反而会引起额外的开销。而太大了又可能再次引起java.lang.OutOfMemory异常或仅仅留下非常小的空间给应用的其它程序执行。