Утечки памяти: причины и поиск
Вопрос
Расскажи, что такое утечки памяти в Android, какие у них причины и как ты их находишь и исправляешь.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Объект не нужен, но достижим от GC root
Самое дорогое: утечка Activity с иерархией view
Причины: статика и синглтоны, листенеры, долгие задачи, внутренние классы, binding фрагмента
Поиск: LeakCanary в debug, Memory Profiler, OOM в отчётах
Лечение: applicationContext, симметричная отписка, lifecycle-aware scope
WeakReference не основной инструмент
Что могут спросить следом
- Как прочитать трассу LeakCanary?
- Почему лямбда может держать Activity?
- Утечка ли ViewModel, которая держит Application?
Разбор
Утечка это объект, который больше не нужен, но остаётся достижимым по сильным ссылкам от корня сборщика мусора. В Android самое дорогое утекать Activity или фрагменту: вместе с ними держится вся иерархия view, картинки и ресурсы. Типичные причины я разделяю на группы. Статические поля и синглтоны, в которые положили Activity или её контекст. Листенеры и ресиверы, от которых не отписались. Долгоживущие асинхронные задачи: потоки, postDelayed, корутины в GlobalScope, колбэки, захватившие Activity. Внутренние и анонимные классы и лямбды, которые неявно держат внешний объект. Во фрагментах binding, не обнулённый в onDestroyView. Ищу LeakCanary в debug-сборке: он сам замечает, что уничтоженная Activity не собралась, снимает дамп и показывает цепочку до GC root, и исправлять нужно ссылку в этой цепочке. Лечение: applicationContext в долгоживущих объектах, подписка и отписка в симметричных колбэках, корутины в viewModelScope и lifecycleScope.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.