有关bitmap优化问题

转载 2016年08月30日 15:14:51

转载来自:http://blog.csdn.net/arui319/article/details/8489451

Java从JDK1.2版本开始,就把对象的引用分为四种级别,从而使程序能更加灵活的控制对象的生命周期。这四种级别由高到低依次为:强引用、软引用、弱引用和虚引用。

这里重点介绍一下软引用和弱引用。

如果一个对象只具有软引用,那么如果内存空间足够,垃圾回收器就不会回收它;如果内存空间不足了,就会回收这些对象的内存。只要垃圾回收器没有回收它,该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队列(ReferenceQueue)联合使用,如果软引用所引用的对象被垃圾回收,Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

如果一个对象只具有弱引用,那么在垃圾回收器线程扫描的过程中,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。不过,由于垃圾回收器是一个优先级很低的线程,因此不一定会很快发现那些只具有弱引用的对象。弱引用也可以和一个引用队列(ReferenceQueue)联合使用,如果弱引用所引用的对象被垃圾回收,Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

弱引用与软引用的根本区别在于:只具有弱引用的对象拥有更短暂的生命周期,可能随时被回收。而只具有软引用的对象只有当内存不够的时候才被回收,在内存足够的时候,通常不被回收。

在java.lang.ref包中提供了几个类:SoftReference类、WeakReference类和PhantomReference类,它们分别代表软引用、弱引用和虚引用。ReferenceQueue类表示引用队列,它可以和这三种引用类联合使用,以便跟踪Java虚拟机回收所引用的对象的活动。

在Android应用的开发中,为了防止内存溢出,在处理一些占用内存大而且声明周期较长的对象时候,可以尽量应用软引用和弱引用技术。

下面以使用软引用为例来详细说明。弱引用的使用方式与软引用是类似的。

假设我们的应用会用到大量的默认图片,比如应用中有默认的头像,默认游戏图标等等,这些图片很多地方会用到。如果每次都去读取图片,由于读取文件需要硬件操作,速度较慢,会导致性能较低。所以我们考虑将图片缓存起来,需要的时候直接从内存中读取。但是,由于图片占用内存空间比较大,缓存很多图片需要很多的内存,就可能比较容易发生OutOfMemory异常。这时,我们可以考虑使用软引用技术来避免这个问题发生。

首先定义一个HashMap,保存软引用对象。

private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();

 

再来定义一个方法,保存Bitmap的软引用到HashMap。

    public void addBitmapToCache(String path) {

        // 强引用的Bitmap对象

        Bitmap bitmap = BitmapFactory.decodeFile(path);

        // 软引用的Bitmap对象

        SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);

        // 添加该对象到Map中使其缓存

        imageCache.put(path, softBitmap);

    }

 

 

    获取的时候,可以通过SoftReference的get()方法得到Bitmap对象。

    public Bitmap getBitmapByPath(String path) {

        // 从缓存中取软引用的Bitmap对象

        SoftReference<Bitmap> softBitmap = imageCache.get(path);

        // 判断是否存在软引用

        if (softBitmap == null) {

            return null;

        }

        // 取出Bitmap对象,如果由于内存不足Bitmap被回收,将取得空

        Bitmap bitmap = softBitmap.get();

        return bitmap;

    }

 

使用软引用以后,在OutOfMemory异常发生之前,这些缓存的图片资源的内存空间可以被释放掉的,从而避免内存达到上限,避免Crash发生。

需要注意的是,在垃圾回收器对这个Java对象回收前,SoftReference类所提供的get方法会返回Java对象的强引用,一旦垃圾线程回收该Java对象之后,get方法将返回null。所以在获取软引用对象的代码中,一定要判断是否为null,以免出现NullPointerException异常导致应用崩溃。

 

经验分享:

到底什么时候使用软引用,什么时候使用弱引用呢?

个人认为,如果只是想避免OutOfMemory异常的发生,则可以使用软引用。如果对于应用的性能更在意,想尽快回收一些占用内存比较大的对象,则可以使用弱引用。

还有就是可以根据对象是否经常使用来判断。如果该对象可能会经常使用的,就尽量用软引用。如果该对象不被使用的可能性更大些,就可以用弱引用。

另外,和弱引用功能类似的是WeakHashMap。WeakHashMap对于一个给定的键,其映射的存在并不阻止垃圾回收器对该键的回收,回收以后,其条目从映射中有效地移除。WeakHashMap使用ReferenceQueue实现的这种机制。

 

优化系列相关博文:

Android开发优化之——对Bitmap的内存优化

Android开发优化之——使用软引用和弱引用

Android开发优化之——从代码角度进行优化

Android开发优化之——对界面UI的优化(1)

Android开发优化之——对界面UI的优化(2)

Android开发优化之——对界面UI的优化(3)

---------------------------------------------------------------------------

http://blog.csdn.net/arui319

《Android应用开发精解》已出版,本文是初稿的部分内容。欢迎购买阅读。

本文可以转载,但是请保留以上作者信息。

谢谢。

---------------------------------------------------------------------------

转载来自:http://outofmemory.cn/java/OutOfMemoryError/Android-BitmapFactory.decodeStream-method-OutOfMemoryError-solution


我的Android App在执行下面代码时出现了OutOfMemoryError异常

image = BitmapFactory.decodeStream(assetManager.open(imgFilename));

App执行到这一步就会出现OOM异常,异常信息如下:

