LeakCanary — was es ist, Bibliothek zur Suche nach Lecks in Android

Was ist LeakCanary?

LeakCanary ist eine Bibliothek zur automatischen Erkennung von Speicherlecks in Android-Anwendungen, entwickelt von Square. Sie integriert sich in den Build-Prozess der App und überwacht automatisch, ob Objekte, die zerstört werden sollten (Activity, Fragment, View), im Speicher verbleiben. Bei Erkennung eines Lecks erstellt LeakCanary einen Heap-Dump und analysiert die Referenzkette, die das Objekt hält.

Die Bibliothek hat sich zum Standard in der Android-Community entwickelt: Laut GitHub hat das Projekt über 28.000 Sterne und wird in Apps von Google, Uber, Airbnb und Facebook verwendet. LeakCanary ist in zwei Hauptversionen verfügbar: der klassischen 1.x (mit manueller Konfiguration) und der modernen 2.x (automatische Integration über ContentProvider). Version 2.x erfordert keine Änderung der Application-Klasse — die Abhängigkeit allein reicht für die volle Funktionalität aus.

Die Hauptaufgabe von LeakCanary ist es zu erkennen, wenn ein Objekt nach dem Ende seines Lebenszyklus weiterhin im Speicher existiert. Dies ist typisch für Lecks über statische Felder, Singletons, nicht abgemeldete Callbacks, anonyme Klassen und Closures, die externe Objekte erfassen.

Warum LeakCanary für die Android-Entwicklung wichtig ist

Speicherlecks unter Android sind aufgrund des begrenzten Arbeitsspeichers mobiler Geräte kritischer als auf dem Desktop. Selbst ein Leck von 5–10 MB bei jedem Bildschirmwechsel kann nach 30–40 Minuten App-Nutzung zu einem OutOfMemoryError führen. LeakCanary erkennt solche Probleme bereits in der Entwicklungsphase, ohne auf einen Absturz in der Produktion zu warten.

Wie funktioniert LeakCanary?

LeakCanary verwendet schwache Referenzen (WeakReference) in Kombination mit erzwungener Garbage Collection. Wenn eine Activity oder Fragment onDestroy aufruft, erstellt LeakCanary eine WeakReference auf dieses Objekt und löst nach einer kurzen Verzögerung (standardmäßig 5 Sekunden) den GC aus. Wenn das Objekt nach dem GC immer noch über die WeakReference zugreifbar ist, wird es von einer starken Referenz gehalten — ein Leck wird aufgezeichnet.

Nach der Erkennung eines Lecks erstellt LeakCanary einen Heap-Dump (Speicherabbild) — eine vollständige Momentaufnahme des App-Speichers im HPROF-Format. Der integrierte Analysator (Shark für Version 2.x) erstellt dann einen Erreichbarkeitsgraphen von den GC Roots bis zum ausgelaufenen Objekt und findet den kürzesten Pfad — die Referenzkette, die das Objekt im Speicher hält.

// Vereinfachte LeakCanary-Erkennungslogik
class ObjectWatcher {
    private val watchedReferences = CopyOnWriteArrayList<KeyedWeakReference>()

    fun watch(watchedObject: Any, description: String) {
        val reference = KeyedWeakReference(watchedObject, description)
        watchedReferences.add(reference)
        BackgroundHandler.postDelayed({
            checkForLeaks()
        }, 5000)
    }

    private fun checkForLeaks() {
        GcTrigger.runGc() // erzwungener GC
        for (ref in watchedReferences) {
            if (ref.get() != null) {
                onLeakFound(ref) // Objekt hat GC überlebt — es ist ein Leck
            }
        }
    }
}

Der entscheidende Punkt ist der erzwungene Aufruf von GcTrigger.runGc(). Ohne ihn ist es unmöglich, ein tatsächlich ausgelaufenes Objekt von einem zu unterscheiden, das der GC noch nicht eingesammelt hat. LeakCanary führt dies bis zu dreimal durch: Wenn das Objekt nach drei GC-Zyklen immer noch im Speicher ist, wird das Leck bestätigt.

