用双缓存技术优化listview异步加载网络图片

泡在网上的日子 / 文 发表于2013-09-20 14:24 次阅读 异步加载,ListView,缓存

缓存简单的来讲就是内存,缓存技术的目的是为了更高效的利用内存,防止out of memory 发生。双缓存又称为二级缓存,它的实现利用了java中的强引用(直接对对象的引用都是强引用)和弱引用(SoftReference)各自的同特点。

在这一篇博客中将会为大家讲解如何将下载回来的图片进行缓存,为了节约流量,并且提高下一次显示图片的速度,避免每次调用getView的时候都去从网络下载图片,就必须用到缓存。

单一的强引用缓存

一个最简单的缓存实现就是将我们的对象(由于是缓存图片,这里就是BitMap对象)放入到一个集合当中,下一次需要这个BitMap的时候就不需要再次从网络上取了,而是直接从这个集合(内存)中取就行了。如下:

HashMap<String, Bitmap> mCache;

HashMap这中键值对形式的集合非常适合我们的场景,每一张图片的URL是唯一的,因此可以作为键,而图片的BitMap对象最为值。当我们从网上下载下来一张图片并已经转换成BitMap之后,我们通过如下代码放入到缓存中:

mCache.put("urlstr",bitmap);

下次如果再需要这张图片就不需要开启线程来获取了,直接在缓存中获取,如下:

mCache.get("urlstr");

经过实际测试,安卓ImageView上显示BitMap速度是非常快的,完全不会造成卡顿,现在我们显示一张图片就跟TextView显示文字一样流畅。

但是这中缓存方式完全没有考虑占用内存大小的情况,假设我们的listView滑动很快,而listView的Item个数又非常多,如果一个BitMap达到100K的话,1000个Item就能占用100m的内存,很容易发生Out Of  Memory的情况。因此我们必须对缓存的大小进行控制。

直接缓存BitMap对象的引用称为强引用,Java虚拟机宁愿抛出OutOfMemoryError错误,使程序异常终止,也不会靠随意回收具有强引用的对象来解决内存不足的问题,因此我们把强引用换成软引用

单一的软引用缓存

一般对软引用是这样解释的:如果一个对象只具有软引用,则内存空间足够,垃圾回收器就不会回收它;如果内存空间不足了,就会回收这些对象的内存。只要垃圾回收器没有回收它,该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存

软引用实现缓存的方法:

先定义一个HashMap

HashMap<String, SoftReference<BitMap>> imageCache = new HashMap<String, SoftReference<BitMap>>()

同样是HashMap,只不过换成了对BitMap的软引用。

放入缓存

imageCache.put(mImageUrl, newSoftReference<BitMap>(bitmap));

从缓存中取出

(imageCache.containsKey(mImageUrl)) {
   SoftReference<BitMap> softReference = imageCache.get(mImageUrl);
   BitMap bitmap = softReference.get();
}

采用软引用之后我们解决了内存占用的问题,但是远远不够,我们发现软引用被回收的几率很高,几乎可以说没有达到缓存的效果,很多时候我们从缓存中取不出BitMap来,因为被回收了,也就是说在这样的缓存中,命中率很低。软引用解决了缓存大小的问题,却背离了缓存设计的初衷。

双缓存(二级缓存)

正因为单一的强引用缓存和软引用缓存都有各自的缺点,因此我何不将两者结合起来,吸取他们的优点呢?

解决方案:设置两级缓存,第一级用LinkedHashMap<String,Bitmap>保留Bitmap的强引用,但是控制缓存的大小MAX_CAPACITY=10,当继续向该缓存中存数据的时候,将会把一级缓存中的最近最少使用的元素放入二级缓存ConcurrentHashMap<String, SoftReference<Bitmap>>,二级缓存中保留的Bitmap的软引用,这样的设计更具有弹性。


为什么这次我们没有用HashMap而是用LinkedHashMap和ConcurrentHashMap呢,从下面的代码中你可以看到LinkedHashMap有个removeEldestEntry()方法,该方法能自动在内存不够的时候被调用。而软引用我们是用的ConcurrentHashMap来存储,因为他支持高并发,这里也可以直接用HashMap,因为很多人都是用的ConcurrentHashMap,我也就跟风了。

下面我将二级缓存的实现封装在了一个类中。

代码如下:

