Analyzing and Resolving an Android WebView Memory Leak Causing Slow Page Loads

Repeatedly clicking the toolbar of an Android app that uses a WebView and then returning to it eventually makes the page open much slower—sometimes up to five seconds—affecting user experience across all WebView pages.

Two typical reasons for slow loading are considered: (1) consistently slow due to layout or business‑logic inefficiencies, and (2) occasional slowdown after several openings, which is usually related to memory leaks. This case falls into the latter, so the analysis starts from a memory perspective.

Using Android’s DDMS tool, the heap memory of the app process was monitored. The heap size kept rising with each repeated opening, and even manual garbage collection (GC) via DDMS did not reduce the heap, indicating that a substantial portion of objects remained referenced and could not be reclaimed, i.e., a memory leak.

Heap dumps (hprof files) were taken at the 5th, 10th, and 20th openings and analyzed with the MAT tool. All three analyses highlighted objects of the DynamicBgDrawable class as having a high leak risk.

Further inspection of the reference chain in MAT showed that the GraphicContent class’s mContents field (a WeakHashMap ) holds a reference to the mBackground object (an instance of DynamicBgDrawable ). Because the map’s key (a View ) is never released, the value ( GraphicContent ) also stays alive, forming a cyclic reference that prevents the DynamicBgDrawable objects from being garbage‑collected.

The Android app runs on the Dalvik virtual machine, a variant of the Java Virtual Machine (JVM). Understanding JVM memory management—especially heap allocation, garbage collection, and reference graphs—is essential for diagnosing such bugs.

Only objects allocated on the heap can leak; stack‑allocated primitives are irrelevant to this problem. Dalvik’s GC follows a mark‑and‑sweep algorithm: it first marks objects reachable from root references, then clears those with a mark count of zero. Objects retained by the GraphicContent chain remain marked and are never reclaimed.

Each time the problematic screen is opened, new objects are allocated, increasing heap usage and fragmentation. As fragmentation grows, allocating large objects takes longer, and the GC pause time lengthens, leading to the observed slowdown. When the retained objects occupy a large portion of the heap, the system may eventually run out of memory (OOM).

To fix the leak, the mView reference was changed to a weak reference. During each GC cycle, the weakly‑referenced View can be reclaimed, which also allows the associated GraphicContent object in the WeakHashMap to be released.

This bug analysis and solution are representative of many Android memory‑leak issues. The approach—using DDMS for heap monitoring, MAT for heap‑dump analysis, and converting strong references to weak references—forms a generic and effective strategy for locating and fixing memory leaks, and it can be highlighted during code reviews.