Question

SETUP :

I have this app which has 4 activities in a linear path, really simple navigation :
A -> B -> C -> D

All the activities share the same background image and all have a couple of regular buttons, a textview or an edittext. All of which are defined in separate views xml files.

The background is a gradient and is kind of heavy. Around 3 megs as an uncompressed bitmap.

The app does nothing yet, the only logic in it, is for starting activities and closing them on button clicks

I tried to use MAT to find a memory leak but couldn’t find anything. The biggest retained size in my app is 656(ko?) the total retained size for the app is 1520(ko?) and I can’t find any object that would be duplicated.
Which by the way completely contradicts dumpsys which shows 27300(ko?) allocated

PROBLEMS :

1. When I navigate UP, I see an increase of memory usage equivalent to the background size.
2. When I navigate DOWN, closing the activities with the back button or a finish command, the memory usage of the app does not decrease.
3. If I go from A to D then back to B and rotate the screen, the app force closes with an OutOfMemory Exception.

QUESTIONS :

Update : I guess the real question is why do I have a huge memory leak(5 megs at a time) with a 27megs app size at freeze time and I can not see it in the MAT ?

1. Why would Android decompress multiple times the same background, once per activity ? Seems inefficient.
2. Is it possible to overcome this problem by using themes or will I see the same “allocate 1 background by activity” weirdness ?
3. Why are the activities not reclaimed when closed ?
4. Why are MAT and dumpsys presenting different numbers ?

CLUES

At exactly the same time I have :
dumpsys meminfo :

Applications Memory Usage (kB):
Uptime: 74006853 Realtime: 110962243

** MEMINFO in pid 22683 [com.kayenko.sosadresse] **
                    native   dalvik    other    total
            size:    20820     5767      N/A    26587
       allocated:    18751     2901      N/A    21652
            free:      312     2866      N/A     3178
           (Pss):     1357      201    16782    18340
  (shared dirty):     2264     1804     5456     9524
    (priv dirty):     1280      116    16032    17428

 Objects
           Views:        0        ViewRoots:        0
     AppContexts:        0       Activities:        0
          Assets:        2    AssetManagers:        2
   Local Binders:       18    Proxy Binders:       16
Death Recipients:        1
 OpenSSL Sockets:        0

 SQL
               heap:        0         MEMORY_USED:        0
 PAGECACHE_OVERFLOW:        0         MALLOC_SIZE:        0

And this dominator tree :

Thansk to anyone with a clue on what I’m suppose to look for.

Answer 1

Memory is a very tricky subject in Android.

Every app gets a heap memory limit depending on the device. This heap memory is the dalvik memory plus the native memory, and you can see it as the total column in the dumpsys meminfo results. The dalvik memory deals with everything except with the bitmaps, that are allocated in the native memory (this is true for Android versions before Honeycomb).

Having said that I can only answer to some of your questions:

1. As far as I know, Android will always allocate memory for Bitmaps, even if they are the same. Therefore, in your case, every activity allocates memory for your background.

2. I don’t know if its better to work with themes, you’ll have to try that.

3. On one hand, activities are not reclaimed while the device has enough memory to deal with the next activity. Every activity is pushed to a pile from where it is recovered when you pressed the back button. In case Android needs more memory it removes one activity from the pile deallocating its memory (going back to question number one, maybe this is the reason for not sharing memory). On the other hand, you can set the activities launchMode to change this behaviour (have a look here).

4. I think MAT doesn’t show native memory data. Use dumpsys meminfo‘s native column to see how much allocated memory for Bitmaps you have.

I have had hard times dealing with OutOfMemory problems myself. Now I have a much more clear idea
of how it works and I am able to work with large files without running out of memory. I would highly recommend these two resources that helped me a lot:

• How to discover memory usage of my application in Android
• Google I/O 2011: Memory management for Android Apps (extremely useful!)

Good luck!