Bitmap的加载与Cache(一)

如何有效的加载一个bitmap,由于Bitmap的特殊性以及Android对单个应用所施加的内存限制,比如16MB,这就导致加载Bitmap的时候很容易出现内存溢出。

因此,如何高效的加载bitmap是一个很重要也很容易被开发者忽略的问题。

Bitmap的高效加载:

如何加载一张图片呢?BitmapFactory类提供了四类方法:decodedFile,decodedResource,decodedStream和decodedByteArray,分别用于支持文件系统,资源,输入流以及字节数组中加载出一个Bitmap对象,其中decodedFile和decodedResource又间接调用了decodedStream方法,这四类方法最终是在Android的底层实现的,对应着BitmapFactory类的几个方法。

高效加载Bitmap的核心就是采用BitmapFactory.Options来加载所需尺寸的图片。这里加色通过ImageView来显示图片,很多时候ImageView并没有图片的原始尺寸那么大,这个时候把整个图片加载进来后再射给ImageView,这显然是没有必要的,因为ImageView并没有办法显示原始的图片。通过Options参数就可以按一定的采样率来加载缩小后的图片,将缩小后的图片在ImageView中显示,这样就会降低内存占用从而在一定程度上避免OOM,提高加载时的性能。其缩放图片主要是用到了Options的inSampleSize参数,即采样率,当inSampleSize为1时,采样后的图片大小为图片的原始大小,当inSampleSize大于1时,比如2,那么采样后的图片其宽/高均为原图大小的1/2,而像素数为原图的1/4,其占有的内存大小也为原图的1/4
拿一张10241024像素的图片来说,嘉定采用ARGB8888格式存储,那么他占有的内存为102410244,即4MB,如果inSampleSize为2,那么采样后的图片其内存占用只有512512*4即1MB。可以发现采样率inSampleSize必须是大于1的整数,图片才会有缩小的效果,并且采样率同时作用于宽/高,这将导致缩放后的图片大小以采样率的2次方形式递减。即inSampleSize=4是,那么缩放比例就是1/16。有一种 特殊情况,就是当inSampleSize小雨1时,其作用相当于1,即无缩放效果。

通过采样率即可有效的加载图片,那么到底如何获取采样率呢?

(1)将BitmapFactory.Options的inJustDecodeBounds参数设为true并加载图片(只会解析 图片的原始宽/高信息,并不会去真正加载图片)

(2)从BitmapFactory.Options中取出图片的原始宽高信息。他们对英语outWitdh和outHeight参数

(3) 根据采样率的规则并结合目标View的所需大小计算出采样率inSampleSize

(4)将itmapFactory.Options的inJustDecodeBounds参数谁为false,然后重新加载图片。

public static Bitmap decodeSanpledBitmapFromResource(Resources res,
            int resId, int reqWidth, int reqHeight) {
        final BitmapFactory.Options options = new BitmapFactory.Options();
        options.inJustDecodeBounds = true;
        BitmapFactory.decodeResource(res, resId, options);
        options.inSampleSize = calculateInSampleSize(options, reqWidth,
                reqHeight);
        options.inJustDecodeBounds = false;
        return BitmapFactory.decodeResource(res, resId, options);
    }
 
    public static int calculateInSampleSize(BitmapFactory.Options options,
            int reqWidth, int reqHeight) {
        final int height = options.outHeight;
        final int width = options.outWidth;
        int inSampleSize = 1;
 
        if (height > reqHeight || width > reqWidth) {
            final int halfHieght = height / 2;
            final int halfWidth = width / 2;
 
            while ((halfHieght / inSampleSize) >= reqHeight
                    && (halfWidth / inSampleSize >= reqWidth)) {
                inSampleSize *= 2;
            }
        }
        return inSampleSize;
    }

除了BitmapFactory的decodedResource方法,其他三个decode系列的方法也是支持采样加载的,并且处理方式也是类似的,但是decodeStream方法稍微特殊,后面会讲解。

Android中的缓存策略:

缓存策略在Android中有着广泛的使用场景,尤其在图片加载这个场景下,缓存策略变得非常重要。

目前常用的一种缓存算法是LRU,LRU是近期最少使用算法,他的核心思想是当缓存满时,会优先淘汰那些近期最少使用的缓存对象。采用LRU算法的缓存由两种:LruCache和DiskLruCache,前者用于实现内存缓存,而后者则充当了存储设备缓存,通过二者的结合就可以很方便的实现一个很高使用价值的ImageLoader。