(...)
08-05 21:22:12.443: I/dalvikvm-heap(2319): Clamp target GC heap from 25.056MB to 24.000MB
08-05 21:22:12.443: D/dalvikvm(2319): GC_FOR_MALLOC freed <1K, 50% free 2709K/5379K, external 18296K/19336K, paused 58ms
08-05 21:22:14.513: D/dalvikvm(2319): GC_EXTERNAL_ALLOC freed <1K, 50% free 2709K/5379K, external 18296K/19336K, paused 101ms
08-05 21:22:14.903: I/dalvikvm-heap(2319): Clamp target GC heap from 25.073MB to 24.000MB
08-05 21:22:14.903: D/dalvikvm(2319): GC_FOR_MALLOC freed 0K, 50% free 2709K/5379K, external 18312K/19336K, paused 53ms
08-05 21:22:22.843: D/ddm-heap(2319): Heap GC request
08-05 21:22:22.963: I/dalvikvm-heap(2319): Clamp target GC heap from 25.073MB to 24.000MB
08-05 21:22:22.963: D/dalvikvm(2319): threadid=1: still suspended after undo (sc=1 dc=1)
08-05 21:22:22.963: D/dalvikvm(2319): GC_EXPLICIT freed 1K, 50% free 2710K/5379K, external 18312K/19336K, paused 116ms

通过DDMS可以看到当时内存堆的使用情况

  • Heap Size:  5.254 MB
  • Allocated:  2.647 MB
  • Free:   2.607 MB
  • %Used:  50.38%
  • #Objects    49,028

  

只要指定到这一行就会出现OutOfMemoryError异常

08-05 21:26:04.783: D/dalvikvm(2319): GC_EXTERNAL_ALLOC freed <1K, 50% free 2710K/5379K, external 18312K/19336K, paused 57ms
08-05 21:26:05.023: E/dalvikvm-heap(2319): 2097152-byte external allocation too large for this process.
08-05 21:26:05.163: I/dalvikvm-heap(2319): Clamp target GC heap from 25.073MB to 24.000MB
08-05 21:26:05.163: E/GraphicsJNI(2319): VM won't let us allocate 2097152 bytes
08-05 21:26:05.163: D/dalvikvm(2319): GC_FOR_MALLOC freed 0K, 50% free 2710K/5379K, external 18312K/19336K, paused 30ms
08-05 21:26:05.283: D/skia(2319): --- decoder->decode returned false

在windows中可以看到图片文件的大小是小于400K的,而BitmapFactory.decodeStream()方法却要试图分配2M的内存。

出现这个异常是因为Android类库在处理图片载入时不是很智能,我们还需要做一些额外的工作。

我测试发现,Drawable.createFromStream方法要不BitmapFactory.decodeStream方法占用更多的内存。

你可以通过修改图片的颜色模式(Color schema)来减少创建图片使用的内存量

BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Config.RGB_565;
Bitmap bitmap = BitmapFactory.decodeStream(stream, null, options);

这个可以参考: http://developer.android.com/reference/android/graphics/Bitmap.Config.html

你也可以通过加载一个缩放之后的图片,来减少创建图片时的内存分配量,但是需要注意图片缩放后可能会损失质量

BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
Bitmap bitmap = BitmapFactory.decodeStream(stream, null, options);

可以参考: http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html 要动态设置图片的inSampleSize,需要先得到图片的尺寸。

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
bitmap = BitmapFactory.decodeStream(stream, null, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
options.inJustDecodeBounds = false;
// recreate the stream
// make some calculation to define inSampleSize
options.inSampleSize = ?;
Bitmap bitmap = BitmapFactory.decodeStream(stream, null, options);

你可以根据用户手机屏幕的大小来计算图片的尺寸,如下代码可以获得手机设备的尺寸。

DisplayMetrics metrics = new DisplayMetrics();
((Activity) activity).getWindowManager().getDefaultDisplay().getMetrics(metrics);
int screenWidth = metrics.widthPixels;
int screenHeight =metrics.heightPixels;

Bitmap优化问题

**在Android项目中,如果直接使用ImageView显示Bitmap会占用较多的资源,如果图片过大,会造成程序崩溃。为了解决这个问题需要对Bitmap进行压缩,以节省内存。因为项目中用到,所以写...

Bitmap性能优化问题

倒影的图片: public static Bitmap createReflectionImageWithOrigin(Bitmap bitmap) { final int reflectionG...

Bitmap内存优化--使用BitmapFactory.options及SoftReference解决OutOfMemory问题

解决Bitmap经常出现OutOfMemory: Android手机分配给App的内存并不是无限的(即最大可用内存),而是有固定限制的, Bitmap会非常占用内存,导致OutofMemory问题,有...

Bitmap内存溢出问题

  • 2015年06月30日 18:26
  • 308B
  • 下载

Android Bitmap内存限制问题

http://hi.baidu.com/lieal/blog/item/d45b068d70d09808b21bba7f.html 最近改bug时遇到了一个问题,一款游戏在被别的程序中断后再返回时会...
  • eustoma
  • eustoma
  • 2011年08月18日 07:43
  • 6284

bitmap内存问题

  • 2012年08月06日 09:42
  • 2KB
  • 下载

高效显示Bitmap图片 减少OOM问题

  • 2014年01月21日 17:15
  • 37KB
  • 下载

Android使用Palette把drawable转为bitmap图像大小改变的问题

项目中要做成以下的效果,本地应用直接使用包名和颜色值遍历找对应,三方应用要去提取app的icon颜色作为背景,首先想到了Android5.0新特性相关的palette。...

一、Bitmap的recycle问题

虽然Android有自己的垃圾回收机制,对于是不是要我们自己调用recycle,还的看情况而定。如果只是使用少量的几张图片,回收与否关系不大。可是若有大量bitmap需要垃圾回收处理,那必然垃圾回收需...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:有关bitmap优化问题
举报原因:
原因补充:

(最多只允许输入30个字)