Analyzing and Resolving an Android WebView Memory Leak That Causes Slow Page Loads

In Baidu's Quality Assurance team, QA engineers routinely discover, locate, and drive the proper fixing of bugs. This case study collects several bug‑discovery and analysis examples for discussion.

Problem Phenomenon Repeatedly clicking the toolbar of the tested Android app and then returning to click again eventually makes the page open slowly, sometimes taking up to 5 seconds. The issue affects all WebView‑based screens in the app.

Preliminary Analysis Slow loading can be caused either by inefficient layout/logic on each load or by memory‑leak‑related slowdown after repeated openings. The observed behavior matches the latter, so the analysis starts from a memory perspective.

Using Android’s DDMS tool to monitor heap memory, the heap size continuously rises with each repeated screen opening, and manual “Gause GC” invocations do not reduce the heap, indicating that many objects remain referenced and are not reclaimed.

Since GC cannot free these objects, a memory leak is suspected. The next step uses the Eclipse Memory Analyzer (MAT) to dump hprof files after the 5th, 10th, and 20th openings. All three dumps highlight DynamicBgDrawable as a leaking class.

Further inspection of the reference chain in MAT shows that GraphicContent.mContents (a WeakHashMap ) holds a reference to mBackground (the DynamicBgDrawable ) via an indirect link, creating a circular reference that prevents both objects from being collected.

Code & Business Analysis The GraphicContent class retains a strong reference to a View . Because the View instance is the DynamicBgDrawable itself, a strong‑to‑strong circular reference is formed, leading to the leak as the view is never released.

Understanding the Root Cause Android apps run on the Dalvik VM, a variant of the Java VM, and share its memory‑management mechanisms. Only heap memory holds objects; therefore, the leak is purely a heap issue. Repeated screen openings allocate new objects, and because the leaked objects are never reclaimed, heap fragmentation grows, GC time lengthens, and eventually the app experiences out‑of‑memory (OOM) failures.

The Dalvik GC process first marks reachable objects; objects still referenced (e.g., those in the circular GraphicContent ↔ DynamicBgDrawable chain) remain marked and are not cleared. As more objects survive each GC, memory fragmentation increases, making subsequent allocations slower and sometimes impossible.

Solution Replace the strong reference mView with a weak reference. When GC runs, the view can be reclaimed, allowing the WeakHashMap entry ( GraphicContent ) to be released as well.

Summary The analysis and fix illustrate a typical Android memory‑leak debugging workflow: use DDMS to observe heap growth, employ MAT to locate leaking objects, trace reference chains to identify circular strong references, and resolve the issue by converting the offending reference to a weak one. This pattern is widely applicable to many Android projects and should be part of regular code‑review checklists.