Количественная оценка и оптимизация взаимодействия пользователя с устройствами Android™

Автор: Сяо Фэнь Ли (Xiao-Feng Li)

 

 

Аннотация

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

 

 

 

 

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

Недавно при тестировании производительности нескольких доступных на рынке устройств Android было обнаружено, что устройство X стабильно демонстрирует худшие результаты, чем устройство Y, в одних и тех же тестах на отображение графики, мультимедиа и веб-страниц. Однако по ощущениям пользователей качество взаимодействия с устройством X было выше в сравнении с устройством Y. Пытаясь найти причину, мы пришли к выводу, что традиционные тесты производительности фактически оценивают не взаимодействие пользователя с системой, а только вычислительные возможности самой системы и подсистем (например, скорость выполнения инструкций) или их пропускную способность (например, количество обработанных операций чтения с диска за период времени).

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

Во-вторых, частота кадров, выбранная в качестве основной метрики для оценки плавности, не всегда может отражать реальное качество, воспринимаемое пользователем. Например, когда мы резко двигали изображение в приложении Gallery3D, на устройстве Y были заметны задержки во время движения, хотя значение частоты кадров устройства Y было выше в сравнении с устройством X. Для количественной оценки разницы между устройствами X и Y мы собрали данные о каждом кадре, отрисованном во время движения в приложении Gallery3D - эти данные показаны на рисунках 1 и 2. Каждый кадр представлен в виде вертикальной черты: по горизонтальной оси указано время отрисовки кадра, а высота черты показывает, сколько времени потребовалось системе для его отрисовки. По рисункам видно, что на устройстве X частота кадров ниже в сравнении с устройством Y, но меньше максимальная длительность отображения кадра, меньше кадров длительностью более 30 мс и меньше дисперсия длительности кадров. Таким образом, максимальная длительность отображения кадра и дисперсия длительности кадров являются важными метриками для оценки качества пользовательского интерфейса.



Рис. 1. Время отрисовки кадров при движении изображения в приложении Gallery3D на устройстве X.



Рис. 2. Время отрисовки кадров при движении изображения в приложении Gallery3D на устройстве Y.

Для сравнения на рисунке 3 показаны данные о кадрах при движении изображения после оптимизации устройства Y. По рисунку видно, что были улучшены все метрики, и распределение времени отрисовки кадров стало более равномерным.



Рис. 3. Время отрисовки кадров при движении изображения в приложении Gallery3D на устройстве Y после оптимизации.

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

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

 

 

 

 

  1. Ввод данных на устройстве пользователем, через сенсор, по сети и т. д. В этой категории можно оценить, насколько точно устройство реагирует на ввод по сравнению с ожидаемой реакцией. При вводе через сенсорный экран оцениваются скорость касания, сила нажатия, диапазон и т. д.
  2. Реакция устройства на ввод. В этой категории можно оценить скорость отклика устройства при вводе.
  3. Переход системы из одного состояния в другое. В этой категории оценивается, например, плавность перехода между изображениями на экране. Эта оценка может быть продолжением оценки реакции устройства на ввод.
  4. Продолжительное управление устройством. Пользователю устройства может потребоваться не только однократный ввод, но и продолжительное управление графическими объектами на экране, например при управлении реактивным самолетом в игре или при перетаскивании значка приложения. В этой категории оценивается соответствующая управляемость устройства.

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

 

 

 

 

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

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

 

 

 

 

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

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

 

 

 

 

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

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

Таблица 1. Пример общепринятых значений метрик пользовательского интерфейса.



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

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

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

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

 

 

 

 

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

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

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

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

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

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

 

 

 

 

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

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

Таблица 2. Пакет Android Workload Suite (AWS) 2.0



