Memory Leaks And Monitor In Android

5 min readJun 25, 2018

A small leak will sink a great ship. - Benjamin Franklin

The concept of memory leaks is quite daunting for a lot of developers out there. They find it difficult, time-consuming, boring and unnecessary but fortunately, none of these are actually true. Once you start getting into it, you will certainly fall in love with it. Let's dive into ways to prevent Leak in your Application

Let's get our hand dirty on Memory Monitor before diving into MemoryLeak in this article.

What is Garbage Collector?

Many people think garbage collection collects and discards dead objects. In reality, Java garbage collection is does the opposite! Live objects are tracked and everything else is designated garbage

Bonus: If you want to learn more about garbage collectors, I highly recommend you to have a look here and here.

What is Memory Leak?

A memory leak is the gradual loss of available OS memory when a program (an application or part of the operating system) repeatedly fails to return memory that it has obtained for temporary use.

In-short, the unused objects are referenced somehow from reachable objects, GC would mark unused objects as useful object and therefore would not be removed. In Android, every application runs in a Linux Process. Each Linux Process has a Virtual Machine (Dalvik Virtual Machine) running inside it. There is a limit on the memory a process can demand and it is different for different devices and also differs for phones and tablets. When some process demands a higher memory than its limit or the process reaches a state where no more objects can be further created(reaching max heap) then it would result in Out Of Memory Exception

Causes For Out Of Memory Exception

Your Application is doing some operation that continuously demands a lot of memory and at some point it goes beyond the max heap memory limit of a process.
You are leaking some memory i.e you didn’t make the previous objects you allocated eligible for Garbage Collection (GC). This is called Memory leak.
You are working with Large Bitmaps

Memory Monitor

Android studio provides Memory Monitor to find deallocated objects, locate memory leaks, and track the amount of memory the connected device is using. After first run of the app you would be provided with Android Profiler option

To open the Memory Profiler, follow these steps View > Tool Windows > Android Profiler (you can also click Android Profiler)

Select the device and app process you want to profile from the Android Profiler toolbar. If you’ve connected a device over USB but don’t see it listed, ensure that you have enabled USB debugging.

In this article we will concentrate on MEMORY timeline (suggest you to explore CPU and Network timeline) lets look into details of Memory timeline . Click anywhere in the **MEMORY ** timeline to open the Memory Profiler.

(1) Force garbage collection. Small Trash icons in the graph indicate garbage-collection events that you or the system triggered.
(2) Capture a heap dump and display its contents.
(3) Record memory allocations and display the recorded data.
(4) The highlighted portion of the graph shows allocations that have been recorded. The purple dots above the graph indicate user actions.
(5) Allocation-recording and heap-dump results appear in a pane below the timeline. This example shows the memory allocation results during the time indicated in the timeline.
(5 and 6) When you view either a heap dump or memory allocations, you can select a class name from this list (5) to view the list of instances on the right (6).
(7) Click an instance to open an additional pane. When you are viewing the allocation record, the additional pane shows the stack trace for where that memory was allocated. When you are viewing the heap dump, the additional pane shows the remaining references to that object.

At the top of the class list, you can use the left drop-down list to switch between the following heap dumps:

Default heap: When no heap is specified by the system.
App heap: The primary heap on which your app allocates memory.
Image heap: The system boot image, containing classes that are preloaded during boot time. Allocations here are guaranteed to never move or go away.
Zygote heap: The copy-on-write heap where an app process is forked from in the Android system.

The list of objects in the heap are arranged by class name, by default. You can use the other drop-down to switch between the following arrangements:

Arrange by class: Groups all allocations based on class name.
Arrange by package: Groups all allocations based on package name.
Arrange by callstack: Groups all allocations into their corresponding call stack. This option works only if you capture the heap dump while recording allocations. Even so, there are likely to be objects in the heap that were allocated before you started recording, so those allocations appear first, simply listed by class name.

Shallow Size: Size of this instance.

Retained Size: Size of memory that all instances of this class is dominating.

Depth: The shortest number of hops from any GC root to the selected instance.