Wie erkennt LeakCanary Verweise auf zerstörte Activities?

LeakCanary verwendet eine schwache (Phantom Reference) oder eine starke (Strong Reference) Referenz in einem speziellen Beobachter, der den Lebenszyklus der Activity "überwacht". Wenn die Activity zerstört wird, zeichnet LeakCanary die Zeit auf und wartet auf die Garbage Collection. Wenn nach der Garbage Collection das Activity-Objekt noch im Speicher vorhanden ist, initiiert LeakCanary einen Heap-Dump, analysiert ihn und erstellt einen Erreichbarkeitsgraphen, um den Pfad von den GC-Wurzeln zu dieser "leckenden" Activity zu finden.

Wichtige Schritte:

1. Überwachung des Lebenszyklus: LeakCanary registriert ActivityLifecycleCallbacks.
2. Lesezeichen setzen (Bookmarking): Beim Aufruf von onDestroy() erstellt LeakCanary eine Referenz auf die Activity (abhängig von der Version) und zeichnet die Zeit auf.
3. Warten auf GC: LeakCanary wartet, bis die Garbage Collection erfolgt ist, um zu prüfen, ob das Objekt zerstört wurde.
4. Nach-GC-Überprüfung: Wenn das Activity-Objekt nach der GC noch zugänglich ist, deutet dies auf ein potenzielles Leck hin.
5. Heap-Dump: LeakCanary ruft Debug.dumpHprofData() auf, um den aktuellen Speicherzustand zu speichern.
6. Analyse des Dumps: LeakCanary (über das Memory Analyzer Tool (MAT) oder einen eigenen Analyzer) scannt den Heap-Dump.
7. Pfadsuche: Das Tool findet Pfade im Objektdiagramm von den GC-Wurzeln bis zum "leckenden" Objekt.
8. Bericht: LeakCanary generiert einen lesbaren Bericht, der die Kette der Referenzen zeigt, die das Objekt vom Garbage Collector fernhalten.