【专业领域】Android图片缓存之内存缓存

在过去的两篇博客已经讲了图片的基本知识和图片的加载方法及优化所有的这些优化都是为了避免应用出现OOM这个问题。一个好的应用程序不仅要健壮不能出错还要方便用户使用,对于用户来说你的应用不仅要美观还要流畅,很快的呈现给他想要的。很快的加载图片除了加载的优化外还需要缓存,下面这篇博客将会讲图片缓存。

什么是缓存?

缓存技术原理就是把用户访问的所有对象看作一个全集,经过算法标记哪些是用户经常访问的对象,把这些对象放到一个集合里,这个集合是全集一个子集,下一次用户再访问的时候会先从这个子集集合中查找用户要访问的对象如果找到就直接返回这个对象,如果没有找到则再去全集中查找。当然了我这里说的只是原理性的东西,缓存是有很多算法的,并且有的不止一级缓存,这里就不过多讲了。

为什么要用到缓存?

有缓存的话可以不必每次从源地址读取文件,既节省了时间也节省了流量。尤其是手机设备,频繁的访问网络资源会消耗很多用户的流量和电量,这是用户不能忍受的,所以无论从哪个方面考虑应用程序都必须加上缓存。

Android中的图片缓存有哪些?各有什么特点?

Android设备的图片缓存分两种,一种是内存缓存,图片缓存在设备的内存中,一种是外部缓存,图片缓存在磁盘上,磁盘可以是内部的存储空间也可以是外部的sd卡。这两种缓存各有各的优点,内存缓存优点是快,缺点是因为也是读取到内存中所以也会消耗内存,所以不能太大,用的时候要考虑分配的空间,还有一个缺点是应用重启后就会消失。外部缓存的优点是可以长久保存大量的数据(相比较内存缓存而言),缺点就是慢。

内存缓存:

在Android中官网推荐使用LruCache作为内存缓存,LruCache实际上就是一个LinkedHashMap( 补充知识:LinkedHashMap是一个双向循环列表,不支持线程安全,LruCache对它进行了封装添加了线程安全操作),里面保存了一定数量的对象强引用,每次添加的新对象都是在链表的头,当分配的空间用完的时候会把末尾的对象移除,移除的对象就可以被gc回收了。这里需要注意一下LruCache的容量,这个容量既不能太大,会造成OOM,又不能太小,起不到缓存的作用。google官网给出一下意见作为参考:

1、分配LruCache大小的时候考虑你的应用剩余内存有多大;

2、一次屏幕显示多少张图片,有多少张图片是缓存起来准备显示的;

3、考虑你的手机分辨率和尺寸, 缓存相同的图片个数,dpi越大的手机需要的内存就会越大,我的一篇博客中()有讲解;

4、图片分辨率和像素质量也决定了占用内存的大小;

5、图片访问的频繁程度是多少,是不是有一些图片是经常访问的?如果存在你可以考虑用多个LruCache来做缓存,按照访问的频率度分配到不同的LruCache中;

6、如何平衡一下图片质量和数量,有些时候可以考虑缓存低分辨率的图片,用到的时候再在后台请求更高质量的图片;

总之你分配的LruCache大小既不能太大,又不能太小,具体到应用中还要你综合考虑。

下面的代码是使用LruCache的例子:

private LruCache<String, Bitmap> mMemoryCache;//声明缓存空间

final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);//获取应用在系统中的最大内存分配

//分配1/8的应用内存作为缓存空间

final int cacheSize = maxMemory / 8;

mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {

@Override

protected int sizeOf(String key, Bitmap bitmap) {

//重写sizeOf方法,返回图片的占用字节数而不是图片的个数,每次添加图片是会被调用

return bitmap.getByteCount() / 1024;

}

};

注意:有同学可能会问下面的代码:

int cacheSize = 4 * 1024 * 1024; // 4MiB

LruCache bitmapCache = new LruCache(cacheSize) {

protected int sizeOf(String key, Bitmap value) {

return value.getByteCount();

}}

这两个sizeOf的计算是不一样的,这里说明一下,这个方法重写的目的是返回图片占用的缓存空间而不是图片的数目,并且这个数值的单位要和cacheSize一样。

综合上面的讲解,在使用内存缓存LruCache时你需要知道如下知识:

1.LruCache封装了LinkedHashMap,提供了LRU(Least Recently Used 最近最少使用算法)缓存的功能;

2.LruCache通过trimToSize方法自动删除最近最少访问的键值对;

3.LruCache不允许空键值, LinkedHashMap允许;

4.LruCache线程安全, LinkedHashMap线程不安全;

5.继承LruCache时,必须要复写sizeOf方法,用于计算每个条目的大小。在put和get的时候会调用safeSizeOf(K key, V value),safeSizeOf(K key, V value)会调用 sizeOf (K key, V value),这个方法默认返回1。

原文发布于微信公众号 - 程序员互动联盟(coder_online)

原文发表时间:2015-04-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏郭霖

Android图片加载框架最全解析(三),深入探究Glide的缓存机制

在本系列的上一篇文章中,我带着大家一起阅读了一遍Glide的源码,初步了解了这个强大的图片加载框架的基本执行流程。 不过,上一篇文章只能说是比较粗略地阅读了Gl...

39810
来自专栏程序员互动联盟

【专业技术】 Android图片缓存之内存缓存

上面两篇博客已经讲了图片的基本知识和图片的加载方法及优化,所有的这些优化都是为了避免应用出现OOM这个问题。一个好的应用程序不仅要健壮不能出错还要方便用户使用,...

3285
来自专栏程序猿DD

程序员你为什么这么累【续】:编码习惯之工具类规范

一个项目不可能没有工具类,工具类的初衷是良好的,代码重用,但到了后面工具类越来越乱,有些项目工具类有几十个,看的眼花缭乱,还有不少重复。如何编写出好的工具类,我...

2046
来自专栏吴伟祥

基于Spring的Web缓存 转

原文:https://www.cnblogs.com/moongeek/p/7689683.html

672
来自专栏码农阿宇

利用Asp.Net Core的MiddleWare思想处理复杂业务流程

最近利用Asp.Net Core 的MiddleWare思想对公司的古老代码进行重构,在这里把我的设计思路分享出来,希望对大家处理复杂的流程业务能有所帮助。

642
来自专栏码农阿宇

利用Asp.Net Core的MiddleWare思想处理复杂业务流程

最近利用Asp.Net Core 的MiddleWare思想对公司的古老代码进行重构,在这里把我的设计思路分享出来,希望对大家处理复杂的流程业务能有所帮助。

771
来自专栏岑玉海

hbase源码系列(八)从Snapshot恢复表

在看这一章之前,建议大家先去看一下snapshot的使用。这一章是上一章snapshot的续集,上一章了讲了怎么做snapshot的原理,这一章就怎么从snap...

2746
来自专栏DOTNET

ASP.NET MVC编程——视图

1Razon语法 使用@符号后接C#或VB.NET语句的方式。 基本规则 1)变量 @后直接变量即可 2)代码块 为使用表达式或多行代码,@后跟大括号将多行代码...

30410
来自专栏不止是前端

TS+React+Router+Mobx+Koa打造全栈应用

3867
来自专栏喵了个咪的博客空间

phalapi-进阶篇2(DI依赖注入和单例模式)

#phalapi-进阶篇2(DI依赖注入和单例模式)# ? ##前言## 先在这里感谢phalapi框架创始人@dogstar,为我们提供了这样一个优秀的开源框...

3025

扫描关注云+社区