Identifying memory leaks in Android applications

35,418 views

Published on

A very brief introduction to using DDMS and Eclipse Memory Analyzer to identify the source of a memory leak in an Android application.

Published in: Technology

Identifying memory leaks in Android applications

  1. 1. Identifying memory leaks inAndroid applicationsZachary Blair
  2. 2. Doesn’t Java handle memory management?!!!1 http://memegenerator.net/instance/27508171
  3. 3. Garbage collection !=Immunity from memory leaks!
  4. 4. 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
  5. 5. 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.
  6. 6. What is “eligible for garbage collection”?Simple Example:Integer volume = new Integer(100); IntegerSystem.out.println(volume); 100volume = null; Volume
  7. 7. What is “eligible for garbage collection”?Simple Example:Integer volume = new Integer(100); IntegerSystem.out.println(volume); 100volume = null; Volume
  8. 8. What is “eligible for garbage collection”?Simple Example:Integer volume = new Integer(100); IntegerSystem.out.println(volume); 100volume = null; null Volume
  9. 9. What is “eligible for garbage collection”?Simple Example:Integer volume = new Integer(100); Integer GarbageSystem.out.println(volume); collected!volume = null; null Volume
  10. 10. 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!Integer volume = new Integer(100); IntegerSystem.out.println(volume); 100volumeList.add(volume); nullvolume = null; Volume volumeList
  11. 11. Haiku Break #1 Memory leak, crash.Lingering reference, why!? You make GC cry.
  12. 12. Detecting a memory leakClue #1: Your application crashes with anjava.lang.OutOfMemoryError after running for a long time.Clue #2: You see frequent GC_ lines in logcat before thecrash. D/dalvikvm( 1325): GC_CONCURRENT freed 1971K, 18% free 12382K/14983K, paused 3ms+7ms Heap statisticsReason for garbagecollection:GC_CONCURRENTGC_FOR_MALLOCGC_EXTERNAL_ALLOCGC_HPROF_DUMP_HEAPGC_EXPLICIT
  13. 13. Identifying the source of the leak• Step #1 Use DDMS (Dalvik Debug Monitor Server) to dump heap snapshots (an HPROF file) − android-sdkstoolsddms.bat
  14. 14. Identifying the source of the leak• Step #2 Use 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
  15. 15. Identifying the source of the leak• Step #3 Open the converted HPROF using Eclipse Memory Analyzer
  16. 16. Identifying the source of the leak• Step #4 Analyze the results using the “Histogram” view
  17. 17. Identifying the source of the leak• Step #4 Analyze 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.
  18. 18. Identifying the source of the leak• Step #5 Exercise 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 #6 Use “hprof-conv” to convert the HPROF file
  19. 19. Identifying the source of the leak• Step #7 Open both HPROF files in Eclipse Memory Analyzer and compare their histograms
  20. 20. Identifying the source of the leak• Step #7 Open 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!
  21. 21. Identifying the source of the leak• Step #7 Open 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!
  22. 22. Identifying the source of the leak• Step #7Shallow heap: the size of the objects themselves.Retained heap: the amount that would be freed if we freedthese objects (greater than shallow heap becausereferenced objects may also be freed).
  23. 23. Haiku Break #2 Unfreed memory, Delta of two HPROF dumps Who references thou?
  24. 24. 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
  25. 25. More Information• Google I/O 2011: Memory management for Android Apps https://www.youtube.com/watch?v=_ CruQY55HOk&feature=relmfu
  26. 26. Thank You

×