This document discusses memory related issues in Android applications. It explains that each app runs in a separate process with limited memory based on the device. If an app demands more memory than the limit, it will crash. Memory leaks and handling large bitmaps can also cause issues. Tools like logcat, MAT, and adb commands can help debug memory problems by analyzing heap dumps and tracking allocations over time.

1. Memory Related issues, why?

2. Memory Related issues, why?
● Each application runs in a linux process, having
a Virtual machine (Dalvik VM) running inside it.
● Hard Limit of memeory is present based on
device heap size which can be 16MB, 32MB,
64MB.
● If application demand more memory then limit,
it gives OutOfMemory error.

3. Memory Related issues, why?
● Some operation which demands a lot of
memory even when we don't have.
● Leaking memory i.e. some object which is not
under use but still not available for GC.
● Dealing with large bitmaps and loading them
together.

4. Heap Sizes on different devices
● Heap Size Limit
– G1 – 16MB
– Droid - 24MB
– Nexus One – 32MB
– Galaxy S3 – 64MB

5. Memory Related issues: How to
find?

6. How to find memory Leak
● Can be done using logcat logs:
– [Reason] [Amount Freed], [Heap Statistics],
[External Memory Statistics], [Pause Time]
– GC_EXPLICIT freed 4178K, 18% free
26631K/32304K, paused 3ms+9ms, total
166ms
● The GC_EXPLICIT happens when we call the
System.gc()

7. Reasons of memory leak
GC_FOR_MALLOC/GC_FOR_ALLOC(new name) means that the GC was triggered because there
wasn't enough memory left on the heap to perform an allocation. Might be triggered when new
objects are being created.
GC_EXPLICIT means that the garbage collector has been explicitly asked to collect, instead of
being triggered by high water marks in the heap. Happens all over the place, but most likely when a
thread is being killed or when a binder communication is taken down.
GC_CONCURRENT Triggered when the heap has reached a certain amount of objects to collect.
GC_EXTERNAL_ALLOC means that the the VM is trying to reduce the amount of memory used for
collectable objects, to make room for more non-collectable.
GC_BEFORE_OOM means that the system is running really low on memory, and that there is a
final GC performed, in order to avoid calling the low memory killer.

8. Memory Related issues, How to
Debug?

9. Debugging
● Check Heap size
● Dump Heap at different points and find items
taking lot of heap – using MAT
● Use Allocation Tracker to check what all
objects are allocated in a time period : try to
analyze

10. Debug using MAT
● Install eclipse plugging : Memory Analyzer
● Dump Heap using DDMS and open it in MAT.
● Check memory usage and places where it is
being used.
● Check Histogram : List of number of instances
per class
● Dominator tree: Gives domanint node for each
memory allocation.
● Gives other useful data for memory analysis.

11. MAT terminology
● Shallow Heap
● Retained Heap
● Dominator tree
●

12. Debug using MAT
● Compare two heap dumps using MAT to
identify difference at two instance.
– Open the first HPROF file (using File > Open Heap Dump).
– Open the Histogram view.
– In the Navigation History view, right click on histogram and select
Add to Compare Basket.
– Check the difference in memory allocation at two instances

13. Useful Adb Commands

14. Adb commands
● Adb shell ps → gives processes running
● adb shell dumpsys meminfo PID-> gives
memory info of process
● adb shell cat /proc/meminfo-> gives a
summary of the overall memory usage of the
system.