2014-05-09 0:12 GMT+02:00 Kostya Vasilyev <firstname.lastname@example.org>:
> Are you absolutely sure that your code does not leak memory?
How to be "absolutely sure". :-) Just kidding.
> Have you tried using Eclipse MAT and putting the app through the usual
> paces, like rotating the screen, pausing / restarting, etc.?
This i have done:
* app started, before killed
* dump hprof and load with mat (leak suspects)
* rotate, rotate, rotate...
* dump hprof again load with mat (leak suspects)
i compared the mat reports with the suspects and i see no differences in the
"leak suspects report". Which sould differ in the occupied size when i am not
> You'd mentioned the app being heavy on image processing -- is your memory
> allocation strategy based on how much memory your app's process gets? You
> can use ActivityManager#getMemoryClass for that.
Actually i am aware of this complicated and consequences so i use the
universal image loader which is configured to scale the images exact in the
bitmap which cost cpu time, but preserves memory.
> It's too bad that your log does not have any memory allocation data. I'd
> consider implementing a crash handler that logs to a file, recording things
I am new to the memory thing, and it doesn't happen a lot. It happens
mostly on a rare ressource device. But question again starting lots of
where you can go back should not be the issue? If the activity itself
anything it can be gc'ed? The backstack just fire the intent again?
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at
You received this message because you are subscribed to the Google Groups "Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.