LruCache:

LruCache是3.1所提供的一个缓存类,通过v4兼容包可以兼容到早起的版本,为了能够兼容至2.2版本,在使用LruCache的时候建议采用v4兼容包中提供的LruCache,而不要直接使用3.1提供的LruCache

LruCache是一个泛型类,他内部采用一个LinkedHashMap以强引用的方法存储外界的缓存对象,其提供了get和put方法来完成缓存的获取和添加操作。接下来简答说一个几个引用:

强引用: 直接的对象引用

软引用: 当一个对象只有软引用存在时,系统内存不足时此对象会被gc回收;

弱引用: 当一个对象只有弱引用存在时,此对象会随时被gc回收。

另外LruCache是线程安全的,因为他使用了LinkedHashMap:

public class LruCache<K, V> {
    private final LinkedHashMap<K, V> map;

功欲善其实,必先利器,接下来我们就看看LruCache的使用,首先典型的初始化:

int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
        int cacheSize = maxMemory / 8;
        mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
            @Override
            protected int sizeOf(String key, Bitmap bitmap) {
                // TODO Auto-generated method stub
                return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
            }
        };

只需要提供缓存的总容量大小并重写sizeOf方法即可。sizeOf方法的作用是计算缓存对象的大小,这里的大小的单位需要和总容量的单位保持一致。对于上面代码,总容量的大小为当前进程可用内存的1/8,单位为KB,sizeOf方法则完成了Bitmap对象的大小计算。

一些特殊情况,还需要重写LruCache的entryRemoved方法,LruCache移除旧缓存时会调用这个方法,因此可以在这个方法中完成一些资源回收(如果需要的话)

除了创建以外还有缓存的获取和添加。

mMemoryCache.get(key);
mMemoryCache.put(key, value);

DiskLruCache:

DiskLruCache的创建:

DiskLruCache并不能通过构造方法来创建,他提供了open方法用于创建自身,如下所示:

public static DiskLruCache open(File directory,int appVersion,int valueCount,long manSize)

第一个参数表示磁盘缓存在文件系统中的存储路径,缓存路径可以选择SD卡上的缓存目录,具体是指/sdcard/Android/data/package_name/cache目录,其中package_name表示当前应用包名,当应用被卸载后,此目录会一并被删除。当然也可以选择SD卡上的其他指定目录,还可以选择data下的当前应用目录,具体可根据需要灵活设定。如果应用卸载后就希望删除缓存目录,那么就选择SD卡上的缓存目录,否则就选择SD卡上的其他目录。

第二个参数表示应用的版本号,一般设为1即可。当版本号发生变化时DiskLruCache会清空之前所有的缓存文件,而这个特性在实际开发中作用并不大,很多情况下既是应用版本号发生了变化缓存文件仍然是有效的,因此这个参数设为1比较好。

第三个参数表示单个节点所对应的数据的个数,一般设为1即可,

第四个参数表示缓存的总大小,比如50MB,当缓存大小超出这个设定值后,DiskLruCache会清楚一些缓存从而保证总大小不大于这个设定值:

private static final long DISK_CACHE_SIZE=1024*1024*50;
File diskCacheDir=getDiskCacheDir(mContext,"bitmap");
if(!diskCacheDir.exists()){
    diskCacheDir.mkdir();
}
mDiskLruCache=DiskLruCache.open(diskCacheDir,1,1,DISK_CACHE_SIZE);

DiskLruCache的缓存添加:
DiskLruCache的缓存添加的操作是通过Editor完成的。Editor表示一个缓存对象的编辑对象,这里仍以图片缓存举例子,首先需要获取图片url所对应的key,然后根据key就可以通过edit()来获取Editor对象,如果这个缓存正在被编辑,那么会返回null,即DiskLruCache不允许同时编辑一个缓冲对象,之所以要把url转换为key,是因为图片的url中很可能有特殊字符,这将影响url在Android中直接使用,一般采用url的md5值作为key:

