Fixing Memory Leaks in Android Applications using DDMS

1
Fixing Memory Leaks in Android Applications using
DDMS MAT
Presented by Sravankumar Reddy Javaji CS286
Mobile Programming
2
Evolution of Devices
HTC Dream (2008)192 MB Ram320480 display
Nexus 5 (2013)2 GB Ram1920x1080 display
3
Heap Size

• Heap size is limited and device dependent
• G1 16 Mb
• Droid 24 Mb
• Nexus One 32 Mb
• Xoom 48 Mb
• GalaxyTab 64 Mb.
• ActivityManager.getMemoryClass()

4
Heap Size ..contd..

• Pre-defined heap-size settings are specified in
  /system/build.prop file for each device.
• dalvik.vm.heapstartsize5m
• dalvik.vm.heapgrowthlimit48m
• dalvik.vm.heapsize128m
• dalvik.vm.heaptargetutilization0.75
• dalvik.vm.heapminfree512k
• dalvik.vm.heapmaxfree2m
• http//stackoverflow.com/questions/20011424/query-
  on-properties-in-system-build-prop

5
Large Heaps

• Honeycomb adds largeHeap option in
  AndroidManifest.xml
• - Degrades performance! Use only if you
  understand why you need it.
• ltapplication
• androidname"com.example.foobar"
• androidlargeHeap"true"
• ...
• lt/applicationgt
• ActivityManager.getLargeMemoryClass()

6
larger heap VS smaller heap

• A larger memory heap
• Allows more objects to be created
• Takes longer to fill
• Allows the application to run longer between
  garbage collection (GC) events
• A smaller memory heap
• Holds fewer objects
• Fills more quickly
• Is garbage collected more frequently (but the
  pauses are shorter)
• May lead to out-of-memory errors
• The more memory we use, the more work GC has, the
  more work GC has the bigger pause will be.
• Battery life

7
Garbage Collection

• Finding out when the Garbage Collection is run?
• - Search for 'GC' or 'gc' in LogCat
• How to trigger the Garbage Collection manually?
• - System.gc()
• Mark and sweep is one of the earliest and
  best-known garbage collection algorithms.

8
Mark and Sweep Algorithm
B
F
GC Roots
A
E
C
D
G
H
9
Mark and Sweep Algorithm
B
F
GC Roots
A
E
C
D
G
H
10
Mark and Sweep Algorithm
B
F
GC Roots
A
E
C
D
G
H
11
Mark and Sweep Algorithm
B
F
GC Roots
A
E
C
D
G
H
12
Changes in Garbage Collection

• Pre-Gingerbread GC
• Stop-the-world
• Full heap collection
• Large Pause Times. Pause times often gt 100ms
• Gingerbread and beyond
• Advantage of multi-core support. Concurrent
  (mostly)
• Partial collections
• Smaller pause times. Pause times usually lt 5ms

13
Bitmaps

• Bitmaps take up a lot of memory, especially for
  rich images like photographs.
• For example, the camera on the Galaxy
  Nexus takes photos up to 2592x1936 pixels (5
  megapixels). Loading this image into memory takes
  about 19MB of memory (259219364 bytes).
• If you're not careful, bitmaps can quickly
  consume your available memory budget leading to
  an application crash due to the dreaded
  exceptionjava.lang.OutofMemoryError bitmap
  size exceeds VM budget.

14
Managing Bitmap Memory

• Old way (pre-Honeycomb)
• Bitmaps are saved in Native memory. Freed via
  recycle() or finalizer
• hard to debug
• full, stop-the-world GCs
• New way
• Bitmaps are saved in Managed (Heap) memory.
  Freed synchronously by GC
• easier to debug
• concurrent partial GCs

15
Understanding heap usage
DDMS (Dalvik Debug Monitor Server) Eclipse
Memory Analyzer (MAT)
16
Debugging a memory leak

• Let's walk through an example using the Honeycomb
  Gallery sample app from the Android SDK.
• We're going to deliberately add a memory leak to
  this app in order to demonstrate how it could be
  debugged.
• Lets implement a cache in this app which holds
  recently-viewed images by making a few small
  changes to ContentFragment.java.

17
Debugging a memory leak ..contd..

• At the top of the class, let's add a new static
  variable
