This article is a continuation of part 1 of this mini series of memory leaks cookbook for Android. Talking about memory leaks sometimes involves more than the technical problem itself.

For one concern, the definition of a memory leak is subjective. The authors of Programming Android with Kotlin: Achieving Structured Concurrency leans more towards a cautionary stance on what constitutes as a memory leak, especially in regards to larger codebases:

• When the heap holds to allocated memory longer than necessary
• When an object is allocated in memory but is unreachable for the running program

For another concern, sometimes the OOMs sprinkling analytics might indicate a symptom to the actual problem — that the application was already taking up most of the memory allocated in the device.

Consider these nebulous concerns as the theme of the next set of performance hits in the score card below:

6. Statically-saved thread primitives within singletons → remove
7. Listeners + View members in Fragment → nullify in onDestroyView
8. Rx leaks -> return results to main thread + clear disposables

6. Statically-saved thread primitives within singletons → remove

This example is presented within the context of Dagger 2/Hilt, but the concepts behind this memory leak can be applied to any form of dependency injection.

Consider the following scenario, where TopologicalProcessor holds a static member reference to a ThreadPoolExecutor:

As explained in documentation,@Singleton annotation is actually a scope. Scope determines how long a dependency is kept alive. In the case of an object annotated with @Singleton, it is kept alive for the lifetime of the component it might be used in.

What makes this a memory leak? The @Singleton annotation might be seen as a “God object”, so what does it matter that the ThreadPoolExecutor would always exist in the lifetime of the heap? The answer lies in how many tasks are kept within ThreadPoolExecutor.

Suppose we inject the dependency TopologicalProcessor in both MainActivity and some instance of SecondActivity so we can feed tasks to load map tiles into tileThreadPoolExecutor at initialization.

At runtime, a user is sitting on the 1) MainActivity screen, 2) opens an instance of SecondActivity, 3) closes it by navigating back, then 4) opens another instance of SecondActivity once more.

A visual representation of Activities and continuous active Runnable in queue given the current memory leak.

Upon examining abridged logging to see what Runnable tasks are stored and executed in tileMapThreadPoolExecutor queue, we can see 3 tasks created shortly after MainActivity starts and run promptly after. Then SecondActivity, which adds its own set of Runnable tasks to the queue. But upon accessing tileMapThreadPoolExecutor queue, we notice that the queue continues to hold on to the same Runnable tasks already added from MainActivity. The result is executing all the tasks again, even though we had already run the tasks earlier and each task should have been disposed of after the work had completed.

We’re already seeing problems, but let’s keep reading down to the last block of logging. SecondActivity is destroyed, then another instance of SecondActivity is started. The new SecondActivity adds its own set of runnable tasks to the queue. However, the queue has not disposed of the other tasks which has already run, and subsequently included in aggregate when attempting to empty the queue. As we can see, this problem can becomes expensive very quickly.

Avoid saving Android data threading primitives using astatic keyword in Java or in a companion object in Kotlin. We do not want forever-living threads which cannot be disposed of by GC!

Removing the static keyword, or moving the class member outside companion object provides an easy fix to the issue, as shown in the code snippet below:

We have now moved tileMapThreadPoolExecutor outside of companion object. Upon running the same set of interactions — opening one instance of SecondActivity, closing it, then opening a new instance of SecondActivity — we can now see in logging that tasks that have been completed have also been cleared in memory.

We now see there are no duplicate tasks running at each opening of an Activity class. Because each Runnable is disposed in the queue after the work is complete, emptying tileMapThreadPoolExecutor won’t involve spinning up needless threads for work that is already completed.

For the lucky few who might find these in their code bases, this fix gives back so much memory, it will be hard to not to declare this a win — so take care to measure heap before and after!

7. Listeners + Views in Fragment → nullify references in Fragment::onDestroyView

Not clearing view references in Fragment::onDestroyView causes these views to be retained using the back stack. This might not be a big deal for smaller applications, but large applications might end up having those small leaks accumulate and cause OOMs.

At one time, this was not clear in documentation: however, this is intended behavior Android developers are expected to know: a Fragment’s View (but not the Fragment itself) is destroyed when a Fragment is put on the back stack. For this reason, developers are expected to clear/nullify references for views in Fragment::onDestroyView.

🤯🐤

This answer is 100% wrong, and I'm sad that this is the answer given to a developer trying to fix leaks.

If you add a fragment to a backstack, you better cleanup all view references in Fragment.onDestroyView()

Definition: https://t.co/MWMGmSl5dohttps://t.co/wKxIoesI7A pic.twitter.com/AvJi3bWxlB

— @py@androiddev.social (@Piwai) December 3, 2019

As you can see, memory leaks are hotly debated: in this case, Programming Android with Kotlin would indeed consider this a memory leak, since views are not cleaned up until the Fragment itself is permanently destroyed. Luckily, there is an easy fix for this — nullifying all View members within a Fragment class on onDestroyView.

Likewise, view bindings and listeners declared as class members should also be nullified in Fragment::onDestroyView. With a code change as little time consumption and risk as possible, it’s a big win for little cost and effort worth showing off.

8. Rx leaks -> return results to main thread + clear disposables with lifecycle

Working with RxJava can be tricky. For the sake of conversation, we stick with RxJava 2 context. There’s two easy rules when working with CompositeDisposable, both of which can be covered with the following code example showing a CompositeDisposable sitting within a presenter layer. This example only shows working with one disposable, but our memory leaks already exist as short as it is. Can you spot the two sources of leaks?

1. Return the results of the event stream back to the main thread at the end of the Rx chain — otherwise, your transformed result might end up floating off in the nethers of background threads, and leaking memory right along with it (or worse, crashes).

Adding .observeOn(AndroidSchedulers.mainThread()) ensures the results of the heavy work is usable for view state:

2. Dispose of the disposables. Unsubscribe to your subscriptions. If we wish to subscribe to a CompositeDisposable within the context of some Android component, make sure to clear the subscription at the end of the lifecycle to prevent leak.

In the case of our current code snippet, we make the clear call for our CompositeDisposable when the View attached to the presenter has ended its life.