identifying memory leaks in android applications
DESCRIPTION
A very brief introduction to using DDMS and Eclipse Memory Analyzer to identify the source of a memory leak in an Android application.TRANSCRIPT
Identifying memory leaks in Android applicationsZachary Blair
Doesn’t Java handle memory management?!!!1
http://memegenerator.net/instance/27508171
Garbage collection != Immunity from memory leaks!
Java/Android Garbage Collection
• All objects created with new are stored on the heap
• GC periodically disposes of objects that are eligible for garbage collection
• Android GC uses a mark-and-sweep algorithm
What is “eligible for garbage collection”?
• Not reachable from any live threads or any static references
− There are no references to the object!
• Cyclic references are not counted.
What is “eligible for garbage collection”?
Simple Example:
Integer100
Integer volume = new Integer(100); System.out.println(volume); volume = null;
Integer100
Volume
What is “eligible for garbage collection”?
Integer100
Integer volume = new Integer(100); System.out.println(volume); volume = null;
Simple Example:
Volume
What is “eligible for garbage collection”?
Integer100
Integer volume = new Integer(100); System.out.println(volume); volume = null; null
Simple Example:
Volume
What is “eligible for garbage collection”?
Integer volume = new Integer(100); System.out.println(volume); volume = null; null
IntegerGarbagecollected!
Simple Example:
Volume
What is “eligible for garbage collection”?
• Lists, Maps, and Sets are prime suspects for memory leaks, because they can accidentally retain references to unused objects!
Integer100
Integer volume = new Integer(100); System.out.println(volume); volumeList.add(volume);
volume = null;
null
Volume volumeList
Haiku Break #1
Memory leak, crash. Lingering reference, why!?
You make GC cry.
Detecting a memory leak
Clue #1: Your application crashes with an java.lang.OutOfMemoryError after running for a long time.
Clue #2: You see frequent GC_ lines in logcat before the crash.
D/dalvikvm( 1325): GC_CONCURRENT freed 1971K, 18% free 12382K/14983K, paused 3ms+7ms
Reason for garbage collection:GC_CONCURRENTGC_FOR_MALLOCGC_EXTERNAL_ALLOCGC_HPROF_DUMP_HEAPGC_EXPLICIT
Heap statistics
Identifying the source of the leak
• Step #1Use DDMS (Dalvik Debug Monitor Server) to dump heap snapshots (an HPROF file)
− android-sdks\tools\ddms.bat
Identifying the source of the leak
• Step #2Use the Android SDK’s “hprof-conv” tool to convert the Android-specific HPROF file into a generic HPROF file that can be analyzed by Eclipse Memory Analyzer
Identifying the source of the leak
• Step #3Open the converted HPROF using Eclipse Memory Analyzer
Identifying the source of the leak
• Step #4Analyze the results using the “Histogram” view
Identifying the source of the leak
• Step #4Analyze the results using the “Histogram” view
• Identifies types of objects allocated!
• Doesn’t know whether they will eventually be freed!
• We must compare two HPROF snapshots to identify which objects are responsible for a leak.
Identifying the source of the leak
• Step #5Exercise your app in a way that tends to cause it to exhibit the memory leak, and then use DDMS to dump another heap snapshot
• Step #6Use “hprof-conv” to convert the HPROF file
Identifying the source of the leak
• Step #7Open both HPROF files in Eclipse Memory Analyzer and compare their histograms
Identifying the source of the leak
• Step #7Open both HPROF files in Eclipse Memory Analyzer and compare their histograms
− Compare the number of instances and sizes of each type of object between the two snapshots.
− A sustained increase in the number of objects may indicate a leak!
Identifying the source of the leak
• Step #7Open both HPROF files in Eclipse Memory Analyzer and compare their histograms
− Compare the number of instances and sizes of each type of object between the two snapshots.
− An unexplained increase in the number of objects may indicate a leak!
Identifying the source of the leak
• Step #7
Shallow heap: the size of the objects themselves.
Retained heap: the amount that would be freed if we freed these objects (greater than shallow heap because referenced objects may also be freed).
Haiku Break #2
Unfreed memory,Delta of two HPROF dumps
Who references thou?
Fixing the leak
• The leak must be the result of unused objects still having references to them so, you can do one of:
− Stop creating the objects
− Stop maintaining references to the objects
− Use weak references (see WeakHashMap) so that those references are invalidated if they are the only ones to the object.
− Make sure to close() open streams and connections
More Information
• Google I/O 2011: Memory management for Android Apps https://www.youtube.com/watch?v=_CruQY55HOk&feature=relmfu
Thank You