Android Memory optimizer 1-memory optimization for bitmap

In Android apps, the most memory-intensive is the picture resource. And on Android, when reading bitmap bitmap, the stack size of the pictures in the virtual machine is only 8M, and if exceeded, a outofmemory exception occurs. Therefore, the memory optimization of the image is an important part of Android application development.

1) to recover bitmap memory in time

The bitmap class has a method recycle (), which can be seen from the method name meaning recycling. There is a question here, the Android system has its own garbage collection mechanism, can be collected from time to time not to use the memory space, of course, including bitmap space. Then why do you need this method?

The construction method of the bitmap class is private, so the developer cannot directly create a bitmap object, but only through the various static methods of the Bitmapfactory class to instantiate a bitmap. Looking closely at the source code of Bitmapfactory, you can see that the resulting bitmap object is eventually implemented by JNI invocation . So, after loading bitmap into memory, it contains two parts of the memory area. To put it simply, part of the Java part is part C. This bitmap object is allocated by the Java section, the system will be automatically recycled when not used, but the corresponding C available memory area, the virtual machine is not directly recoverable, this can only invoke the underlying function release. Therefore, the recycle () method needs to be called to release the memory of part C. From the source code of the bitmap class, it is also possible to see that the Recycle () method does invoke the Jni method.

So if you don't call recycle (), is there a memory leak? It's not. Each Android application runs in a separate process with independent memory, and if the entire process is applied itself or the system kills, the memory is freed and of course the C part of the memory is included.

Android's management of the process is very complex. Simply put, the process of the Android system is divided into several levels, and the system will kill some low-priority processes in case of insufficient memory to provide sufficient memory space for other processes. In the actual project development process, some developers will use Process.killprocess (Process.mypid ()) when exiting the program to kill their own process, but some applications will only use the call Activity.finish () method to shut down all activity.

Experience Sharing: Android phone users, depending on the habits, may have two ways to quit the entire application: one is to press the home button to go directly to the desktop, the other is from the application Exit button or press the back key to quit the program. So what is the difference between these two approaches from a system perspective? By pressing the home key, the application is not turned off, but it becomes a background application. By pressing the back key, the application is generally closed, but the process has not been killed, but it has become an empty process (the program itself does not take into account the special handling of the exit). The Android system has done a lot of process management work, which has been able to meet the needs of users. Personally, the application does not need to manually kill its own process when exiting the app. For the process management of the application itself, give it to the Android system to handle it. What the application needs to do is to try to do the memory management work of the program itself.

In general, if you can get a reference to a bitmap object, you need to call Bitmap's recycle () method in a timely manner to free up the memory space bitmap occupies, instead of waiting for the Android system to release.

The following is a sample code fragment that frees bitmap.

First determine if it has been recycled if (bitmap! = null &&!bitmap.isrecycled ()) { Recycle and set to NULL Bitmap.recycle (); bitmap = null; } System.GC ();

As can be seen from the code above, the Bitmap.recycle () method is used to reclaim the memory occupied by the bitmap, then the bitmap is empty, and finally the garbage collector of the system is called using System.GC () to recycle, which can be notified to the garbage collector as soon as possible. It is important to note that calling System.GC () does not guarantee that the recycling process will begin immediately, but only to expedite the recovery.

How to call the Recycle () method for recycling has been understood, then when to release bitmap memory more appropriate? In general, if the code is no longer required to use the bitmap object, it can be freed. Once the memory is freed, the bitmap object can no longer be used and, if used again, throws an exception. So be sure to release it when you're not using it. For example, if you use bitmap in an activity, you can recycle it in the activity's OnStop () or OnDestroy () method.

2) Catching exceptions

Because bitmap is eating large memory, in order to avoid the application in allocating bitmap memory when the OutOfMemory exception occurs after crash off, you need to pay special attention to instantiate the bitmap part of the code. In general, you must capture OutOfMemory exceptions in the code that instantiates bitmap.

The following is a code example.

