突然出现的Out Of Memory这个BUG导致我们项目中断了好几天,在经过不断地摸索之后,今天终于得到了解决。鉴于其强大的破坏力与多发性(尤其是当开发图形丰富的软件 时),在此将解决方法同大家分享,希望大家以后少走弯路,而本人水平有限,如有不当,还望指教!
那么,首先让我们来看看遇到这个BUG时系统输出的Log:
按我们的经验一行一行地分析,发现了报错的原因:bitmap size exceeds VM budget,
中文意思是bitmap占用的内存大小超过了虚拟机(DVM)的允许值。
带着这个信息,我去问谷哥和度娘,果然有大把大把的人遇到了这个问题,有的人还长久以来身陷其中,难以自拔~~
而解决方案则是五花八门,但是有的网友却反映这些网上通用的解决方案完全没作用!?
我并没有尝试所有网上的解决方法,在尝试了部分之后确实没有起到多少作用,该出BUG的地方照出不误,
搞得我甚至有点怀疑这是Google的一个设计缺陷。
经过信息检索,我弄清了这样一个事实:Android虚拟机不允许单个程序中的Bitmap占用超过8M的内存,一旦超过了就会报错,
而报的错正是bitmap size exceeds VM budget.
现在好了,这一切看似如此简单:要想程序的bitmap小于8M,要么就在用了bitmap后立即回收这部分内存,要么就压缩图片的大小啊。
依据这两点思路,我在我的项目中进行了实践。
(一般而言,只用这两种方法就可以解决大部分Out Of Memory的BUG,如果还不能解决,请继续往下看)
第一种方法--及时回收bitmap内存:
一般而言,回收bitmap内存可以用到以下代码
- if(bitmap != null && !bitmap.isRecycled()){
- bitmap.recycle();
- bitmap = null;
- }
- 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的地方进行了修改,用到了以下方法:
- //压缩,用于节省BITMAP内存空间--解决BUG的关键步骤
- BitmapFactory.Options opts = new BitmapFactory.Options();
- opts.inSampleSize = 2; //这个的值压缩的倍数(2的整数倍),数值越小,压缩率越小,图片越清晰
- //返回原图解码之后的bitmap对象
- bitmap = BitmapFactory.decodeResource(Context, ResourcesId, opts);
即先将图片缩小一倍,再将这缩小了一倍的图片作为bitmap存入内存,这样一来,它占用的bitmap内存大大减小。
后来经测试,BUG果然解决了。图片缩小一倍后,顺应了内存的“敏感性”,也就不会再报错了。
以上方法应该足以解决大多数bitmap内存溢出问题,但是具体情况还是要具体分析。
相关推荐
android bitmap outofMemory 用来解决android中常见的bitmap outOfMemory
主要为大家详细介绍了Android避免内存溢出Out of Memory方法汇总,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
基本上解决了OOM问题 如果 方便可以直接引用BitmapManager类到 项目中使用 解决blog 地址http://www.cnblogs.com/liongname/articles/2345087.html
uniapp项目体量过大时,打包H5会报错, - process out of memory 解决放案: 替换HBuildX内置\HBuilderX\plugins\node\node.exe版本 添加\HBuilderX\plugins\compile-node-sass\node_modules\node-sass-china\...
android加载大量图片内存溢出的三种解决办法
android 图片下载 有效解决内存溢出问题 android 图片下载 有效解决内存溢出问题
Android webview 内存泄露的解决方法 最近在activity嵌套webview显示大量图文发现APP内存一直在涨,没法释放内存,查了很多资料,大概是webview的一个BUG,引用了activity导致内存泄漏,所以就尝试传递...
Android防止内存溢出浅析.zip
在我们试图新建一个对象时,而垃圾收集器又找不到任何可用内存时被抛出,这种情况下我们是可以捕获该 异常的; 另一种情况是,CLR需要内存时,而却系统却不能提供,也会抛出该异常. 但此时,我们的应用程序是不能捕获该...
OOM全称”Out Of Memory”,即内存溢出。 内存溢出已经是软件开发历史上存在了近40年的“老大难”问题。在操作系统上运行各种软件时,软件所需申请的内存远远超出了物理内存所承受的大小,就叫内存溢出。 内存溢出...
一个android小工程,里面有我自己写的一个工具类,可以轻松避免加载图片列表内存溢出,分享给需要的朋友,工程使用android 1.6SDK完成
针对Android应用中Gallery内存溢出的解决方案
Android防止内存溢出浅析
kettle内存溢出(Java heap space)以及解决方法
解决内存溢出的问题,在使用myeclipse时候,经常遇到内存溢出的问题。
Bitmap bitmap = BitmapFactory.decodeFile(imageFile, opts); 设置inJustDecodeBounds为true后,decodeFile并不分配空间,但可计算出原始图片的长度和宽度,即opts.width和opts.height。有了这两个参数,再通过...
使用BitmapFactory加载图片时,如果图片过大可能引起OutOfmemory溢出的问题。解决办法。
Android有效解决加载大图片时内存溢出的问题
myeclipse内存溢出解决方法 非常好用