Archive for ‘Android’

October 3, 2012

View Android Application memory usage with Eclipse DDMS plugin

While the Android runtime (Dalvik) is garbage collected, it is important to be mindful of your
application’s memory usage since mobile devices are rather memory constrained. Using too much
memory can lead to excessive garbage collection that degrades performance. In extreme cases, you
may run in to the dreaded OutOfMemoryError and application crash.

There are two main memory analysis tools available in the Android SDK; the Allocation Tracker and
the ability to dump the heap. The Allocation Tracker is useful if you want to understand what kinds
of allocations are happening within a given period of time while heap dumps provide a much finer
grained view of exactly what is utilizing memory for your application.

The Allocation Tracker is a pretty useful tool for identifying cases where critical code paths may
benefit from moving allocations to a higher scope to reduce performance costs associated with
garbage collection.

To use the Allocation Tracker, start your application by selecting Run -> Debug As -> Android Application
in Eclipse. Then select your device. Once the application is running, open the DDMS perspective by
selecting Window -> Open Perspective -> DDMS.

Once the DDMS perspective is open, select the Allocation Tracker tab and click on the Start Tracking
button when you are ready to start. Once tracking is started, run through the feature(s) of the
application you wish to track and then click the Get Allocations button. This should result in a
list of all of the allocations that occured since you clicked the Start Tracking button.

Clicking on any of the items in the list will present a callstack so you can pinpoint the exact line
of code that is responsible for the allocation.

Going through the list, you should consider any duplicate entries as cases that should be reviewed
to determine if there is a benefit to refactoring the code in order to prevent multiple allocations.

The DDMS also has a heap tab that is extremely useful in identifying cases where your application may
be keeping a reference to an object that is no longer needed. For the lack of a better term, we’ll
identify these as memory leaks, but they should not be considered to be memory leaks like in c and

Once you have selected the heap tab in the DDMS perspective, you will see a list of applications
per device that is attached. This should be located on the left hand side and is inside of a
navigation tab labeled ‘Devices’. Click on the application you wish to view and then click on the
‘update heap’ button in the devices tab. If you have trouble finding the ‘update heap’ button, it’s
the second icon from the left.

Heap output will be displayed after each garbage collection. You can force a garbage collection by
clicking on the ‘Cause GC’ button. The result should be a high level statistical summary of the heap
usage. At the very least, you should take note of the Allocated memory.

At this point, it is recommended to run through your application several times while periodically
forcing a garbage collection and updating the heap statistics. Keeping an eye on the allocated memory
in the statistical summary is a good idea.

If you do notice that the Allocated memory keeps increasing while running through the application,
you most likely have a case where references are being held to objects that are no longer needed. If
you do run into this problem, I would recommend using the Memory Analyzer Tool.

The Memory Analyzer Tool is a tool for analyzing heap dumps. A stand alone version of the tool can
be downloaded from

To create a heap dump, click on the ‘Dump HPROF file’ icon which is in the devices tab just to the
right of the ‘Update Heap’ icon and then follow the prompt to save the file. Note that it may take
several seconds for the file prompt to pop up.

The resulting file is in a different format than what the Memory Analyzer Tool can read, so it will
need to be converted with the hprof-conv tool that can be found in your Android SDK tools folder.
Simply run hprof-conv with the first parameter being the existing heap dump file and the second
parameter the name you wish the converted heap dump file to have. On windows it would be

hprof-conv.exe myApp.hprof converted-myApp.hprof

Once the file is converted, start the Memory Analyzer Tool and open using the File / Open menu item.
This should result in a popup window that gives options for different types of reports. I suggest
starting with the ‘Leak Suspects Report’; which is selected by default. Clicking the finish button
will display the complete report for the heap.

Explaining all of the features of the Memory Analyzer Tool is beyond the scope of this post, but I
would recommend starting with the list of suspect areas that is given, followed by using the
Histogram feature.

Complete documentation for the Memory Analyzer Tool can be found at