2014-05-09 15:53 GMT+02:00 Kostya Vasilyev <[email protected]>: > > > > 2014-05-09 16:59 GMT+04:00 Daniel Rindt <[email protected]>: > >> 2014-05-09 0:12 GMT+02:00 Kostya Vasilyev <[email protected]>: >> > 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
