Какие инструменты используются для отслеживания ошибок и аналитики
Что проверяют
Умеете ли вы видеть, что происходит с приложением у реальных пользователей, и реагировать до того, как упадёт рейтинг. Интервьюеру важно, отличаете ли вы краши, ANR, нефатальные ошибки и продуктовую аналитику. Следом часто спрашивают, как читать стек после R8 и как не отправить в аналитику персональные данные.
Как отвечать
Разделите инструменты по назначению:
- Firebase Crashlytics: краши, ANR, нефатальные ошибки через
recordException(), контекст черезsetCustomKey()иlog(). Gradle-плагин Crashlytics для минифицированной сборки сам загружает mapping-файл R8, без него стеки нечитаемы; - Sentry: ошибки и производительность, есть self-hosted вариант, когда данные нельзя отдавать в чужое облако;
- AppMetrica: аналитика и краш-репорты, частый выбор для российского рынка и устройств без GMS;
- Android vitals в Play Console: официальные метрики стабильности. Если доля пользователей с крашами выше 1,09% или с ANR выше 0,47%, приложение хуже показывается в магазине;
- продуктовая аналитика: Firebase Analytics (GA4) или AppMetrica, события с параметрами, воронки, когорты;
- производительность: Firebase Performance Monitoring, JankStats, Macrobenchmark для замеров старта.
Хорошо рассказать про связку: Timber с собственным Tree, который пишет хлебные крошки в Crashlytics, и setUserId() с внутренним идентификатором вместо почты. Добавьте свой пример: какой краш нашли по отчёту, сколько пользователей он затрагивал и как проверили исправление.
Где спотыкаются
Выпускают релиз без загруженного mapping-файла. Отчёты приходят со стеком из a.b.c, и разобрать самый массовый краш уже нельзя.
Кладут в custom keys и события почту, телефон или ФИО. Это нарушает правила магазина и 152-ФЗ, аналитика должна работать с обезличенными идентификаторами.
Ловят исключение в catch и молча глотают. Такая ошибка не попадёт ни в один отчёт, пока пользователи не начнут писать в поддержку, поэтому нефатальные ошибки нужно отправлять через recordException().