Some simple ways to avoid memory leaks

The previous article talked about how Android memory management works, and also how Android memory Leak and Oom can happen. This time mainly talk about the coding level, how to prevent the occurrence of memory leak.

Objects have a life cycle, the life cycle of the object is a process level, some activity is in the life cycle, with the activity extinction, some service life cycle, with the service extinction. A very important reason to judge whether an object exists in many cases is whether its actual life cycle conforms to its original life cycle. Many memory leak occur, to a large extent, the life cycle of the mismatch, the object destroyed with the activity has become a process-level object, Memory leak can not be avoided.

1, the Common Memoryleak analysis

1.1 Frequent use of the static keyword decoration
Many beginners like to use static class static variable, declaring the assignment call is simple and convenient. Because the static declaration variable's life cycle is actually the same as the life cycle of the app (process level). A lot of use, it will occupy the memory space is not released, a few will also cause the memory of the constant overhead, until the hang off. The rational use of static is generally used to modify the basic data types or lightweight objects, to avoid repairing the collection or large objects, commonly used to decorate global configuration items, tool class methods, internal classes.

1.2 Bitmap Hidden danger
The improper handling of bitmap is likely to cause oom, and the vast majority of cases where application oom occurs for this reason. Bitamp bitmaps are well-deserved fats in Android, so be careful when you operate them.
1.2.1 Release recycle in time. Since DALIVK does not take the initiative to recycle, developers need to recycle out when bitmap is not being used.
1.2.2 Set a certain compression rate. If the requirement permits, the bitmap should be scaled to a certain extent, controlled by the Bitmapfactory.options Insamplesize property. If you just want to get bitmap properties, you don't need to allocate memory based on bitmap pixels, just use Bitmapfactory.options's Injustdecodebounds property when parsing the BMP.
1.2.3 finally recommended that you use soft or weak references and local caches when loading network images, and we recommend using Android-universal-imageloader or Xutils.

1.3 Page Background Map
When setting the background and picture in the layout and code, if it is a solid color, use color as much as possible, if it is a regular graphic, use shape to draw, if it is slightly more complex, you can use 9patch graph, if you cannot use 9patch, the model for several main resolutions is cut.

1.4 View Cache
In the ListView and GridView, many items in the list (Convertview) are reusable and do not need to be regenerated every time getview. In addition, the page drawing is actually very time-consuming, Findviewbyid is also relatively slow. So do not reuse view, in the list when it is particularly significant, often the phenomenon of sliding very card.

1.5 References to Hell
The objects generated in the activity should, in principle, be released after the activity life cycle ends. The activity object itself is also, so try to avoid having appliction process-level objects referencing activity-level objects, and if so, you should also dereference them at the end of the activity. If you do not apply applicationcontext to get resources in activity.
Service is the same.

1.6 Broadcastreceiver, Service unbind
To bind broadcasts and services, be sure to remember to unbind them when they are not needed.

1.7 Handler Cleanup
Call Handler.removecallbacksandmessages (NULL) in the OnDestroy method of the activity, and cancel the processing of all messages, including pending messages;

1.8 Cursor Close in time
When querying the SQLite database, will return a cursor, when the query is complete, close immediately, so that the query result set can be retrieved in a timely manner.

1.9 I/O flow
I/O stream operation finished, read and write end, remember to close.

1.10 Threads
When the thread no longer needs to continue to execute the time to remember to close, open the number of threads is not easy to too much, generally with their own machine core number of the best, recommended to open threads, the use of thread pool.

1.11 String/stringbuffer
It is recommended to use StringBuffer when more characters are needed for stitching.

2. Summary

If the above is perfect, you can be sure that your program will run very well.

Of course, sometimes we will be in order to improve the efficiency of the program to the activity level of resources used to upgrade to the process level, such as Imagecache, or other datamanager.

I can only say that space and time are relative, sometimes need to sacrifice time for space, and sometimes need to sacrifice space in exchange for time. Memory is the existence of space, performance is the existence of time. The perfect program is perfect under certain conditions.

Some simple ways to avoid memory leaks