Android遇到内存溢出（Out Of Memory）BUG的经验与解决方法

突然出现的Out Of Memory这个BUG导致我们项目中断了好几天，在经过不断地摸索之后，今天终于得到了解决。鉴于其强大的破坏力与多发性（尤其是当开发图形丰富的软件时），在此将解决方法同大家分享，希望大家以后少走弯路，而本人水平有限，如有不当，还望指教！
那么，首先让我们来看看遇到这个BUG时系统输出的Log:

[java]  view plain copy

1. 01-02 12:01:59.732  8388  8388 E AndroidRuntime: FATAL EXCEPTION: main  
2. 01-02 12:01:59.732  8388  8388 E AndroidRuntime: java.lang.OutOfMemoryError  
3. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)  
4. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:503)  
5. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:356)  
6. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:800)  
7. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.content.res.Resources.loadDrawable(Resources.java:2915)  
8. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.content.res.Resources.getDrawable(Resources.java:1264)  
9. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.drawable.AnimationDrawable.inflate(AnimationDrawable.java:282)  
10. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.drawable.Drawable.createFromXmlInner(Drawable.java:901)  
11. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.graphics.drawable.Drawable.createFromXml(Drawable.java:837)  
12. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.content.res.Resources.loadDrawable(Resources.java:2897)  
13. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.content.res.Resources.getDrawable(Resources.java:1264)  
14. 01-02 12:01:59.732  8388  8388 E AndroidRuntime:    at android.view.View.setBackgroundResource(View.java:14762)  

按我们的经验一行一行地分析，发现了报错的原因：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内存可以用到以下代码

[java]  view plain copy

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的地方进行了修改，用到了以下方法：

[java]  view plain copy

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内存溢出问题，但是具体情况还是要具体分析。

转：http://blog.csdn.net/ekechang/article/details/6706602