Поиск и устранение утечек памяти в мобильном приложении

Приложение вылетает на iOS после 20 переключений экрана карты — в heap 240 MB только от MapViewController. Crash log содержит Terminated due to memory pressure. Instruments → Allocations показывает прирост ~12 MB на каждое открытие, и эти 12 MB никогда не освобождаются. Это не предположение, а точная утечка памяти.

Каждое такое «зависание» снижает LTV пользователя: по данным App Annie, утечки памяти увеличивают uninstall rate на 15-20% за первую неделю. Исправление утечек не только спасает приложение от крашей, но и экономит бюджет: стоимость фикса одной утечки на порядок ниже потерь от оттока пользователей. Наши инженеры с опытом более 7 лет выполнили свыше 30 проектов по оптимизации памяти. Мы поможем найти и устранить утечки с гарантией результата.

Почему утечки памяти критичны для производительности?

Утечки памяти приводят к постепенному росту потребления RAM, вызывая троттлинг CPU, частые GC паузы на Android и увеличение времени отклика. В конечном итоге — crash или зависание. На iOS при 80% загрузки RAM система начинает закрывать фоновые процессы, а при 90% — убивает приложение. На Android — OutOfMemoryError. Пользователи удаляют такие приложения в течение нескольких дней. По статистике, 68% пользователей сталкивались с проблемами памяти и 25% сразу деинсталлируют приложение после двух крашей.

Какие типы утечек памяти встречаются на iOS и Android?

Retain cycles на iOS

ARC считает сильные ссылки. Если A держит B, а B держит A — ни один не достигнет нулевого счётчика и никогда не освободится. Самые частые паттерны:

Closure без [weak self]:

// УТЕЧКА
viewModel.onDataLoaded = {
    self.tableView.reloadData()
}
// ПРАВИЛЬНО
viewModel.onDataLoaded = { [weak self] in
    self?.tableView.reloadData()
}

Timer:

