Том Пантелс, Шень Гуо, Радж Шри Чабуксвар
Содержание
Почему важно создать хороший сенсорный интерфейс?. 3
Экономия электроэнергии за счет оптимизации сенсорного ввода. 4
Программы для анализа сенсорного ввода в Windows. 5
Казуальная многопользовательская мультисенсорная игра с замедленным откликом на касания 7
Трехмерная казуальная игра с исчезновением реакции на касания. 11
Введение
Эффективное взаимодействие с пользователем — крайне важный аспект современных программных продуктов. Другие функции и характеристики важны с точки зрения функциональности устройства, но все они не будут иметь значения при недостаточно быстром отклике на сенсорное управление и при его недостаточном удобстве. С момента появления Windows 8 жесты стали основным способом взаимодействия с ультрабуками под управлением Windows, планшетами и смартфонами. Эффективность таких систем частично зависит от того, насколько сенсорное управление повышает удобство пользователей и насколько удобство пользователей зависит от скорости работы и быстроты отклика сенсорного интерфейса.
Время отклика — это длительность промежутка между началом движения пальца по экрану для выполнения жеста и появлением на экране наглядной реакции на выполняемый жест. Время отклика обычно измеряется довольно короткими промежутками (порядка 100—500 мс). Важно определить и оптимизировать недостаточно быстро работающие компоненты обработки сенсорного ввода, чтобы добиться наибольшего удобства для пользователей.
Реализация сенсорного управления в приложениях для Windows — это совершенно новое направление (от измерений до анализа и оптимизации). Не всегда можно исходить из того, что если приложение постоянно обновляет сцену, то оно будет быстро реагировать на сенсорные жесты пользователя. В этой статье обсуждаются способы измерения скорости отклика, методы анализа при оптимизации сенсорного управления в системах с архитектурой Intel (IA), а также инструменты, необходимые для анализа проблем, связанных с реагированием приложений на касания.
Помимо времени отклика, важными факторами, влияющими на удобство пользователей, являются использование ресурсов компьютера и время работы от аккумулятора. В этой статье описываются два приложения с различными неполадками, такими как неудовлетворительный отклик (или отсутствие отклика) на касания и высокое потребление электроэнергии. Обе эти неполадки важны для производительности приложения и для удобства пользователей. Затем описывается оптимизация этих приложений для устранения выявленных неполадок.
Почему важно создать хороший сенсорный интерфейс?
Ультрабуки и планшеты получают все более широкое распространение на рынке, а сенсорное управление является одним из важнейших факторов для удобства пользователей. Устройства с сенсорным управлением буквально повсюду: это телефоны, планшеты, ультрабуки и моноблоки. Последние представляют собой настольные ПК, у которых системный блок встроен в заднюю часть монитора. Компания Gartner, занимающаяся ИТ-исследованиями, считает, что к 2015 году свыше 50 % компьютеров, приобретенных для пользователей младше 15 лет, будут оснащены сенсорными экранами [1].
Выпустив Windows 8, корпорация Майкрософт запустила Магазин Windows — это централизованный портал, на котором разработчики публикуют свои приложения, а пользователи могут их приобретать. Если приложение медленно реагирует на сенсорные жесты пользователя, то оно получит плохую оценку в магазине, что, без сомнения, скажется на показателях продаж.
Рисунок 1. Роль программного обеспечения в сенсорном управлении
На рис. 1 показана важная роль программного обеспечения и драйверов: во всем наборе технологий, отвечающих за сенсорное управление, 3 из 5 уровней являются программными (то есть образуют 60 %). Неудовлетворительное время отклика обычно является именно программной проблемой.
Обработка сенсорного ввода
Реализовать поддержку сенсорного ввода и жестов в десктопных приложениях для Windows можно тремя способами. Полную информацию об использовании этих сенсорных API см. в статье «Сообщения и очереди сообщений» [7]. Сообщения WMGESTURE и WMTOUCH обратно совместимы с Windows 7, а сообщения WMPOINTER — нет. У каждого из них есть как достоинства, так и недостатки. Сообщения WMPOINTER проще всего в реализации, но предоставляют меньше всего возможностей управления. Для сообщений WMTOUCH требуется писать наибольший объем кода, но они поддерживают самые широкие возможности управления. Сообщения WMGESTURE по своим характеристикам находятся на промежуточном уровне. Для поддержки сенсорного управления в приложениях для Магазина Windows можно использовать много разных способов — от класса GestureRecognizer, обрабатывающего сенсорный ввод и манипуляции, до API DirectManipulation, которые появились в Windows 8.1.
Экономия электроэнергии за счет оптимизации сенсорного ввода
Еще одним важным фактором удобства программы для пользователей является экономное потребление электроэнергии. Многое зависит от того, сколько электроэнергии потребляет приложение и как оно влияет на длительность работы системы от аккумулятора. Если приложение быстро расходует заряд аккумулятора, пользователи не будут его запускать. Высокое потребление электроэнергии обычно обусловлено значительной нагрузкой на ресурсы системы, т. е. ЦП, ГП и даже устройства хранения данных, выполняющие ненужную работу. В приведенных ниже примерах показаны эти проблемы и подчеркнут дополнительный эффект: зачастую при оптимизации сенсорного ввода также снижается и потребление электроэнергии. Этот дополнительный эффект мы также называем «бонусом за экономию электричества».
Программы для анализа сенсорного ввода в Windows
Для оптимизации сенсорных приложений для Windows можно использовать множество инструментов и программ. Правильное использование всех этих программ для измерения и анализа крайне важно для выявления проблем, связанных с сенсорным управлением. Ниже приводится краткое описание таких программ, их назначение и применимость к определенным аспектам анализа сенсорного ввода.
А. Средства измерения
1. Измерение времени отклика с помощью камеры высокого разрешения
i. Запишите сенсорное взаимодействие на видео, а затем вручную переходите от кадра к кадру для получения значений времени отклика.
2. Системный монитор Windows
i. Входит в состав Windows, позволяет анализировать работу ЦП и выводить другие показатели системы.
ii. Эта программа собирает информацию с шагом в 1 секунду и выводит наглядное представление работы системы при запущенном приложении.
3. Intel® Power Gadget
i. Собирает метрику электропитания, например потребляемую мощность пакета (ЦП и ГП).
4. Регистратор производительности Windows (WPR)
i. Входит в состав Windows 8/8.1 ADK.
ii. WPR обладает пользовательским интерфейсом (WPRUI), дающим возможность выполнять трассировку для сбора определенных метрик работы системы, таких как использование ЦП, операции фиксации виртуальной памяти, потребление электроэнергии и т. п.
5. FRAPS
i. Выдает кадровую скорость приложения (в кадрах в секунду) и работает только в десктопных приложениях.
ii. На веб-сайте заявлена поддержка только Windows 7, но можно использовать и для десктопных приложений под управлением Windows 8/8.1.
Б. Средства анализа
1. Анализатор производительности Windows (WPA)
i. Входит в состав Windows 8/8.1 ADK.
ii. WPA используется для загрузки ETL-файла, созданного программой WPR, поэтому можно выполнять подробный анализ.
2. Intel® VTune™ Amplifier XE 2013
i. Позволяет разработчикам определять, какие функции и модули потребляют слишком много времени.
ii. Дает подробное представление о расписании потоков.
3. Intel® Performance Bottleneck Analyzer (PB A)
i. Предоставляет расширенные возможности анализа для оптимизации скорости отклика программ.
4. GPUView
i. Входит в состав Windows 8/8.1 ADK. Позволяет подробно анализировать работу очереди контекста ЦП и аппаратной очереди ГП. При сборе этой информации используйте в WPRUI параметр трассировки «Работа ГП».
5. Intel® Graphics Performance Analyzer (Intel GPA)
i. Предоставляет информацию о работе графической подсистемы, включая кадровую скорость.
В. Какие вопросы следует задавать при использовании этих программ
1. Intel Power Gadget показывает, что потребляемая мощность пакета (ЦП и ГП) существенно превышает обычную?
2. Анализатор производительности Windows показывает высокую нагрузку на ЦП?
- Экран при этом обновляется?
- Если в нагрузке на ЦП наблюдаются пики, что при этом происходит на экране? Возможно, анимация, которая запускается через каждые 3 секунды, увеличивает нагрузку на ЦП с такой же частотой.
3. GPUView показывает, что очередь ЦП/ГП заполнена?
4. Что Intel Performance Bottleneck Analyzer показывает на временной шкале?
■ Примените фильтрацию по модулю, потребляющему больше всего ресурсов ЦП, и посмотрите, какие происходят действия модуля и потока.
5. Приложение изменило разрешение тактового таймера системы с 15,6 мс (по умолчанию в Windows) на меньшее значение?
■ Если приложение меняет разрешение тактового таймера системы на меньшее значение, например на 1 мс, приложение будет слишком часто выполнять вызовы Update и Draw, из-за чего может быть заполнена очередь контекстов ЦП и очередь ГП.
Теперь перейдем к инструментам, которые были использованы для оптимизации двух описываемых приложений, и ответим на некоторые заданные выше вопросы.
Примеры
Для этих примеров мы использовали камеру высокого разрешения, чтобы получать среднее время отклика порядка 200 мс. В приведенных примерах приложения не только слишком медленно реагировали на касания, но и в некоторых случаях вообще никак не реагировали на них.
Казуальная многопользовательская мультисенсорная игра с замедленным откликом на касания
1. Описание проблемы
У этого десктопного приложения для Windows наблюдаются задержки порядка 170 мс. Хуже того, это приложение зачастую вообще не реагирует на действия пользователя (при жестах не изменяется экран). Поскольку это приложение — спортивная игра, из-за отсутствия реакции на касания часто засчитывался несправедливый результат.
2. Использование различных средств для выявления проблем
Первое использованное нами средство — системный монитор Windows, поскольку он собирает данные о том, что происходит в системе, когда запущено приложение. Если рассмотреть использование приложением ресурсов при отсутствии сенсорных жестов, можно понять, где возникнут узкие места при обработке жестов. Здесь можно увидеть завышенную нагрузку на определенные ресурсы (использование ЦП, скорость переключения контекста, скорость прерываний и пр.), если она составляет 100 % или превышает пороговые значения, полученные в ходе анализа прежних нагрузок.
Рисунок 2.Приложение бездействует, ЦП загружен на 100 %
На рис. 2 показано, что одно ядро ЦП (процессор 0) загружено на 100 %. Это означает, что одноядерное приложение израсходовало все ресурсы процессора при обновлении изображения, которое не изменяется визуально.
Следующая программа — Intel Power Gadget — использовалась для того, чтобы оценить влияние полной загрузки приложением одного ядра ЦП. Мы открыли командную строку от имени администратора, перешли в папку установки и ввели команду:
PowerLog3.0.exe -duration <длительность выполнения в секундах> -file <файл журнала.csv>
После выполнения команды мы ввели имя файла журнала и нажали клавишу «Ввод». На рис. 3 показано потребление электроэнергии пакетом (ЦП и ГП) в период, когда приложение было запущено, но не обрабатывало сенсорные команды. По оси X — частота выборки, с которой программа читала показатели MSR, а по оси Y — потребляемая мощность процессора в Вт [3].
Рисунок 3.Потребление электроэнергии пакетом (ЦП и ГП) в режиме бездействия, Вт
Такое же поведение наблюдалось при выполнении сенсорных жестов, как показано в графиках нагрузки на ЦП, причем уровень потребляемой мощности оставался примерно одинаковым и при обработке жестов, и без жестов. Это явно указывает на то, что что-то потребляло все ресурсы, из-за чего реакция на касания была затруднена. Пока приложение не было запущено, потребляемая мощность системы составляла около 2,5 Вт. Это означает, что приложение вызвало увеличение потребляемой мощности на 9 Вт. Что же привело к повышению мощности, потребляемой ЦП и ГП, на 9 Вт?
Затем мы использовали программу Intel GPA, которая показала 350 кадров в секунду, когда приложение не обрабатывало сенсорные жесты, и 210 кадров в секунду при обработке сенсорных жестов. Этот вопрос постоянно обсуждается, но принято считать, что человеческий глаз не может отличить отрисовку со скоростью 60 кадров в секунду от скорости 120 кадров в секунду. Это означает, что, с точки зрения пользователя, изображение при 60 кадрах в секунду было бы точно таким же, как при 210 кадрах в секунду.
Затем мы использовали GPUView и определили, что эта сверхвысокая кадровая скорость привела к заполнению очереди ГП, поскольку приложение пыталось как можно скорее отправить задание в конвейер ГП. На рисунке показаны строки пакетов, отмеченных двойным знаком решетки, который указывает, что существующий пакет готов к отображению на экране. И вся эта деятельность происходила, когда приложение отображало неподвижный экран.
Рисунок 4. Снимки экрана GPUView с заполненными очередями ГП/ЦП
Что привело к загрузке ЦП на 100 % и к заполнению очередей ЦП/ГП?
Мы использовали программу WPRUI, выбрав трассировку только использования ЦП, чтобы снизить издержки, вызванные самой этой программой. При анализе программ, находящихся в состоянии бездействия, следует учитывать и издержки программы, применяемой для анализа. На этом этапе мы уже знали, что приложение заполняло очереди ЦП/ГП. Итак, что вызывалось перед графическим модулем? Изучив стек вызовов к графическому модулю, мы обнаружили возможную причину бесполезной работы.
Рисунок 5.Стек вызовов приложения
Изучив стек вызовов, показанный на рис. 5, мы обнаружили, что метод Game::Tick вызывался перед вызовом D3D9 Present, который обращался к графическому модулю igdumd32.dll. Этот метод Game::Tick непреднамеренно задал разрешение тактового таймера системы равным 1 мс вместо 15,6 мс, принятого в Windows по умолчанию. См. рис. 6.
Рисунок 6.Метод Game::Tick изменил разрешение тактового таймера системы
Поэтому приложение выполняло вызовы Update и Draw через каждую 1 мс, то есть при вызове метода Game::Tick. Вызов этих методов каждую миллисекунду также приводил к слишком частому пробуждению ЦП, который не переходил в состояния более глубокого сна (С-состояния), а также к ненужному повышению нагрузки на ГП.
3. Результат
Существуют API, с помощью которых можно запретить приложению изменять разрешение тактового таймера системы и синхронизировать приложение с частотой вертикальной развертки экрана (Vsync). После использования этих API мы добились того, что ЦП больше не тратил 100 % времени своей работы на вызовы Update и Draw.
Рисунок 7. Использование ЦП после оптимизации
Поскольку ЦП больше не выполнял ненужные расчеты Update и вызовы Draw каждую миллисекунду, очередь контекстов ЦП и очередь ГП уже не были заполнены. На снимке экрана на рис. 8 показана работа при 60 кадрах в секунду, поскольку частота вертикальной развертки экрана составляла 60 Гц.
Рисунок 8.Работа оптимизированных очередей ЦП и ГП
Кадровая скорость приложения была теперь ограничена 60 кадрами в секунду, поскольку пакеты присутствия передавались синхронно с частотой вертикальной развертки монитора, составляющей 60 Гц. За счет оптимизации потребления приложением ресурсов при бездействии (изображение на экране не меняется, сенсорные жесты не обрабатываются) нам удалось добиться более плавного и быстрого реагирования на касания. Среднее время отклика оптимизированного приложения составило около 110 мс (тогда как ранее оно составляло около 170 мс), причем касания уже не пропускались (ранее приложение иногда на них вообще не реагировало).
Дополнительный выигрыш: потребляемая пакетом мощность сократилась на 8,5 Вт. Теперь пользователи могли дольше играть в эту игру на мобильном устройстве без подзарядки.
Подведем итоги: поведение бездействующего приложения может привести к переполнению конвейера обработки касаний. После оптимизации у приложения появилось больше свободных ресурсов для обработки жестов, поэтому задержки обработки касаний сократились.
Трехмерная казуальная игра с исчезновением реакции на касания
1. Описание проблемы
В этом примере мы рассматриваем трехмерную игру для десктопного режима Windows 8, использующую сообщения WMTOUCH для обработки сенсорного ввода. В ходе игры пользователь проводит по экрану в разные стороны, чтобы игровой персонаж выполнял различные действия (прыгал, скользил, приседал и пр.). Если никакие жесты не выполняются, то игровой персонаж все время просто бежит по заданному направлению.
В начальной версии игры при выполнении двух типов сенсорных жестов игровой персонаж не выполнял нужных действий, а продолжал по-прежнему бежать вперед.
- При последовательном выполнении двух жестов, если интервал времени между ними был слишком мал, на второй жест игра обычно не реагировала.
- Если протяженность жеста на сенсорном экране была слишком мала, то игра на такие жесты не реагировала.
2. Использование различных средств для выявления проблем
- Изоляция проблемы. Определите, с чем связаны проблемы отклика на касания — с приложением или с платформой (оборудование, драйвер, ОС). Здесь рекомендуется запустить WPR, переключиться в приложение и выполнять одиночный жест касания в определенные моменты в ходе сбора данных, чтобы события касания и их длительность наглядно отображались при анализе.
Рисунок 9.Касания с откликом и касания без отклика
Вручную запишите события касания с откликом и без отклика. С помощью процесса, отслеживающего регистрацию касаний, мы смогли отметить, когда ОС регистрирует касания, найдя функции обработки сообщений в стеке вызовов, как показано на рис. 9 (фиолетовые пики).
- Сравнение стеков вызовов «правильной» и «неправильной» работы интерфейса. Сравнение различных аспектов касаний, на которых есть отклик (правильная работа), и касаний без отклика (неправильная работа) часто показывает различия в том, какие функции вызываются приложением.
Мы изучили стеки вызовов, содержащие FrameMove(), поскольку именно эта функция, исходя из ее названия, обновляет изображение на экране. В стеке вызовов «правильной работы» вызывается функция AvatarMovesToTheLeft::FrameMove, а при «неправильной работе» она не вызывается (см. рис. 10).![]()
Рисунок 10.Стеки вызовов при касаниях с откликом и касаниях без отклика
- Трассировка стеков вызовов. С помощью трассировки стека вызовов «неправильной работы» мы определили место нарушения цепочки вызовов. Вызывались функции обработки сообщений Windows, в том числе PeekMessage, DispatchMessage, и даже функция игры WndProc. Это подтвердило, что весь сенсорный ввод был получен функцией обработки сообщений приложения, но функции xxxSlideLeftState или xxxSlideRightState, задающие режим бега игрового персонажа для предполагаемой команды, не были вызваны (см. рис. 11)..
Рисунок 11.Стек вызовов обработки сообщений при «неправильной работе»
3. Результат
A. Причина отсутствия отклика на быстрый последующий жест состоит в том, что игра реагирует на жесты только в том случае, если игровой персонаж находится в состоянии «бег вперед». Если же он в другом состоянии, сенсорный ввод не обрабатывается. Например, после первого жеста состояние игрового персонажа изменяется с «бег вперед» на «скольжение вправо». Если второй жест будет выполнен раньше, чем состояние вернется к «бегу вперед», этот жест не будет обработан. Эту проблему удалось устранить путем кеширования сенсорных сообщений для соответствующего режима бега.
Б. Причина отсутствия отклика на короткие жесты была связана с функцией игры WndProc. Игра распознавала сенсорный жест только в случае, если его протяженность превышала 60 логических пикселей. Поэтому некоторые короткие жесты не обрабатывались. При одинаковом разрешении 60 логических пикселей на экране ультрабука соответствуют большему физическому расстоянию, чем на экране iPhone. Из-за этого короткие жесты в игре, перенесенной с платформы iPhone на ультрабук, будут с большей вероятностью неверно обрабатываться на экране ультрабука. Решение же состоит в том, чтобы установить пороговое значение для протяженности жеста на основе физического расстояния на экране, вычисляемого на основе количества точек на дюйм (DPI), а не логических пикселей.
Подведем итоги. Нам удалось определить, где возникают проблемы (на уровне приложения или на уровне платформы) путем сравнения вызовов API сообщений Windows для определения регистрации касаний операционной системой. Затем мы сравнили стеки вызовов жестов с ожидаемым откликом (правильная работа) и жестов без отклика (неправильная работа), чтобы определить различия в вызываемых функциях. И наконец, мы провели трассировку стека вызовов обработки сообщений, чтобы найти, где именно прерывается цепочка вызовов. Начало трассировки стека вызовов было в функциях, вызывавшихся из стека «правильной работы».
Заключение
Оптимизация сенсорного управления крайне важна, и для измерений и анализа в этой области доступно множество инструментов. Помните о необходимости иметь эталонную точку (базовую линию), с которой можно было бы сравнивать данные, полученные при работе приложения. Изучайте различия в данных, полученных, когда приложение просто запущено и когда приложение получает сенсорные жесты. Сравнивайте поведение приложения в случаях, когда оно реагирует на жесты и когда не реагирует.
Не всегда можно исходить из того, что если приложение постоянно обновляет сцену, то оно будет быстро реагировать на сенсорные жесты пользователя. Сцену следует обновлять лишь при необходимости, чтобы не расходовать впустую ресурсы системы, которые можно использовать для быстрого отклика на жест. Зачастую бесполезное обновление сцены с малозначимой анимацией приведет к заполнению очередей сообщений Windows, очередей ЦП или ГП, что может привести к значительным задержкам наглядного отклика на касания.
Справочные материалы
[1] Fiering, Leslie. Компания Gartner утверждает, что к 2015 году свыше 50 % ПК, приобретенных для пользователей младше 15 лет, будут оснащены сенсорными экранами. Gartner, 7 апреля 2010 г. Веб. 3 марта 2014 г.
[2] Chabukswar, Rajshree, Mike Chynoweth, Erik Niemeyer. Intel® Performance Bottleneck Analyzer.Корпорация Intel, 4 августа 2011 г. Веб. 12 февраля 2014 г.
[3] Seung-Woo Kim, Joseph Jin-Sung Lee, Vardhan Dugar, Jun De Vega. Intel® Power Gadget.Корпорация Intel, 7 января 2014 г. Веб. 25 марта 2014 г.
[4] Freeman, Jeffrey M. Вопросы и ответы по Intel Graphics Performance Analyzers (Intel GPA).Корпорация Intel, 17 декабря 2013 г. Веб. 25 марта 2014 г.
[5] H, Victor. «Смартфоны iPhone обладают наивысшей скоростью отклика на касания, более чем вдвое по сравнению с устройствами Android и Windows Phone».Phone Arena. Phonearena, 1 октября 2013 г. Веб. 26 марта 2014 г.
[6] Комплект средств для развертывания и оценки Windows (Windows ADK).Корпорация Майкрософт, 2 апреля 2014 г. Веб. 3 апреля 2014 г.
[7] Сообщения и очереди сообщений.Корпорация Майкрософт, 24 января 2012 г. Веб. 26 марта 2014 г.
[8] Intel® VTune Amplifier XE 2014.Корпорация Intel, 6 марта 2014 г. Веб. 3 апреля 2014 г.
[9] Fraps 3.5.99. Fraps, 26 февраля 2013 г. Веб. 3 апреля 2014 г.
Материалы по теме
Создание удобного сенсорного интерфейса и оптимизация элементов управления для сенсорного ввода