最近维护一个项目,有一个功能是用户可以从相机或是本地选择头像,经常会OOM,比较头疼,于是查找了一些资料,自己总结一下对BitMap的优化:
1.BitMap及时回收
Bitmap类的构造方法都是私有的,所以开发者不能直接new出一个Bitmap对象(called from JNI),只能通过BitmapFactory类的各种decode方法来实例化一个Bitmap。因为用到了JNI(Java Native Interface的缩写,它提供了若干的API实现了Java和其他语言的通信(主要是C&C++)),所以,加载 Bitmap到内存里以后,是包含两部分内存区域的,一部分是Java部分的,一部分是C部分的。这个Bitmap对象是由Java部分分配的,不用的时候系统就会自动回收了,但是那个对应的C可用的内存区域,虚拟机是不能直接回收的,这个只能调用底层的功能释放。所以BitMap提供了 recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到,recycle()方法里也的确是调用了JNI方法了的。
所以,如果能够获得Bitmap对象的引用,就需要在不需要的时候(一般在Activity的onStop()或者onDestroy()中)调用Bitmap的recycle()方法来释放Bitmap占用的内存空间。(如果回收的时机不对,如在回收后又调用bitmap对象会报错)。
// 先判断是否已经回收
if(bitmap != null && !bitmap.isRecycled()){
// 回收并且置为null
bitmap.recycle();
bitmap = null;
}
2.缓存
有的时候App中可能大量相同的BitMap,如果每次都是重新创建一个BitMap,就会造成内存的浪费,这里介绍两个类。LruCache和DiskLruCache。
LruCache 为缓存到内存中,这样加载显示比较快,例如ListView滑动不会有卡顿的情况,但是占用内存,也可能被回收。
DiskLruCache 缓存到磁盘,一般都是SDCard中,位置/sdcard/Android/data/<application package>/cache
3.缩放和压缩
有的时候,我们用的图片资源可能很大,但是,只是要显示在页面上一个很小的位置。我们就可以对其进行缩小。
BitmapFactory.Options 有一个属性 inJustDecodeBounds,当设置为true后,在调用decode方法。不会把图片读到内存中,我们就可以获得图片的大小,然后很据显示位置的大小设置其压缩比inSampleSize(为1时不压缩)。
// 设置了此属性一定要记得将值设置为false
options.inJustDecodeBounds = true;
Bitmap bitmap = null;
bitmap = BitmapFactory.decodeFile(url, options);
// 判断200是否超过原始图片高度
int be = (int) ((options.outHeight > options.outWidth ? options.outHeight / 150
: options.outWidth / 200));
// 如果超过,则不进行缩放
if (be <= 0)
be = 1;
options.inSampleSize = be;
options.inPreferredConfig = Bitmap.Config.ARGB_4444;
options.inPurgeable = true;
options.inInputShareable = true;
options.inJustDecodeBounds = false;// 再次使用时一定要设置成false,不然Bitmap为空
try {
bitmap = BitmapFactory.decodeFile(url, options);
} catch (OutOfMemoryError e) {
System.gc();
Log.e(TAG, "OutOfMemoryError");
}
然后是压缩,compress(format, quality, stream),BitMap的compress方法的第二个参数,是压缩比例,100表示不压缩,越小压缩越大。