// УТЕЧКА — Timer удерживает target сильно
timer = Timer.scheduledTimer(timeInterval: 1.0, target: self,
                              selector: #selector(tick), userInfo: nil, repeats: true)

При закрытии ViewController timer продолжает работать и удерживает ViewController. Решение — Timer.scheduledTimer(withTimeInterval:repeats:block:) с [weak self] и timer.invalidate() в deinit.

Delegate без weak:

// УТЕЧКА
protocol DataDelegate: AnyObject { func didLoad() }
class DataService {
    var delegate: DataDelegate? // должен быть weak!
}

Используйте weak var delegate: DataDelegate?.

Утечки на Android

Context leak — самая распространённая: Activity Context хранится в singleton. Activity не освобождается, пока Repository жив. Используйте только applicationContext.

Anonymous inner class + Handler:

private val handler = Handler(Looper.getMainLooper())
handler.postDelayed({
    updateUI()
}, 5000)

Решение: WeakReference<MyActivity> или lifecycleScope.launch { delay(5000); updateUI() }.

LiveData observers без removeObserver: Подписка liveData.observe(this, ...) с this как Fragment, а не viewLifecycleOwner, приводит к накоплению наблюдателей при каждом пересоздании View. Всегда используйте viewLifecycleOwner.

Какие инструменты помогают обнаружить утечки?

Instruments Leaks обнаруживает retain cycles в 5 раз быстрее, чем ручная проверка кода. LeakCanary находит утечки в 3 раза быстрее, чем ручной анализ heap-дампов.

Подробнее: LeakCanary и Instruments.

Из нашей практики: кейс с RxJava Disposable

Недавно к нам обратился клиент — Flutter-разработчик, перешедший на Android. Его приложение содержало утечку через Observable.interval. Подписка создавалась в onCreate, Disposable нигде не сохранялся. При каждой ротации экрана создавался новый Observer, старый продолжал работать. Через 10 ротаций — 10 активных потоков. LeakCanary нашёл это за 2 минуты: retained Activity через Observable → Observer → Activity reference. Решение: CompositeDisposable, добавляем все подписки, вызываем disposables.clear() в onStop() или onDestroy().

Как мы устраняем утечки: процесс и сроки

1. Аудит кодовой базы (1-2 дня)
2. Настройка LeakCanary / Instruments (0.5 дня)
3. Проведение тестовых сценариев (0.5 дня)
4. Анализ heap dump (1 день)
5. Исправление утечек (2-5 дней в зависимости от сложности)
6. Добавление логирования в deinit/onDestroy (0.5 дня)
7. Регрессионное тестирование (1 день)

Сроки: диагностика — 1–3 дня, исправление — 2–7 дней.

Что входит в услугу

Мы предоставляем полный отчёт с диаграммами heap dump, инструкции по внедрению защитных паттернов, а также рекомендации по архитектуре для предотвращения утечек в будущем. При необходимости подключаем CI-проверки (LeakCanary в debug, строгая проверка retain cycles). В результате вы получаете стабильное приложение с гарантированным снижением расхода RAM на 30-50%.

Типичные ошибки при самостоятельном поиске утечек

1. Использование Instruments Leaks только для одного сценария — утечки могут проявляться только при определённой последовательности действий.
2. Игнорирование утечек в сторонних библиотеках — часто проблема не в вашем коде, а в зависимостях.
3. Забывают проверять deinit/onDestroy подклассов ViewController/Activity — ошибка всплывает через месяц.

Утечки памяти — это не фатально, но требует системного подхода. Мы предлагаем полный цикл: от диагностики до внедрения защитных мер. Свяжитесь с нами, чтобы получить консультацию по вашему проекту. Закажите аудит памяти уже сегодня.

Оптимизация мобильных приложений: cold start, память, батарея, FPS, профилирование

Приложение с временем холодного старта 4+ секунды теряет пользователей ещё до первого экрана. Android Vitals в Google Play Console прямо влияют на ранжирование в поиске: приложения с плохими метриками получают меньший organic reach. Apple аналогично мониторит crash rate и время запуска через MetricKit. Оптимизация — это не «сделать быстрее», а понять где именно теряется время и что с этим делать.

Cold Start: где убивается время до первого кадра

Cold start — запуск приложения, когда процесс не существует в памяти. На Android это время от нажатия на иконку до Activity.onWindowFocusChanged(hasFocus = true). На iOS — от tap до viewDidAppear первого экрана.

Android: main thread перегружен при инициализации

Application.onCreate() — главный враг быстрого старта на Android. Разработчики инициализируют здесь всё подряд: Firebase, Analytics, базу данных, HTTP-клиент, DI-контейнер. Каждый SDK добавляет 20–200 мс на main thread.

Инструмент для диагностики: Android Studio Profiler → App Startup. Показывает граф инициализации с временем каждого компонента. Альтернатива — Tracing.beginSection("MyInitTag") в коде + systrace.

Решение: App Startup Library (Jetpack) с явным графом зависимостей инициализаторов. Компоненты, нужные только в конкретных сценариях, инициализируются лениво — by lazy {} или initializer с флагом lazyInit. Firebase Analytics, например, не нужен до первого пользовательского действия — его инициализацию можно отложить.

ContentProvider-ы, автоматически добавляемые SDK через AndroidManifest merge, тоже запускаются при старте. tools:node="remove" в манифесте позволяет отключить конкретный провайдер и инициализировать SDK вручную в нужный момент.

Ещё одна грабля: Room.databaseBuilder().build() на main thread. Это синхронная операция создания/открытия файла БД — на медленных устройствах занимает 50–300 мс. Переносим в coroutine с Dispatchers.IO, в ViewModel через viewModelScope.launch.

iOS: Dyld linking и +load

На iOS cold start делится на pre-main (до вызова main()) и post-main. Pre-main — время загрузки dylib, rebase/binding, Objective-C runtime initialization и выполнения +load методов.

Xcode Instruments → App Launch template показывает время pre-main и post-main раздельно. DYLD_PRINT_STATISTICS=1 в схеме запуска выводит детальное время загрузки в консоль.

Что убивает pre-main:

• Много динамических библиотек (каждая dylib — накладные расходы на линковку). CocoaPods добавляет отдельную dylib на каждый pod. Решение: Swift Package Manager со статической линковкой (type: .static) или use_frameworks! :linkage => :static в CocoaPods.
• +load методы в Objective-C — выполняются синхронно при загрузке класса, до main(). Сторонние SDK могут злоупотреблять этим. +initialize — ленивый аналог, вызывается при первом обращении к классу.

Post-main — application(_:didFinishLaunchingWithOptions:). Та же история что на Android: синхронная инициализация всего. lazy var для сервисов, которые не нужны немедленно. SwiftUI @StateObject инициализирует объект только когда View появляется — это уже встроенная ленивость.

Целевые метрики (App Store рекомендации): cold start < 400 мс для простых приложений, < 2 секунды для сложных. Warm start (процесс в памяти, но Activity/Scene пересоздаётся) — < 1 секунда.

Память: утечки, OOM, excessive pressure

Утечка памяти в iOS — retention cycle: объект A держит ссылку на B, B держит на A, ни один не освобождается. Классика: Timer с self в замыкании без [weak self]. Timer удерживает замыкание, замыкание удерживает self (ViewController), ViewController не освобождается при закрытии. Instruments → Leaks или Memory Graph Debugger в Xcode — находит живые объекты, которых не должно быть.

На Android garbage collector управляет памятью, но утечки всё равно случаются. Activity или Fragment, удерживаемые через статическую ссылку, singleton, или Handler/Runnable после onDestroy — классика. LeakCanary — обязательный инструмент в debug-сборке. Добавляется одной зависимостью debugImplementation "com.squareup.leakcanary:leakcanary-android" и автоматически детектирует утечки с полным стектрейсом.

OutOfMemoryError чаще всего происходит из-за загрузки изображений. Bitmap в памяти занимает ширина × высота × 4 байта. Изображение 4000×3000 px — 48 МБ в памяти, независимо от размера файла на диске. Glide / Coil правильно обрабатывают это: загружают с даунсемплингом под размер View, кешируют в LRU-кеш. Загружать в ImageView без Glide/Coil через BitmapFactory.decodeFile — путь к OOM на устройствах с 2 ГБ RAM.

На Flutter Dart VM имеет свой GC, но нативные ресурсы (изображения, текстуры) не управляются Dart GC. Image.network кеширует изображения в памяти без автоматического освобождения при выходе из дерева виджетов — при длинных списках с картинками используем cached_network_image с правильным memCacheWidth/memCacheHeight.

FPS и UI Performance

60 FPS — 16.67 мс на кадр. 120 FPS (ProMotion) — 8.33 мс. Всё что занимает больше на main thread — джанк.

Типичные причины просадок FPS:

На iOS: синхронная декодировка изображений в cellForRowAt. Когда ячейка таблицы появляется, UIImage(contentsOfFile:) декодирует JPEG/PNG на main thread — видно как заторможенный скролл на длинных списках. Решение: UIImage.preparingForDisplay() (iOS 15+) или ImageIO с kCGImageSourceCreateThumbnailWithTransform в background queue, результат через DispatchQueue.main.async.

На Android: RecyclerView.Adapter.onBindViewHolder с синхронными операциями. Базы данных, файловая система, синхронные сетевые запросы на main thread — StrictMode.ThreadPolicy с detectAll().penaltyLog() в debug-сборке покажет все нарушения.

На Flutter: build() метод вызывается часто, он должен быть дешёвым. setState() на верхнем виджете пересобирует всё дерево. const конструкторы, RepaintBoundary, разбиение на мелкие виджеты с локальным стейтом — основные инструменты. Flutter DevTools → Performance показывает janky frames (красные) с причинами.

Профилирование Compose: Recomposition Highlighter и трассировка через Trace.beginSection в @Composable. remember для дорогих вычислений, derivedStateOf для computed values, LazyColumn вместо Column + forEach для длинных списков.

Батарея: Wake locks, WorkManager, сетевые запросы

Приложение в топе по расходу батареи — пользователь видит это в настройках и удаляет. Android Battery Historian (из ADB bug report) показывает детальный timeline: wake locks, wakeups, network activity, sensor usage.

Основные потребители энергии:

• Постоянный GPS (разбираем в maps-geo)
• Polling сети каждые N секунд вместо push
• Holding wake lock дольше необходимого
• Excessive AlarmManager wakeups

WorkManager с Constraints — правильный способ планировать фоновые задачи: setRequiredNetworkType, setRequiresBatteryNotLow, setRequiresCharging. ОС батчирует задачи и выполняет в удобное время.

На iOS BGTaskScheduler с BGProcessingTaskRequest (для тяжёлых задач при зарядке) и BGAppRefreshTaskRequest (для лёгких обновлений) — система решает когда выполнять, разработчик только регистрирует и реализует логику.

Батчинг сетевых запросов: вместо 10 отдельных запросов в течение минуты — один батч запрос. Меньше радио-активностей (LTE radio потребляет много при инициализации соединения), меньше wakeups.

Инструменты профилирования

MetricKit на iOS — особенно ценен: реальные данные с устройств пользователей, а не симулятора. MXMetricManager получает агрегированные метрики раз в сутки: MXAppLaunchMetric, MXHangDiagnostic, MXCPUExceptionDiagnostic. Диагностики по hang и CPU-exceptions содержат стектрейс с реального устройства — золото для диагностики production-проблем.

Процесс оптимизации

Начинаем с измерения, не с предположений. Инструменты выше дают цифры: конкретное время cold start, конкретный объём памяти, конкретные кадры с просадкой. Потом — приоритизация по impact: что больше всего влияет на пользовательский опыт именно в этом приложении.

Аудит производительности существующего приложения: 3–5 рабочих дней. Реализация оптимизаций — от недели до двух месяцев в зависимости от запущенности проблем и архитектуры кода.