🌳 Dominator Tree & Retained Size - Measuring the True Cost of Memory Leaks

Dominator Tree and Retained Size — Measuring the True Cost of Android Memory Leaks

Learn how Shark uses dominator trees and retained size to measure leak impact, prioritize fixes, and explain the real cost of retained objects in Android apps.

In the previous part of this series, we saw how Shark parses heap dumps and generates leak traces. But one important question still remains: which leaks should you fix first?

Not all memory leaks are equally dangerous. A destroyed Activity retaining an entire view hierarchy can be far more expensive than a small isolated object. That is why Shark uses dominator trees and retained size to estimate impact, not just existence.

Table of Contents

1. Why Not All Leaks Are Equal

Leak detection tells you that something is being retained. Impact analysis tells you whether that leak is small, moderate, or serious.

  • A tiny object leak may be noisy but not urgent.
  • A leaked Activity may retain Views, adapters, child Fragments, drawables, and other large object graphs.
  • A high retained size usually means more wasted memory and more pressure on app stability.

This is where retained size becomes more useful than raw leak count. It helps you prioritize based on cost rather than just occurrence.

2. What Is a Dominator Tree?

A dominator tree is a graph structure used in memory analysis. In simple terms, one object dominates another object if every path from a GC root to that object passes through the dominator.

That means the dominated object cannot stay alive independently. If the dominator is collected, the dominated objects can usually be collected too.

  • Each node represents an object in the heap.
  • A parent object may dominate many children in the object graph.
  • This structure helps analysis tools estimate memory ownership and cleanup impact.

A simple mental model is a memory ownership tree: if the parent goes away, its dominated subtree can go away with it.

3. What Is Retained Size?

Retained size is the total amount of memory that would be freed if a particular object were garbage collected.

This includes not only the memory used by the object itself, but also the memory used by objects that are kept alive only because of it.

  • Shallow size: memory used by the object itself.
  • Retained size: shallow size plus the dominated memory graph that depends on it.

This distinction matters because the most dangerous leaks are usually not the biggest individual objects, but the objects retaining large subgraphs.

4. How Shark Uses Dominator Trees

Shark uses dominator tree analysis after parsing the heap dump. Once it builds the heap graph, it can estimate which objects dominate others and how much memory would be recovered if a leaking object were fixed. 

val heapGraph = Hprof.openHeapGraph(heapDumpFile)
val dominatorTree = DominatorTree(heapGraph)
val retainedSize = dominatorTree.retainedSize(leakingActivity)

High-level analysis flow:

GC Roots → Heap Graph → Dominator Tree → Retained Size → Leak Prioritization

This is what turns a heap dump from a static snapshot into a prioritization tool.

5. Example: Leaking Activity with Retained Size

Suppose a destroyed Activity is still retained in memory. That Activity may dominate many related objects:

  • its view hierarchy,
  • adapters and listeners,
  • child Fragments,
  • drawables, caches, and other UI-linked objects.

In that case, LeakCanary and Shark may report something like: 

Retained size: 5 MB
com.example.LeakyActivity
Leaking: YES

This does not just mean the Activity is leaking. It means fixing that one root retention problem could free roughly 5 MB of memory immediately.

6. Why This Matters in Real Apps

Dominator trees and retained size matter because they improve engineering judgment.

  • Better prioritization: fix large-impact leaks before minor noise.
  • Clearer performance reasoning: retained size helps explain memory pressure more concretely.
  • Stronger advocacy: it is easier to justify a fix when you can show how much memory is being wasted.
  • Smarter triage: teams can separate “interesting” leaks from “urgent” leaks.

In mature Android teams, this kind of prioritization is what turns memory debugging from reactive cleanup into deliberate performance engineering.

7. Analyze LeakCanary Reports Faster with LeakLens

Retained size and dominator trees are powerful, but large reports can still be difficult to interpret quickly. LeakLens helps by analyzing LeakCanary reports, explaining retention paths, and suggesting likely fixes directly inside Android Studio.

It is especially useful when you want to move faster from “this leak retains 5 MB” to “this is the most likely root cause and fix.”

Explore LeakLens

8. What to Read Next

This article explains how Shark measures impact. To continue through the full LeakCanary internals series, read the related posts below:

FAQ

What is a dominator tree in memory analysis?

A dominator tree shows which objects control the reachability of other objects from GC roots, making it easier to estimate memory ownership and impact.

What is retained size in LeakCanary or Shark?

Retained size is the total memory that would be freed if a leaking object were garbage collected, including the objects it keeps alive.

