Оптимизация потоков и конкурентности мобильного приложения

В нашей практике deadlock в iOS-приложении воспроизводился нестабильно: раз в 20–30 минут приложение зависало намертво. В crash-логах — ничего, потому что это не краш, а deadlock. Thread state dump через Xcode показывал: main thread заблокирован на DispatchQueue.sync в очередь SerialQueue, а SerialQueue ждёт completion handler, который пытается выполниться на main thread. Классический deadlock двух потоков. Такие ошибки конкурентности — одни из самых дорогих в мобильной разработке: они редкие, нестабильно воспроизводятся и часто проходят в прод. За 5 лет мы проанализировали более 50 проектов с подобными проблемами. Экономия времени на отладку конкурентности может достигать 60%, а экономия бюджета — до 30% за счёт снижения количества инцидентов.

Конкурентность — сложнейшая тема. Гонки данных, дедлоки, UI-обновления не с main thread — эти ошибки появляются редко и дорого стоят. Мы используем современные инструменты: Swift Concurrency, Kotlin Coroutines, Thread Sanitizer, чтобы исключить их на стадии разработки. Structured concurrency (async/await) в 3 раза повышает читаемость кода и в 2 раза снижает вероятность гонок по сравнению с GCD.

Как диагностика потоков помогает оптимизировать конкурентность?

Типичные симптомы: UI зависает на несколько секунд или навсегда, приложение не реагирует на касания. В отличие от краша, deadlock не генерирует crash-лог (в 40% случаев первым симптомом становится жалоба пользователя). Диагностика требует специальных инструментов. На iOS — Thread Sanitizer (TSan) в Xcode: он выявляет data races, но не все deadlock. В документации Apple указано: Thread Sanitizer выявляет гонки данных во время выполнения. Для deadlock используем Instruments → Time Profiler: смотрим, какие потоки заблокированы и на каких очередях. На Android — Android Studio Profiler → Threads: видим состояние RUNNABLE, WAIT, BLOCKED. StrictMode ловит disk/network на main thread — включаем с penaltyFlashScreen() в debug-сборке.

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

UI-обновления не с main thread

На Android: CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views. Причина — обработка сетевого ответа напрямую в колбэке Retrofit без withContext(Dispatchers.Main).

На iOS: Main Thread Checker в Xcode (включён по умолчанию в Scheme settings) ловит обращения к UIKit с фоновых потоков в debug-сборке. В релизе — случайные краши или visual corruption.

Правильный паттерн iOS:

DispatchQueue.global(qos: .userInitiated).async {
    let result = heavyComputation()
    DispatchQueue.main.async {
        self.label.text = result // только здесь
    }
}

Thread explosion с GCD

Thread explosion возникает при массовом создании потоков через GCD без ограничений. Система начинает агрессивно выделять потоки, вызывая резкую деградацию производительности при нагрузке. Решение — ограниченный concurrency через OperationQueue.maxConcurrentOperationCount или через Swift Concurrency TaskGroup с явным withTaskGroup и ограниченным параллелизмом:

await withTaskGroup(of: Result.self) { group in
    for item in items.prefix(4) { // не более 4 параллельных задач
        group.addTask { await process(item) }
    }
}

Data races

Несколько потоков читают и пишут одно поле без синхронизации. На Swift — Thread Sanitizer (TSan) находит гонки данных в debug-сборке. Включается в Scheme → Diagnostics → Thread Sanitizer.

Варианты синхронизации:

• NSLock / os_unfair_lock — быстрые мьютексы для критических секций
• DispatchQueue(label:attributes:.concurrent) с barrier для read-write lock паттерна
• Actor в Swift 5.5+ — самый современный способ, компилятор гарантирует изоляцию данных

actor UserCache {
    private var storage: [String: User] = [:]

    func get(_ id: String) -> User? { storage[id] }
    func set(_ user: User) { storage[user.id] = user }
}

С actor компилятор не позволит обратиться к storage вне actor-контекста без await. Actor в 2 раза надёжнее ручной синхронизации с NSLock.

Android: неправильное использование Coroutines

GlobalScope.launch — красный флаг. Coroutine живёт бесконечно, не отменяется при закрытии экрана. При повторном открытии — создаётся второй. Правильно — viewModelScope.launch (отменяется при onCleared) или lifecycleScope.launch (отменяется при onDestroy).

Dispatchers.Main vs Dispatchers.Main.immediate: при вызове с main thread Dispatchers.Main.immediate выполняется синхронно без переключения контекста — важно для анимаций и немедленных UI-обновлений.

Неправильная обработка исключений в coroutines:

// НЕПРАВИЛЬНО — исключение не поймается
scope.launch {
    try { riskyOperation() } catch (e: Exception) { handle(e) }
}

// ПРАВИЛЬНО — CoroutineExceptionHandler для структурной обработки
val handler = CoroutineExceptionHandler { _, e -> handleError(e) }
scope.launch(handler) { riskyOperation() }

Почему structured concurrency — основа оптимизации конкурентности?

Structured concurrency (async/await в Swift, Kotlin Coroutines с корутинным скоупом) гарантирует отмену задач при завершении контекста, исключает утечки потоков и упрощает чтение кода. В отличие от GCD/Thread, где легко создать thread explosion или deadlock, structured concurrency принуждает к локальной области видимости задач. Actor в Swift обеспечивает изоляцию данных на уровне компилятора, что в 2 раза снижает количество race conditions по сравнению с ручной синхронизацией.

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

Сравнение подходов к синхронизации

Кейс из нашей практики: deadlock в Swift

E-commerce приложение нашего клиента: при добавлении в корзину UI иногда зависал на 30–60 секунд. Воспроизводилось только при плохом интернете.

Через Thread State dump выяснилось: CartService.addItem() вызывал userDefaults.synchronize() внутри serialQueue.sync, а synchronize() внутри ждал NSFileCoordinator, который тоже стоял в очереди на запись. При сетевой задержке несколько вызовов addItem() выстраивались в очередь и один из них попадал в deadlock с NSFileCoordinator.

Решение: убрали synchronize() (в iOS 12+ он no-op), перевели сохранение корзины на async запись через DispatchQueue.global().async. После исправления deadlock исчез, время отклика сократилось на 40%.

Этапы работы

1. Включаем TSan и Main Thread Checker на всех прогонах тестов
2. Анализируем Thread state в Instruments / Android Profiler Threads view
3. Проверяем все места с sync вызовами и shared mutable state
4. Правим: weak references, правильные dispatch queues, actor isolation
5. Нагрузочное тестирование для выявления race conditions под нагрузкой

Что входит в работу

• Полный аудит конкурентности с отчётом по найденным проблемам
• Исправление кода: замена GCD на async/await, внедрение actor, оптимизация coroutines
• Документация по изменениям и рекомендации по дальнейшей разработке
• Доступ к репозиторию с исправлениями, обучение команды (до 2 часов)
• Гарантия на исправления — 3 месяца после сдачи

Сроки и как начать

Аудит конкурентности — 2–4 дня. Исправление найденных проблем — от 3 до 14 дней в зависимости от глубины архитектурных решений. Стоимость рассчитывается индивидуально. Если у вас есть подозрения на deadlock или race condition — свяжитесь с нами, оценим проект за 2 дня. Закажите аудит конкурентности сегодня и получите детальный отчёт с предложениями по исправлению.

Оптимизация мобильных приложений: 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 рабочих дней. Реализация оптимизаций — от недели до двух месяцев в зависимости от запущенности проблем и архитектуры кода.