Течёт память: что это, типичные сценарии и диагностика

Что такое утечка памяти в мобильных приложениях?

Утечка памяти — это ситуация, когда выделенная память не возвращается системе после того, как объект перестал быть нужен программе. Сборщик мусора считает такой объект живым, потому что на него ведёт активная цепочка ссылок от GC Root.

В Java/Kotlin сборщик мусора работает автоматически, но он не может определить, что объект логически не нужен, если на него есть техническая ссылка. Разработчик должен явно обрывать ненужные связи. В Swift/Objective-C ARC автоматически подсчитывает ссылки, но retain cycles блокируют обнуление счётчика.

Основная опасность утечек — кумулятивный эффект. Каждая утечка съедает небольшой объём памяти, но при многократных переходах между экранами (поворотах экрана, открытии/закрытии Activity) утечки накапливаются, пока не исчерпают лимит heap.

Чем утечка отличается от раздувания?

Утечка — объект недоступен коду, но не удалён GC. Раздувание — объект логически нужен, но хранится в избыточном количестве. Пример раздувания: кеш изображений на 100 MB при рабочем наборе в 30 MB. Обе проблемы ведут к OOM, но причины и методы лечения разные.

Как работает сборщик мусора и почему возникают утечки?

ART (Android Runtime) использует поколенческую сборку мусора с concurrent compaction. Память делится на молодое поколение (Young), старое (Old) и огромные объекты (Large). Объекты, пережившие несколько циклов GC, перемещаются в Old generation, где сборка происходит реже — это ускоряет обычные циклы.

GC начинается, когда heap достигает определённого порога занятости (обычно 75-85%). Во время GC все потоки приложения приостанавливаются (STW — Stop The World). Чем больше живых объектов, тем дольше пауза. Утечки увеличивают количество живых объектов, удлиняя GC паузы.

Сборщик определяет живые объекты, обходя граф от GC Roots: статические поля, стековые переменные активных потоков, JNI references. Любой объект, достижимый по ссылкам от этих корней, считается живым — даже если разработчик знает, что он больше не нужен.

// Example: static collection as GC Root — permanent leak
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference does not prevent GC — correct behavior
    }
}

WeakReference решает проблему: GC игнорирует weak ссылки при определении живых объектов. Если на объект остались только weak ссылки, он будет собран в ближайший цикл GC.

Типичные сценарии утечек в Android и iOS

Activity Context — самый массовый сценарий утечек в Android. Если синглтон, статическое поле или долгоживущий сервис хранит ссылку на Activity Context, то вся Activity со всеми View не может быть собрана GC. Решение: используйте Application Context для долгоживущих объектов.

Handler и посланные сообщения — Handler.postDelayed(runnable, delay) ставит сообщение в очередь Main Looper. Если Activity уничтожена до истечения delay, сообщение всё ещё в очереди и держит ссылку через Runnable → анонимный класс → внешний класс (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // mandatory: clear queue
        super.onPause()
    }
}

Inner Classes — нестатический внутренний класс имеет неявную ссылку на экземпляр внешнего класса. Если внешний класс — Activity, а внутренний класс передан куда-то вовне (например, в RecyclerView.Adapter), Activity не может быть собрана.

• TimerTask и ScheduledExecutorService — задачи, запланированные до уничтожения Activity
• BroadcastReceiver — незарегистрированный в onPause/onDestroy продолжает держать Context
• ViewModel с ссылкой на View — ViewModel переживает Activity, ссылка на View ведёт к утечке
• Retrofit Call — если Call не отменён, ответ приходит в уничтоженный Fragment

Инструменты диагностики утечек памяти

Android Studio Memory Profiler — встроенный инструмент для мониторинга heap в реальном времени. Показывает график занятой памяти, количество аллокаций и объектов по типам. Позволяет записать heap dump и экспортировать в HPROF-формат для анализа в MAT.

Eclipse MAT (Memory Analyzer Tool) — десктопный анализатор heap dump. Автоматически строит Leak Suspects Report, который подсвечивает объекты с наибольшим retained size и предлагает предполагаемую GC root chain для каждого подозрительного объекта.

Xcode Memory Graph Debugger — для iOS. Приостанавливает приложение и визуализирует граф объектов. Retain cycles подсвечиваются красным, можно кликнуть на любой объект и увидеть его retain count и ссылки.

По данным Uber Engineering Blog, внедрение автоматического профилирования памяти (LeakCanary + heap dump analysis) в CI/CD пайплайн сокращает количество memory-related инцидентов в production на 60% в течение 3 месяцев.

Методы устранения утечек

Замена Context — если объект живёт дольше Activity, используйте applicationContext. Все долгоживущие объекты (синглтоны, репозитории, database helpers) должны получать Application Context, а не Activity Context. Исключение: UI-компоненты, которым нужен доступ к теме или ресурсам, специфичным для Activity.

Lifecycle-aware компоненты — использование LifecycleObserver, DefaultLifecycleObserver или reactivelx автоматически отменяет подписки при onDestroy. Android Jetpack предоставляет lifecycleScope и viewModelScope, которые очищаются соответствующим событием.

Static inner class — если внутреннему классу не нужен доступ к полям внешнего, сделайте его static. Статический внутренний класс не имеет неявной ссылки на внешний. Если доступ нужен, используйте WeakReference для явной ссылки.

class MyActivity : AppCompatActivity() {

    // ❌ Non-static inner class — implicit reference to MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ Static inner class — no implicit reference
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

В iOS используйте capture lists: [weak self] в замыканиях, которые могут пережить создателя. Для делегатов используйте слабые ссылки (weak var delegate). Для замыканий, которые гарантированно вызываются только при жизни self, можно использовать [unowned self], но осторожно — при обращении к освобождённому объекту будет crash.