I track potential memory leaks in my Android app and I am faced with the fact that I am not sure what to do. First, I will describe what I am trying to do.
For what it's worth, I'm building for Eclair (2.1, API level 7) and testing for HTC Incredible running Gingerbread (2.3.7, API level 10). From observing LogCat, I assume that my application has a maximum heap size of about 32 MB.
I am trying to create an address book in which you have several contact pages. You move between pages by scrolling left and right, and you move through the current page by scrolling up and down. To do this, I use Gallery , whose adapter adapts the contact list to a ListView , whose adapter, in turn, adapts one contact to RelativeLayout .
Everything seems to be working fine, but I quickly ran out of my own (external) memory by scrolling through the gallery. I dumped HPROF after waving some Gallery and pulled it into MAT. On the histogram, I found that I had several hundred of my RelativeLayout contacts that held exclusively for my ListView s contact. Here is what I found when I looked at the [truncated] MAT merge_shortest_paths output of this ListView :
android.view.ViewRoot$1 + this$0 android.view.ViewRoot + mAttachInfo android.view.View$AttachInfo + mScrollContainers java.util.ArrayList + array java.lang.Object[303] + [110], [112], [114], [116], [118], ... com.example.LeakyListView + ...and so forth.
The only thing that kept the ListView leak was in this field android.view.View$AttachInfo mScrollContainers . The problem is that I don’t know how my views appear there in the first place, so I don’t understand how to connect this leak.
How to solve this memory leak? Or at least how is this link chain built and what are ViewRoot , AttachInfo and mScrollContainers ?
In the near future I will try to isolate it to a simple test case and postal code, but I hope this is enough to start a conversation.