Analysis of Android Development Optimization: detailed explanation of bitmap memory optimization

1) The memory of bitmap should be recycled in time

Bitmap class has a method recycle (), which means recycle according to the method name. There is a doubt here. The Android system has its own garbage collection mechanism, which can recycle unused memory space from time to time, including bitmap space. Then why do you need this method?

The construction methods of bitmap class are private, so developers cannot directly create a bitmap object, but can only instantiate a bitmap through various static methods of bitmapfactory class. Looking carefully at the source code of bitmapfactory, we can see that the generation of bitmap objects is finally realized through JNI call. Therefore, after loading bitmap into memory, it contains two memory areas. In short, one part is Java and the other part is C. This bitmap object is partially allocated by Java and will be automatically recycled when not in use. However, the virtual machine cannot directly recycle the memory area available for C. This can only be released by calling the underlying function. Therefore, you need to call the recycle () method to free the memory of Part C. It can also be seen from the source code of the bitmap class that the JNI method is indeed called in the recycle () method.

Is there a memory leak if you don't call recycle()? Not really. Each Android application runs in an independent process with independent memory. If the whole process is killed by the application itself or the system, the memory will be released, including part C of the memory.

Android process management is very complex. In short, the processes of the Android system are divided into several levels. 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()) to kill their processes when exiting the program, but some applications will only close all activities by calling the activity. Finish() method.

Experience sharing:

Android phone users may exit the entire application in two ways according to their habits: one is to press the home key to directly return to the desktop; The other is to exit the program from the exit button of the application or press the back key. So from a systematic point of view, what is the difference between the two methods? Press the home key, the application is not closed, but becomes a background application. Press the back key. Generally speaking, the application closes, but the process is not killed, but becomes an empty process (the program itself does not take into account the special handling of exit).

Android system has done a lot of process management work, which can meet the needs of users. I personally suggest that the application does not need to manually kill its own process when exiting the application. The process management of the application itself can be handled by the Android system. What the application needs to do is to manage the memory of the program itself as much as possible.

Generally speaking, if you can get the reference of bitmap object, you need to call the recycle () method of bitmap in time to release the memory space occupied by bitmap instead of waiting for the Android system to release it.

The following is a sample code snippet for releasing bitmap.

We know how to call the recycle () method for recycling. When is it appropriate to release bitmap memory? Generally speaking, if the code no longer needs to use bitmap objects, it can be released. After the memory is released, the bitmap object can no longer be used. If it is used again, an exception will be thrown. So be sure to release it when it is no longer in use. For example, if you use bitmap in an activity, you can recycle it in the onstop () or ondestroy () methods of the activity.

2) Catch exception

Because bitmap is a big memory eater, in order to avoid the crash after the OUTOFMEMORY exception occurs when the application allocates bitmap memory, special attention should be paid to the code of instantiating the bitmap part. In general, OUTOFMEMORY exceptions must be caught in the code instantiating bitmap.

The following is a code example.

Experience sharing:

Many developers will habitually catch exceptions directly in their code. However, for outofmemoryerror, this is not captured. Because outofmemoryerror is an error, not an exception. Just a reminder here to avoid writing wrong code and not capturing outofmemoryerror.

3) Cache generic bitmap objects

Sometimes, you may need to use the same picture multiple times in an activity. For example, an activity will display a list of user avatars. If the user does not set a avatar, a default avatar will be displayed, which is located in the resource file of the application itself.

If there is a scenario similar to the above, you can cache the same bitmap. If you do not cache, although you see the same picture file, the bitmap instantiated using the method of bitmapfactory class is a different bitmap object. Caching can avoid creating multiple bitmap objects and waste of memory.

Experience sharing:

Web developers are familiar with caching technology. In fact, caching technology is often used in Android application development. The cache mentioned here has two levels: hard disk cache and memory cache. For example, in the process of developing network applications, you can save some data obtained from the network to the SD card and read it directly from the SD card next time instead of from the network, so as to save network traffic. This method is hard disk cache. For another example, applications often use the same object, which can also be cached in memory and read directly from memory when necessary. This method is memory caching.

4) Compressed picture

If the picture pixel is too large, OUTOFMEMORY exception is bound to occur when more than 8m memory space is required during the instantiation of bitmap using the method of bitmapfactory class. What should we do at this time? If this is the case, you can reduce the size of the picture to reduce the use of memory in the process of loading the picture and avoid exceptions.

Use bitmapfactory.options to set insamplesize to zoom out the picture. The property value insamplesize indicates that the thumbnail size is a fraction of the original picture size. That is, if this value is 2, the width and height of the extracted thumbnail are 1 / 2 of the original picture, and the size of the picture is 1 / 4 of the original size.

If you know that the pixels of the picture are too large, you can reduce it. So how do you know that the picture is too big?

Using bitmapfactory.options to set injustdecodebounds to true, and then using methods such as decodefile() will not really allocate space, that is, the decoded bitmap is null, but the width and height of the original picture can be calculated, that is, options.outwidth and options.outheight. Through these two values, you can know whether the picture is too large.

Experience sharing:

If the source of the image of the program is the resources in the package or the image on your own server, and the size of the image can be adjusted by the developer, generally speaking, you only need to pay attention to the use of the image not to be too large, pay attention to the quality of the code, and recycle the bitmap object in time, so as to avoid OUTOFMEMORY exceptions.

If the picture of the program comes from the outside, you should pay special attention to OUTOFMEMORY at this time. One is that if the loaded image is large, it needs to be reduced first; The other is to catch exceptions to avoid program crash.