Mobile Development 13 min read

Sieve – Android Memory Analysis System: Design, Implementation, and Dominator‑Tree Based Retained Size Calculation

This article introduces Sieve, an internal Android memory‑analysis platform that parses Hprof heap dumps, builds dominator trees, computes retained sizes, and constructs reference paths to help developers locate OOM‑causing leaks and optimize memory usage.

JD Retail Technology
JD Retail Technology
JD Retail Technology
Sieve – Android Memory Analysis System: Design, Implementation, and Dominator‑Tree Based Retained Size Calculation

The article starts by describing the persistent challenge of memory leaks and OOM crashes in Android applications, noting that existing tools such as LeakCanary and MAT either provide limited insight or are not well‑suited for Android‑specific objects like large Bitmaps.

It then presents Sieve, an internal JD.com tool that accepts an Hprof file, generates a detailed analysis report, and visualises key metrics such as activity/fragment usage, bitmap sizes, object reference chains, and the top 30 classes by memory consumption.

Implementation details are divided into four main stages:

Heap‑dump parsing: The system reads class, stack‑frame, and heap information from the Hprof file, focusing on objects and their classification as GC Roots (Stack Local, Thread, JNI Local, JNI Global, etc.).

Dominator‑tree generation and Retained Size calculation: Using a top‑down approach, the tool builds a dominator tree where each node’s parent is its immediate dominator, then aggregates Shallow Size values up the tree to obtain each object’s Retained Size.

Reference‑path construction: Starting from suspected objects, a breadth‑first search discovers shortest paths to GC Roots, producing a tree of reference chains that can be visualised as leak traces.

Special handling for Bitmaps: Because Bitmaps may be promoted to GC Roots, the system records their associated mBuffer and adds its Shallow Size to the Bitmap’s retained size, ensuring accurate memory accounting.

The article also discusses practical challenges such as the overhead of Debug.dumpHprof() causing GC pauses, the large size of Hprof files leading to OOM in the analysis process, and the trade‑offs of sampling large object sets.

Finally, it notes that the approach is primarily targeted at Android versions below 8.0, where Bitmap pixel data resides in the Zygote Heap, and invites interested readers to explore the detailed implementation code (e.g., the public class TestA { int a; TestB b; } snippet and the public final class PathsFromGCRootsTree { private String description; private ArrayList inboundTrees; } class) for deeper understanding.

Mobile DevelopmentAndroidLeak DetectionMemory Profilingdominator-treeRetained SizeHprof
JD Retail Technology
Written by

JD Retail Technology

Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.