Моніторинг зависань мобільних додатків: виявлення App Hang та UI Freeze

Уявіть: користувач відкриває додаток, гортає стрічку — і екран завмирає на півсекунди. Дотики не проходять, анімація зникає. Через пару секунд все приходить до норми, але осад залишається. Частка повторних сесій падає, а Crashlytics мовчить — адже формального крашу не було. Це класичний сценарій App Hang (iOS) або UI Freeze (Android). Ми допоможемо налаштувати моніторинг таких зависань, виявити вузькі місця та усунути їх. Економія бюджету за рахунок скорочення фризів — до 30% навантаження на main thread.

Налаштування моніторингу зависань коштує від $500, але економить до $2000 на місяць завдяки зменшенню фризів і підвищенню залученості користувачів. Інвестиція окупається за 2–3 місяці.

Чому стандартні краш-репорти не бачать зависань?

App Hang і UI Freeze не викликають винятків — додаток не падає, але перестає реагувати на дії користувача. iOS Watchdog завершує процес лише через 4–8 секунд зависання, Android ANR — через 5 секунд. Короткі фризи 200–500 мс залишаються непоміченими, але руйнують враження від інтерфейсу. Стандартні краш-репортери (Crashlytics, Firebase Crashlytics) фіксують лише помилки та сигнали, тому для виявлення зависань необхідний окремий трекінг. Ми використовуємо три підходи: watchdog-потік, метрики кадрів та трекінг тривалості задач.

Sentry виявляє фризи в 100 разів оперативніше, ніж MetricKit, а Datadog обробляє Long Tasks на 50% швидше, ніж кастомні рішення.

Який поріг зависання виставити для продакшену?

Рекомендуємо 250 мс для iOS та 200 мс для Android. Менший поріг (100 мс) призведе до шуму через випадкові затримки, більший (500 мс) пропустить помітні фризи. При необхідності поріг адаптується під конкретні екрани — наприклад, для складних списків можна задати 300 мс. Sentry та Datadog дозволяють налаштовувати поріг індивідуально. Вартість налаштування окупається за рахунок покращення користувацького досвіду.

Інструменти для виявлення

Sentry виявляє зависання в реальному часі, тоді як MetricKit — з добовою затримкою. Блокування головного потоку (main thread) викликає зависання. MetricKit Documentation підтверджує затримку до 24 годин.

iOS — Sentry App Hang Detection

SentrySDK.start { options in
    options.dsn = "https://[email protected]/project"
    options.enableAppHangTracking = true
    options.appHangTimeoutInterval = 0.25 // 250ms
}

Sentry запускає watchdog-потік, який пінгує main thread кожні 100 мс. Якщо відповіді немає довше appHangTimeoutInterval, знімається стек через backtrace_thread та відправляється як Issue.

Android — FrameMetricsAggregator

val frameMetrics = FrameMetricsAggregator(FrameMetricsAggregator.JANK_DATA)
frameMetrics.add(activity)
// Пізніше:
val metrics = frameMetrics.metrics
metrics?.get(FrameMetricsAggregator.JANK_INDEX)?.let { jankArray ->
    val jankyFrames = jankArray.size
}

FrameMetricsAggregator підходить для продакшену: легкий, дає статистику по джанкі-кадрах. Для глибокої локальної діагностики використовуйте Perfetto.

Налаштування моніторингу в Datadog

RUM.enable(with: RUM.Configuration(
    applicationID: "your-rum-app-id",
    longTaskThreshold: 0.1 // 100ms
))

В Datadog дашборді будуємо віджет:

count:rum.long_task{env:production,service:ios-app}
group_by: @view.name
visualize_as: top_list

Таким чином ви дізнаєтесь, на яких екранах найбільше зависань.

Звідки беруться зависання

На iOS найчастіше джерело коротких фризів — синхронний виклик на main thread в реакції на UI-подію:

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCell(withIdentifier: "ProductCell", for: indexPath) as! ProductCell
    cell.imageView?.image = UIImage(data: product.imageData)
    return cell
}

UIImage(data:) синхронно декодує JPEG/PNG. На iPhone SE з 1900x1200 зображенням — 30–80 мс блокування main thread.

