OOM内存溢出(转)

时间:2022-02-15 16:44:03

突然出现的Out Of Memory这个BUG导致我们项目中断了好几天,在经过不断地摸索之后,今天终于得到了解决。鉴于其强大的破坏力与多发性(尤其是当开发图形丰富的软件时),在此将解决方法同大家分享,希望大家以后少走弯路,而本人水平有限,如有不当,还望指教!
  内存溢出将抛出如下异常:
  java.lang.OutOfMemoryError: bitmap size exceds VMbudget....
  按我们的经验一行一行地分析,发现了报错的原因:bitmap size exceeds VM budget,
  中文意思是bitmap占用的内存大小超过了虚拟机(DVM)的允许值。
  经过信息检索,我弄清了这样一个事实:Android虚拟机不允许单个程序中的Bitmap占用超过8M的内存,一旦超过了就会报错,
  而报的错正是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内存溢出问题,但是具体情况还是要具体分析。 
  第三种方案 : 对图片采用软引用,及时地进行recyle()操作
   
  SoftReference<Bitmap> bitmap;
  bitmap = new SoftReference<Bitmap>(pBitmap);
  if(bitmap != null){
  if(bitmap.get() != null && !bitmap.get().isRecycled()){
  bitmap.get().recycle();
  bitmap = null;
  }
  }
  第四种方案 : 对复杂的listview or gridview进行合理设计与编码:
   1. 注意重用Adapter里面的 convertView 以及holder机制的运用 ----- 参考资料: api demo list 14. Efficient Adapter
  public View getView(int position, View convertView, ViewGroup parent) {
  if (convertView == null) {
  v = mInflater.inflate(resource, parent, false);
  final int[] to = mTo;
  final int count = to.length;
  final View[] holder = new View[count];
  for (int i = 0; i < count; i++) {
  holder = v.findViewById(to);
  }
  v.setTag(holder);
  } else {
  }
  }
  第五种方案: 单个页面,横竖屏切换N次后 OOM
   1. 看看页面布局当中有没有大的图片,比如背景图之类的。去除xml中相关设置,改在程序中设置背景图(放在onCreate()方法中):
  Drawable bg = getResources().getDrawable(R.drawable.bg);
  XXX.setBackgroundDrawable(rlAdDetailone_bg);
  在Activity destory时注意,bg.setCallback(null); 防止Activity得不到及时的释放
  2. 跟上面方法相似,直接把xml配置文件加载成view 再放到一个容器里,然后直接调用 this.setContentView(View view);方法
  避免xml的重复加载
  第六种方案:自定义Android堆内存大小和优化Dalvik虚拟机的堆内存分配 
  注意若使用这种方法:project build target 只能选择 <= 2.2 版本,否则编译将通不过。 所以不建议用这种方式 
  private final static int CWJ_HEAP_SIZE= 6*1024*1024;
  private final static float TARGET_HEAP_UTILIZATION = 0.75f;
  VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);//自定义Android堆内存大小 
  VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);//优化Dalvik虚拟机的堆内存分配
  第七种方案:尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图。
  因此,改用先通过BitmapFactory.decodeStream方法,创建出一个bitmap,再将其设为ImageView的 source,
  decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode,
  无需再使用java层的createBitmap,从而节省了java层的空间。
  如果在读取时加上图片的Config参数,可以跟有效减少加载的内存,从而跟有效阻止抛out of Memory异常
  另外,decodeStream直接拿的图片来读取字节码了, 不会根据机器的各种分辨率来自动适应, 
  使用了decodeStream之后,需要在hdpi和mdpi,ldpi中配置相应的图片资源, 
  否则在不同分辨率机器上都是同样大小(像素点数量),显示出来的大小就不对了。