Jak LeakCanary wykrywa odniesienia do zniszczonych Activity?

LeakCanary używa słabego (Referencja Fantomowa) lub silnego (Referencja Silna) pola referencyjnego w specjalnym obserwatorze, który "słucha" cyklu życia Activity. Gdy Activity jest niszczona, LeakCanary rejestruje czas i czeka na garbage collection. Jeśli po garbage collection obiekt Activity nadal istnieje w pamięci, LeakCanary inicjuje zrzut stosu (heap dump), analizuje go i tworzy graf dostępności, aby znaleźć ścieżkę od GC Roots do tego "wyciekającego" Activity.

Kluczowe kroki:

1. Monitorowanie cyklu życia: LeakCanary rejestruje ActivityLifecycleCallbacks.
2. Zakładanie (Bookmarking): Podczas wywołania onDestroy(), LeakCanary tworzy odniesienie do Activity (w zależności od wersji) i zapisuje czas.
3. Oczekiwanie na GC: LeakCanary czeka na wykonanie garbage collection, aby sprawdzić, czy obiekt został zniszczony.
4. Sprawdzenie po GC: Jeśli obiekt Activity nadal jest dostępny po GC, wskazuje to na potencjalny wyciek.
5. Zrzut pamięci: LeakCanary wywołuje Debug.dumpHprofData() w celu zapisania aktualnego stanu pamięci.
6. Analiza zrzutu: LeakCanary (przez Memory Analyzer Tool (MAT) lub własny analizator) skanuje zrzut pamięci.
7. Wyszukiwanie ścieżki: Narzędzie znajduje ścieżki w grafie obiektów od GC Roots do "wyciekającego" obiektu.
8. Raport: LeakCanary generuje czytelny raport, pokazujący łańcuch referencji, który utrzymuje obiekt z dala od garbage collection.