private String hashKeyFormUrl(String url) {
        String cacheKey;
        try {
            final MessageDigest mDigest = MessageDigest.getInstance("MD5");
            mDigest.update(url.getBytes());
            cacheKey = bytesToHexString(mDigest.digest());
        } catch (Exception e) {
            // TODO: handle exception
            cacheKey = String.valueOf(url.hashCode());
        }
        return cacheKey;
    }
 
    private String bytesToHexString(byte[] digest) {
        // TODO Auto-generated method stub
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < digest.length; i++) {
            String hex = Integer.toHexString(0xFF & digest[i]);
            if (hex.length() == 1) {
                sb.append('0');
            }
            sb.append(hex);
        }
        return sb.toString();
    }

将图片的url转化为key以后,就可以获取Editor对象了,对于这个key来说,如果当前不存在其他Editor对象,那么edit()就会返回一个新的Editor对象,通过他就可以得到一个文件输出流,需要注意的是,由于前面在DiskLruCache的open方法中设置了一个子节点只能有一个数据,因此下面的DISK_CACHE_INDEX常量直接设为0即可:

String key=hashKeyFormUrl(url);
        DiskLruCache.Editor editor=mDiskLruCache.edit(key);
        if(editor!=null){
            OutputStream outputStream=editor.newOutputStream(DISK_CACHE_INDEX);
        }

有了文件输出流,接下来就是,从网络下载图片时,图片就可以通过这个文件输出流写入到文件系统上:

public boolean downloadUrlToStream(String urlString,
            OutputStream outputStream) {
        HttpURLConnection urlConnection = null;
        BufferedOutputStream out = null;
        BufferedInputStream in = null;
 
        try {
            final URL url = new URL(urlString);
            urlConnection = (HttpURLConnection) url.openConnection();
            in = new BufferedInputStream(outputStream, IO_BUFFER_SIZE);
 
            int b;
            while ((b = in.read()) != -1) {
                out.write(b);
            }
        } catch (Exception e) {
            // TODO: handle exception
        } finally {
            if (urlConnection != null) {
                urlConnection.disconnect();
            }
            MyUtils.close(out);
            MyUtils.close(in);
        }
        return false;
    }

经过上面的步骤,其实并没有真正的将图片写入文件系统,还必须通过Editor的commit()来提交写入操作,如果图片下载 过程发生了异常,那么还可以通过Editor的abort()来回退整个操作:

OutputStream outputStream=editor.newOutputStream(DISK_CACHE_INDEX);
        if(downloadUrlToStream(url,outputStream)){
            editor.commit();
        }else{
            editor.abort();
        }
        mDiskLruCache.flush();

经过上面的步骤,图片就已经被正确的写入到文件系统中了,接下来图片的获取操作就不需要请求网络了。

DiskLruCache的缓存查找:
和缓存添加过程类似,缓存找找过程也需要将url转换为key,然后通过DiskLruCache的get方法得到一个Snapshot对象,接着再通过Snapshot对象即可得到缓存的文件输入流,有了文件输入流,自然就可以得到Bitmap对象了,为了避免加载图片过程中导致的OOM问题,一般不建议直接加载原始图片。但是BitmapFactory.Options的方式压缩图片对FileInputStream的缩放存在问题,原因是,FileInputStream是一种 有序的文件流,而两次decodeStream调用印象了文件流的位置属性,导致了第二次decodeStream时得到的是null。为了解决这个问题,可以通过文件流来得到他所对应的文件描述符,然后再通过BitmapFactory.decodeFileDescriptor方法来加载一张缩放后的图片,代码如下:

Bitmap bitmap = null;
        String key = hashKeyFormUrl(url);
        DiskLruCache.Snapshot snapShot = mDiskLruCache.get(key);
        if (snapShot != null) {
            FileInputStream fileInputStream = (FileInputStream) snapShot
                    .getInputStream(DISK_CACHE_INDEX);
            FileDescriptor fileDescriptor = fileInputStream.getFD();
            bitmap = mImageResizer.decodeSampledBitmapFromFileDescriptor(
                    fileDescriptor, reqWidth, reqHeight);
            if(bitmap!=null){
                addBitmapToMemoryCache(key,bitmap);
            }
        }

好了,就说到这里,主要介绍了一些缓存策略和高效加载bitmap的方式,后续会继续对于ImageLoader进行学习并解析。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,948评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,371评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,490评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,521评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,627评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,842评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,997评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,741评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,203评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,534评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,673评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,339评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,955评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,770评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,000评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,394评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,562评论 2 349

推荐阅读更多精彩内容