Detailed Explanation For Profile From "adb Shell Dumpsys Meminfo My-app-name"?

Can anyone give me a detailed explanation about the profile gotten by adb shell dumpsys meminfo my-app-name? The result is just as below as it mentioned in How do I discover memory

Solution 1:

We now have more documentation covering RAM use in Android that goes into some detail about what different RAM numbers mean: Managing Your App's Memory. In particular, have a look at the middle of the page here that discusses key parts of the meminfo dump: Investigating Your RAM Usage.

It looks like your meminfo output is from a fairly old version of Android, before we could identify many of the different types of allocations. To map what you are seeing to the current documentation, just consider "other" to be everything that the modern dump shows besides the native and dalvik sections. In your dump, I believe your dalvik section is actually the modern "Dalvik Heap" and "Dalvik Other" put together.

As far as the native and other sections increasingly after only a change in the Java code, yes this can certainly happen. A number of parts of the Android Java API sits on top of native allocations, and can also cause other allocations. The classic example of this would be bitmaps on Gingerbread and earlier, where the data for the bitmap was a native allocation rather than being an array allocations in the Java heap as it is today.

Your increased other allocations can be due to a number of things as you will see listed in the more recent versions of the data -- the memory backing cursors, shared memory areas from ashmem, devices allocating things for you such as graphics textures, etc. There are so many things it can be hard to say what might be going on, which is why the report is more detailed these days. (And even there, we still have a number of things that get collapsed in to unknown.)

For debugging this, you probably want to look at your Java heap for leaked objects. Since the actual allocation for the object is not in the Java heap, this can be tricky of course. I'd suggest taking a heap dump early in your app, do whatever you do that causes its RAM footprint to increase, take a heap dump after that, and look for what object counts have increased. The referenced documentation shows how to compare heap dumps with MAT.

Also when you are looking at your Java heap just as a general analysis (except when doing diffs), always be sure to follow the instructions there for stripping out the zygote part of the heap. As the documentation mentions, every process has a large number of allocations from zygote, but these are shared across all processes so not generally relevant for heap analysis. I very often see people concerned because they see a lot of very large bitmaps in their app that the system seems to have allocated on them, and think that is the major thing using RAM in their app, when it is not, it is just the shared allocations from zygote.