offer swap space for memory. • Android’s VM performs routine GC. • Don’t ignore when and where app allocates and releases memory. • The only way is analyze app’s memory usage with tools and proper care.
limited size by the device manufacturer. Memory is garbage-collected. • The native heap used by the C++ new operator. The app is limited only by the physical memory available on the device. There is no garbage collection. • Android shared memory - ashmem. Android can “unpin” the memory rather than freeing it. This is a lazy free; the memory is freed only if the system actually needs more memory. When Android “pins” the memory back, old data will still be there if it hasn't been freed.
Shared user ID - all must have same Flag. • Better focus on reducing overall memory usage. • Does not guarantee a fixed increase in available memory. Increase Heap size
has a reference to an object that is no longer needed, preventing the VM to perform the garbage collection for that reference. • Degradation in performance as the memory consumption increases.
is being used by only your process. • RAM that the system can reclaim when your app’s process is destroyed. • Most important portion is “private dirty” RAM - the most expensive. • Used by only your process and its contents exist only in RAM so can’t be paged to storage. • Dalvik and native allocations will be private dirty RAM • Dalvik and native allocations you share with the Zygote process are shared dirty RAM.
RAM usage that takes into account sharing pages across processes. • RAM pages that are unique to process directly contribute to its PSS value. • Shared Pages contribute to the PSS value only in proportion to the amount of sharing. • For example, a page that is shared between two processes will contribute half of its size to the PSS of each process. • PSS from all processes actual memory usage in device. • Good Comparison against the RAM use of other processes.
Better understanding memory-hogging objects allocations. • Useful to analyze critical code paths. • For example - flinging a list in your app • Viewing all the allocations that need to be done for that behaviour. • What thread they are on. • Where they came from.
crashe/s . • Attempt to reproduce the problem. You need to figure out what navigation sequence triggers the leak, possibly by brute force. • Dump the heap when the OOM occurs. • Poke around the heap dump and find an object that should have been garbage collected. • Compute the shortest strong reference path from that object to the GC roots. • Figure out which reference in the path should not exist, and fix the memory leak.
activity if instances of the inner class could outlive the activity's lifecycle. • Avoid passing anonymous inner class objects to static / singleton classes which keep a strong reference to it. • Don’t hold references to activities whenever possible. Tips to Go
reused. • Blank activity with very little memory consumption, transition to it and force a GC. • Use Heap dump. • Use Allocation Tracker. before and after the transition. Tips to Go
matrixy
murabayashi
syumai
azuki
0si43
izumin5210
hsawaji
mot_techtalk
gam0022
kakao
cer
1024jp
manfredsteyer
mojombo
rmw
rocio
irinanazarova
cassininazir
productmarketing
keavy
shpigford
hatefulcrawdad
jeffersonlam
addyosmani
moore