Bitmap Bitmap = null; try { Instantiate bitmap Bitmap = bitmapfactory.decodefile (path); } catch (OutOfMemoryError e) { // } if (bitmap = = null) { Returns the default Bitmap object if the instantiation fails return defaultbitmapmap; }

The outofmemory exceptions that may occur during the initialization of the bitmap object are captured here. If an outofmemory exception occurs, the app does not crash, but it gets a default bitmap diagram.

Experience Sharing: Many developers will habitually capture exception directly in the code. But for OutOfMemoryError, this is not captured. Because OutOfMemoryError is an error, not a exception. Just make a reminder to avoid writing the wrong code and not capturing OutOfMemoryError.

3) Caching of common bitmap objects

Sometimes, you may need to use the same image multiple times in an activity. For example, an activity will show a list of users ' avatars, and if the user does not set the avatar, a default avatar will be displayed, which is in the resource file of the application itself.

If you have a scenario like the one above, you can cache the same bitmap. If you do not cache, although you see the same picture file, but using the Bitmapfactory class method to instantiate the bitmap, is a different bitmap object. Caching avoids the waste of memory by avoiding creating multiple bitmap objects.

Experience Sharing: Web developers are familiar with caching techniques. In fact, during the development of Android application, the technology of caching is often used. Here the cache has two levels, one is the hard disk cache, and the other is the memory cache. For example, in the development of network applications, some data obtained from the network can be saved to the SD card, the next time directly from the SD card read, not read from the network, thereby saving network traffic. This is how the hard disk is cached. For example, applications often use the same object, or they can be cached in memory and read directly from memory when needed. This approach is memory caching.

4) Compress picture

If the picture pixel is too large, the process of instantiating bitmap using the Bitmapfactory class method requires a memory space greater than 8M, and a OutOfMemory exception is bound to occur. What should be handled at this time? If this is the case, you can narrow the picture to reduce the use of memory in the process of loading the picture to avoid the occurrence of an exception.

You can use Bitmapfactory.options to set Insamplesize to narrow your picture. The property value insamplesize indicates that the thumbnail size is one of a fraction of the original picture size. That is, if the value is 2, then the width and height of the thumbnail are taken to be 1/2 of the original image, and the image size is 1/4 of the original size.

If you know that the picture's pixels are too large, you can narrow it down. So how do you know the picture is too big?

Use Bitmapfactory.options to set Injustdecodebounds to True, then use DecodeFile () and other methods, do not really allocate space, that is, the decoded bitmap is null, However, you can calculate the width and height of the original image, that is, Options.outwidth and options.outheight. With these two values, you can tell if the picture is too large.

Bitmapfactory.options opts = new Bitmapfactory.options (); Set Injustdecodebounds to True Opts.injustdecodebounds = true; Use the DecodeFile method to get the width and height of the picture Bitmapfactory.decodefile (path, opts); Print out the width and height of the picture LOG.D ("Example", Opts.outwidth + "," + opts.outheight);

In the actual project, you can take advantage of the above code, first get the picture's true width and height, and then determine whether you need to run down. If you do not need to zoom out, set the value of Insamplesize to 1. If you need to zoom out, dynamically calculate and set the value of the insamplesize to narrow the picture. It is important to note that you should not forget to set the Opts.injustdecodebound back to false until the next time you instantiate the bitmap object by using Bitmapfactory's DecodeFile () method. Otherwise, the obtained bitmap object is still null.

Experience Sharing: If the picture of the program is the source of the package, or the picture on its own server, the size of the picture can be adjusted by the developer, then generally speaking, only need to pay attention to the use of the picture is not too large, and pay attention to the quality of the code, timely collection of bitmap objects, Can avoid the occurrence of outofmemory anomalies. If the picture of the program comes from outside, this time special need to pay attention to the occurrence of outofmemory. One is that if the loaded picture is larger, it needs to be narrowed first, and the other is to catch the exception and avoid the program crash.

Optimization Series related blog posts:

Android Development Optimization--memory optimization for bitmap

Android Development optimization-using soft references and weak references

Optimized for Android development – from a code perspective

Android Development Optimization-UI optimization (1)

Android Development Optimization-UI optimization (2)

Android Development Optimization-UI optimization (3)

---------------------------------------------------------------------------

http://blog.csdn.net/arui319

The "Android Application development Solution" has been published, this article is part of the first draft. Welcome to buy Reading.

This article can be reproduced, but please keep the above author information.

Thank you.

---------------------------------------------------------------------------

From for notes (Wiz)

Android Memory optimizer 1-memory optimization for bitmap