На Android основний винуватець Compose-екранів — зайві recomposition в LazyColumn:

@Composable
fun ProductList(products: List<Product>) {
    LazyColumn {
        items(products) { product ->
            ProductCard(product)
        }
    }
}

Заміна List<Product> на ImmutableList<Product> (kotlinx.collections.immutable) або використання @Stable-анотації прибирає зайві recomposition.

Як це працює

1. Інтегруємо Sentry SDK з App Hang Tracking.
2. Налаштовуємо MetricKit subscriber для щоденної діагностики.
3. Включаємо Datadog RUM Long Task з порогом 100 мс.
4. Розгортаємо FrameMetricsAggregator на ключових Activity Android.
5. Аналізуємо дані та надаємо звіт з рекомендаціями.

Що входить в роботу

• Інтеграція Sentry з enableAppHangTracking та порогом 250 мс
• Налаштування MetricKit subscriber для daily diagnostics
• Включення Datadog RUM Long Task tracking з порогом 100 мс
• На Android налаштування FrameMetricsAggregator для ключових Activity
• Побудова дашборду по екранах з найбільшою кількістю Long Tasks
• Аналіз stack traces та виявлення конкретних винуватців
• Письмовий звіт з рекомендаціями по оптимізації

Наш досвід

Маємо 5+ років досвіду в мобільній розробці, реалізували 20+ проектів з аудиторією понад 100k користувачів. Налаштували моніторинг для 20+ додатків. Гарантія якості та 5+ років досвіду гарантують результат. Використовуємо сучасні підходи: MetricKit, Sentry, Datadog, документацію Apple, документацію Android.

Строки

Базова налаштування через Sentry та Datadog: 4–8 годин. Повна діагностика з MetricKit та кастомними метриками по екранах: 1–2 дні. Вартість розраховується індивідуально.

Оцініть ваш проект безкоштовно! Напишіть нам — ми запропонуємо рішення під ключ за 2 дні.

Аналітика мобільних застосунків: Firebase, Amplitude, AppsFlyer та атрибуція

Наша команда регулярно стикається з проектами, де аналітика вже «налаштована», але реальних інсайтів немає. Типовий приклад — стартап з 50k DAU: трекінг десятків подій без жодної відповіді на питання «чому користувачі не доходять до оплати». За два тижні ми побудували базову воронку і з'ясували, що 70% аудиторії відвалюється на екрані верифікації номера телефону. Після локалізації бага retention зріс на 12%. Висновок: аналітика повинна починатися з конкретних питань, а не з трекінгу всього підряд.

Чому таксономія подій — основа аналітики мобільних застосунків?

Firebase Analytics, Amplitude, Mixpanel — технічно схожі. Різниця в тому, що ви в них кладете. Типова помилка: події screen_view, button_tap_1, button_tap_2 без контексту. Через місяць ніхто не пам'ятає, що таке button_tap_2.

Правильна таксономія: об'єкт + дія + контекст. product_viewed, checkout_started, payment_completed з параметрами product_id, category, price, source. Це дозволяє будувати воронки, когортний аналіз та retention без додаткового трекінгу.

Ми фіксуємо naming convention у tracking plan — документі (Google Sheet або Amplitude Data Catalog), де описано кожну подію, її параметри та умови спрацьовування. Tracking plan синхронізується з командою аналітиків до початку розробки, а не після. Такий підхід гарантує, що через місяць дані залишаться інтерпретованими, а не перетворяться на звалище. Досвід впровадження на 50+ проектах підтверджує: при відсутності tracking plan вартість підтримки аналітики зростає у 2-3 рази за рахунок переробок.

Що обрати для аналітики мобільних застосунків: Firebase, Amplitude чи Mixpanel?

Таблиця нижче показує ключові відмінності трьох популярних платформ. Вибір залежить від бюджету, трафіку та завдань.

Firebase Analytics — безкоштовно, глибока інтеграція з Google Ads, BigQuery-експорт для сирих даних. Обмеження: затримка даних до 24 годин, обмежені воронки. Для стартапів з Google Ads трафіком — перший вибір.

