"Avoiding memory leaks in Android" Денис Жучинский
0 likes1,709 views
The document discusses memory management in Android, focusing on avoiding memory leaks and OutOfMemoryErrors. It covers concepts like garbage collection, memory areas, tools for monitoring memory usage, and best practices to prevent memory leaks. Key recommendations include using weak references, recycling bitmaps, and being mindful of static references and long-lived objects.
"Avoiding memory leaks in Android" Денис Жучинский
- 1. Avoiding memory leaks in Android Denis Zhuchinski Prom.ua d.zhuchinskiy@smartweb.com.ua https://github.com/zhuchinskyi/ https://ua.linkedin.com/in/denys-zhuchinskyi-96ab0673
- 2. Agenda ● Memory Management ● Garbage Collector ● Memory Leaks ● Tools ● Demo ● How to avoid OutOfMemoryError?
- 4. Android Memory Management ● Each app process is forked from an existing process called Zygote ● No swap space ● Virtual Address Space (Memory management unit) ● Paging and Memory-Mapping (mmapping) ● Process space limitation
- 5. Sharing Memory ● Binder IPC Driver ● Android shares the same dynamic RAM across processes using explicitly allocated shared memory regions (ashmem) ● Most static data is mmapped into a process (VM code, app resources, native code)
- 6. Application Memory Restrictions ● Isolated in process ● Hard limit heap size ● Heap size limit varies between devices ● Low-Memory Killer (Proportional Set Size) ActivityManager.getMemoryClass() ActivityManager.getLargeMemoryClass()
- 7. Process Priority Activity Process Visible Process Service Process Background Process Empty Process Critical Priority High Priority Low Priority
- 8. Main Process Memory Areas ● Stack (local variables, partial results, method invocation) ● Heap (all objects) ○ Java ○ Native ● java.lang.StackOverFlow ● java.lang.OutOfMemoryError
- 9. Main Process Memory Areas ● Stack (local variables, partial results, method invocation) ● Heap (all objects) ○ Java ○ Native ● java.lang.StackOverFlow ● java.lang.OutOfMemoryError
- 11. Garbage Collection ● Automatic memory management scheme ● VM performs routine garbage collection (GC) ● Uses mark-and-sweep algorithm
- 12. Dalvik and ART
- 13. ART GC Enhancement ● Enumerates all allocated objects and marks all reachable objects in only one pause while Dalvik’s GC pauses twice ○ enumeration phase performed by application ○ pre-cleaning technique ● Parallelization ● Lower total GC time (cleaning up recently-allocated) ● Compacting GC merges freed-up single blocks in one location of memory (Still in development by Android Open-Source Project)
- 15. Memory Leaks
- 16. ● Memory leak: situation where some objects are not used by application any more, but GC fails to recognize them as unused ● Memory consumption increases -> Degradation in performance ● GC does not prevent leaks! Memory Leaks
- 17. How to detect? ● Huge memory consumption in Android Studio Memory Monitor ● Frequent GC calls in LogCat ● App crashes with an OutOfMemmoryError (OOM) D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time> 07-02 15:56:14.275: D/dalvikvm(30615): GC_FOR_ALLOC freed 4442K, 25% free 20183K/26856K, paused 24ms, total 24ms 07-02 15:56:16.785: I/dalvikvm-heap(30615): Grow heap (frag case) to 38.179MB for 8294416-byte allocation 07-02 15:56:17.225: I/dalvikvm-heap(30615): Grow heap (frag case) to 48.279MB for 7361296-byte allocation 07-02 15:56:17.625: I/Choreographer(30615): Skipped 35 frames! The application may be doing too much work on its main thread. 07-02 15:56:19.035: D/dalvikvm(30615): GC_CONCURRENT freed 35838K, 43% free 51351K/89052K, paused 3ms+5ms, total 106ms I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, Large_objects_freed> (<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)> 07-02 16:00:44.531: I/art(198): Explicit concurrent mark sweep GC freed 700(30KB) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 186us total 12.763ms 07-02 16:00:44.545: I/art(198): Explicit concurrent mark sweep GC freed 7(240B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 198us total 9.465ms 07-02 16:00:44.554: I/art(198): Explicit concurrent mark sweep GC freed 5(160B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 224us total 9.045ms
- 18. Dalvik GC Reason ● GC_CONCURRENT ● GC_FOR_MALLOC ● GC_HPROF_DUMP_HEAP ● GC_EXPLICIT ● GC_EXTERNAL_ALLOC D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
- 19. ART GC Reason ● Concurrent ● Alloc ● Explicit ● NativeAlloc ● CollectorTransition ● HomogeneousSpaceCompact I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, Large_objects_freed> (<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>
- 20. Tools
- 21. Tools ● adb shell dumpsys meminfo <package_name | pid> ● Android Monitor ○ Heap Dump ○ Allocation Tracker ● Eclipse Memory Analyzer Tool (MAT) ● LeakCanary (Square)
- 23. ● Do not keep long-lived references to an Activity, Context, View, Drawable... ● Avoid non-static inner classes in an activity if you don’t control their life cycle ● Avoid mutable static fields ● Use Weak References ● Try to not have long living objects ● Use as much as possible application Context instead of Activity ● Remember to call unregisterReceiver() after calling registerReceiver() ● Implement cancellation policies for background threads ● Use LeakCanary in the QA cycle ● Keep an eye on the heap while the app is running ● Don’t assume GC will clean up all for you! ● Search for memory leaks even when things aren't failing! How to avoid Memory Leaks?
- 24. ● Use bitmaps with correct resolution ● Recycle the bitmaps more often, instead of just onDestroy() ● Send large files to server by chunks ● Avoid creating unnecessary objects ● Check the available heap of your application ● Coordinate with the system by implementing onTrimMemory() callback ● External libraries should be used carefully ● Use Proguard and zipalign How to avoid OutofMemoryError?
- 25. References ● http://developer.android.com/intl/ru/training/articles/memory.html ● https://xakep.ru/2014/05/21/excurse-in-android-architecture/ ● https://software.intel.com/en-us/android/articles/art-vs-dalvik-introducing-the-new-android- x86-runtime ● https://software.intel.com/en-us/android/articles/tips-for-optimizing-android-application- memory-usage ● https://android.googlesource.com/platform/art/+/master/runtime/gc/ ● http://developer.android.com/intl/ru/tools/debugging/debugging-memory.html ● http://www.raizlabs.com/dev/2014/03/wrangling-dalvik-memory-management-in-android-part- 1-of-2/ ● https://acadgild.com/blog/analyze-manage-android-devices-memory-allocation-through-ddms- mat/ ● http://developer.android.com/intl/ru/tools/help/am-memory.html ● http://developer.android.com/tools/debugging/debugging-memory.html
- 26. Q&A