fixing memory leaks in android applications using ddms & mat presented by sravankumar reddy...
Post on 17-Dec-2015
224 Views
Preview:
TRANSCRIPT
Fixing Memory Leaks in Android Applications using DDMS & MAT
Presented by Sravankumar Reddy Javaji
CS286 Mobile Programming
HTC Dream (2008)192 MB Ram
320×480 display
Nexus 5 (2013)2 GB Ram
1920x1080 display
Evolution of Devices
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()
• Pre-defined heap-size settings are specified in /system/build.prop file for each device.
dalvik.vm.heapstartsize=5mdalvik.vm.heapgrowthlimit=48mdalvik.vm.heapsize=128mdalvik.vm.heaptargetutilization=0.75dalvik.vm.heapminfree=512kdalvik.vm.heapmaxfree=2m
• http://stackoverflow.com/questions/20011424/query-on-properties-in-system-build-prop
Heap Size ..contd..
Honeycomb adds “largeHeap” option in AndroidManifest.xml:- Degrades performance! Use only if you understand why you need it.
<applicationandroid:name="com.example.foobar"android:largeHeap="true"...
</application>ActivityManager.getLargeMemoryClass()
Large Heaps
• 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
larger heap VS smaller heap
• 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.
Garbage Collection
Mark and Sweep Algorithm
GC Roots A
E
D G H
B F
C
Mark and Sweep Algorithm
GC Roots A
E
D G H
B F
C
Mark and Sweep Algorithm
GC Roots A
E
D G H
B F
C
Mark and Sweep Algorithm
GC Roots A
E
D G H
B F
C
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.
1
23
4
Examining heap usage in DDMS
1
2
Creating a heap dump
Click on Histogram view
Analyzing heap dumps using MAT
Analyzing heap dumps using MATThe 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. !
top related