Анализ взаимодействия пользователя с системой с помощью Android* Workload Suite (AWS)

Краткий обзор

Оценка эффективности работы пользователя с системой отличается от традиционного измерения ее рабочих параметров. Результаты большинства таких тестов ничего не говорят об эффективности взаимодействия пользователя с системой, так как измеряются только ее статичные состояния. В то же время пользовательские действия - это в большей степени переходные состояния. В данной статье рассматривается пакет Android Workload Suite (AWS), который включает в себя набор тестов для имитации взаимодействия пользователя с ОС Android и анализа соответствующих показателей. Мы полагаем, что AWS отражает реальную картину работы клиентских устройств на базе Android и позволяет адекватно оценивать их производительность, энергопотребление и удобство использования.
 

Сценарии пользовательских действий на клиентском устройстве

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

  1. Определить репрезентативные сценарии использования
  2. Сопоставить поведение пользователя и реакцию системного ПО на них
  3. Разработать тесты

Чтобы подобрать оптимальные сценарии взаимодействия, мы проанализировали множество материалов. В их числе официальная документация крупнейших отраслевых компаний, популярные приложения из интернет-магазинов, встроенное ПО различных устройств, а также формфакторы планшетных ПК и смартфонов. Кроме того, мы изучили жизненный цикл пользовательских интерфейсов, архитектуру и исходный код ОС Android. На наш взгляд, варианты использования устройств можно разделить на четыре категории, которые представлены на рис. 1. Все они очень важны для проведения комплексного тестирования.
 

 

Рис. 1. Категории вариантов использования клиентских устройств


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

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

 

 

 

 

Рис. 2. Сценарии использования браузера


Каждый сценарий можно условно отнести к одной из следующих категорий:

  • Действия пользователя.
    Сюда входят сценарии таких типичных операций, как просмотр веб-страниц, игры, создание документов, изменение настроек и т. д. Основные средства ввода - сенсорный экран и виртуальная клавиатура. К этой категории относятся также сценарии ввода/вывода и обмена данными.
  • Загрузка и отображение.
    Данная категория включает в себя системные вычислительные задачи, такие как загрузка веб-страницы в браузере, открытие электронной книги, просмотр коллекции картинок и т. д. Отображение обычно входит в сценарий загрузки, но в некоторых случаях считается самостоятельным сценарием, например при прорисовке страниц на HTML5, мультимедийных компонентов, графики и т. д.
  • Управление задачами.
    Две предыдущие категории охватывают общие сценарии работы с приложениями. В последнюю, третью категорию входят различные сценарии управления приложениями, в том числе запуск приложений, переключение между задачами, уведомления, входящие вызовы и многозадачность.

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

  1. 1. Как пользователь управляет устройством. Сюда относятся две важные области для анализа.
    1. Точность/погрешность.Оцениваются такие параметры системы, как точность, погрешность, разрешение экрана и область ввода сенсорного экрана, виртуальной клавиатуры и других элементов интерфейса. В частности, оцениваются следующие характеристики: реакция на различную силу нажатия, точность отслеживания движений пальца по экрану, возможность одновременного нажатия несколькими пальцами и т. д.
    2. Согласованность.Оценивается задержка прорисовки графического объекта при перемещении его пальцем по экрану. Также анализируется согласованность между действиями пользователя и реакцией датчиков положения на них, например угол между фактическим наклоном корпуса устройства и положением объекта на экране, который должен следовать за его наклоном.
  2. Как устройство реагирует на действия пользователя. Сюда также входят две важные области для анализа:
    1. Отклик. Оценивается задержка между вводом данных или совершением действия и видимым откликом устройства на этот ввод или действие. Здесь также учитывается время, затраченное на завершение действия.
    2. Плавность. Оценивается плавность отображения графических объектов, в том числе максимальное время прорисовки кадра, разброс прорисовки кадров по времени, число кадров в секунду (FPS), процент потерянных кадров и т. д. Как мы уже отметили ранее, одного параметра FPS недостаточно для оценки плавности прорисовки.

На основе описанной методологии можно уточнить модель жизненного цикла взаимодействия с браузером с учетом областей анализа для каждого сценария (см. рис. 3).

Рис. 3. Сценарии использования браузера с учетом областей анализа


