Android Development — Memory Leaks

And How to Identify them using LeakCanary

What is a Memory Leak in Android?

A memory Leak can be described as a waste of the memory resource by our app.

Imaging having an old VCR player, because you know that you have a few VHS tapes in your garage, only to find out the tape cases are empty and you have been wasting space by not throwing out the VCR player!

This is exactly what happens in memory leaks as the GarbageCollector wants to clear the space that the object is saved in, only to find the object is still referenced in other place. the garbageCollector will never be able to clear an object that have a reference so the memory is never cleaned up.

It’s Working so why should I fix it?

The focus of any engineer as a starting point for any task is for it to work, but as engineers and not just “Coders” the code we write and features that we deliver should be usable and perform well for actual users.
Memory Leaks will eventually lead to OutOfMemory Exception. thus memory leaks cant be ignored for long.

So Where do we start?

I would suggest starting with LeakCanary which is a memory leak detection library for Android.

simply add the following line to your build.gradle

Note: LeakCanary should only be added on debug, hence the debug-Implemention was used.

What is the Canary doing to my app !?

Internally what leakCanary does, simply is that it monitors a destroyed activity, waits for five seconds and then forces a garbage collection. If the activity is still there, LeakCanary considers it as a potential leak.

This is essentially the automation of the manual process of using the profiler to monitor, force Garbage-Collector and dump heap that we used to do manually.

Leak canary monitors the of the Activity ,Fragment,ViewModel, Service, fragment’s View

Leaks Found..

After adding leak Canary and running the app navigate across your app normally, once leaks are found you will notice the bird icon on the statues bar :

after clicking the notification LeakCanary will dump the heap and give you the analysis “Leak trace” which can be accessed from LeakCanary App on the device or directly on the Logs.

dumping heap in progress

analysis is done!

Leak Sources

Leaks could happen at the 2 categories :

• App level
• Library level

App level leaks can be fixed be identified and fixing each leak on its own, but when it comes to 3rd party libraries leaks there isn't much that we can do.

In LeakCanary you will see Library leaks reported as the following:

So that you can focus on workable leaks or assist the need of a library that cause a significant leaking

Common Leaks ..

For App level leaks it can be alot of causes but here we mention some of the most common so you can avoid them while coding:

Inner Classes and Anonymous Classes

Sometimes anonymous class or inner class instance lives longer than the container instance . If this instance calls any property of the container class then it would leak it.

Static Variables

Since variables inside companion object are static and not related to the object life cycle then saving any reference to the activity in a static variable will cause a leak.

Singleton

Avoid passing the activity context in singleton variables like managers, and pass the application context instead.

View Leaks

Any Saved references to views as lateinit var btnNext on Fragment level needs to be nulled out in onDestroyView . If you are using viewBinding binding you need to null out the binding class reference in the same manner.

clearing out the binding class

Callbacks

We need to be aware of callbacks and what are they registered upon. in normal scenarios UI callbacks(listeners) like onClickListener on a button wont cause a leak but other callbacks needs to be unregistered.

Thanks for reading!