Концепции для мобильных интерфейсов

Концепции для мобильных интерфейсов

На этой странице объясняются ключевые концепции разработки мобильных интерфейсов в RUM. Понимание этих концепций поможет вам анализировать поведение пользователей и производительность приложений в мобильной среде.

Начало работы приложения

Запуск приложения отражает инициализацию мобильного приложения, измеряя время, необходимое для загрузки приложения и появления первого видимого элемента после запуска пользователем.

Типы запуска приложений

Существует три типа запуска приложений, каждый из которых имеет различные характеристики производительности:

• Холодный старт: происходит при запуске приложения из неактивного состояния. Это случается, например, при первом запуске приложения после загрузки устройства. Холодный старт включает в себя полный процесс инициализации, включая загрузку ресурсов, настройку среды выполнения и инициализацию приложения.
• Теплый старт: включает в себя подмножество операций, которые происходят во время холодного старта. Это может произойти, если пользователь выходит из приложения, а затем вскоре запускает его снова. Поведение может значительно отличаться в зависимости от платформы.
• Горячий старт: имеет меньшие накладные расходы, чем холодный или теплый старт. Если состояние приложения все еще находится в памяти, можно избежать таких операций, как инициализация объектов, развертка макета и рендеринг. Это происходит, когда приложение полностью работает в фоновом режиме и снова выводится на передний план.

Полный список данных, перехваченных при запуске приложения, см. в разделе «Семантический словарь».

Представления и их краткие обзоры

В мобильных приложениях представление (view) представляет собой экран, с которым взаимодействует пользователь. Представления — это отдельные экраны или макеты в мобильном приложении, отображающие определенный контент или функциональность, например, корзина покупок или страница настроек. Посещение пользователем определенного представления объединяется в событие сводки по представлению (view summary event).

Жизненный цикл представления

• Отображение начинается, когда приложение показывает новый экран мобильного устройства.
• Отображение завершается, когда пользователь переходит с экрана на другой экран.

Экземпляры представлений и сводные данные

Событие «Сводка по просмотру» объединяет следующие данные из одного посещения сайта:

• Взаимодействие пользователя с данным представлением.
• Ошибки, обнаруженные в процессе просмотра.
• Запросы, сделанные во время активного просмотра.

Экземпляры просмотра идентифицируются уникальным идентификатором view.identifier, в то время как все экземпляры одного и того же экрана имеют один и тот же идентификатор view.name для агрегированного анализа. Это позволяет анализировать как отдельные посещения просмотра, так и общие закономерности производительности по всем посещениям одного и того же просмотра.

Полный список данных, полученных в результате события сводки представления, см. в разделе «Семантический словарь».

Навигация

Навигация представляет собой переход между представлениями в мобильном приложении. Эти события позволяют получить представление о том, как пользователи перемещаются по приложению:

• Событие навигации запускается, когда предыдущий вид останавливается (например, из-за касания пользователя или автоматического запуска).
• Навигация завершается при запуске следующего представления.

Типы навигации

Мобильная навигация может запускаться различными способами:

• Навигация: Пользователь вручную инициировал навигацию, нажав кнопку или вернувшись назад.
• Авто: Переход в приложении был запущен автоматически (например, из-за истечения времени ожидания или автоматической смены экрана).
• API: Разработчик мобильного приложения вручную вызывает функцию startView для сигнализации о создании нового представления, что неявно создает событие навигации.

Взаимодействие с пользователями

Ранний доступ

Взаимодействия пользователей представляют собой действия, выполняемые пользователями на внешнем интерфейсе мобильного приложения. Вы можете включить запись взаимодействий пользователей, как описано в разделе «Настройка записи взаимодействий пользователей для мобильных интерфейсов».

В настоящее время для мобильных устройств поддерживаются следующие виды взаимодействия с пользователем:

• Прикосновения
• Жесты
• Вращение устройства

В отличие от RUM Classic, в RUM взаимодействие можно фиксировать независимо от каких-либо запросов или действий пользователя.

Полный список взаимодействий с пользователями см. в разделе «Семантический словарь».

Действия пользователя

Действие пользователя представляет собой важную операцию в мобильном интерфейсе. Оно объединяет запросы, действия навигации и ошибки, возникающие в результате одного взаимодействия пользователя, предоставляя полную картину того, что произошло и сколько времени это заняло. Например, действие пользователя начинается, когда пользователь нажимает кнопку, и заканчивается, когда завершается соответствующий сетевой запрос и отображается новый экран.

Как начинаются действия пользователя

Действие пользователя начинается с одного из следующих событий:

• Взаимодействие с пользователем: Касание элемента пользовательского интерфейса, имеющего зарегистрированный обработчик действий (например, кнопки или элемента списка), за которым в течение 100 мс следует веб-запрос или навигация по представлению, запускает автоматическое действие пользователя. Если в течение 100 мс не происходит ни того, ни другого, действие пользователя не создается, поскольку само по себе касание не считается действием пользователя.
• Вызов API: Создается вручную с помощью API Ключ-АСТРОМ. Это полезно для отслеживания пользовательских рабочих процессов, которые не фиксируются автоматически, например, многоэтапных процессов или взаимодействий, которые агент не может отслеживать. Подробнее см. раздел «Настройка мониторинга мобильного интерфейса с помощью API RUM».

Что такое группы действий пользователя?

