Android Memory overflow Management and testing

Today, we find that the project is being done, from time to time error: DALVIKVM heap out of memory on a 7458832-byte allocation

Why is memory overflow? I have never met such a situation before. Later on the Internet to check the information, or quite a lot of.

What do you say? Because Android development is basically based on the Java language, the program runs on a Java virtual machine. While the virtual machine does not allow bitmap in a single program to occupy more than 8M of memory, from the log can be seen from the error: 7458832-byte is about 7M more appearance, basically coincide with the above data. A large number of images are used in my project, so the possibility of memory overflow is high because of the picture.

So, here's a solution:

The first scenario:

Android heap memory can also define its own size and optimize heap memory allocations for Dalvik virtual machines (LZ has not tried, but many people on the web say it is feasible ).

To enforce the memory size of your own software, we use the Dalvik.system.VMRuntime class provided by Dalvik to set the minimum heap memory as an example:

Private final static int cwj_heap_size = 6* 1024* 1024;
Vmruntime.getruntime (). Setminimumheapsize (Cwj_heap_size); Sets the minimum heap memory size to 6MB. Of course, the memory crunch can also be handled by manually interfering with the GC.

The second scenario:

Manually reclaim the memory.

The sample code is as follows: bit is Bitmap object

if NULL &&! bit.isrecycled ()) {                    bit.recycle ();                     NULL ;                }
System.GC ();

The Bitmap.recycle () method recycles the memory occupied by the bitmap and invokes the system's garbage collector with System.GC ().

It should be noted that the recovery of memory should be timely, such as Surfaceview, should be in the onsurfacedestroyed this method of recovery. If the activity uses bitmap, it can be recycled in the OnStop or OnDestroy method, and so on.

I'm using this method first, I found that the frequency of bugs appears to be reduced, but still exists.

The third scenario:

Since it is the problem of the picture, it is from the image. is to make the volume size of the picture smaller.

This is also divided into two areas:

1, the resolution is unchanged, the picture size decreases 2, the resolution changes, the picture decreases. (It is easy to use PS)

It is important to note: Do not reduce too small to affect the beauty of the human eye look.

The above three kinds of schemes, the latter two are simpler and commonly used.

In addition, because it is the image of the Android memory problems, then summed up the image-related methods of performance, the results are very rewarding ah ... (I don't know, I see a fright)

The test environment is: Notebook i3 processor, 64-bit Win7 system, test phone for Xiaomi 2S, test image size of 500KB

Compare drawable with bitmap memory size

Comparing the Decoderesource method of Bitmapfactory class with the efficiency of Decodestream method

And the Decoderesource method of the optimized Bitmapfactory class .

Paste the following code and run diagram: (each time you run only one method, hide the other three ways)

 Public classMainactivityextendsActivity {intNumber = 1000;    Drawable[] Array;    Bitmap bitmap[]; @Overrideprotected voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate);         Setcontentview (R.layout.main);        Testdrawable (); //Testbitmap_decoderesource (); //Testbitmap_decodestream (); //Testnewbitmap_decoderesource ();    }    /*** Decoderesource method of the optimized Bitmapfactory class*/    Private voidTestnewbitmap_decoderesource () {bitmap=NewBitmap[number];  for(inti = 0; I < number; i++) {log.i ("", "Test section" + (i + 1) + "picture"); //compression to save bitmap memory space-key steps to fix a bugBitmapfactory.options opts =Newbitmapfactory.options (); Opts.insamplesize= 2;//This value is compressed in multiples (2 integers), the smaller the value, the smaller the compression rate, the clearer the picture//returns the Bitmap object after the original image was decodedBitmap[i] =Bitmapfactory.decoderesource (Getresources (), R.drawable.begin_background, opts); }    }    /*** Decodestream method of Bitmapfactory class*/    Private voidTestbitmap_decodestream () {bitmap=NewBitmap[number];  for(inti = 0; I < number; i++) {log.i ("", "Test section" + (i + 1) + "picture"); Bitmap[i]=Bitmapfactory.decodestream (Getresources (). Openrawresource (R.drawable.begin_background));//Here's the way to change.        }    }    /*** Decoderesource method of Bitmapfactory class*/    Private voidTestbitmap_decoderesource () {bitmap=NewBitmap[number];  for(inti = 0; I < number; i++) {LOG.D ("", "Test section" + (i + 1) + "picture"); Bitmap[i]=Bitmapfactory.decoderesource (Getresources (), r.drawable.begin_background); }    }    /*** Use of drawable*/    Private voidtestdrawable () {array=NewBitmapdrawable[number];  for(inti = 0; I < number; i++) {LOG.W ("", "Test section" + (i + 1) + "picture"); Array[i]=getresources (). getdrawable (R.drawable.begin_background); }    }}

First put out the drawable of the use of the results: (smooth test finished 1000 pictures)

Bitmapfactory Class of Decoderesource method Run Result: (incredibly only 11 photos)

The Decoderesource method for running the optimized Bitmapfactory class is: (46 can be achieved after optimization, and opts.insamplesize = n; The larger the parameter of n is, the more the quantity can be reached, but the image quality is lost.

Decodestream method for Bitmapfactory class: (Up to 22 pictures)

Now, I believe you have an intuitive understanding of the performance of these methods related to images in Android. In fact, in the test in addition to see the number, you can also see the gap in the running time.