Was ist Shark — der Heap-Dump-Analysator

Shark ist der in LeakCanary 2.x eingebaute Heap-Dump-Analysator, geschrieben in Kotlin. Im Gegensatz zum früheren HAHA-Analysator lädt Shark nicht die gesamte HPROF-Datei in den Speicher, sondern durchläuft ihren Objektgraphen mit minimalen Allokationen. Dies reduziert den RAM-Verbrauch während der Analyse von 50 MB auf 2–5 MB und verkürzt die Analysezeit von 30 Sekunden auf 1–3 Sekunden.

Wie installiere und konfiguriere ich LeakCanary?

Die Installation von LeakCanary 2.x in einem modernen Android-Projekt erfordert eine einzige Zeile in build.gradle. Die Bibliothek verwendet ContentProvider zur automatischen Initialisierung — es ist nicht nötig, die Application-Klasse zu ändern oder Code in MainActivity einzufügen. Die Abhängigkeit wird nur für Debug-Builds hinzugefügt, damit Release-APKs keinen zusätzlichen Code enthalten.

// build.gradle (app/module)
dependencies {
    // debugImplementation — Bibliothek nur für Debug-Builds
    debugImplementation "com.squareup.leakcanary:leakcanary-android:2.14"
}

Nach dem Hinzufügen der Abhängigkeit und dem Neubau des Projekts erscheint LeakCanary automatisch in der App. Beim ersten Start zeigt die Bibliothek eine Systembenachrichtigung zur Bestätigung der Aktivierung. Alle erkannten Lecks erscheinen als Benachrichtigungen — ein Tippen auf die Benachrichtigung öffnet einen Bildschirm mit einem detaillierten Bericht (LeakTrace).

Zur Anpassung kannst du einen eigenen AppWatcherInstaller erstellen und Parameter überschreiben: GC-Timeout, Liste der überwachten Objekttypen, Aktivierung des Heap-Dump-Speicherns auf Disk. Für 90% der Projekte ist die Standardkonfiguration jedoch optimal.

Konfiguration für Coroutinen und Jetpack Compose

Ab Version 2.12 unterstützt LeakCanary die automatische Überwachung von ViewModel, Coroutinen-Scopes und Compose-State-Objekten. Es sind keine zusätzlichen Abhängigkeiten erforderlich — die Bibliothek erkennt automatisch, welche Jetpack-Komponenten im Projekt verwendet werden, und aktiviert die entsprechenden Detektoren.

Wie lese ich einen LeakCanary-Bericht

Ein LeakCanary-Bericht (LeakTrace) ist eine mehrzeilige Referenzkette von der GC Root zum ausgelaufenen Objekt. Jede Zeile zeigt die Klasse und das Feld, durch das eine starke Referenz verläuft. Entwickler sollten die Kette von unten nach oben lesen: Die unterste Zeile ist das ausgelaufene Objekt, die oberste Zeile der Einstiegspunkt (GC Root).

Ein typischer LeakTrace sieht so aus: GC Root → statisches Application-Feld → Singleton → Callback → Activity. Wenn ein Entwickler eine solche Kette sieht, ist das Problem klar: Das Singleton hält einen Callback, der eine Referenz auf die Activity erfasst hat. Die Lösung besteht darin, die starke Referenz im Singleton durch eine schwache zu ersetzen.

┬
├─ android.app.Application
│    Leaking: NO (Application — singleton)
│    ↓ Application.leakedActivities
├─ java.util.ArrayList
│    Leaking: NO (ArrayList — normal)
│    ↓ ArrayList[0]
├─ com.example.MainActivity
│    Leaking: YES (Activity destroyed but still in memory)
│    ↓ MainActivity.mCallback
├─ com.example.CallbackWrapper
│    Leaking: UNKNOWN
│    ↓ CallbackWrapper.mListener
│              ~~~~~~~~~~
├─ com.example.MyCallback (anonymous)
│    Leaking: UNKNOWN
│    ↓ MyCallback.this$0
├─ com.example.MainActivity
│    Leaking: YES (MainActivity is the leak)
╰