Набор Android UXtune включает в себя три вида инструментов для выполнения следующих задач.

 

 

 

 

  1. Имитация повторяемых операций ввода, используемых для управления устройством. Инструмент Android input-Gestures позволяет имитировать жест касания на сенсорном экране, избавляя разработчика от выполнения операций на устройстве вручную. Другие функции инструмента, позволяющие имитировать сенсорный ввод, находятся в стадии разработки.
  2. Визуализация внутрисистемного взаимодействия между программными компонентами, включая события, кадры, потоки и т. д. В настоящее время доступна версия Android UXtune 1.0. Интеграция с событиями блока мониторинга производительности (PMU) находится в стадии разработки.
  3. Извлечение важных метрик качества пользовательского интерфейса. В настоящее время доступны инструменты Android meter-FPS, Android app-launch и Android touch-pressure, предназначенные для измерения частоты кадров, времени запуска приложений и чувствительности к силе нажатия при сенсорном вводе.

Пакет AWS и набор инструментов UXtune более подробно описаны в других технических документах.

 

 

 

 

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

Чтобы проиллюстрировать методологию оптимизации интерфейса Android, рассмотрим пример с операцией перетаскивания.

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

Как показано на рисунке 4, в момент времени T0 пользователь начинает пальцем перетаскивать значок в позиции P0. В момент времени T1, когда палец достигает позиции P1, значок начинает перемещаться. В момент времени T2, когда значок перемещается в позицию P1, палец находится в позиции Р2. Между значком пальцем заметно расстояние отставания. Подведем итог:

 

 

 

 

  • T0: момент времени, когда пользователь начинает пальцем перетаскивать значок в позиции P0;
  • P1: позиция пальца, при которой значок начинает движение в момент времени T1;
  • T2: момент времени, когда значок достигает позиции P1;
  • P2: позиция пальца в момент времени T2.



Рис. 4. Расстояние отставания при перетаскивании.

На следующем этапе мы определяем сценарий и метрики выполнения программы, позволяющие выявить и оценить расстояние отставания при перетаскивании. В этом примере можно выбрать сценарий перетаскивания значка приложения по домашнему экрану Android. Одной метрикой может быть расстояние между позициями P0 и P1, то есть значение P1 – P0. Альтернативной или дополнительной метрикой может быть время, по прошествии которого начинается движение значка при перетаскивании, то есть значение T1 – T0. Метрика времени может быть показательнее, чем метрика расстояния, в зависимости масштаба расстояния на экране, поскольку физическое расстояние в миллиметрах отличается от расстояния в пикселах и при одинаковом расстоянии в пикселах фактические визуальные эффекты могут отличаться. Еще одной дополнительной метрикой расстояния отставания может быть расстояние P2 – P1, которому также соответствует время перемещения значка из позиции P0 в позицию P1, то есть T2 – T1. Чем меньше значение каждой из метрик (T1 – T0, P1 – P0, P2 – P1 и T2 – T1) тем выше качество пользовательского интерфейса.

На третьем этапе мы создаем рабочую нагрузку, чтобы воспроизвести симптом и получить значения выбранных метрик. На домашнем экране Android создается рабочая нагрузка, и вычисляются метрики в соответствии со значениями программного стека. На рисунке 5 показана диаграмма реализации рабочей нагрузки. Как это принято в программировании на базе Android, основной код рабочей нагрузки включен в методы обратного вызова onTouch() и onDraw(). Метод обратного вызова onTouch() получает событие касания в качестве параметра и вычисляет обновление содержимого, которое должно быть отображено на экране. Метод обратного вызова onDraw() выполняет фактическую отрисовку содержимого, обновленного методом onTouch(). При этом метод onTouch() обрабатывает события сенсорного ввода с помощью четырехшаговой конечной машины, каждое состояние которой соответствует действиям пользователя - от нажатия пальцем на экран до снятия пальца с экрана. Метод обратного вызова onDraw() также является четырехшаговым и отвечает за видимые пользователем переходы между состояниями на экране. В течение третьего шага, пока палец продолжает двигаться и на экране отображается перемещающийся значок, мы регистрируем отметки времени для отрисованных кадров и координаты событий касания, как показано на рисунке 5. Затем мы вычисляем значения T1, P1, Т2 и Р2, как показано ниже:

 

 

 

 

  • T1 = время отрисовки кадра F1 методом SurfaceFlinger
  • P1 = значение позиции события касания в момент времени T1
  • T2 = время отрисовки кадра, на котором значок находится в позиции P1
  • P2 = значение позиции события касания в момент времени T2



