NOTE: This blog post was originally hosted on Motorola's MOTODEV web site. That site was decommissioned in 2012. I've made every attempt to preserve blog posts and accompanying forum posts with their original content. Many web links are no longer valid, so they have been removed and replaced with emphasized text.
by Eric Cloninger (EricC)
One of the promises of Java, circa 1996, was that memory problems would be solved by a garbage collector that was smarter than we were. While garbage collection does solve many of the problems that made our lives more difficult, it's no silver bullet that slays the beast. Memory problems still exist and the opaque nature of Java memory actually makes the debugging process more difficult. MOTODEV Studio helps alleviate some of this difficulty by including a common memory analysis tool called MAT.
MAT, or the "Memory Analyzer Tool", is an Eclipse project that was developed in open-source by committers from IBM and SAP. MAT reads the output of the Java standard HPROF command and displays the results in a manner that can be interpreted by humans.
The MOTODEV Studio team made some adjustments to MAT to make it easier for Android developers to use, but most of this functionality comes from the existing MAT plugins or Google's ADT plugin. The MAT wiki has some basic FAQs, but the best article I've found on how to review and understand the results is available on SAP's web site.
The following steps describe one way to perform this task. There are many ways to get work done with Eclipse, so if this doesn't match your own workflow, you should be able to adapt these instructions to meet your needs. I suggest you run through these instructions once with your app at a stable state such as in the main activity. Read the results and try to gain an understanding of what objects are created by the OS and base classes. HPROF generates so much information that you need to learn the skill of spotting the needle in the haystack. Otherwise you could waste time looking at results that aren't particularly interesting or useful. Keep in mind that HPROF takes a snapshot of the current conditions and doesn't monitor the execution over time, you may need to run \ these steps multiple times to identify problems that arise.
As I mentioned at the outset, there will be some false positives in the results and it helps to know which ones are caused by the framework and which come from your code. In my case, the problem was actually the second candidate, as shown below.
As useful as HPROF and MAT are, this is an inexact method. HPROF only works at a specific moment in time, not across the lifetime of your application. You could run HPROF twice in quick succession and get wildly different results. The randomness of the Garbage Collector makes finding the moment where problems crop up to be non-deterministic. One trick I've seen developers use is to put sleep() statements into the code at specific points. Once they hit the sleep statement, they have time to switch over to MOTODEV Studio long enough to trigger the data capture.
MAT is a useful tool and can be an essential part of a diagnostic workflow. It takes the input from HPROF and displays it in a way that you can track memory allocation issues. It doesn't track API usage and it won't tell you which processes are using too much of the CPU. But, used properly, it can help you create a faster and more efficient application.
Good luck with your mobile applications and thank you for using MOTODEV Studio.