2014-05-09 15:53 GMT+02:00 Kostya Vasilyev <kmans...@gmail.com>: > > > > 2014-05-09 16:59 GMT+04:00 Daniel Rindt <daniel.ri...@gmail.com>: > >> 2014-05-09 0:12 GMT+02:00 Kostya Vasilyev <kmans...@gmail.com>: >> > 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 >> wrong? > > > Well, personally, I usually use the object histogram at the starting point > -- filtered by my app's package. > > When I see something that looks strange, I right click on a object class and > do "merge shortest paths to object roots" to investigate. > > That's just me -- I've not used "leak suspects" -- but maybe you'd be able > to see something interesting in the histogram?
I tried what you said, but please tell me what i can recognize as "strange"? I don't find a definitve guide to find a leak. I can't really see any weird thing. The only conclusion i come to is that every new opened activity consumes more heap and i have the feeling that this causes the oom. >> > 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. > > > That's a well known library, but I guess it still needs to be configured in > a way that makes sense for your app's flow. I've set it for now just to preserve 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 >> > like: >> > >> > Debug.getNativeHeapAllocatedSize() >> > Debug.getNativeHeapFreeSize() >> > Runtime.getRuntime().maxMemory() >> > Runtime.getRuntime().totalMemory() >> > Runtime.getRuntime().freeMemory() >> > ActivityManager.getMemoryClass() >> >> I am new to the memory thing, and it doesn't happen a lot. It happens >> mostly on a rare ressource device. > > > You can create an emulator image with lowered per-process memory quotas. > Don't know if it actually works the way it's supposed to, but the setting is > there. > >> >> But question again starting lots of >> activities >> where you can go back should not be the issue? If the activity itself >> isn't leaking >> anything it can be gc'ed? The backstack just fire the intent again? > > > There have been a few discussions on this list about it -- with no clear > answer that I can remember. This should be fairly easy to verify in the > debugger. > > Maybe you can use the lifecycle callbacks (onStop / onStart) to release some > memory? You mean set collections to null? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- 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 android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
