Android随记------图片oom

转自：http://blog.csdn.net/sevensundark/article/details/7519169

近段时间一直在折腾Bitmap相关的内存溢出问题，就调试解决中的感受和经验做个简单的总结。
（关于Bitmap的内存消耗机制就不作详细说明，大概就是Bitmap关系到的内存是native heap，它与Davilk heap有所区别，因为native heap并不受java gc的控制，所以必须手动去释放)

1.利用图片组件的ondraw方法中cavans进行绘制
      尤其是在需要控制图片的频繁刷新（比如放大，旋转等）时，不断创建新的Bitamp对象的方式是非常糟糕的，即使在代码中进行及时的内存释放，频繁的create风险太高，可以通过利用Matrix、Canvas操纵一个Bitmap对象来实现。

2.及时释放bitmap对象
       注意对作为中间变量的bitmap对象的recycle释放，必要时考虑调用System.gc（）通知系统更“积极”地进行垃圾回收

3.操作bitmap对象时，减少bitmap的creat，copy等操作，操作考虑是否能重用元bitmap对象
      尽量减少Bitmap.createBitmap，bitamp.copy等操作，也就是尽可能减少Bitmap中间变量的创建。在元bitmap对象可重用的前提下，尽量避免新内存的开销
      这有个相关的例子：
CustomImgView.java     自定义ImageView
[java] view plain copy print?
public Bitmap getBitmap() { 
         
        // mBitmap 为全局变量 
        if (mBitmap != null && !mBitmap.isRecycled()) 
        { 
            mBitmap.recycle(); 
            mBitmap = null; 
        } 
         
        mBitmap = Bitmap.createBitmap(w, h, f); 
        Canvas canvas = new Canvas(mBitmap); 
         
        // 在画布上进行绘制 
        ........ 
        canvas.drawBitmap(mSrcBitmap, src, dest, bmp); 
 
        return mBitmap; 
    } 

Save.java   相关的代码片段
[java] view plain copy print?
Bitmap highRes=v.getBitmap(); 
                     
if (highRes == null) continue; 
 
Matrix matrix = new Matrix(); 
matrix.postScale(w, h); 
canvas.drawBitmap(highRes, matrix, paint); 
可见，Save先通过CustomImgView取得bitmap对象，然后进行缩放处理。
其实可以发现，CustomImgView中为了生成所需的bitmap投入一个临时的mBitmap并在canvas上进行绘制，而Save里，得到这个bitmap进行缩放也还是通过canvas操作的，两个明显可以合并在一起。
再看一下优化后的代码
CustomImgView.java  方法换了个名字
[java] view plain copy print?
public void drawInto(Canvas canvas, int inWidth, int inHeight) { 
    float scaleW = w; 
    float scaleH = h; 
        ........ 
    // 缩放处理后，canvas绘制 
    canvas.drawBitmap(mSrcBitmap, src, midRect, bmp); 
} 

Save.java
[java] view plain copy print?
CustomImgView v = (CustomImgView) view; 
v.drawInto(w, h); 

去掉多余的bitmap变量，代码也变干净了。
其实这种情况，也是前期为了实现功能，往往就会容易忽略了Bitmap内存。项目后期，解决内存释放，也确实遇到这方面比较多的问题，就此马克...

4.尽量减少并避免Bitmap类型的全局变量，即使有也注意释放

5.避免decodeResouce，decodeStream的读取频繁调用，考虑资源读取时的复用性
       主要是指对同一图片资源，避免频繁的BitmapFactory.decodeResouce、BitmapFactory.decodeStream来读取资源，考虑复用性

6.避免占用内存的风险
      在代码中应该注意占用高内存的风险。例如：逻辑要求先生成一个Bitmap A，它只是临时bitmap，再在它基础上计算生成Bitmap B,可在某种条件下，产生出来的A和B会是一样的，我们需要判断这种场合避免进行多余无用的bitmap产生，即便是临时Bitmap A会即时释放，可“在瞬间这边程序是耗费着大内存”

7.考虑利用图片文件的存取来绕开Bitmap操作的高内存消耗
      例如，逻辑里要保持一个大图片的副本，保证随时能恢复，但使用的频率不是很高，可以考虑将它保存成文件，等到要使用的时候再读取，避免大图片一直占用着内存

8.建立缓存数组，避免图片重复解码造成的内存消耗
      主要是用在adaptor中的，在显示范围内的图片，会在getView方法中重新解码显示，可以构建Bitmap缓存数组在图片首次显示的时候记录进数组中，避免后面再次显示时的图片的重新解码。

9.降低素材图片资源大小（分辨率）
     这个估计也是“没有办法的办法”了，根据需要摒弃过高分辨率图片，降低图片素材显示的内存消耗

自己调试用来查看堆内存的代码：
    Debug.getNativeHeapSize()       当前进程navtive堆本身总的内存大小
    Debug.getNativeHeapAllocatedSize()       当前进程navtive堆中已使用的内存大小
    Debug.getNativeHeapFreeSize()       当前进程navtive堆中剩余的内存大小