Краш-аналитика: как ловить падения приложения
Чтобы ловить падения приложения, подключите краш-аналитику — Firebase Crashlytics или Sentry — с первого же релиза, настройте алерты на новые группы ошибок и контролируйте метрику crash-free users: у здорового продукта она выше 99,5%. Без этих инструментов о крашах вы узнаёте из гневных отзывов в сторах, когда пользователи уже удалили приложение.
Почему падения нельзя отследить вручную
Краш происходит на устройстве пользователя, а не на вашем сервере. Логов у вас нет, а воспроизвести ошибку сложно: сотни моделей Android-смартфонов, разные версии ОС, нестабильный интернет в метро Алматы, нехватка памяти на бюджетных устройствах. Один и тот же экран может стабильно работать на Pixel и падать на Redmi из-за агрессивного менеджера памяти MIUI.
Цена молчания высокая. Значительная часть пользователей удаляет приложение после первого-второго вылета и не возвращается. Google Play учитывает стабильность в ранжировании: если user-perceived crash rate превышает порог Android Vitals (1,09%), приложение теряет позиции в поиске и рекомендациях стора. App Store формального порога не публикует, но рейтинг быстро проседает из-за отзывов со словом «вылетает».
Краш-аналитика решает три задачи: автоматически собирает стектрейсы со всех устройств, группирует тысячи одинаковых падений в одну проблему и присылает алерт, пока ошибка затронула десятки пользователей, а не тысячи.
Crash-free — главная метрика стабильности
Crash-free показывает долю пользователей или сессий, которые не столкнулись с падением за период. Метрика существует в двух вариантах, и путать их не стоит:
- Crash-free users — процент пользователей без единого краша. Строгий показатель: одно падение «портит» пользователя на весь отчётный период.
- Crash-free sessions — процент сессий без падений. Мягче: пользователь мог упасть один раз из двадцати запусков, и девятнадцать сессий засчитаются как чистые.
Ориентиры, которые мы используем в работе:
- ниже 99,0% crash-free users — критическая стабильность, нужен пожарный режим;
- 99,0–99,5% — терпимо для раннего MVP, недопустимо для продукта с платным трафиком;
- 99,5–99,8% — рабочая норма для большинства приложений;
- выше 99,9% — уровень банковских и e-commerce продуктов с массовой аудиторией.
Считайте в абсолютных числах. При 50 000 активных пользователей разница между 99,5% и 99,9% — это 200 человек в месяц, которые увидели вылет на своём экране. За привлечение каждого из них вы уже заплатили.
Firebase Crashlytics: бесплатный стандарт индустрии
Crashlytics — часть Firebase от Google и де-факто стандарт мобильной разработки. Подключается за день, работает на iOS, Android, Flutter и React Native, полностью бесплатен и не ограничивает объём событий.
Что инструмент умеет из коробки:
- группировка падений по сигнатуре стектрейса — десять тысяч одинаковых крашей превращаются в одну карточку со счётчиком затронутых пользователей;
- расшифровка стектрейсов: dSYM-файлы для iOS, mapping-файлы ProGuard/R8 для Android — без их загрузки трейс нечитаем;
- custom keys и логи-«хлебные крошки»: какой экран был открыт и какой ID заказа обрабатывался в момент падения;
- non-fatal ошибки — перехваченные исключения, которые не уронили приложение, но сигналят о скрытой проблеме;
- velocity-алерты — уведомление, когда свежая проблема резко набирает обороты в новом релизе.
Ограничения тоже есть. Данные живут только в облаке Google: self-hosted варианта нет, что не подходит проектам с жёсткими требованиями к хранению данных — госсектору и части финтеха. События иногда приходят с задержкой до нескольких часов. Аналитика по ANR (зависаниям Android) скромнее, чем в Android Vitals, поэтому консоль Google Play всё равно придётся проверять.
Sentry: контекст, релизы и self-hosted
Sentry вырос из веб-мониторинга и сейчас уверенно работает с мобильными платформами. Главное отличие от Crashlytics — глубина контекста и контроль над данными.
- Release health — crash-free sessions и скорость принятия по каждому релизу: видно, как версия 2.4.1 ведёт себя относительно 2.4.0 в первые часы раскатки.
- Breadcrumbs автоматически — HTTP-запросы, навигация между экранами, тапы: события до краша записываются без ручной разметки.
- Performance tracing — медленные запуски, фризы интерфейса, тяжёлые сетевые запросы. Краш-аналитика и APM в одном продукте.
- Self-hosted — Sentry открыт, его можно развернуть на собственном сервере. Когда персональные данные обязаны храниться внутри Казахстана, это решающий аргумент.
Платная сторона: облачный Sentry тарифицируется по объёму событий. Небольшой команде хватает тарифа Team — порядка 15 000–25 000 ₸ в месяц по курсу 2026 года; нагруженные продукты выходят на 60 000–150 000 ₸. Self-hosted бесплатен по лицензии, но требует сервер от 8 ГБ RAM и время DevOps-инженера на обновления.
Crashlytics или Sentry: что выбрать
| Критерий | Firebase Crashlytics | Sentry |
|---|---|---|
| Цена | Бесплатно, без лимитов | От ~15 000 ₸/мес в облаке или self-hosted |
| Хранение данных | Только облако Google | Облако или собственный сервер |
| Release health | Базовые срезы по версиям | Подробно: adoption и crash-free по релизам |
| Performance-мониторинг | Отдельный продукт Firebase | Встроен: tracing, фризы, время запуска |
| Бэкенд и веб | Нет | Да, единая панель на весь стек |
| Скорость подключения | 0,5–1 день | 1–3 дня |
| Кому подходит | MVP и чисто мобильные продукты | Финтех, продукты с веб-частью, строгий комплаенс |
Наша практика: большинству проектов на старте достаточно Crashlytics — он бесплатный и закрывает девять задач из десяти. Sentry подключаем, когда у продукта есть веб-часть и бэкенд, когда заказчику нужен self-hosted или когда команде не хватает данных о производительности. Инструменты не исключают друг друга — на крупных проектах они работают параллельно.
Процесс: от алерта до стабильного релиза
Инструмент без процесса — просто дашборд, на который никто не смотрит. Рабочая схема выглядит так:
- Алерты в мессенджер команды. Новая группа крашей или резкий рост существующей — сообщение в Slack или Telegram в течение минут, а не на утреннем созвоне.
- Triage в течение рабочего дня. Каждой проблеме присваиваем приоритет: сколько пользователей затронуто, есть ли обходной путь, падает оплата или второстепенный экран настроек.
- Фикс с воспроизведением. По breadcrumbs и custom keys восстанавливаем сценарий и пишем регрессионный тест. Краш, найденный аналитикой, — это пробел в тестировании мобильного приложения, и закрывать его нужно автотестом, а не только хотфиксом.
- Поэтапная раскатка. Релиз на 10% аудитории, сутки наблюдаем crash-free, затем 50% и 100%. Google Play поддерживает staged rollout из коробки, App Store — phased release на семь дней.
- Ретроспектива. Повторяющиеся типы падений — NPE, force unwrap, гонки данных — повод ужесточить правила код-ревью и контроля качества кода и добавить статический анализ в CI.
Мы встраиваем этот цикл в каждый проект разработки мобильных приложений: SDK подключается на старте, алерты настраиваются до публикации, а в первые недели после релиза команда дежурит по метрикам стабильности.
Сколько стоит внедрение краш-аналитики в Казахстане
Реалистичные цены казахстанского рынка на 2026 год:
| Работа | Срок | Стоимость |
|---|---|---|
| Подключение Crashlytics: iOS + Android, dSYM/mapping, алерты | 2–4 дня | 150 000 – 300 000 ₸ |
| Внедрение облачного Sentry: SDK, release health, интеграция с трекером задач | 3–5 дней | 250 000 – 450 000 ₸ |
| Sentry self-hosted: сервер, развёртывание, бэкапы, регламент обновлений | 1–2 недели | 500 000 – 900 000 ₸ |
| Аудит стабильности существующего приложения и план фиксов | 1 неделя | 200 000 – 400 000 ₸ |
| Поддержка и мониторинг стабильности | ежемесячно | от 100 000 ₸/мес |
Итоговая цифра зависит от размера кодовой базы, числа платформ и состояния проекта. Если приложение уже падает и теряет аудиторию, начните с аудита: за неделю мы покажем топ-10 проблем по влиянию на пользователей и оценим стоимость их устранения. Студия Applications.kz работает с 2007 года, за плечами 300+ проектов в Казахстане, ОАЭ и Таиланде. Команда разработки мобильных приложений в Алматы подготовит смету за 24 часа — звоните +7 (707) 928-13-15.
Частые вопросы
Можно ли следить за стабильностью по отзывам в сторах?
Нет. Отзыв пишет один пользователь из сотен столкнувшихся с проблемой, причём с задержкой в дни. В отзыве нет стектрейса, модели устройства и шагов воспроизведения — чинить по нему почти невозможно. Краш-аналитика присылает технические детали через минуты после падения, и команда успевает выпустить фикс до волны негатива.
Crashlytics полностью бесплатный — в чём подвох?
Подвоха нет: Google окупает Firebase за счёт экосистемы — облачных сервисов и рекламных продуктов. Реальные ограничения другие: данные хранятся только в облаке Google, выгрузка сырых событий требует подключения BigQuery, а мониторинг бэкенда инструмент не покрывает. Для типового мобильного продукта этих компромиссов обычно не замечают годами.
Что делать, если crash-free резко упал после релиза?
Остановить раскатку: в Google Play — halt staged rollout, в App Store — паузу phased release. Затем открыть топ новых проблем версии, найти доминирующую группу крашей и выпустить хотфикс именно по ней. Если фикс требует времени, откатите фичу удалённым конфигом или feature-флагом — это быстрее, чем новая сборка через ревью сторов.
Передаёт ли краш-аналитика персональные данные?
По умолчанию SDK собирает технические данные: модель устройства, версию ОС, стектрейс. Персональные данные туда попадают, только если разработчик сам положил их в логи или custom keys — этого делать нельзя. Для проектов с жёстким комплаенсом используем self-hosted Sentry на сервере в Казахстане и фильтры данных перед отправкой события.
Краши и ANR — это одно и то же?
Нет. Краш — аварийное завершение процесса, ANR — зависание интерфейса Android дольше пяти секунд, после которого система предлагает закрыть приложение. Google Play штрафует за оба показателя, но пороги разные: 1,09% для крашей и 0,47% для ANR. Crashlytics и Sentry умеют отслеживать ANR, поэтому настраивайте алерты на обе метрики сразу.