Чтобы набор тестов давал репрезентативные результаты как для планшетных ПК, так и для смартфонов, мы проанализировали разницу в использовании этих устройств. Как и следовало ожидать, основное различие - это их размер. Смартфон обычно умещается в ладони, но тем не менее оснащен целым арсеналом функций:

  • Голосовая и видеосвязь
  • Проигрыватель музыки и подкастов
  • Фото- и видеокамера с распознаванием лиц и штрих-кодов
  • GPS- и AGPS-навигатор, компас и т. д.
  • Коммуникатор для текстовых и мультимедийных чатов
  • Чтение электронных книг и новостей
  • Встроенный фонарик, ночное видение и другие функции

Что касается приложений для смартфонов, то они оптимизированы под небольшой размер экрана. Игры для смартфонов преимущественно выполнены в мультипликационном стиле и содержат простую анимацию. Сенсорное управление в них организовано достаточно просто и чаще всего основано на акселерометре. Кроме того, в смартфонных играх для управления чаще используется «встряхивание» устройства, так как смартфон гораздо проще трясти в руке, в то время как игры для планшетных ПК анализируют наклон корпуса устройства при помощи встроенного в него гироскопа. Помимо разницы в датчиках, планшетные ПК с крупным экраном обладают следующими характеристиками:

  • Более реалистичная визуализация графики и действий
  • Упрощенное и более точное сенсорное управление, в том числе виртуальные панели в играх, текстовые процессоры и рукописный ввод текста
  • Больший объем дискового пространства для хранения различного содержимого: новости, обучающие материалы, электронные книги и т. д.
  • Поддержка многопользовательских режимов в играх, обучающих программах
  • Полнофункциональные, как на ПК, веб-браузеры и RSS-агрегаторы
  • Больше места на рабочем столе для доступа к повседневным приложениям; впрочем, смартфон используется чаще как карманное устройство

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

Некоторые сценарии применимы к обоим типам устройств, однако требуют адаптации. Так, одна и та же 2D-игра может более активно использовать анимированные спрайты на планшетном ПК, чем на смартфоне, в то время как сценарий для браузера может загружать полную версию веб-страницы на планшете, а ее мобильную версию - на смартфоне.

Создание тестов для оценки взаимодействия пользователя с Android

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

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

В верхней части рисунка 4 представлены обобщенные сценарии использования ресурсов в ОС Android. Элемент «Ввод» инициирует Задачу 1, которая, в свою очередь, запускает Службу 1. Затем Служба 1 обращается к Службе 2, которая запускает Задачу 2. Итоговый результат работы («Вывод») берется из Задачи 2.

В нижней части рисунка изображено четыре варианта измерения системных показателей.

  • Автономный тест. Функционирует без входных данных от пользователя и по окончании работы возвращает результат.
  • Микротест. Выполняет несколько потоков в стеке. Не является полноценным платформенным приложением.
  • Инструмент для измерения. Позволяет тестирующему инженеру ввести данные и возвращает результаты замеров. Инструмент может принимать на вход различные данные.
  • Драйвер сценария для встроенного приложения. Вводит данные в триггеры и снимает выходные результаты со встроенных приложений. Один из вариантов его использования - обеспечение единых входных значений для различных устройств при анализе интерфейса браузера.

Рис. 4. Взаимосвязь между тестами и инструментами


Разработанные нами тесты интерфейсов ОС Android реализуют все четыре основные задачи. Однако в окончательную версию пакета, скорее всего, войдут только первый и четвертый типы, так как тесты первого типа удобно использовать для тестирования по принципу «белого ящика», а тесты четвертого типа - по принципу «черного ящика».

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

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

  • Ясность. Показатель должен быть понятен человеку. В противном случае его нельзя использовать для оценки работы пользователя с системой.
  • Измеримость. Показатель можно многократно замерять, причем для этого не требуется специальное аппаратное или программное обеспечение.
  • Стабильность. Показатель должен иметь схожие значения в разных тестах. Если его колебания слишком велики, то такой показатель не подходит для тестирования.
  • Сопоставимость. Значения показателя можно сравнить для различных систем. На основе такого показателя разработчики могут сопоставлять системы друг с другом.
  • Обоснованность. Показатель должен объяснять процессы, происходящие в стеке приложения. Другими словами, он должен быть тесно связан с поведением программы и вычисляться на основе параметров работы ее стека.
  • Проверяемость. Показатель можно использовать для проверки оптимизации. Его значения до и после оптимизации должны отражать изменения, произошедшие в работе пользователя с системой.
  • Автомaтизм. Для целей разработки ПО процесс измерения показателя должен быть автоматизирован. Это особенно удобно для регрессивного тестирования и проверки перед загрузкой в репозиторий. Впрочем, данный критерий не является обязательным, поскольку не имеет прямого отношения к анализу и оптимизации пользовательских интерфейсов.

