Краш додатка: що це, причини вильотів і методи відлову

Що таке краш додатка

Краш — неочікуване завершення програми, спричинене винятковою ситуацією, яку код не обробив. У мобільних ОС краш призводить до негайного закриття додатка й показу екрана “Додаток зупинено” або повернення на домашній екран.

Краші поділяються на два великі класи. Оброблені помилки — блоки try/catch перехоплюють виняток, додаток продовжує працювати, можливо з втратою функціональності. Необроблені краші — виняток спливає до рівня ОС, і система вбиває процес. Другий тип особливо небезпечний, оскільки користувач не може зберегти дані.

Система з двома мільйонами користувачів і 0.1% crash rate втрачає 2 000 користувачів на кожному релізі. За даними Google Play Console (2024), додатки з crash rate вище 1.5% виключаються з рекомендацій і втрачають до 30% органічного трафіку.

Основні причини вильотів у мобільних додатках

NullPointerException (NPE) — король крашів у Java/Kotlin. Спроба викликати метод на null-об'єкті. У Kotlin NPE трапляється рідше завдяки null safety, але все ще можливий при використанні оператора !! або взаємодії з Java-кодом. Google (2024) оцінює: NPE становлять 25% усіх крашів Android-додатків.

IndexOutOfBoundsException — звернення до елемента списку за неіснуючим індексом. Часта причина: дані прийшли з сервера в неочікуваному форматі, а UI намагається відобразити позицію, якої немає. Рішення — завжди перевіряй розмір колекції перед доступом за індексом.

ANR (Application Not Responding) — Android-специфічна проблема. UI-потік блокується більш ніж на 5 секунд. Основні причини: мережеві запити на головному потоці, важкі обчислення, синхронізація з базою даних. StrictMode в Android допомагає виявити блокування UI-потоку на етапі розробки.

OutOfMemoryError (OOM) — додаток перевищив ліміт пам'яті. На мобільних пристроях з 2–4 GB RAM OOM — часта проблема при роботі з великими зображеннями або нескінченними списками без пагінації. Рішення — Glide/Coil для завантаження зображень, LruCache для кешування, ViewHolder у RecyclerView.

Runtime exceptions і фатальні помилки

Runtime exceptions — помилки, які компілятор не перевіряє на етапі збірки. Вони проявляються тільки при виконанні коду на конкретному пристрої з конкретними даними. У Java це RuntimeException і його підкласи: NullPointerException, IllegalArgumentException, ArithmeticException.

Фатальні помилки (FATAL) — не runtime, а системні збої. Signal 11 (SIGSEGV) — порушення сегментації пам'яті в native-коді. Signal 6 (SIGABRT) — аварійне завершення, викликане самим додатком через abort(). Такі краші важко діагностувати, оскільки stack trace часто не показує зрозумілого контексту.

В iOS основні причини — NSInvalidArgumentException (неочікуваний nil у параметрі) і EXC_BAD_ACCESS (доступ до звільненої пам'яті). Swift зменшив кількість крашів порівняно з Objective-C, але помилки в ObjC runtime і C-бібліотеках все ще призводять до падінь.

Моніторинг і збір crash-логів

Firebase Crashlytics — стандарт для мобільних додатків. Автоматично збирає stack trace, додає логи, user ID і метадані пристрою. Групує краші за сигнатурою (клас помилки + рядок). Real-time alerts — сповіщення, коли crash rate перевищує заданий поріг (наприклад, >0.1% за годину).

Sentry — альтернатива з більш гнучкими можливостями. Дозволяє створювати custom contexts, додавати breadcrumbs (попередні події), налаштовувати in-app filtering для виключення неважливих помилок. Source maps для Kotlin і Swift дозволяють бачити вихідний код, а не обфусковані імена.

Best practices для логів: відправляй ключові метадані перед виконанням небезпечної операції — так у лозі буде видно, що робив користувач перед крашем. Додавай custom keys (номер версії API, останній екран, розмір вхідних даних). Це перетворює марний stack trace на actionable інформацію.

Приклад: налаштування Crashlytics в Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Стратегії запобігання крашам

Optional binding і null safety — у Kotlin використовуй `?` для nullable-типів, `let` і `?:` для безпечної обробки null. У Swift — optionals і guard let. Modern Kotlin (2024) додав Contract-анотації: `@ContractsDsl` дозволяє оголосити, що функція не повертає null, і компілятор це перевіряє.

Error handling в мережі — кожен мережевий запит повинен обробляти timeout, помилки парсингу та відмову сервера. Retrofit з Result-типом — sealed class, який гарантує, що помилка буде оброблена. No Exception-стиль: замість try/catch використовуй sealed Result для явної обробки успіху та помилки.

Feature flags — вимикай проблемний функціонал віддалено без релізу нової версії. Якщо серверна операція викликає краш на старих пристроях — флаг вимикає її для цієї групи. Firebase Remote Config дозволяє змінювати поведінку додатка без публікації в магазині.

Поступовий rollout — випускай нову версію на 5% аудиторії й моніторь crash rate. Якщо rate залишається нижче цільового (зазвичай <0.1%), розширюй до 25%, потім 50%, потім 100%. Google Play Console і App Store Connect підтримують staged rollouts для автоматичної зупинки при перевищенні порогу.

План дій при виявленні помилки

Крок 1: Класифікація — визнач severity: Critical (краш у >1% користувачів), High (0.1–1%), Medium (<0.1%). Для Critical крашів — immediate response. Для решти — стандартний процес багфіксу в поточному спринті. Google Play Console автоматично класифікує краші за кількістю зачеплених користувачів.

Крок 2: Аналіз stack trace — відкрий лог у Crashlytics, подивись точне місце падіння. Перевір custom keys: який екран, які дані, версія ОС. Співстав з останнім деплоєм — часто краш викликаний свіжою зміною в коді, яка зачепила неочікуваний сценарій використання.

Крок 3: Відтворення — спробуй відтворити краш на пристрої або емуляторі з аналогічними параметрами. Якщо не виходить — перевір crash log на патерни: конкретні моделі (Samsung A10), версії Android (API < 26), локалі. Рішення — додай захисну умову, яка покриває сценарій.

Крок 4: Фікс і моніторинг — випусти hotfix з пріоритетом. Після релізу переконайся, що crash rate по цьому типу падає до нуля. Напиши regression-тест, який покриває сценарій крашу. Без тесту той самий баг може повернутися в наступному рефакторингу.