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.
Advertisement
Answer
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.