Возьмем для примера воспроизведение видео. Традиционные тестовые среды измеряют только производительность при проигрывании роликов, а также отдельные показатели, например FPS (число кадров в секунду) или процент потерянных кадров. Но если руководствоваться такой методикой при оценке пользовательских интерфейсов, возникают как минимум две проблемы. Первая из них связана с тем, что воспроизведение ролика - это только одна из составляющих работы с видео. Как правило, жизненный цикл взаимодействия с видео состоит из следующих этапов: запуск проигрывателя → начало воспроизведения → перемотка вперед или назад → воспроизведение ролика → возврат на главный экран (см. рис. 5). Таким образом, качество воспроизведения видео не характеризует в полной мере общее удобство работы с ним. То есть можно утверждать, традиционная оценка производительности - это частный случай оценки интерфейса. Вторая проблема заключается в том, что показатель FPS не может полностью отражать плавность воспроизведения. В следующем разделе на конкретном примере описаны типичные трудности, возникающие при разработке тестов.

Рис. 5. Сценарии использования для теста воспроизведения видео

 

Пример разработки теста

Рассмотрим процесс создания теста на примере сценария прокрутки страницы в браузере. Действия, совершаемые пользователем при прокрутке страницы вверх или вниз, показаны на рис. 6.

Рис. 6. Действия пользователя при прокрутке страницы в браузере


Как видно на рисунке, в момент времени T0 пользователь нажимает на экран и начинает вести по нему пальцем из позиции P0. Когда палец доходит до позиции P1 в момент времени T1, содержимое страницы начинает перемещаться вслед за ним. По достижении содержимого страницы позиции P1 в момент времени T2 пользователь перемещает палец в позицию P2. Таким образом, между перемещением пальца и содержимого страницы постоянно присутствует задержка. В момент T3 пользователь убирает палец с экрана и содержимое страницы смещается в ту позицию, где только что находился палец.

В данном сценарии мы решили измерить три характеристики:

  • Время отклика: насколько быстро контент перемещается вслед за пальцем пользователя?
  • Задержка: на какое расстояние контент «запаздывает» при перемещении?
  • Плавность: насколько плавно отображается анимация при прокрутке?

Для того чтобы измерить время отклика, нам необходимо понять, как именно браузер выполняет прокрутку страницы. Этот процесс показан на рис. 7.

Рис. 7. Внутренний механизм прокрутки в стеке приложения Android


На рисунке показаны три ряда: для входящих необработанных событий, для событий браузера и для событий прорисовки в браузере. Сенсорный экран регистрирует нажатие и генерирует необработанные события для системы. Получив эти события, платформа преобразует их в события перемещения, такие как ACTION_DOWN, ACTION_UP и ACTION_MOVE. С каждым событием ассоциирована пара координат (X, Y). Браузер вычисляет расстояние между точкой, с которой связано текущее событие перемещения, и начальной позицией (т. е. координатой в событии ACTION_DOWN). Если полученное расстояние превышает определенный порог, заданный в системе, браузер будет трактовать эти события перемещения как составную часть жеста прокрутки и соответственно сместит содержимое страницы вверх или вниз. Браузер сдвигает контент пошагово, прорисовывая новый кадр на каждом шаге. Однако для пользователя все это выглядит как непрерывный процесс.

На рис. 8 показана схема измерения отклика браузера при прокрутке. Под временем отклика понимается промежуток между получением первого необработанного события и прорисовкой первого кадра во время прокрутки.

 

 

Рис. 8. Измерение времени отклика браузера при прокрутке