• private static HashMapltString,Bitmapgt
  sBitmapCache new HashMapltString,Bitmapgt()
• This is where we'll cache the Bitmaps that we
  load.
• Now we can change the updateContentAndRecycleBitma
  p() method to check the cache before loading, and
  to add Bitmaps to the cache after they're loaded.
• void updateContentAndRecycleBitmap(int category,
  int position)
• if (mCurrentActionMode ! null)
• mCurrentActionMode.finish()

18
Debugging a memory leak ..contd..
// Get the bitmap that needs to be drawn and
update the ImageView. // Check if the Bitmap
is already in the cache String bitmapId ""
category "." position mBitmap
sBitmapCache.get(bitmapId) if (mBitmap
null) // It's not in the cache, so load
the Bitmap and add it to the cache. //
DANGER! We add items to this cache without ever
removing any. mBitmap
Directory.getCategory(category).getEntry(position)
.getBitmap(getResources())
sBitmapCache.put(bitmapId, mBitmap)
((ImageView) getView().findViewById(R.id.image)).s
etImageBitmap(mBitmap)
19
Debugging a memory leak ..contd..

• What is Memory Leak here?
• We added Bitmaps to the cache without ever
  removing them. In a real app, we'd probably want
  to limit the size of the cache in some way.

20
Examining heap usage in DDMS

• Select the process com.example.android.hcgallery
  in the left pane, and then click the Show heap
  updates button in the toolbar. Then, switch to
  the VM Heap tab in DDMS. It shows some basic
  stats about our heap memory usage, updated after
  every GC. To see the first update, click the
  Cause GC button.
• We can see that our live set (the Allocated
  column) is a little over 8MB. Now flip through
  the photos, and watch that number go up. Since
  there are only 13 photos in this app, the amount
  of memory we leak is bounded. In some ways, this
  is the worst kind of leak to have, because we
  never get an OutOfMemoryError indicating that we
  are leaking.

21
Examining heap usage in DDMS
2
3
4
1
22
Creating a heap dump
2
1
23
Analyzing heap dumps using MAT
Click on Histogram view
24
Analyzing heap dumps using MAT
The Histogram view shows a list of classes
sortable by the number of instances, the shallow
heap or the retained heap.
25
Analyzing heap dumps using MAT

• If we sort by shallow heap, we can see that
  instances of byte are at the top. As of Android
  3.0 (Honeycomb), the pixel data for Bitmap
  objects is stored in byte arrays (previously it
  was not stored in the Dalvik heap), and based on
  the size of these objects, it's a safe bet that
  they are the backing memory for our leaked
  bitmaps.
• Right-click on the byte class and select List
  Objects gt with incoming references. This produces
  a list of all byte arrays in the heap, which we
  can sort based on Shallow Heap usage.
• Pick one of the big objects, and drill down on
  it. This will show you the path from the root set
  to the object -- the chain of references that
  keeps this object alive. Lo and behold, there's
  our bitmap cache!

26
Analyzing heap dumps using MAT
Culprit
27
Comparing heap dumps with MAT

• We need to create two separate HPROF files.
• Open the first HPROF file (if it is not already
  opened)
• Open the Histogram view.
• Open the second HPROF file.
• Switch to first HPROF file's Histogram view and
  click compare to another Heap Dump Icon.
• Then a window will be prompted to select a heap
  dump from the open editors as baseline.
• Select second HPROF file and press OK.

28
Comparing heap dumps with MAT..contd..
29
Downloading MAT

• MAT for Eclipse IDE- http//download.eclipse.org/
  mat/1.3/update-site
• Standalone MAT- http//www.eclipse.org/mat/

30
References

• http//dubroy.com/blog/google-io-memory-management
  -for-android-apps/
• https//developer.android.com/training/displaying-
  bitmaps/manage-memory.html
• http//macgyverdev.blogspot.com/2011/11/android-tr
  ack-down-memory-leaks.html
• http//www.brpreiss.com/books/opus5/html/page424.h
  tml
• https//sites.google.com/site/pyximanew/blog/andro
  idunderstandingddmslogcatmemoryoutputmessages
• http//www.vogella.com/articles/EclipseMemoryAnaly
  zer/article.html
• http//rockgrumbler.blogspot.com/2011/02/common-me
  mory-leak-causes-in-java.html

31
Queries. ?
32
Thank You. !