Как строится мониторинг и метрики в приложениях

Что проверяют

Знаете ли вы, что происходит с приложением после релиза: как узнать о падении раньше, чем из отзывов в сторе, и какие цифры считать здоровьем приложения. Следом часто спрашивают, как вы ловите ANR и медленный холодный старт.

Как отвечать

Разделите мониторинг на слои:

• стабильность: Firebase Crashlytics или Sentry для крашей и нефатальных ошибок. Главные метрики: доля пользователей и сессий без крашей и доля ANR. В Android vitals у Google Play есть пороги «плохого поведения», и их превышение снижает видимость приложения в сторе;
• производительность: холодный старт, пропущенные кадры, сетевые запросы. Инструменты: Firebase Performance Monitoring, JankStats из Jetpack, Macrobenchmark и Baseline Profiles для старта, локально Android Studio Profiler и Perfetto;
• логи: Timber с деревом, которое в релизе отправляет ошибки в Crashlytics, а в отладке пишет в Logcat;
• продуктовые события: Firebase Analytics или AppMetrica, воронки и конверсии отдельно от технических метрик;
• реакция: алерты на рост крашей в новой версии, поэтапный выкат в Play Console с остановкой раскатки при всплеске.

Добавьте про контекст ошибки: версия приложения, модель устройства, версия Android, последние действия пользователя в виде breadcrumbs. И про R8: стектрейс из обфусцированного кода читается только с mapping-файлом, поэтому его загрузка должна быть частью каждой релизной сборки.

Где спотыкаются

Ограничиваются одним Crashlytics. Краши видны, а ANR, медленный старт и подтормаживания интерфейса остаются вне поля зрения.

Забывают про mapping-файлы. Стектрейсы из релиза приходят с именами вроде a.b.c, и разбирать их нечем.

Логируют всё подряд, включая токены и телефоны пользователей. Это одновременно утечка персональных данных и лишний трафик.