Звітування про збої в мобільній розробці — що це, сервіси та налаштування

Що таке звітування про збої?

Звітування про збої — це процес автоматичного збору технічної інформації про падіння застосунку та її централізованої передачі на сервер для аналізу. На відміну від логування, звітування про збої фіксує саме аварійні ситуації — момент, коли застосунок був примусово завершений системою або ОС.

Кожен звіт про збій містить три ключові компоненти: тип винятку (NullPointerException, SIGSEGV, NSInternalInconsistencyException), повний стек викликів з номерами рядків та інформацію про середовище — версію ОС, модель пристрою, розмір вільної пам'яті. За даними Sentry Engineering, 2024, саме поєднання цих трьох елементів дозволяє відтворити та виправити 85% критичних помилок.

Сучасні системи звітування про збої розширюють функціональність за межі звичайних збоїв. Firebase Crashlytics автоматично групує повторювані падіння в issues, Sentry відстежує регресії між релізами, а Bugsnag показує шлях користувача до помилки. Всі три сервіси підтримують iOS, Android, React Native та Flutter.

За даними Google I/O 2024, застосунки без звітування про збої витрачають на діагностику однієї критичної помилки в середньому 3–5 робочих днів, тоді як з Crashlytics — 15–30 хвилин. Економія часу становить понад 90% для кожного інциденту.

Як працює система збору звітів про збої

Архітектура системи звітування про збої складається з трьох шарів: клієнтський SDK, встановлений у застосунку, серверний API для прийому та обробки звітів, і веб-дашборд для аналізу. Клієнтський SDK перехоплює необроблені винятки, серіалізує їх у JSON та відправляє на сервер при наступному запуску застосунку.

Відправка звіту про збій відбувається асинхронно після перезапуску застосунку. Це принциповий момент: в момент збою застосунок не може гарантувати успішне відправлення даних по мережі. SDK записує звіт у локальне сховище, і при наступному запуску відправляє його фоновим потоком. За даними Firebase Engineering, 2024, такий підхід забезпечує доставку 99.7% звітів про збої.

Для non-fatal винятків (оброблені винятки всередині try-catch) SDK відправляє звіт негайно, оскільки застосунок продовжує роботу. Non-fatal звіти містять ті ж дані, що й збій, але не переривають сесію користувача. Це особливо корисно для відстеження помилок API-запитів, валідації даних та бізнес-логіки.

Групування збоїв — серверний алгоритм, який об'єднує однакові збої на основі хешу від останніх 5–10 фреймів стеку. Це дозволяє розробнику бачити не 1000 окремих звітів, а одне issue з 1000 входжень, що охоплюють різні пристрої та версії ОС.

Firebase Crashlytics: інтеграція та можливості

Firebase Crashlytics — найпопулярніший сервіс звітування про збої для мобільних застосунків, що використовується більш ніж у 3 мільйонах проектів по всьому світу. Безкоштовний тариф включає необмежену кількість звітів, інтеграцію з Google Analytics та автоматичне групування збоїв.

Інтеграція Crashlytics на Android

Підключення Crashlytics на Android мінімальне: додайте залежність у build.gradle та ініціалізуйте SDK в Application.onCreate. Crashlytics автоматично встановлює власний Thread.setDefaultUncaughtExceptionHandler, перехоплюючи всі необроблені винятки.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

Ключова можливість Crashlytics — custom keys та logs. Розробник може додати до 64 пар ключ-значення до кожного звіту про збій: стан екрану, вибраний тариф, рівень користувача. Також доступний запис custom log-повідомлень, які потрапляють у звіт у хронологічному порядку.

Velocity Alert — автоматичне виявлення регресій

Velocity Alert — функція Crashlytics, яка відстежує різке зростання кількості збоїв для конкретного issue. Якщо після нового релізу кількість падінь перевищує порогове значення, команда отримує push-сповіщення та email за 5–15 хвилин до масових скарг користувачів.

Налаштування порогу спрацювання: 2x за 1 годину для критичних issues. За даними Google, 2024, команди з увімкненим Velocity Alert випускають hotfix-релізи в середньому на 40% швидше, ніж команди, що покладаються на ручний моніторинг дашборду.