In diesem Beispiel zeigt LeakCanary, dass MainActivity über die Kette gehalten wird: Application → ArrayList → MainActivity → CallbackWrapper → MyCallback → erneut MainActivity. Der this$0-Pfeil zeigt an, dass die anonyme Klasse MyCallback eine externe Referenz auf die Activity erfasst hat. Die Lösung besteht darin, den Callback zu einer schwachen Referenz zu machen oder ihn in onDestroy abzubrechen.

LeakCanary zeigt auch den Leck-Status für jedes Element der Kette an: NO (kein Leck — Wurzelelement), YES (Objekt sollte zerstört werden), UNKNOWN (Status konnte nicht bestimmt werden). Der Status UNKNOWN bedeutet kein Problem — es ist ein Zwischenobjekt, das LeakCanary nicht eindeutig klassifizieren kann.

LeakCanary 2.x vs. 1.x: Hauptunterschiede

Der Übergang von Version 1.x zu 2.x war grundlegend: Die Entwickler schrieben die Bibliothek von Grund auf neu und ersetzten den veralteten HAHA-Analysator durch die eigene Engine Shark, die in Kotlin geschrieben ist. Shark ist um Größenordnungen schneller, benötigt weniger Speicher für die Analyse und ermittelt die Grundursachen von Lecks genauer.

Der Hauptvorteil von Shark besteht darin, dass es nicht den gesamten Heap-Dump in den Speicher lädt, sondern seinen Referenzgraphen mit minimalen Allokationen durchläuft. Dies macht LeakCanary 2.x für den Einsatz auf Geräten mit wenig RAM geeignet, ohne das Risiko eines OutOfMemoryError während der Analyse.

Version 2.x führte auch die Möglichkeit ein, Heap-Dumps in eine Datei zu exportieren für die spätere Analyse im Android Studio Memory Profiler. Aktiviere dazu die Einstellung dumpHeapWhenLeakFound in der AppWatcher-Konfiguration.

Typische Lecks, die LeakCanary findet

LeakCanary erkennt effektiv mehrere Klassen von Lecks, die für Android typisch sind. Am häufigsten sind Lecks über statische Referenzen auf eine Activity — Entwickler behalten eine Referenz auf den Activity-Kontext in einem Singleton, und die Activity kann nach Ende ihres Lebenszyklus nicht vom GC eingesammelt werden.

Die zweithäufigste Kategorie sind Lecks über nicht abgemeldete Listener. Wenn registerListener in onStart aufgerufen, aber unregisterListener in onStop/onDestroy nicht aufgerufen wurde, wird das Listener-Objekt vom System gehalten, selbst nachdem die Aktivität zerstört wurde. LeakCanary zeigt eindeutig, welcher Listener und in welchem Systemdienst noch lebt.

// Typisches Leck: Activity in einem Singleton-Callback erfasst
object AnalyticsManager {
    private var callback: ((String) -> Unit)? = null

    fun register(callback: (String) -> Unit) {
        this.callback = callback // starke Referenz auf Callback
    }

    fun unregister() {
        callback = null // NICHT VERGESSEN, in onDestroy aufzurufen!
    }
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        AnalyticsManager.register { event ->
            logEvent(event) // Lambda erfasst this
        }
        // wenn unregister nicht in onDestroy aufgerufen wird → Activity-Leck
    }
}

Die dritte Kategorie sind Lecks über Fragment im BackStack. Wenn FragmentTransaction.addToBackStack() aufgerufen wird, ohne das Fragment beim Zurückgehen zu entfernen, bleiben alte Fragment-Instanzen im Speicher. LeakCanary hilft, solche versteckten Lecks früh in der Entwicklung zu erkennen.

Für jedes erkannte Leck liefert LeakCanary eine Beschreibung und Empfehlungen zur Behebung. Version 2.14 fügte die Integration mit Android Lint hinzu — die Bibliothek kann automatisch Aufgaben im Issue-Tracker erstellen, wenn ein Leck im CI erkannt wird.