Unfortunately we need the garbage collection. Sorry cat :(

Note: Android runs on ART (Android Runtime) which is another runtime environment however GC works the same as on JVM.

You probably have learned that in java objects live inside the heap while references and variables live in the stack. In this post we will focus mainly on the heap. Objects inside a heap have different life spans due to garbage collection, which is very good, because fragments get created, destroyed and created over and over again (at least they should) and require the space to do so while other objects are wanted to live a little bit longer (a bitmap cache, a global state holder, a repository, etc.).

Many android developers I’ve met have heard of memory leaks but are not really aware of what they really are and how they are caused. Most of them know that a progress dialog could cause memory leaks if not handled and cleared properly. Despite knowing that, some don’t understand why it actually causes a leak. I have seen Developers setting a reference to a view / context in a static field, just to reuse it later for dependency injection, a sensor API, etc. This will always cause a memory leak if the view / context is not unreferenced after it is unusable (e.g. when the fragment is supposed to be destroyed).

If you don’t want your view (or any other object) leak memory, then avoid coupling it to an object which will live longer than your view. If you do it anyway, make sure you free your view from that reference once your view should die.

A memory leak is basically an object you are not using anymore but is still referenced. That object will live inside the heap blocking space for further allocations.

Structure of the Heap

The GC basically scans the heap and analyzes the objects. Unreferenced objects are marked for garbage collection (removal of the heap). However, the heap can grow very big and complex so it could be very inefficient to constantly scan all the objects inside the heap. How does this happen then?

Oracle has done some research and found out that most allocation of bytes happens in the early stage of an application and it decreases during during the life time.

Most allocated bytes have a short life span. Source: https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

For this reason the heap has been broken down into three categories. The Young Generation, the Old Generation and the Permanent Generation. Additionally, the Young Generation has 3 containers: eden, S0 and S1 (we’ll talk about them in a second). The objects inside the heap contain an age, which you can think of as an integer that is being incremented after certain operations. The Young Generation contains the freshly allocated objects, allowing short living objects to be removed quickly. A garbage collection that happens here is called minor garbage collection. The Old Generation contains older objects, the ones that are already alive for a longer time (Repositories, Application Class, etc.). Your view should actually have no business here. A garbage collection that happens here is called major garbage collection. The Permanent Generation consists of meta data required for the runtime environment (JVM, ART, etc.) which is used to describe classes and methods.