Інтеграція Crashlytics на iOS

На iOS Crashlytics SDK інтегрується через CocoaPods або Swift Package Manager. SDK перехоплює як Objective-C винятки (через NSSetUncaughtExceptionHandler), так і сигнали ОС (SIGSEGV, SIGABRT) через власний mach exception handler.

За даними Apple Developer, 2024, Crashlytics для iOS обробляє до 98% всіх типів падінь, включаючи низькорівневі помилки пам'яті, які не перехоплюються стандартними засобами. Це робить Crashlytics стандартом де-факто для iOS-розробки.

Sentry та Bugsnag: альтернативні платформи

Sentry — open-source платформа моніторингу помилок, що підтримує 80+ мов та фреймворків. На відміну від Crashlytics, Sentry орієнтована на бекенд-розробників, але надає повноцінний SDK для iOS, Android, React Native та Flutter.

Ключова перевага Sentry — Performance Monitoring в єдиному дашборді. Розробник бачить не лише збої, а й транзакції, які до них призвели: повільні мережеві запити, зависання UI, довгі операції з базою даних. За даними Sentry, 2024, 40% збоїв мають попередні проблеми продуктивності, які залишаються непоміченими без такого підходу.

Bugsnag відрізняється підходом до групування помилок — замість стеку викликів він аналізує шлях користувача (user journey). Кожен звіт про збій містить послідовність екранів та дій користувача, які призвели до помилки. Це особливо корисно для складних бізнес-процесів: оформлення замовлення, реєстрація, платіж.

Вартість сервісів варіюється: Crashlytics безкоштовний у рамках Firebase, Sentry пропонує безкоштовний тариф на 5000 подій на місяць, Bugsnag — від $29 на місяць. Всі три платформи надають SDK з відкритим кодом. Вибір сервісу залежить від розміру команди, бюджету та вимог до безпеки даних.

Звітування про збої на iOS: особливості та NSException

Особливість iOS — багатошарова архітектура обробки помилок. Crash-reporting SDK повинні перехоплювати Objective-C винятки (NSException), Swift-помилки (Error), сигнали POSIX (SIGSEGV, SIGBUS) та mach-винятки. Кожен тип вимагає окремого механізму перехоплення.

NSException — найпростіший тип для перехоплення через NSSetUncaughtExceptionHandler. Однак, за даними Apple, 2024, лише 30% збоїв у сучасних Swift-застосунках є NSException. Решта 70% — сигнали ОС та Swift runtime-помилки, для яких потрібен механізм mach exception handler.

Розробникам iOS важливо тестувати звітування про збої через локальну генерацію збоїв різного типу: __builtin_trap() для сигналів, [NSException raise:...] для винятків, fatalError() для Swift. Тільки так можна переконатися, що SDK покриває всі типи падінь.

Звітування про збої на Android: ANR та нативні збої

Android додає два специфічних типи падінь, яких немає на iOS: ANR (Application Not Responding) та нативний збій у C/C++ коді. ANR виникає, коли UI-потік заблокований більш ніж на 5 секунд — система показує діалог «Застосунок не відповідає» та пропонує закрити його.

Стандартний Thread.setDefaultUncaughtExceptionHandler не перехоплює ANR, оскільки це не виняток, а сигнал від ActivityManager. Для відстеження ANR Crashlytics та Sentry використовують фоновий watchdog-потік, який перевіряє відгук UI-потоку кожні 5 секунд. За даними Firebase, 2024, 15% всіх проблем на Android — ANR, а не збій.

Нативний збій на Android виникають у C/C++ коді, запущеному через JNI (Java Native Interface). Ці падіння не є Java-винятками і не перехоплюються Thread.setDefaultUncaughtExceptionHandler. Для їх обробки використовуються Google Breakpad або Crashpad, які встановлюють sigaction-обробники для сигналів SIGSEGV, SIGABRT, SIGBUS.

За даними Google I/O 2024, кількість нативних збоїв зростає з поширенням ігрових рушіїв (Unity, Unreal Engine) та бібліотек комп'ютерного зору (ML Kit, OpenCV). Розробникам гібридних застосунків рекомендується завжди підключати нативне звітування про збої.