Fixing Memory Leaks in Android Applications using DDMS & MAT

Fixing Memory Leaks in Android Applications using DDMS & MAT Presented by Sravankumar Reddy Javaji CS286 Mobile Programming

Evolution of Devices HTC Dream (2008)192 MB Ram320×480 display Nexus 5 (2013)2 GB Ram1920x1080 display

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()

Heap Size ..contd.. • Pre-defined heap-size settings are specified in /system/build.prop file for each device. • dalvik.vm.heapstartsize=5m • dalvik.vm.heapgrowthlimit=48m • dalvik.vm.heapsize=128m • dalvik.vm.heaptargetutilization=0.75 • dalvik.vm.heapminfree=512k • dalvik.vm.heapmaxfree=2m • http://stackoverflow.com/questions/20011424/query-on-properties-in-system-build-prop

Large Heaps • Honeycomb adds “largeHeap” option in AndroidManifest.xml: - Degrades performance! Use only if you understand why you need it. <application android:name="com.example.foobar" android:largeHeap="true" ... </application> • ActivityManager.getLargeMemoryClass()

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

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.

Mark and Sweep Algorithm B F GC Roots A C E D G H

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

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 (2592*1936*4 bytes). • If you're not careful, bitmaps can quickly consume your available memory budget leading to an application crash due to the dreaded exception:java.lang.OutofMemoryError: bitmap size exceeds VM budget.

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

Understanding heap usage – DDMS (Dalvik Debug Monitor Server) – Eclipse Memory Analyzer (MAT)

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.

Debugging a memory leak..contd.. • At the top of the class, let's add a new static variable: private static HashMap<String,Bitmap> sBitmapCache = new HashMap<String,Bitmap>(); This is where we'll cache the Bitmaps that we load. • Now we can change the updateContentAndRecycleBitmap() 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(); }

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)).setImageBitmap(mBitmap); }

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.

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.

Examining heap usage in DDMS 2 3 4 1

Creating a heap dump 2 1

Analyzing heap dumps using MAT Click on Histogram view

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.

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 > 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!

Analyzing heap dumps using MAT Culprit

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.

Comparing heap dumps with MAT..contd..

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

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-track-down-memory-leaks.html • http://www.brpreiss.com/books/opus5/html/page424.html • https://sites.google.com/site/pyximanew/blog/androidunderstandingddmslogcatmemoryoutputmessages • http://www.vogella.com/articles/EclipseMemoryAnalyzer/article.html • http://rockgrumbler.blogspot.com/2011/02/common-memory-leak-causes-in-java.html

Queries. ?

Thank You. !

Fixing Memory Leaks in Android Applications using DDMS & MAT