🦈 Shark Heap Analysis - LeakCanary's Detective at Work

Shark Heap Analysis — How LeakCanary Turns Heap Dumps into Actionable Leak Traces

Learn how Shark parses Android heap dumps, builds a HeapGraph, traces GC-root paths, filters known leaks, and generates actionable LeakCanary reports.

In the previous article, we saw how LeakCanary freezes the app briefly to capture a .hprof heap dump. But a heap dump on its own is only raw binary data. To make it useful, LeakCanary needs an analysis engine that can parse memory records, reconstruct object relationships, and explain why retained objects are still alive.

That analysis engine is Shark.

Shark is where memory leak debugging becomes understandable. It transforms a raw heap snapshot into a structured object graph, finds the most relevant retaining paths, and produces the LeakTrace reports developers use to fix leaks.

Table of Contents

1. What Is Shark?

Shark is LeakCanary’s heap analysis engine. Its purpose is to inspect the .hprof file generated after a heap dump and convert that low-level memory snapshot into something developers can reason about.

In practice, Shark parses raw heap records, builds a graph of objects and references, locates suspected leaking objects, and traces how those objects remain reachable from GC roots.

2. Why Shark Matters

Without Shark, a heap dump would remain an unreadable artifact. Shark is the layer that turns memory data into debugging insight.

  • It parses raw heap data into a queryable object graph.
  • It automates leak detection by finding shortest or most relevant retention paths.
  • It filters known patterns using reference matching for framework or library leaks.
  • It produces LeakTrace output that developers can use directly.

This is why Shark is often the difference between “we have a heap dump” and “we know what to fix.”

3. Parsing the Heap Dump

Shark begins by reading the .hprof heap dump format. In the original article, this is described as Shark Hprof streaming through heap records efficiently and opening the dump as a graph-backed structure. [page:1] 

val heapGraph = Hprof.openHeapGraph(heapDumpFile)

This step is important because it converts raw binary memory data into an internal model that Shark can traverse and analyze.

4. Building the HeapGraph

Once the dump is parsed, Shark exposes the memory snapshot as a HeapGraph. This graph contains classes, object instances, fields, and references between objects. 

val activityClass = heapGraph.findClassByName("com.example.LeakyActivity")
val instances = activityClass.instances

A good mental model is to think of HeapGraph like a memory database. Instead of guessing what is retaining an object, Shark can traverse the reference graph directly.

5. How Shark Finds Leaks

Shark’s HeapAnalyzer coordinates the core leak detection flow. It starts from suspected leaking objects, then works backward through the heap graph to understand why those objects are still reachable.

  1. Identify suspected leaking objects, often provided by ObjectWatcher.
  2. Find shortest paths from GC roots to those objects.
  3. Apply ReferenceMatchers to filter or classify known library and framework leaks.
  4. Generate a human-readable LeakTrace.

This is the stage where Shark transforms object retention into a causal explanation.

6. Reading a LeakTrace Example

A LeakTrace is easiest to understand when you read it from the GC root down to the leaking object: 

GC Root: System class
↓
android.view.inputmethod.InputMethodManager
↓ InputMethodManager.mLastSrvView
com.example.LeakyActivity

Leaking: YES (Activity was destroyed)

This tells you that the destroyed Activity is still reachable because a system-managed object, InputMethodManager, is holding a reference chain to it.

That is what makes Shark useful: it does not just say “this object leaked.” It shows the actual path that kept it alive.

7. Retained Size and Prioritization

Shark does more than find retention paths. It also uses dominator tree analysis to estimate retained size, which helps teams understand how much memory would be recovered if a leaking object were fixed. [page:1]

  • Small retained size may indicate a minor leak.
  • Large retained size often points to a high-priority memory problem.
  • Retained size helps teams prioritize fixes instead of treating every leak as equally severe.

This is why Shark is both a debugging engine and a prioritization engine.

8. Shark Analysis Flow

The high-level flow can be summarized like this:

Heap Dump (.hprof) → Shark Hprof → HeapGraph → HeapAnalyzer → LeakTrace → Developer Fix

That pipeline is where raw memory inspection becomes engineering action.

9. Analyze LeakCanary Reports Faster with LeakLens

Shark gives you the core analysis, but complex leak traces can still take time to interpret. LeakLens complements this workflow by analyzing LeakCanary reports, explaining retention paths, and suggesting likely fixes directly inside Android Studio.

It is especially useful once you already understand Shark’s role in the leak analysis pipeline.

Explore LeakLens

10. What to Read Next

This article covers the analysis engine behind LeakCanary. To continue through the full series, read the related posts below:

FAQ

What is Shark in LeakCanary?

Shark is LeakCanary’s heap analysis engine. It parses heap dumps, builds object graphs, finds retaining paths, and generates LeakTrace reports.

What is a HeapGraph in Shark?

HeapGraph is Shark’s graph representation of the heap dump, exposing classes, instances, fields, and references for memory analysis.

How does Shark find memory leaks?

Shark starts from suspected leaking objects, traces paths from GC roots, applies reference matchers, and generates human-readable leak traces.

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