Пока пользователь выполняет действие, агент связывает события, являющиеся результатом этого взаимодействия, позволяя анализировать их вместе и понимать полное влияние отдельного взаимодействия.

• Веб-запросы: Каждый веб-запрос, инициированный во время выполнения действия пользователем, группируется в рамках этого действия. Эти запросы определяют, когда действие завершается и как долго оно остается активным.
• Ошибки: Ошибки и исключения, возникающие во время действий пользователя, связываются с ними, поэтому вы можете увидеть, какие взаимодействия привели к сбоям.
• Навигация по представлению: Если взаимодействие приводит к новому экрану, результирующая навигация связывается с действием пользователя. Это устанавливает тип действия на изменение представления. Навигация расширяет действие пользователя, но не используется для группировки запросов.

Для действий пользователей API вы также можете прикреплять свойства событий для получения дополнительной бизнес-контекстной информации. Подробнее см. раздел «Настройка мониторинга мобильного интерфейса с помощью API RUM».

Как завершаются действия пользователя

Действие пользователя остается активным до тех пор, пока сохраняется активность. Агент продлевает действие пользователя, пока выполняются веб-запросы или происходит навигация, применяя 100-миллисекундное окно бездействия после завершения последнего запроса или навигации.

Действие пользователя завершается при выполнении одного из следующих условий:

• Завершено: В течение 100 мс после последнего запроса веб-сайта или перехода по ссылке не происходит ни одного перехода. Действие пользователя завершается, и об этом сообщается. Это стандартный путь завершения автоматических действий пользователя.
• Приложение переведено в фоновый режим: Приложение переходит в фоновый режим. Действие пользователя немедленно прекращается.
• Прервано: Происходит новое взаимодействие пользователя с обработчиком действий или создается новое действие пользователя API. Предыдущее действие пользователя прерывается и связывается с новым.
• Достигнута максимальная продолжительность: Действие пользователя достигает максимальной продолжительности в 50 секунд и автоматически завершается.
• Закрытие API: Вы явно закрываете действие пользователя, созданное через API, вызывая соответствующий complete метод. Действие пользователя завершается в момент вызова.

Захваченные данные

Каждое действие пользователя фиксирует следующую информацию:

• Имя: Для автоматических действий пользователя имя соответствует шаблону {interaction type} on {element name} on {view name}, например, touch on Checkout on CartActivity. Для действий пользователя через API имя — это пользовательское имя, которое вы указываете.
• Тип: Указывает, привело ли действие к изменению отображения, осталось ли отображение прежним или было создано через API.
  • Автоматические действия пользователя имеют либо тип same_view, либо navigation.
  • Созданные вручную действия пользователя всегда имеют тип api.
• Инициирование взаимодействия: Для автоматических действий пользователя указываются имя и тип элемента пользовательского интерфейса, отреагировавшего на касание, а также название экрана, на котором это произошло.
• Длительность: Время от начала до конца действия пользователя, охватывающее всю сетевую активность, которую оно вызывает.
• Количество запросов, переходов по ссылкам и ошибок: Число веб-запросов, переходов по ссылкам и ошибок, произошедших во время выполнения пользователем действий.
• Причина завершения: Почему действие пользователя завершилось, например, обычное завершение, истечение времени ожидания, переход приложения в фоновый режим или прерывание другим действием.

Каждое связанное событие (взаимодействие пользователя, навигация, ошибка или запрос) содержит идентификатор user_action.instance_id действия пользователя, который связывает его с этим действием пользователя.

Имя элемента пользовательского интерфейса формируется на основе доступной метки или идентификатора элемента и может содержать предоставленный пользователем текст, например, метку кнопки. Те же правила маскировки конфиденциальности, которые применяются к событию, запускающему взаимодействие пользователя, также применяются к имени элемента в действии пользователя. Имя экрана формируется на основе имен классов исходного кода и не подлежит маскировке.

Полный список данных, полученных в результате действия пользователя, см. в разделе «Семантический словарь».

Ошибки

RUM фиксирует различные типы ошибок, которые могут возникать в мобильных приложениях.

Сбои

Сбой — это критическая ошибка, приводящая к завершению работы приложения. Когда ваше мобильное приложение аварийно завершает работу, Ключ-АСТРОМ автоматически сообщает о событии сбоя. Отчет о сбое включает в себя:

• Время возникновения события.
• Полный трассировочный стек исключения.
• Информация об устройстве.
• Контекст сессии.

Сбои группируются по сходству трассировки стека и места их возникновения в исходном коде, что упрощает отслеживание проблем в разных версиях вашего приложения.

Полный список данных, полученных в результате сбоя, см. в разделе «Семантический словарь».

Приложение не отвечает (ANR)

События ANR — это критические ошибки, характерные для мобильных приложений, когда основной поток приложения перестаёт отвечать и не может обрабатывать события ввода пользователя или обновлять пользовательский интерфейс. Это приводит к закрытию приложения, вызывая недовольство пользователей.

События ANR автоматически регистрируются RUM. Эти события отправляются только в том случае, если пользователь перезапускает мобильное приложение в течение 10 минут. Ошибки ANR всегда являются фатальными (error.is_fatal = true), поскольку не отвечающее приложение приводит к фатальному завершению работы.

Полный список данных, полученных в результате события «приложение не отвечает», см. в разделе «Семантический словарь».