Для измерения плавности прокрутки мы зафиксировали время прорисовки каждого кадра, как видно из рис. 9. Затем мы рассчитали максимальное время отображения кадра, количество кадров длиной свыше 30 мс, FPS и разброс кадров по времени.

Рис. 9. Измерение плавности прокрутки в браузере


Однако в измерении плавности есть один нюанс: как определить, какие кадры относятся к прокрутке, а какие нет? Первый кадр выявить довольно легко, но с последним кадром возникает сложность. В тот момент, когда пользователь убирает палец с экрана, браузер все еще прорисовывает кадры прокрутки (если, конечно, пользователь не перемещал палец очень уж медленно). Последний кадр можно определить, взяв за основу тот, после которого пользователь убрал палец, или использовав кадр, во время которого браузер обновил страницу. Для простоты мы выбрали первый вариант, рассчитывая на то, что, когда пользователь убирает палец, контент уже прорисован достаточно хорошо, чтобы можно было оценить плавность прокрутки.

Для того чтобы оценить «запаздывание» контента при перемещении пальца, мы измерили координаты и время создания всех необработанных событий и прорисованных кадров. На основе этих данных можно вычислить максимальное расстояние между кадром и точками возникновения предшествующих ему событий. Обозначим расстояние до k-го кадра как Distance[k]. Определив максимальное значение Distance[k] среди всех кадров, мы как раз и получим искомое «запаздывание». Рис. 10 подробно иллюстрирует данный подход.

Рис. 10. Измерение «запаздывания» прокрутки в браузере


Для многократного воспроизведения теста мы использовали инструмент Android UXtune*, который генерирует стандартный жест ввода.

Всего мы разработали две версии теста для измерения показателей прокрутки. Первая из них работает автономно, причем в нее включен собственный браузер и драйвер сценария, который запускает автоматическое выполнение и измерение. Вторая содержит в себе только драйвер сценария и для замеров использует встроенный браузер устройства. Соответственно, первая версия предназначена для сравнения работы ОС Android на разных устройствах, а вторая - для сопоставления встроенных браузеров одного устройства.

Оптимизация пользовательского интерфейса с помощью Android Workload Suite (AWS)

Основываясь на описанной выше методологии, мы разработали пакет Android Workload Suite (AWS), который позволяет тестировать интерфейс Android и вносить в него изменения.

Тесты, входящие в пакет AWS 2.0, перечислены в табл. 1. Идеи для этих тестов были отобраны с учетом наших обширных исследований мобильных платформ и приложений, а также отзывов пользователей.

Таблица 1. Состав пакета Android Workload Suite (AWS) 2.0



Кроме того, мы разработали комплексную методологию оптимизации интерфейса Android, которая включает в себя следующие этапы.

 

 

 

 

Этап 1. Собрать отзывы и мнения пользователей или самостоятельно выявить проблемы и области для исследования.

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

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

Этап 4. С помощью теста и вспомогательных инструментов проанализировать стек приложения и предложить способ его оптимизации. При этом результаты оптимизации проверяются с помощью того же самого теста.

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

На третьем этапе мы рекомендуем использовать Android Workload Suite (AWS). Для четвертого этапа нами разработан инструмент Android UXtune, облегчающий анализ стека приложения.

Учитывая отзывы пользователей и изменения в платформе Android, мы продолжаем совершенствовать пакет AWS.

 

 

 

 

Дополнительные материалы

Ниже приведены ссылки на некоторые полезные веб-сайты, посвященные пользовательским интерфейсам.

Благодарность

Автор выражает признательность своим коллегам Грегу Жу и Ке Чен за их неоценимую помощь в разработке методологии оптимизации интерфейсов Android.
 

Об авторе

Ксяо Фэн Ли (Xiao-Feng Li) работает архитектором программного обеспечения в центре оптимизации систем группы разработки приложений и служб корпорации Intel. Господин Ли обладает обширным опытом в области параллельных вычислений и технологий реального времени. До своего перехода в Intel в 2001 году он занимал руководящую должность в исследовательском центре компании Nokia. В свободное время господин Ли увлекается катанием на коньках и китайской каллиграфией.
 

Для получения подробной информации о возможностях оптимизации компилятора обратитесь к нашему Уведомлению об оптимизации.
Возможность комментирования русскоязычного контента была отключена. Узнать подробнее.