Рис. 5. Создание рабочей нагрузки при оптимизации расстояния отставания.

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

На четвертом этапе мы анализируем и оптимизируем расстояние отставания при перетаскивании с применением доступных инструментов. На рисунке 6 далее показана основная причина отставания при перетаскивании и вычислено расстояние отставания для одного момента времени.



Рис. 6. Анализ расстояния отставания при перетаскивании

Диаграмма времени выполнения на рисунке 6 построена с помощью набора инструментов Android UXtune, разработанного для анализа пользовательского интерфейса. Комментарии и стрелки добавлены мной для удобства просмотра. Для нас наиболее важными являются три потока, отмеченных звездочкой. Это поток отрисовки (surfaceFlinger), поток событий (inputDisptacher) и поток приложения, которое обрабатывает событие. Путь выполнения события касания (на диаграмме - событие M-1) отмечен оранжевыми стрелками.

Как показано на рисунке выше, событие М–1 с координатами (850; 542,8) передается из потока событий в поток приложения. В ожидании обработки оно находится в очереди сообщений приложения. Поток приложения извлекает это событие из очереди и вычисляет в своем буфере поверхности содержимое кадра для соответствующей позиции. Затем поток приложения передает буфер поверхности в поток отрисовки. Поток отрисовки загружает буфер и компонует его с другими поверхностями системы, а затем записывает результат в буфер кадра экрана.

Когда обработка события М–1 полностью завершается и кадр отрисовывается на экране, поток событий уже передает событие M+1 с координатами (852; 404,6), соответствующими является текущей позиции пальца. Мы рассчитываем расстояние отставания при перетаскивании для этого момента и получаем 542,8 – 404,6 = 138 пикселов. Обратите внимание на то, что отметка времени события касания в потоке событий не совпадает в точности с моментом времени, когда палец касался экрана. Разница может составлять до нескольких миллисекунд. Но это не влияет на анализ и оптимизацию расстояния отставания при перетаскивании.

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

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

Сначала приложение рассчитывает скорость движения пальца (Speedfinger) на основании полученных событий касания. Затем приложение рассчитывает, насколько далеко может передвинуться палец (Distancefinger) за время обработки одного кадра (Timeframe), то есть от начала отрисовки одного кадра до начала отрисовки следующего кадра. Приложение прогнозирует позицию пальца (NextPositionfinger) в момент времени, когда будет виден следующий кадр. Прогнозируемая позиция пальца равна его текущей позиции (CurrPositionfinger) плюс расстояние его перемещения за время отрисовки одного кадра (Distancefinger). Когда приложение попытается отрисовать следующий кадр, значок будет отрисован в прогнозируемой позиции пальца (NextPositionicon). Для расчета используются следующие основные формулы.

 

 

 

 

Speedfinger = (P1 – P0)/(T1 – T0)
Timeframe = 1/FPS
Distancefinger = Speedfinger * Timeframe
NextPositionfinger = Distancefinger + CurrPositionfinger
NextPositionicon = NextPositionfinger
 

Мы успешно разработали алгоритм прогнозирования для системы Android на платформе Intel®. Обратите внимание на то, что может потребоваться дополнительный механизм регулирования, не дающий значку обогнать палец.

 

 

 

 

Технические факторы, влияющие на взаимодействие пользователя с системой

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

 

 

 

 

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

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

 

 

 

 

 

 

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

Автор благодарит своих коллег Грега Чжу (Greg Zhu) и Кэ Чэнь (Ke Chen) за огромную поддержку в ходе разработки методологии для оптимизации пользовательского интерфейса Android.
 

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