android缓存具体解释

Android缓存：

採用缓存，可以进一步大大缓解数据交互的压力。又能提供必定的离线浏览。下边我简略列举一下缓存管理的适用环境：

1. 提供网络服务的应用

2. 数据更新不需要实时更新，哪怕是3-5分钟的延迟也是可以採用缓存机制。

3. 缓存的过时时间是可以接受的(相似网易的新闻阅读,支持离线离线阅读)

这样所带来的优势：

1. 减少server的压力

2. 提升client的响应速度(本地数据提取嘛)

3. 必定程度上支持离线浏览(可以參考网易的那个新闻应用,我的感受离线阅读作得很棒。)

 

1、缓存管理的方法

缓存管理的原理很是简：经过时间的设置来推断是否读取缓存仍是又一次下载；断网下就没什么好说的，直接去缓存就能够。如图：

里面会有一些细节的处理，后面会具体阐述。基于这个原理，眼下我的用过的两种比較常见的缓存管理方法是:数据库和文件(txt)。

 

2、数据库(SQLite)缓存方式

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

从实现上咱们可以看到这样的方法可以灵活存放文件的属性。进而提供了很是大的扩展性。可以为其余的功能提供必定的支持。

从操做上需要建立数据库，每次查询数据库，假设过时还需要更新数据库。清理缓存的时候还需要删除数据库数据。稍显麻烦。而数据库操做不当又easy出现一系列的性能，ANR问题，指针错误问题。实现的时候要慎重。详细做的话。但也仅仅是添加一个工具类或方法的事情。

另外一个问题，缓存的数据库是存放在/data/data/<package>/databases/文件夹下，是占用内存空间的。假设缓存累计。easy浪费内存，需要及时清理缓存。

固然这样的方法从眼下一些应用的有用上看。我没有发现什么问题,预计使用的量还比較少吧。

本文本人不太喜欢数据库，缘由操做麻烦，尤为是要本身写建表那些语句，你懂的。我側重文件缓存方式。

 

3、文件缓存方式

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

实现上仅仅能使用这一个属性，没有为其余的功能提供技术支持的可能。操做上却是简单。比較时间就能够。而且取的数据也就是文件中的JSON数据而已。自己处理也不easy带来其余问题，代价低廉。

 

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

1. 不一样类型的文件的缓存时间不同。

笼统的说。不变文件的缓存时间是永久，变化文件的缓存时间是最大忍受不变时间。

说白点，图片文件内容是不变的，通常存在SD卡上直到被清理。咱们是可以永远读取缓存的。配置文件内容是可能更新的，需要设置一个可接受的缓存时间。

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

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

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

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

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

固然。做为一款好的应用，不会死定一种状况。针对于不一样网络变换不一样形式的缓存功能是必须有的。

而且这个时间依据本身的实际状况来设置：数据的更新频率，数据的重要性等。

 

5、什么时候刷新

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

事实上什么时候刷新我也不知道，这里我提供两点建议：

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异常或仅仅留下很是小的空间给应用的其它程序执行。