Мониторинг сбоев и производительности мобильного приложения
Мониторинг сбоев позволяет увидеть неполадки раньше жалоб пользователей: какие метрики отслеживать, какие инструменты выбрать и как расставить приоритеты.
Команда rabbitclipПубликация: 5 мин чтения
Коротко
Мониторинг сбоев мобильного приложения представляет собой настройку, которая каждый раз, когда приложение закрывается на телефоне пользователя, автоматически собирает сведения о том, где произошла неисправность, на каком устройстве и в какой версии, и сообщает об этом вам. Мониторинг производительности таким же образом измеряет более размытые проблемы: время запуска, подтормаживания и расход памяти. Когда налажено и то и другое, вы видите реальное состояние приложения в руках пользователей. Без них вы принимаете решения только по отзывам в магазинах приложений, а эти отзывы выражают мнение лишь небольшой части людей, которые столкнулись с проблемой.
Тот, у кого приложение вылетает, как правило, вам не пишет. Он закрывает его, пробует ещё раз, а затем удаляет. Приложение, которое прекрасно работает на ваших тестовых телефонах, может вести себя иначе на устройстве трёхлетней давности или при слабом соединении. Мониторинг служит единственным способом сделать эту невидимую группу видимой.
Одно и то же ли мониторинг сбоев и мониторинг производительности?
Нет, они отвечают на разные вопросы. Мониторинг сбоев фиксирует тот момент, когда приложение закрывается: на какой строке кода, на каком устройстве, под какой версией системы и что делал в этот момент пользователь. Мониторинг производительности измеряет то, что ощущается плохо, даже когда приложение не закрывается: медленный экран, дёрганую прокрутку, разрастающуюся память.
На Android существует и третий вид неисправности, приложение, которое не отвечает, известное как ANR. Приложение не вылетает, а зависает, и система предлагает пользователю закрыть его. Хорошо настроенный мониторинг показывает эти три группы отдельно: вылеты, отсутствие ответа и медлительность.
Какие метрики стоит отслеживать?
Несколько осмысленных показателей лучше, чем стена из графиков. Первый из них доля сеансов без сбоев: вероятность того, что сеанс завершится без неисправности после того, как пользователь открыл приложение. Сравнивайте её по версиям; если в новом выпуске она падает, значит, этот выпуск привнёс регрессию.
Вторая группа это показатели производительности. Панели магазинов приложений тоже предлагают собственные показатели состояния. Google Play Console и инструменты Apple для разработчиков бесплатно показывают данные о сбоях и об отсутствии ответа, собранные у пользователей, и для большинства компаний именно с них стоит начинать.
- Доля сеансов без сбоев, сравниваемая версия за версией
- Время холодного запуска: как быстро открывается приложение, которое было полностью закрыто
- Доля медленных и замороженных кадров: насколько плавно ощущаются прокрутка и переходы
- События отсутствия ответа (ANR) и затронутые модели устройств
Какие инструменты и данные стоит использовать?
Для отчётов о сбоях существуют широко используемые готовые сервисы; Firebase Crashlytics и Sentry являются известными примерами. Выбор зависит от той инфраструктуры, которой команда уже пользуется, и от того, что вам нужно отслеживать. Разницу создаёт не столько название инструмента, сколько правильность настройки.
Та часть настройки, которую пропускают чаще всего, это обеспечение читаемости отчёта. Код выпущенного приложения обфусцирован и лишён имён, поэтому, чтобы сделать отчёт о сбое читаемым, при каждом выпуске нужно загружать в сервис мониторинга соответствующие файлы символов и сопоставления. Если этого не делать, отчёт превращается в список бессмысленных адресов, и никто не может сказать, где именно находится неисправность.
Отчёты несут и контекст: последние действия пользователя, номер версии, модель устройства, состояние сети. Следите за тем, чтобы в этом контексте не было персональных данных; имена, адреса электронной почты и данные карт ни в коем случае не должны попадать в отчёт. О том, как персональные данные оказываются в журналах, стоит поговорить с юристом или с ответственным за защиту данных.
Как расставить приоритеты среди поступающих неисправностей?
Как только мониторинг заработал, за первую неделю набирается список из десятков неисправностей, и заниматься всеми сразу невозможно. Приоритет опирается на две проверки: сколько пользователей затронуто и на каком этапе их пути это происходит. Один-единственный сбой при оплате, входе или регистрации стоит выше, чем частый, но безвредный сбой на экране настроек.
Неисправность, которая появляется вместе с новым выпуском, рассматривают отдельно, потому что это регрессия и, как правило, самый быстрый для исправления вид. Если это возможно, поэтапная раздача новой версии пользователям позволяет остановить выпуск, когда обнаруживается проблема.
- Число затронутых пользователей и то, как часто это повторяется
- Момент, когда это происходит: в первую очередь оплата, вход и регистрация
- Началось ли это с нового выпуска, иными словами, является ли это регрессией
- Затронутая группа устройств и версий системы
Какие ошибки часто встречаются при мониторинге сбоев и производительности?
Самая частая ошибка состоит в том, что мониторинг настраивают уже после запуска, и первая волна сбоев проходит незамеченной. Вторая ошибка в том, что собирают отчёты, которые никто не читает. Один человек или одна роль должны регулярно просматривать неисправности и внимательно следить за ними в первые дни после каждого выпуска.
Третья ошибка в том, что приложение тестируют только на самых новых телефонах. Реальная пользовательская база включает более старые устройства и медленные соединения, и именно там проблемы с производительностью обычно и проявляются.
- Настраивать мониторинг после запуска
- Не загружать файлы символов и сопоставления, оставляя отчёты нечитаемыми
- Собирать отчёты, которые никто регулярно не просматривает
- Записывать персональные данные в отчёты или журналы
Когда мониторинг производительности не нужен или преждевременен?
Для приложения, которое ещё не запущено и у которого нет пользователей, подробная панель производительности преждевременна; интерпретировать пока нечего. На этом этапе достаточно настроить отчёты о сбоях, поскольку с первых же реальных пользователей они дают почти бесплатную страховку, требующую небольшого сопровождения.
Сложный набор средств мониторинга не нужен и для простого корпоративного приложения с небольшим числом пользователей, которое открывают редко; бесплатных данных о состоянии на панелях магазинов приложений может хватить. Проверка такова: если мониторинг не меняет ни одного решения, которое вы приняли бы, он лишний.
Мониторинг сбоев и производительности позволяет увидеть приложение таким, каким его на самом деле воспринимают пользователи, тогда как отзывы в магазинах показывают лишь самую громкую часть проблемы. Настройте мониторинг до запуска, при каждом выпуске загружайте файлы, которые делают отчёты читаемыми, регулярно просматривайте несколько осмысленных метрик и ранжируйте неисправности по тому, сколько пользователей они затрагивают. Если вам нужна помощь в том, как следить за состоянием вашего приложения, вы можете договориться с rabbitclip об ознакомительной встрече.
Частые вопросы
Что такое доля сеансов без сбоев?
Это доля сеансов, которые проходят от запуска приложения до его закрытия без сбоя. При сравнении по версиям она даёт быструю оценку стабильности нового выпуска.
Стоит ли использовать готовый инструмент для мониторинга сбоев?
Для большинства компаний да. Широко используемые сервисы, такие как Firebase Crashlytics и Sentry, предлагают готовое решение, а создание собственного редко добавляет ценности. Настоящая разница состоит в том, чтобы правильно его настроить и загружать файлы символов.
Достаточно ли одних только панелей магазинов приложений?
Для начала их часто бывает достаточно, поскольку они бесплатно показывают данные о сбоях и об отсутствии ответа. Чтобы увидеть, где и на каком шаге возникает неисправность, и чтобы сравнивать версии, обычно нужен отдельный инструмент мониторинга.
Считаются ли данные мониторинга персональными данными?
Могут считаться, если в отчёте есть сведения, позволяющие определить пользователя. Позаботьтесь о том, чтобы не добавлять в отчёты имена, адреса электронной почты и платёжные данные, и спросите юриста о правовом положении вашего приложения.