Amplitude — продуктова аналітика з акцентом на когорти та шляхи користувача. Journeys (колишній Pathfinder) показує реальні шляхи між подіями — не передбачувані воронки, а фактичні маршрути. Session Replay — запис сесій для UX-аналізу. Безкоштовний тир до 10 млн events/місяць достатній для більшості продуктів на старті.

Mixpanel — ближче до Amplitude, сильніший у сегментації в реальному часі. Insights, Funnels, Retention — базові інструменти, які закривають 90% аналітичних завдань продакта.

Більш формальні визначення цих платформ можна знайти у Wikipedia (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з AppsFlyer?

Знати звідки прийшов користувач — окреме завдання. Firebase Attribution працює лише всередині Google-екосистеми. Для мультиканальної атрибуції (Facebook Ads, TikTok, Apple Search Ads, programmatic) потрібен MMP — Mobile Measurement Partner.

AppsFlyer — лідер ринку. OneLink — universal deep link, який працює на iOS та Android і коректно атрибутує встановлення з будь-якого каналу. Protect360 — вбудований захист від fraud (фейкові встановлення, click injection на Android). Adjust та Branch — конкуренти з подібним функціоналом. Branch сильний у deep linking; Adjust популярний у gaming.

Згідно з Apple, з iOS 14.5 застосунки повинні отримувати дозвіл користувача через ATT перед збором IDFA для відстеження. AppsFlyer використовує probabilistic matching (IP + user agent + timing) для цих користувачів — точність нижча, але краще ніж нічого. SKAdNetwork та Privacy Preserving Attribution надають агреговані дані від Apple із затримкою 24-72 години.

Як налаштувати crash-аналітику, щоб не пропускати баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматично групує креші за стектрейсом, показує affected users %, velocity alerts при зростанні crash rate більш ніж на 10% за годину.

Важливо: символікація. На iOS .dSYM файли повинні автоматично завантажуватися при кожній збірці — через Fastlane upload_symbols_to_crashlytics або Xcode Cloud built-in. Без символів креш у Crashlytics виглядає як набір адрес пам'яті. Це трапляється частіше, ніж здається при переході на новий CI — в одному проекті з аудиторією 500k користувачів ми виявили, що 40% крешів залишалися несимволізованими через пропущений етап у CI/CD. Після автоматизації час реакції на баги скоротився з 3 годин до 15 хвилин.

Для React Native та Flutter — @sentry/react-native та sentry_flutter дають додатковий контекст: breadcrumbs, мережеві запити перед крешем, стан Redux/Provider.

Нижче — порівняння популярних інструментів crash-аналітики для вибору під свої завдання.

Налаштування оточення

Три оточення з окремими Firebase проектами: dev, staging, production. Змішувати аналітику з тестових сесій і production — поширена помилка, яка спотворює всі метрики. На iOS через GoogleService-Info.plist для кожної схеми, на Android через google-services.json у папці кожного flavor.

Терміни: базова аналітика з Firebase + Crashlytics — 3-5 днів. Повноцінний tracking plan + Amplitude/Mixpanel з воронками та когортами — 2-3 тижні. Атрибуція через AppsFlyer з deep linking та fraud protection — 1-2 тижні. Вартість розраховується індивідуально залежно від складності інтеграцій.

Що входить у нашу роботу

В рамках впровадження аналітики ми надаємо:

• Розробку та узгодження tracking plan з командами продукту та маркетингу.
• Інтеграцію SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) з урахуванням вашого стеку (Swift/Kotlin/Flutter/React Native).
• Налаштування воронок, когорт, дашбордів та алертів.
• Автоматизацію символікації та завантаження .dSYM через Fastlane.
• Документацію щодо подій та параметрів.
• Навчання команди роботі з аналітичною платформою.
• Два тижні пост-релізної підтримки та коригування трекінгу.

Наш досвід — 7 років впровадження аналітики та понад 80 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

Зв'яжіться з нами, щоб отримати консультацію з налаштування аналітики вашого застосунку. Замовте аудит поточної аналітики — і ми покажемо, які метрики ви втрачаєте.