Как LeakCanary определяет ссылки на уничтоженные Activity?

LeakCanary использует слабое (Phantom Reference) или сильное (Strong Reference) ссылочное поле в специальном Observer, который "слушает" жизненный цикл Activity. Когда Activity уничтожается, LeakCanary фиксирует время и ждет сборки мусора. Если после сборки мусора объект Activity все еще существует в памяти, LeakCanary инициирует дамп кучи (heap dump), анализирует его и строит граф достижимости, чтобы найти путь от GC Roots к этому "утекшему" Activity.

Ключевые шаги:

1. Наблюдение за жизненным циклом: LeakCanary регистрирует ActivityLifecycleCallbacks.
2. Закладка (Bookmarking): При вызове onDestroy(), LeakCanary создает ссылку на Activity (зависит от версии) и записывает отметку времени.
3. Ожидание GC: LeakCanary ждет наступления сборки мусора, чтобы проверить, был ли объект уничтожен.
4. Проверка после GC: Если объект Activity все еще доступен после сборки мусора, это указывает на потенциальную утечку.
5. Дамп кучи: LeakCanary вызывает Debug.dumpHprofData() для сохранения текущего состояния памяти.
6. Анализ дампа: LeakCanary (через Memory Analyzer Tool (MAT) или свой анализатор) сканирует дамп кучи.
7. Поиск пути: Инструмент находит пути в графе объектов от корневых элементов сборщика мусора (GC Roots) до "утекшего" объекта Activity.
8. Отчет: LeakCanary генерирует читаемый отчет, показывающий цепочку ссылок, которая удерживает объект от сборки мусора.