Android Notes------Picture oom

Reprinted from: http://blog.csdn.net/sevensundark/article/details/7519169

I have been tossing Bitmap-related memory overflow issues for a while, so I will make a brief summary of my feelings and experience in debugging and solving.
(The memory consumption mechanism of Bitmap will not be explained in detail, probably the memory related to Bitmap is native heap, which is different from Davilk heap, because native heap is not controlled by java gc, so it must be released manually)

1. Using the cavans in the ondraw method of the picture component to draw,
      especially when you need to control the frequent refresh of the picture (such as zooming, rotating, etc.), the way of constantly creating new Bitamp objects is very bad, even if the memory is released in time , the risk of frequent create is too high, which can be achieved by using Matrix and Canvas to manipulate a Bitmap object.

2. Release the bitmap object in time.
       Pay attention to the recycle release of the bitmap object as an intermediate variable. If necessary, consider calling System.gc() to notify the system to perform garbage collection more "actively".

3. When operating the bitmap object, reduce the creat and copy of the bitmap. And other operations, the operation considers whether the meta bitmap object can be reused
      to minimize Bitmap.createBitmap, bitamp.copy and other operations, that is, reduce the creation of Bitmap intermediate variables as much as possible. On the premise that the meta bitmap object is reusable, try to avoid the overhead of new memory.
      Here is a related example:
CustomImgView.java Custom ImageView
[java] view plain copy print?
public Bitmap getBitmap() { 
         
        // mBitmap is a global variable 
        if (mBitmap != null && !mBitmap.isRecycled()) 
        { 
            mBitmap.recycle(); 
            mBitmap = null; 
        } 
         
        mBitmap = Bitmap. createBitmap(w, h, f); 
        Canvas canvas = new Canvas(mBitmap); 
         
        // draw on the canvas 
        ........ 
        canvas.drawBitmap(mSrcBitmap, src, dest, bmp); 
 
        return mBitmap; 
    } 

Save.java related code snippets
[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); 
It can be seen that Save first obtains the bitmap object through CustomImgView, and then scales it.
In fact, it can be found that in CustomImgView, in order to generate the required bitmap, a temporary mBitmap is put into a temporary mBitmap and drawn on the canvas. In Save, the bitmap obtained and zoomed are also operated through the canvas, and the two can obviously be merged together.
Take another look at the optimized code. The
CustomImgView.java method has been renamed
[java] view plain copy print?
public void drawInto(Canvas canvas, int inWidth, int inHeight) { 
    float scaleW = w; 
    float scaleH = h; 
        ... ..... 
    // After zooming, the canvas draws 
    canvas.drawBitmap(mSrcBitmap, src, midRect, bmp); 
} 

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

Remove the redundant bitmap variables and the code is cleaner.
In fact, in this case, in order to realize the function in the early stage, it is often easy to ignore the Bitmap memory. In the later stage of the project, to solve the memory release, there are indeed many problems in this area, so mark...

4. Minimize and avoid the global variables of Bitmap type, and pay attention to release even if there are

5. Avoid frequent reading of decodeResouce and decodeStream Calling, considering the reusability of resource reading
       mainly refers to the same image resource, avoiding frequent BitmapFactory.decodeResouce, BitmapFactory.decodeStream to read resources, considering reusability

6. Avoid the risk of occupying memory
      in the code should pay attention Risk of high memory usage. For example: the logic requires to generate a Bitmap A first, which is only a temporary bitmap, and then calculate and generate Bitmap B based on it. However, under certain conditions, the generated A and B will be the same, and we need to judge this situation to avoid To generate redundant and useless bitmaps, even temporary Bitmap A will be released immediately, but "in an instant, the program consumes a lot of memory"

7. Consider using image file access to bypass the high memory consumption of Bitmap operations.
      For example, logic It is necessary to keep a copy of a large picture in it to ensure that it can be restored at any time, but the frequency of use is not very high, you can consider saving it as a file, and then read it when you want to use it, so as to avoid large pictures occupying memory all the time

8. Establish a cache Array to avoid memory consumption caused by repeated decoding of pictures
      It is mainly used in the adapter. The pictures in the display range will be re-decoded and displayed in the getView method. You can build a Bitmap cache array and record it in the array when the picture is displayed for the first time, so as to avoid the re-decoding of the picture when it is displayed again later. .

9.
     It is estimated that there is no way to reduce the size (resolution) of the material and picture resources. According to the needs, discard the high-resolution pictures and reduce the memory consumption of the picture material display. Debug the code used to view the heap memory by

yourself :
    Debug. getNativeHeapSize() The total memory size of the current process's navtive heap itself
    Debug.getNativeHeapAllocatedSize() The used memory size of the
    current process's navtive heap