突然出现的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中配置相应的图片资源， 否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。