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? > > > 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. > > > 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? -- K -- 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.
