[Android] Bitmap OOM解决办法二

忽然出现的Out Of Memory这个BUG致使咱们项目中断了好几天,在通过不断地摸索以后,今天终于获得了解决。鉴于其强大的破坏力与多发性(尤为是当开发图形丰富的软件 时),在此将解决方法同你们分享,但愿你们之后少走弯路,而本人水平有限,若有不当,还望指教!测试

那么,首先让咱们来看看遇到这个BUG时系统输出的Log:spa

按咱们的经验一行一行地分析,发现了报错的缘由:bitmap size exceeds VM budget,设计

中文意思是bitmap占用的内存大小超过了虚拟机(DVM)的容许值。code

带着这个信息,我去问谷哥和度娘,果真有大把大把的人遇到了这个问题,有的人还长久以来身陷其中,难以自拔~~对象

而解决方案则是五花八门,可是有的网友却反映这些网上通用的解决方案彻底没做用!?图片

我并无尝试全部网上的解决方法,在尝试了部分以后确实没有起到多少做用,该出BUG的地方照出不误,内存

搞得我甚至有点怀疑这是Google的一个设计缺陷。开发

通过信息检索,我弄清了这样一个事实:Android虚拟机不容许单个程序中的Bitmap占用超过8M的内存,一旦超过了就会报错,get

而报的错正是bitmap size exceeds VM budget.虚拟机

如今好了,这一切看似如此简单:要想程序的bitmap小于8M,要么就在用了bitmap后当即回收这部份内存,要么就压缩图片的大小啊。

依据这两点思路,我在个人项目中进行了实践。

(通常而言,只用这两种方法就能够解决大部分Out Of Memory的BUG,若是还不能解决,请继续往下看)

第一种方法--及时回收bitmap内存:

通常而言,回收bitmap内存能够用到如下代码

  1. if(bitmap != null && !bitmap.isRecycled()){

  2. bitmap.recycle();

  3. bitmap = null;

  4. }

  5. System.gc();

bitmap.recycle()方法用于回收该bitmap所占用的内存,接着将bitmap置空,最后,别忘了用System.gc()调用一下系统的垃圾回收器。

在这里要声明一下,bitmap能够有多个(觉得着能够有多个if语句),但System.gc()最好只有一个(因此我将它写在了if语句外),由于System.gc()

每次调用都要将整个内存扫描一遍,于是若是屡次调用的话会影响程序运行的速度。为了程序的效率,我将它放在了全部回收语句以后,

这样已经起到了它的效果,还节约的时间。

回收bitmap已经知道了,那么“及时”怎么理解呢?

根据个人实际经验,bitmap发挥做用的地方要么在View里,要么在Activity里(固然确定有其余区域,可是原理都是相似的),

回收bitmap的地方最好写在这些区域刚刚不使用bitmap了的时刻。

好比说View若是使用了bitmap,就应该在这个View再也不绘制了的时候回收,或者是在跳转到的下一个区域的代码中回收;

再好比说SurfaceView,就应该在onSurfaceDestroyed这个方法中回收;

同理,若是Activity使用了bitmap,就能够在onStop或者onDestroy方法中回收......

结合以上的共同点,“及时回收”的原理就是在使用了bitmap的区域结束时或结束后回收。

第二种方法--压缩图片:

这个方法固然很简单了,就是使图片体积大小变小,

能够有两种方式:

一种是使图片质量下降(分辨率不变),

另外一种是使图片分辨率下降(分辨率改变)。

总之,使图片大小变小就好了。

实践证实,使图片质量下降(分辨率不变)能够大幅度地减少体积,并且质量的差别肉眼看上去并不明显。

我刚开始使用的就是这两种方法,原理很简单,但是,个人BUG发生虽然没那么频繁了,可是它依然存在!!

后来通过几天的努力与尝试,结合我项目的一些具体状况,我终于解决了这个使人头痛的BUG,可是事实却有点出乎个人意料。

当我使用了上述两种方法BUG依然还没解决的时候,我开始怀疑,bitmap超过8M会报错,可如今我把前先后后的bitmap都回收了,

不可能还有8M了,那为何还会报错呢?

终于我发现了这个缘由:当内存中已经被一些bitmap使用过以后,不管被回收与否,它都会变得特别“敏感”,这个时候,

若是bitmap忽然要占用大量的内存,即便和以前已经剩下的内存加起来不到8M,系统也会报错,缘由是它变“敏感”了!

我不知道这个用底层原理如何解释比较好,可是我想“敏感”这个词应该能够很形象地进行解释。

因而,为了顺应内存的“敏感性”,我将那个须要同时装载多个大致积bitmap的地方进行了修改,用到了如下方法:

  1. //压缩,用于节省BITMAP内存空间--解决BUG的关键步骤

  2. BitmapFactory.Options opts = new BitmapFactory.Options();

  3. opts.inSampleSize = 2; //这个的值压缩的倍数(2的整数倍),数值越小,压缩率越小,图片越清晰

  4.  

  5. //返回原图解码以后的bitmap对象

  6. bitmap = BitmapFactory.decodeResource(Context, ResourcesId, opts);

即先将图片缩小一倍,再将这缩小了一倍的图片做为bitmap存入内存,这样一来,它占用的bitmap内存大大减少。

后来经测试,BUG果真解决了。图片缩小一倍后,顺应了内存的“敏感性”,也就不会再报错了。

以上方法应该足以解决大多数bitmap内存溢出问题,可是具体状况仍是要具体分析。

相关文章
相关标签/搜索