Why is retained size more useful than leak count?

Leak count tells you how many suspicious objects exist, but retained size helps prioritize which leaks are actually expensive and urgent.

This guide is part of the Android Quality Suite.

Comments

Post a Comment

Featured Articles

Optimize Jetpack Compose: Performance & Best Practices

Image
      Jetpack Compose offers a declarative approach to building UIs in Android. However, like any UI framework, optimization is key to achieving smooth performance and a great user experience. This detailed guide expands on the provided checklist, offering in-depth explanations and practical code examples for each optimization technique. I. Core Principles: Laying the Foundation for Performance Use Stable Types:  Compose relies on stable types to efficiently track changes and minimize recompositions. A stable type guarantees that if two instances of the type are equal according to  equals() , they will always be equal. Using unstable types can force unnecessary recompositions.   // Stable data class (recommended) data   class   User ( val  name: String,  val  age:  Int ) // Unstable list (avoid directly in Compose state) // Use SnapshotStateList instead val users = remember { mutableStateListOf<User>() } // Cor...
Read more

Play Store Uploads with Fastlane Supply - 4

Image
If you’ve ever manually uploaded an APK or AAB to the Google Play Store, you know it can be a tedious process. From filling out all the necessary metadata to selecting the correct APK version, it can feel like a lot of repetitive work. But with Fastlane Supply , you can automate this entire process — making your app releases smoother, faster, and error-free. In this section, we’ll explore how Fastlane Supply works and how to set it up to upload your Android app directly to the Play Store with ease. Step 1: Set Up Google Play API Access Before you can upload your app with Fastlane Supply , you need to set up Google Play API access . This ensures that Fastlane can communicate with the Play Store and upload your APK or AAB. Here’s how you can set up API access: Create a Google Cloud project : Go to the Google Cloud Console. Create a new project. Enable the Google Play Developer API : In the Cloud Console, search for and enable the Google Play Developer API . Create a service account ...
Read more

Building a Production-Ready Kotlin Multiplatform Platform Kit: Lessons from My BlrKotlin x InMobi Talk

Image
How I built an open-source Kotlin Multiplatform reference project to help Android teams move beyond tutorials and start thinking about production-ready architecture. Last weekend, I had the opportunity to speak at the BlrKotlin x InMobi Android Meetup in Bengaluru, where I shared something I've been working on over the past few months—a practical Kotlin Multiplatform Platform Kit . Rather than giving another introduction to Kotlin Multiplatform, I wanted to focus on a question many Android teams eventually ask once they move past the excitement of "Hello World" examples: "We understand what Kotlin Multiplatform is—but how do we actually structure a project we'd be comfortable maintaining in production?" To answer that question, I built kmp-platform-kit , an open-source reference repository that demonstrates how to organize a Kotlin Multiplatform codebase with clean architecture, modular boundaries, and engineering decisions inspired by re...
Read more

Android Device Security: Sandboxing, Rooting, and Attestation Explained

Image
  As Android developers, understanding device security is essential to protect our apps and users. In this comprehensive guide, we’ll explore Android’s security architecture, including sandboxing, rooting and jailbreaking, and how to implement device attestation using SafetyNet and Play Integrity. We’ll cover each topic in detail, providing code snippets and best practices, following. What is Sandboxing in Android? Sandboxing is the security mechanism that isolates each app’s code and data from other apps and from the underlying system. In Android, this ensures that one app cannot freely read or modify another app’s private data or perform privileged operations unless explicit permissions or IPC channels are used.​ High-Level Idea Each app runs in its own isolated environment with: Its own Linux user ID (UID) and process. Its own private data directory (e.g., /data/data/<package_name>/ ). By default: One app cannot directly access another app’s files. An app cannot perfo...
Read more

From ‘Master’ to ‘Main’: The Meaning Behind Git’s Naming Shift

Image
                             Git changed its default branch name from master to main due to concerns about inclusivity and to remove references to terms with problematic historical connotations. The term master has been associated with slavery, and many tech communities sought to use more neutral and inclusive language. Reason for the Change: Inclusivity & Sensitivity- Many organizations aimed to remove racially charged terminology from software development. Consistency Across Communities- Other projects and platforms, such as Github, Gitlab, and software frameworks, also made similar changes. Modern Naming Conventions- main is a cleaner and more intuitive name, as it represents the primary branch of a repository. Interesting Facts —  It wasn’t originally about slavery  — The term Git did not originate from the master/slave concept used in computing. It likely came from Bitkeeper , a version contro...
Read more