Говоря о стабильности приложения, мы привыкли следить за показателем crash-free. Чем выше процент — тем лучше. Чтобы посчитать его, не нужны дополнительные действия. Главное, не забыть активировать в AppMetrica компонент крэшей.
Но стопроцентный crash-free ещё не означает идеальную работу приложения. Несовершенства в коде не всегда приводят к падению приложения. Иногда ничего не упало, но кнопка — не нажимается, изменения — не сохраняются, бонусы к опыту, за идеальное прохождение уровня в игре — не зачитываются, а пользователь — огорчается.
Такие случаи тоже нужно отлавливать и устранять. Под это заточены методы try … catch и отчёт Ошибки в AppMetrica. О нём и поговорим, ведь мы его полностью переработали.
Практически всё. Мы внесли изменения в сам механизм сбора ошибок, обновили интерфейс отчёта и разделили его по операционным системам.
Таким образом, группировка ошибок полностью под вашим контролем. А перейдя внутрь ошибки, вы увидите новые полезные поля: параметры, stack trace, текстовое описание и вложенные ошибки:
Ошибки теперь делятся на подгруппы, для более точной классификации.
Как и крэши, ошибки можно закрывать. Прямо как в тикет-системах. Если ошибка возникнет после закрытия, в новой версии приложения, «тикет» автоматически переоткроется:
Благодаря этому проще выстраивать процессы и приоритеты. А ещё — следить за эффективностью работы над ошибками и не упускать из виду то, что лишь казалось исправленным.
В отличие от крэшей, сообщения об ошибках не отправляются автоматически. Разработчик сам задаёт условия, в которых нужно отправить ошибку. Как правило, применяя методы обработки исключений. Для отправки в SDK используется метод _YandexMetrica.reportError_. Подробные инструкции по использованию метода смотрите в документации для Android и iOS.
Ошибки хранятся на устройстве так же как обычные события и отправляются на сервер по тем же правилам.
Если вы пользуетесь отчётом Крэши, то заметили, что в Ошибках нет метрики, аналогичной Crash-free. Это нормально, ввиду самой природы ошибок.
Crash-free — доля сессий, не завершившихся аварийно. На одну сессию может быть только один крэш, и для пользователя все крэши выглядят примерно одинаково. Крэш определяется операционной системой как аварийное завершение. Система сохраняет крэш-логи автоматически. AppMetrica достаёт их из хранилища, каталогизирует и приводит в читаемый вид.
Знание доли сессий без ошибок вряд ли будет иметь практический смысл: ошибок на сессию может быть несколько. И что считать ошибкой, разработчик определяет сам. Если не настроить сбор конкретных ошибок в приложении, они не попадут в отчёт вовсе. Но если отчёт пуст, это не говорит о том, что ошибок нет. Возможно, их просто не удалось поймать. А вот низкий процент падений приложения говорит о его стабильности более однозначно.
Автоматически собираются операционной системой
Крэш, по однозначному определению, — любое аварийное завершение приложения
Возникают не чаще, чем один раз за сессию
Собираются, если разработчик настроит их сбор
Что считать ошибкой приложения, разработчик определяет сам
Могут возникать несколько раз за сессию
Важно то, сколько раз возникает конкретная ошибка, по сравнению с прочими. Это помогает оценить критичность бага и расставить приоритеты.
Если вы давно хотели поработать над стабильностью приложения более глубоко — самое время обновить SDK для iOS и для Android и настроить новые методы.
Важно: старая версия отчёта будет работать до 1 сенября 2020, поэтому рекомендуем не затягивать с обновлением.
Уже пользуетесь отчётом? Поделитесь впечатлениями в Telegram-чате!
Мы поработали над Ошибками, чтобы вам было удобнее работать над ошибками.
– Команда AppMetrica