Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Effective memory management


Published on

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Effective memory management

  1. 1. Effective Memory Management Denis Zhuchinski
  2. 2. Agenda ● Android Memory Management ● Memory Leaks ● Tools ● Demo ● How to avoid OutOfMemoryError?
  3. 3. Android Memory Management
  4. 4. Android Memory Management ● No swap space ● Virtual Address Space ● Paging and Memory-Mapping (mmapping)
  5. 5. Application Memory Regions ● Heap ○ Java ○ Native ● Stack ● Shared Memory
  6. 6. Sharing Memory ● Each app process is forked from an existing process called Zygote ● Most static data is mmapped into a process (Dalvik code, app resources, native code) ● Android shares the same dynamic RAM across processes using explicitly allocated shared memory regions (ashmem or gralloc)
  7. 7. Application Memory Restrictions ● Isolated in process ● Hard limit heap size ● Heap size limit varies between devices ● Proportional Set Size (PSS): Clean, Dirty ● ActivityManager.getMemoryClass() ● ActivityManager.getLargeMemoryClass()
  8. 8. Process Priority Activity Process Visible Process Started Service Process Background Process Empty Process Critical Priority High Priority Low Priority
  9. 9. Main Process Memory Areas - Stack (method invocation, local variables) - Heap (all objects) ● java.lang.StackOverFlow ● java.lang.OutOfMemoryError
  10. 10. Main Process Memory Areas - Stack (method invocation, local variables) - Heap (all objects) ● java.lang.StackOverFlowError ● java.lang.OutOfMemoryError
  11. 11. Are there memory leaks in Android? Isn’t Java a garbage-collected language?
  12. 12. Garbage Collection ● Dalvik and ART performs routine garbage collection (GC) ● Uses mark-and-sweep algorithm ● All objects created with new are stored on the heap
  13. 13. ART GC Enhancement ● Enumerates all allocated objects and marks all reachable objects in only one pause while Dalvik’s GC pauses twice ● 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)
  14. 14. ART GC Enhancement
  15. 15. Memory Leaks
  16. 16. ● Memory leak is a situation where some objects are not used by application any more, but GC fails to recognize them as unused ● Degradation in performance as the memory consumption increases Memory Leaks
  17. 17. How to detect? ● App crashes with an java.lang.OutOfMemmoryError (OOM) ● Frequent GC calls in LogCat before the crash 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-01 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-01 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-01 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. 18. Tools
  19. 19. Tools ● adb shell dumpsys meminfo <package_name | pid> ● Android Monitor ○ Allocation Tracker ○ Heap Dump ● Eclipse Memory Analyzer Tool (MAT) ● LeakCanary (Square)
  20. 20. Demo
  21. 21. ● 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 ● Use Soft and 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 ● Keep track of your references ● 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?
  22. 22. ● 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?
  23. 23. References - - android-x86-runtime - memory-usage - - - android-part-1-of-2/ - ddms-mat/ -
  24. 24. Q&A