CODEWITHSUNDEEP
javaandroidmemory-leaksout-of-memoryheap-memory
Tony
Tony

Reputation: 1603

How to find root of memory leaks?

My app is basicly and image editor. There is a welcome page which opens main activity with an intent. If orientation changes when main activity is working the memory consumption simply doubles up and remains that way. If i close the main activity turn back to welcome activity and start main activity again same problem does not occur. I think all these indicates memory leak, i have investigated myself but couldn't find why app is leaking memory. I am using Application contexts and there is no static field in my app. I have tried to dump heap and analyze it with MAT, however i couldn't find anything good. I was hoping someone could show me right direction to find the roots of memory leak or other possible explanation of the problem.

Upvotes: 4

Views: 2289

Answers (5)

NickT
NickT

Reputation: 23873

My application was suffering from a a bad leak, and whilst I found the MAT tool useful, I found that the main cause was my not managing the activity stack correctly. I think the most useful way of checking this was from the command line using:

adb shell dumpsys meminfo your.package.name

You'll get an output like 

adb shell dumpsys meminfo your.package.name
Currently running services:
  meminfo
-------------------------------------------------------------------------------
DUMP OF SERVICE meminfo:
Applications Memory Usage (kB):
Uptime: 150876 Realtime: 150875

** MEMINFO in pid 253 [your.package.name] **
                    native   dalvik    other    total
            size:     5404     4103      N/A     9507
       allocated:     5294     3110      N/A     8404
            free:      101      993      N/A     1094
           (Pss):     2346     3737     2198     8281
  (shared dirty):     1964     4644     1480     8088
    (priv dirty):     2204     1856      956     5016

 Objects
           Views:       30        ViewRoots:        2
     AppContexts:        3       Activities:        2
          Assets:        2    AssetManagers:        2
   Local Binders:       13    Proxy Binders:       16
Death Recipients:        2
 OpenSSL Sockets:        0

 SQL
            heap:        0          dbFiles:        0
       numPagers:        0   inactivePageKB:        0
    activePageKB:        0

Check on the activities count and watch the heap size change as you change orientations, etc. Make sure you are not starting copies of already running activities. You can control the stack with the flags you give to the intent on starting an activity.

Upvotes: 2

Femi
Femi

Reputation: 64700

If your application is an image editor and you are seeing this type of behavior then I expect that you are not recycling the Bitmap memory (see http://developer.android.com/reference/android/graphics/Bitmap.html#recycle%28%29).

When your orientation changes and the Activity gets destroyed you will need to locate any large Bitmaps in use by your Views and then either call recycle on them or use the onRetainNonConfigurationInstance method (see http://developer.android.com/reference/android/app/Activity.html#onRetainNonConfigurationInstance%28%29) to pass it to the new Activity instance.

Upvotes: 0

Edwin Buck
Edwin Buck

Reputation: 70949

Remember that in a JVM (and even in an I-can't-believe-it's-not-a-JVM like Davlik) there are many items which you use which aren't exactly under your control. So, the correct approach is to find a way to verify that your code doesn't memory leak, and then you will know that if memory blooms, it is likely some external subsystem, or some intended consequence of the application's actual memory needs.

From your description, it could easily be that the display rendering is simply keeping a lazily built cached memory buffer for each screen orientation.

I only mention this because you have already (from your post) compared heap dumps, and if the heaps don't show a trend in object accumulation, then it is likely some item contained within a library implementation. I know this is a very general rule of thumb, and doesn't apply to most programs (as they probably do contain true memory leaks), but it is something that might be investigated when other options are exhausted.

If you really want to verify that a particular library is keeping a cached copy of the screen orientation, you can always write up a small "test" program which is missing all of the confounding factors (like the rest of your program) and see how it performs on screen orientation shifts.

As far as using VisualVM, it is excellent for detecting user space memory leaks; however, as it is running on a different architecture and implementation, it might miss platform specific library issues.

Upvotes: 2

CommonsWare
CommonsWare

Reputation: 1007399

This specific scenario was covered in a Google I|O 2011 conference presentation. I recommend watching the presentation, as it may help you find your problem better using MAT.

Upvotes: 3

bugs_
bugs_

Reputation: 3744

VisualVM http://visualvm.java.net/
It's in JDK distribution since some version of 1.6

Upvotes: 1

Related Questions