Hoe detecteert LeakCanary verwijzingen naar vernietigde Activities?

LeakCanary gebruikt een zwakke (Phantom Reference) of sterke (Strong Reference) referentie in een speciale observer die "luistert" naar de levenscyclus van de Activity. Wanneer de Activity wordt vernietigd, registreert LeakCanary de tijd en wacht op garbage collection. Als na de garbage collection het Activity-object nog steeds in het geheugen bestaat, start LeakCanary een heap dump, analyseert deze en bouwt een bereikbaarheidsgrafiek om de route van GC Roots naar deze "lekke" Activity te vinden.

Belangrijke stappen:

1. Monitoring van de levenscyclus: LeakCanary registreert ActivityLifecycleCallbacks.
2. Bookmarking: Bij het aanroepen van onDestroy() maakt LeakCanary een referentie naar de Activity (afhankelijk van de versie) en registreert de tijd.
3. Wachten op GC: LeakCanary wacht tot de garbage collection plaatsvindt om te controleren of het object is vernietigd.
4. Post-GC controle: Als het Activity-object nog steeds toegankelijk is na de GC, duidt dit op een potentieel lek.
5. Heap dump: LeakCanary roept Debug.dumpHprofData() aan om de huidige geheugenstatus op te slaan.
6. Analyse van de dump: LeakCanary (via Memory Analyzer Tool (MAT) of zijn eigen analyzer) scant de heap dump.
7. Zoektocht naar pad: De tool vindt paden in de objectgrafiek van GC Roots naar het "lekke" object.
8. Rapport: LeakCanary genereert een leesbaar rapport dat de keten van referenties toont die het object buiten de garbage collector houdt.