Http://ttlnews.blogspot.com/2010/01/attacking-memory-problems-on-android.html
This article was written in January 2010, some of which are already unsuitable for the android mechanism now.
I've divided the memory issues into two types: oom and Stack Overflow
The maximum heap memory that an Android process can allocate (heap memories) is 16M (now different from custom versions of Android)
If you will repeatedly open and close a Activity20 time, there is a possibility of memory overflow, then where is the memory overflow, where can be collected by GC?
adb shell Procrank
Use this command to get some application memory data, but only get very simple data
adb shell Dumpsys meminfo
Use this command to get more relevant data
If you want to learn more about memory allocation and recycling, you need the Eclipse memory Analyzer tool (MAT) tools.
How to use the mat tool: http://kohlerm.blogspot.com/2009/04/analyzing-memory-usage-off-your-android.html
What the http://blog.csdn.net/sgwhp/article/details/9842509 mat can display
Best Practices:
1. It is best to set the anonymous listeners to NULL in OnDestroy (), such as View.setonclicklistener (null);
2. If there is no static drawable variable, but the View,view object referenced in the Drawable object references the context, activity may leak;
Android Source Fragment Drawable object reference View Object
So it's best to call View.getbackground () in OnDestroy (). Setcallback (NULL);
A general unbinddrawables approach has emerged in StackOverflow related questions and answers
Http://stackoverflow.com/questions/9461364/exception-in-unbinddrawables
"Supplement" above method to the ListView and GridView useless 3. Setting object in OnDestroy () = null Although setting object = null is not necessary, but allows the GC to speed up a bit;
4. To set all objects to null, although convenient, but also error-prone, the best way is to use the Mat tool to monitor which objects may leak, and then place null in OnDestroy (). Otherwise, if a background thread is still running and needs to call these objects, Nullpointerexceptions is prone to appear.
5.Images (Bitmaps) does not allocate memory like a generic Java object, but by calling the Natvie method, bitmap consumes the memory of the non-Dalvik heap. So when you use the Mat tool, you'll find that the memory you see with the Procrank and Dumpsys commands is much larger than in the mat.
Added
Excerpt from https://developer.android.com/training/displaying-bitmaps/manage-memory.html (translated:) http://su1216.iteye.com/blog/1931629
(1) Android2.2 and previous versions, the threads applied during GC will stop, which can cause delays and slow down performance. Therefore, the concurrency GC mechanism was added in 2.3, so as long as the bitmap is no longer referenced, the occupied memory will be reclaimed immediately.
(2) in the 2.3 and previous versions, the bitmap pixel data is stored in the native memory, not with the bitmap object stored in the Dalvik heap, will cause the pixel data in native memory can not be explicitly recycled, Causes the app to crash beyond the memory size limit.
After 2.3 (API level 11), the pixel data is stored on the Dalvik heap along with the bitmap object.
6. Loading the network such as tablets in Android will be more difficult to operate, just load a few 200x200 pixels of the picture will cause the memory consumption of the explosion, 20k size of the 200x200 PNG images need to occupy 160K of memory (each pixel occupies 4bytes) [ 200x200x4/1024 = 156.25k] The following methods are recommended "excerpted from http://android-developers.blogspot.com/2008/09/android-photostream.html"
(1) First get the size of the picture (in pixels)
Bitmapfactory.options Options = new Bitmapfactory.options (); Load only part of the picture information, reduce memory consumption options.injustdecodebounds = true; Bitmap Tmpbitmap = Bitmapfactory.decodestream (new bytearrayinputstream (new URL). OpenStream ()), null, options); Get the long and wide pixels of a picture
(2) This will allow you to know the size of the image before downloading the web image, and then compress it according to the size of the image you want to display (usually Android will scale the image when it is drawn)
The memory footprint of the captured image is smaller.
(3) A better way is to download the image locally, and resize it to fit the size when used. You will no longer need a picture object when you call Bitmap.recyce () to release the memory footprint of the image, but if you call recycle () and then try to draw the bitmap, you will get an error: "Canvas:trying to use a recycled Bitmap "(for Android2.3 and previous versions).
7.ListView Convertview Cache Mode "Many online data"
8.debug will keep the object in a usable state and memory cannot be recycled. So do not use debug when memory analysis (using the Mat tool). And a few more GC operations before heap dump "Cause: http://groups.google.com/group/android-developers/browse_thread/thread/7b0ea57d9507d33f"
There's a question in the back of the article.
Problem:
I wrote a simple demo, only two activity, repeated open secondactivity 6 times, using the Mat tool to see the memory found there are 6 secondactivity objects, why this?
Reply:
Possible causes of the above problems
(1) How to open and close secondactivity, is it through intent? Is the hardware back button turned off secondactivity?
(2) in secondactivity reload OnDestroy (), log, repeat open secondactivity 6 times, OnDestroy () log will print 6 times?
(3) How fast to reopen and close secondactivity? Preferably when you see a GC log and then reopen, it may not have time to GC, so there will be more than one object in memory (may be your demo memory footprint is too small to meet the requirements of GC)
(4) Check whether the state of the 6 secondactivity objects is Unknown,mat and also the object that Unkown state is counted. Supplement: You can use the ADB shell dumpsys meminfo command to see the number of active activity in the current memory "
Android Memory leak monitoring (MAT) and solutions
