Inerpreting memory Info field in android device dump

[Anirudh]

Hi,

I wanted to know what the different fields in memory info of android
device dump indicate (We get this dump by selecting Dump device state
option in DDMS)

The output would be similar to:
** MEMINFO in pid 1981 [ani.foo.hello] **
native dalvik other total
size: 3716 3911 N/A 7627
allocated: 3691 3332 N/A 7023
free: 20 579 N/A 599
(Pss): 1428 2298 3737 7463
(shared dirty): 1032 3700 1216 5948
(priv dirty): 1400 2196 692 4288

Objects
Views: 5 ViewRoots: 1
AppContexts: 2 Activities: 1
Assets: 2 AssetManagers: 2
Local Binders: 8 Proxy Binders: 11
Death Recipients: 0
OpenSSL Sockets: 0

SQL
heap: 13 dbFiles: 0
numPagers: 1 inactivePageKB: 2
activePageKB: 0

I ran the HelloWorld program in device and emulator. The memory dumps
for this application are similar on both.

The fields that I found most interesting were the Views and
Activities. Every time I close (back button, have not overridden this,
onDestroy is being called properly) and relaunch the application,
their values are incremented.

For example, Views: 10 and Activities: 2 for 2nd launch
Views: 15 and Activities: 3 for 3rd launch and so on.

Do these fields indicate the active views and activities in the
process or are they just counter variables?

Can someone clarify these for me?

Regards,
Anirudh

[Dianne Hackborn]

On Tue, Aug 25, 2009 at 6:14 AM, Anirudh <aithal...@gmail.com> wrote:

I wanted to know what the different fields in memory info of android
device dump indicate (We get this dump by selecting Dump device state
option in DDMS)

The output would be similar to:
** MEMINFO in pid 1981 [ani.foo.hello] **
                   native   dalvik    other    total
           size:     3716     3911      N/A     7627

The space the memory allocator is maintaining for its heap.
 

      allocated:     3691     3332      N/A     7023

The amount the memory allocator currently has allocated for its heap.
 

           free:       20      579      N/A      599

The amount of free memory the allocator has for its heap.
 

          (Pss):     1428     2298     3737     7463

The kernel's pss pages for each of the memory categories (pss = unshared memory for the process + a weighted amount of shared memory based on how many processes it is shared in).
 

 (shared dirty):     1032     3700     1216     5948

The kernel's private dirty pages for each of the memory categories in that process.
 

   (priv dirty):     1400     2196      692     4288

The kernel's private dirty pages for each of the memory categories in that process.
 

Objects
          Views:        5        ViewRoots:        1
    AppContexts:        2       Activities:        1
         Assets:        2    AssetManagers:        2
  Local Binders:        8    Proxy Binders:       11
Death Recipients:        0
 OpenSSL Sockets:        0

Counts of currently active objects in the process for some key classes.
 

 SQL
           heap:       13          dbFiles:        0
      numPagers:        1   inactivePageKB:        2
   activePageKB:        0

SQLite memory use and resource counts.
 

The fields that I found most interesting were the Views and
Activities. Every time I close (back button, have not overridden this,
onDestroy is being called properly) and relaunch the application,
their values are incremented.

Then you probably have a leak. :)  You can use hat to determine what is holding on to the object.
 

For example, Views: 10 and Activities: 2 for 2nd launch
Views: 15 and Activities: 3 for 3rd launch and so on.

Do these fields indicate the active views and activities in the
process or are they just counter variables?

Total number of currently allocated objects.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Anirudh]

Thanks a lot for this info.

">Then you probably have a leak. :) You can use hat to determine what
is
>holding on to the object. "

This was exactly the whole point of my question. Irrespective of the
activity launched and the process it attaches itself to, the number of
Views and Activities always increase in an arithmetic progression.

My app was not doing anything special here apart from what the
template HelloWorld app on eclipse does (I just changed the name).
Also, the heap usage statistics show that there has been no memory
leak.

The steps are simple enough:
> Launch the app
> Take a device state dump
> Note down the Views and Activities number of the app
> Close the app
> Take a device state dump
> Note down the Views and Activities number of the app
> Repeat the above steps

It can be seen that the number of Views and Activities keep growing as
explained earlier.

Why is this so? Is the dump giving the total number of Views and
activities? If not, surely caching these things might be a problem?

Can you please clarify?

Regards,
Anirudh

[Dianne Hackborn]

Are you forcing a GC before you look at the numbers?

Those were explicitly put there for us to determine when certain kinds of leaks are happening, so they definitely count the total number of currently active objects.  If you are saying you are just running the plain hello world program, I am pretty positive the basic system doesn't have any leaks in this area, so I don't know what to say -- except do be sure to force a GC before collecting the numbers.