DDMS Heap - 1-byte array(byte[], boolean[])

Question

I experience some memory leaks in my android application. I've already used MAT to analyze the memory usage. But I have one question from the DDMS perspectiv in Eclipse, what does 1-byte array[byte[], boolean[]) mean?

Is this specific for my application? You can see that this is the big memory leak issue, this always increases in size, and the rest will increase and decrease randomly. My guess is that the GC doesn't catch this type. Can anybody explain why this happen, with this little information?

Answer 1

One byte array is the designation for any data structure that is organized as a single byte array. In you case and with that size, I would bet in a Bitmap or a Drawble.

Most common reasons for memory leaks are static object not properly managed and holding references to:

• Context
• View (which holds reference to context (and possibly also to bitmap)
• Thread (which are not easly collected by GC)
• Handler (which holds reference to context)

Most of them can be solved ensuring that you set the object to null when it's no long required.

Regards.

Answer 2

A byte and a boolean are each 1 byte. If you have an array of those you have a "1-byte array".

A ByteBuffer for example should internally hold one of those.

You have a total of 614 of them where the smallest one be a byte[24] (or boolean[24]), the largest one is 3MB. All of them together use 104MB.

The GC will get rid of them if they are no longer referenced.

For example when you put

private static byte myArray[] = new byte[3 * 1024 * 1024];

in one of your classes and never set it back to null (myArray = null) then this one can't be garbage collected because another Object has a reference to it. The object would be the class itself (as in String.class). The class object can't be garbage collected since classes are never unloaded. (they are referenced by their ClassLoader which could itself be referenced / loaded by another ClassLoader and you can't create Objects & use classes without them - they need to stay and they need to keep a reference to their classes)

It's usually not that simple but often start with static somewhere.

Within MAT (after you force GC) look at the reference chain for the objects that are no longer intended to stay alive and identify the one Object that holds the reference. Set that one to null in your code and your leak is gone. Explained in more detail here:

http://android-developers.blogspot.de/2011/03/memory-analysis-for-android.html

Answer 3

I ran to this problem tonight and almost I checked every bit of code but I couldn't find anything.

What I did was starting the app from intelij and then pressing home button and open the app again. Every time the app heap was doubled.

Finally I discover when I launch the app from ADB and press the home button and open the app again it doesn't bring back the old activity, it just start a new one. When I pressed finish it starts to cycle through all of them. It's like they are treated as two different intent. So I put android:launchMode="singleTop" on the main activity in manifest and it resolved the problem.

Although it's not the main cause of this problem but if you encountered this check this out before anything. It wasted three or four hours for me.