package com.jcodecraeer.client.common;
import java.lang.ref.SoftReference;
import java.util.Collections;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.Map.Entry;
import java.util.concurrent.ConcurrentHashMap;
import android.graphics.Bitmap;
import android.util.Log;
public class ImageCache {
    private static final int MAX_CAPACITY = 50;// 一级缓存的最大空间
    private static final long DELAY_BEFORE_PURGE = 10 * 1000;// 定时清理缓存
    // 0.75是加载因子为经验值,true则表示按照最近访问量的高低排序,false则表示按照插入顺序排序
    private HashMap<String, Bitmap> mFirstLevelCache = new LinkedHashMap<String, Bitmap>(
            MAX_CAPACITY / 2, 0.75f, true) {
        protected boolean removeEldestEntry(Entry<String, Bitmap> eldest) {
            if (size() > MAX_CAPACITY) {// 当超过一级缓存阈值的时候,将老的值从一级缓存搬到二级缓存
                mSecondLevelCache.put(eldest.getKey(),
                        new SoftReference<Bitmap>(eldest.getValue()));
                return true;
            }
            return false;
        };
    };
    // 二级缓存,采用的是软应用,只有在内存吃紧的时候软应用才会被回收,有效的避免了oom
    private ConcurrentHashMap<String, SoftReference<Bitmap>> mSecondLevelCache = new ConcurrentHashMap<String, SoftReference<Bitmap>>(
            MAX_CAPACITY / 2);
    /**
     * 放入缓存
     *
     * @param url
     * @param value
     */
    public void addBitmap2Cache(String url, Bitmap value) {
        if (value == null || url == null) {
            return;
        }
        synchronized (mFirstLevelCache) {
            mFirstLevelCache.put(url, value);
        }
    }
    /**
     * 从缓存中获取
     *
     * @param url
     * @param value
     */
    public Bitmap getBitmapFromCache(String url) {
        Bitmap bitmap = null;
        bitmap = getFromFirstLevelCache(url);// 从一级缓存中拿
        if (bitmap != null) {
            return bitmap;
        }
        bitmap = getFromSecondLevelCache(url);// 从二级缓存中拿
        return bitmap;
    }
    /**
     * 从二级缓存中拿
     *
     * @param url
     * @return
     */
    private Bitmap getFromSecondLevelCache(String url) {
        Bitmap bitmap = null;
        SoftReference<Bitmap> softReference = mSecondLevelCache.get(url);
        if (softReference != null) {
            bitmap = softReference.get();
            if (bitmap == null) {// 由于内存吃紧,软引用已经被gc回收了
                mSecondLevelCache.remove(url);
            }
        }
        return bitmap;
    }
    /**
     * 从一级缓存中拿
     *
     * @param url
     * @return
     */
    private Bitmap getFromFirstLevelCache(String url) {
        Bitmap bitmap = null;
        synchronized (mFirstLevelCache) {
            bitmap = mFirstLevelCache.get(url);
            if (bitmap != null) {// 将最近访问的元素放到链的头部,提高下一次访问该元素的检索速度(LRU算法)
                mFirstLevelCache.remove(url);
                mFirstLevelCache.put(url, bitmap);
            }
        }
        return bitmap;
    }
    public void clear() {
        mFirstLevelCache.clear();
        mSecondLevelCache.clear();
    }
}

现在我们只需三步就能完成这个二级缓存了。

新建缓存对象:

private ImageCache imageCache = new ImageCache();

将BitMap放入缓存:

imageCache.addBitmap2Cache(mImageUrl, bitmap);

从缓存中获取BitMap:

Bitmap bitmap = imageCache.getBitmapFromCache(mImageUrl);


收藏 赞 (5) 踩 (1)
上一篇:[布局效率问题]解决ListView的getview调用次数多于子view个数的问题
我们知道listview的getview调用次数是和他的子view个数相关的, 且getView执行的次数和adapter的getCount值没有直接关系 ,getCount和你listView里面的条目数量(行数量)有关系 ,getView方法执行次数取决于你屏幕上显示几个条目,比如你有100行 ,但是你一屏
下一篇:android中的文件操作详解以及内部存储和外部存储
其实安卓文件的操作和java在pc环境下的操作并无二致,之所以需要单独讲解是因为安卓系统提供了不同于pc的访问文件系统根路径的api,同时对一个应用的私有文件做了统一的管理。根据我的经验,初学者在这部分感到很容易混淆内部存储和外部存储两个概念。 相对