Image optimization for android memory optimization

Manipulate the image itself. Try not to use setImageBitmap, setImageResource, BitmapFactory.decodeResource to set up a large image, because these methods end up using createBitmap in the java layer after decode and consume more memory. Instead, create an bitmap using the BitmapFactory.decodeStream method and set it to source of ImageView. The biggest secret of decodeStream is that it calls JNI directly > > nativeDecodeAsset() to complete decode, eliminating the need to use createBitmap in java layer, thus saving space in java layer. If you add the Config parameter of the image when reading, you can reduce the memory load more effectively, thus preventing the memory exception from being thrown more effectively. In addition, decodeStream directly takes pictures to read bytecode, and will not automatically adapt according to the various resolutions of the machine. After using decodeStream, it is necessary to configure the corresponding image resources in hdpi, mdpi and ldpi. Otherwise, it is the same size (number of pixels) on the machine with different resolutions, and the size displayed will be wrong.

 
InputStreamis=this.getResources().openRawResource(R.drawable.pic1); 
BitmapFactory.Optionsoptions=newBitmapFactory.Options(); 
options.inJustDecodeBounds=false; 
options.inSampleSize=10;//width . hight Let's make it the original 10 points 1 
Bitmapbtp=BitmapFactory.decodeStream(is,null,options); 

 
if(!bmp.isRecycle()){ 
bmp.recycle()// Reclaim the memory occupied by the image  
system.gc()// Remind the system to timely recall  
} 

 
/** 
* Read pictures of local resources in the most provincial way  
*@paramcontext 
*@paramresId 
*@return 
*/ 
publicstaticBitmapreadBitMap(Contextcontext,intresId){ 
BitmapFactory.Optionsopt=newBitmapFactory.Options(); 
opt.inPreferredConfig=Bitmap.Config.RGB_565; 
opt.inPurgeable=true; 
opt.inInputShareable=true; 
// Get resource images  
InputStreamis=context.getResources().openRawResource(resId); 
returnBitmapFactory.decodeStream(is,null,opt); 
} 

The value in option refers to the scale of the image. The value of 2 is recommended in SDK. The larger the value, the less clear the image. The length and width are only 1/2 of the original picture. As the image size decreases, so does the memory footprint. The downside of this is that the image quality gets worse, and the higher the inSampleSize value, the worse the image quality. The quality of the zoom images on different phones may vary due to the different algorithms used by each phone manufacturer. I've seen pictures on the moto phone scale to acceptable quality, the same scale on the 3-star phone, but much worse quality.

There are four types of Android, :
ALPHA_8:1byte memory per pixel
ARGB_4444: 2byte memory per pixel
ARGB_8888: 4byte memory per pixel
RGB_565: 2byte memory per pixel
The default color mode of Android is ARGB_8888, which is the most delicate color mode and the highest display quality. But again, the memory footprint is the largest.
The above code is read 1.png in ARGB_4444 mode. The memory reduction is not as significant as in the first method, but for most images, there is no difference between ARGB_8888 mode and ARGB_8888 mode. However, a color bar may appear when reading an image with a gradient effect. In addition, will affect the image of the special effects processing.
Optimize heap memory allocation for Dalvik virtual machines. For the Android platform, the DalvikJavaVM used by the Android hosting layer can be optimized in many ways from the current performance. For example, we may consider manually interfering with GC processing in the development of some large games or resource-consuming applications. The setTargetHeapUtilization method provided by dalvik.system.VMRuntime class can enhance the processing efficiency of the program heap memory. Usage:

 
privatefinalstaticfloatTARGET_HEAP_UTILIZATION=0.75f; 
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 

Can.
Also, you can define the size of the heap memory.

 
privatefinalstaticintCWJ_HEAP_SIZE=6*1024*1024;VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);// Set the minimum heap Memory for 6MB The size of the  

Call the image recycle() method:
This is not really a way to actually reduce the memory of the image. The main purpose is to mark the image object and facilitate the recovery of the local data of the image object. The local data of the image object takes up the largest amount of memory and is calculated separately from the memory of the Java part of the program. So it often happens that Javaheap is enough to use, while OutOfMemoryError occurs in pictures. Calling this method when the image is not in use can effectively reduce the peak value of the image local data, thereby reducing the probability of OutOfMemoryError. However, the image object that calls recycle() is in a "defunct" state, causing a program error. So this method is not recommended if there is no guarantee that the image object will never be called again. In particular, note that picture objects that have been assigned to the control using the setImageBitmap(Bitmapimg) method may be called by the system class library, causing a program error.

USES the Matrix object to zoom in on the image to change the color mode :
While zooming in on an Matrix object is bound to consume more memory, it is sometimes necessary to do so. The enlarged image USES ARGB_8888 color mode, even if the original image is ARGB_4444 color mode also one, and there is no way to directly specify the color mode when zooming in. You can change the image color pattern in the following ways.
The following code

 
Matrixmatrix=newMatrix(); 
floatnewWidth=200;// The width of the enlarged image  
floatnewHeight=300;// The length of the enlarged image  
matrix.postScale(newWidth/img.getWidth(),newHeight/img.getHeight()); 
Bitmapimg1=Bitmap.createBitmap(img,0,0,img.getWidth(),img.getHeight(),matrix,true);// Get an enlarged image  
img2=img1.copy(Bitmap.Config.ARGB_4444,false);// get ARGB_4444 Color pattern of the picture  
img=null; 
img1=null; 

An extra image object, img1, is generated over the original image. But the system will automatically reclaim img1, so the actual memory is still reduced.