Windows 应用程序的触摸响应测量、分析和优化

Tom Pantels

0/5 (0投票)

2014年5月28日

CPOL

17分钟阅读

20086

本文介绍了两个应用程序，它们展示了触摸响应时间差或无响应以及高能耗等问题，这两者都对应用程序性能和用户体验至关重要。然后，我们将讨论如何优化这些应用程序以解决这些问题。

引言

用户体验 (UX) 是当今产品的制胜法宝。虽然其他功能在设备的功能性中也很重要，但任何功能都无法弥补感知到或实际存在的响应和易用性方面的不足。自 Windows 8 推出以来，触摸手势已成为与基于 Windows 的超极本™ 设备、平板电脑和手机进行交互的主要方式。这些系统的实用性部分取决于触摸如何改善用户体验 (UX)，进而取决于触摸界面的速度和响应能力对 UX 质量的影响。

触摸响应时间是从用户开始移动手指执行触摸手势到应用程序提供用户期望的手势视觉更新的那一刻之间的延迟。触摸响应以非常小的采样时间 (100-500 毫秒范围) 进行测量。识别和优化性能较差的触摸响应区域对于实现最佳用户体验至关重要。

对于 Windows 应用程序而言，触摸功能实现是一个全新的领域——从测量到分析和优化。一个不总是正确的假设是，如果一个应用程序一直在更新场景，它就能快速响应用户的触摸手势。本文讨论了测量触摸响应的方法、在 Intel® 架构 (IA) 上进行触摸优化的分析方法，以及理解与触摸响应相关的问题所需的工具组合。

除了触摸响应时间，计算机资源利用率和电池寿命是影响用户体验的非常重要的因素。本文介绍了两个应用程序，它们展示了触摸响应时间差或无响应以及高能耗等问题，这两者都对应用程序性能和用户体验至关重要。然后，我们将讨论如何优化这些应用程序以解决这些问题。

为什么实现良好的触摸用户体验很重要？

超极本设备和平板电脑在市场上的普及率不断增长，触摸是提供良好用户体验 (UX) 的基本支柱之一。如今，触摸屏设备无处不在，从手机、平板电脑、超极本到一体机 (AIO)——它们是将机箱集成到显示器背面的台式电脑。IT 研究公司 Gartner 预计，到 2015 年，购买给 15 岁以下用户的 PC 中，将有超过 50% 配备触摸屏 [1]。

通过 Windows 8，微软建立了 Windows 应用商店，它充当一个中心化的触摸驱动枢纽，供开发人员发布应用程序，供消费者购买。如果应用程序对用户的触摸手势有明显的延迟，该应用程序可能会获得差评，这无疑会影响其销量。

图 1. 软件在触摸堆栈中的作用

图 1 显示了软件和驱动程序在触摸响应能力中的关键作用，其中 5 层中有 3 层属于软件堆栈（占约 60%）。糟糕的触摸响应能力通常是软件堆栈中的问题。

触摸处理

Windows 桌面应用程序有三种方式支持触摸输入和手势。要全面了解这些触摸 API 的用法，请阅读“关于消息和消息队列”[7]。WM_GESTURE 和 WM_TOUCH 消息都向后兼容 Windows 7，而 WM_POINTER 消息则不兼容。每种消息都有优缺点。WM_POINTER 最易于实现，但控制力最弱。WM_TOUCH 需要的代码最多，但允许非常精细地控制，而 WM_GESTURE 则处于中间状态。Windows 应用商店应用程序支持触摸的许多方法都可以使用，从处理触摸输入和操作的 GestureRecognizer 类到使用 Windows 8.1 中引入的 DirectManipulation API。

优化触摸带来的节能红利

能源是提供卓越用户体验的另一个重要支柱。应用程序的可用性受其消耗的能量以及它对电池寿命的影响。如果应用程序迅速耗尽能量，用户将不愿意运行它。高能耗通常源于对系统资源的重度使用，即 CPU、GPU 甚至存储设备执行不必要的工作。下面的案例研究展示了这些问题，并强调了在优化触摸处理功能时通常会看到的次要效果，即应用程序的能耗降低。这种降低能耗的次要效果就是我们所说的“节能红利”。

用于触摸分析的 Windows 工具

许多工具可用于帮助您优化基于 Windows 的触摸应用程序。理解每种工具的测量和分析用途对于查明与触摸相关的问题至关重要。以下是对工具的简要描述、它们 intended 的用途以及与触摸分析特定方面的相关性。

测量工具
1. 使用高分辨率相机测量响应时间
  1. 录制触摸交互的视频，逐帧手动回放以获得响应时间。
2. Windows PerfMon
  1. 预装在 Windows 中，用于查看 CPU 和其他系统统计信息。
  2. 此工具以一秒为粒度收集数据，并提供应用程序运行时系统行为的概述。
3. Intel® Power Gadget
  1. 收集功耗/能耗指标，例如封装（CPU 和 GPU）功耗。
4. Windows Performance Recorder (WPR)
  1. 随 Windows 8/8.1 ADK 一起提供。
  2. WPR 具有用户界面 (WPRUI)，允许执行跟踪以收集特定的系统指标，例如 CPU 利用率、虚拟内存提交、功耗等。
5. FRAPS
  1. 报告应用程序的渲染速率 (FPS)，仅适用于桌面应用程序。
  2. 尽管网站声称它仅支持到 Windows 7，但您可以在 Windows 8/8.1 桌面应用程序上使用它。
分析工具
1. Windows Performance Analyzer (WPA)
  1. 随 Windows 8/8.1 ADK 一起提供。
  2. WPA 用于加载 WPR 生成的 .etl 文件，以便进行深入分析。
2. Intel® VTune™ Amplifier XE 2013
  1. 允许开发人员了解哪些函数/模块最耗时。
  2. 提供线程调度的详细视图。
3. Intel® Performance Bottleneck Analyzer (PBA)
  1. 提供响应能力优化的高级分析功能。
4. GPUView
  1. 随 Windows 8/8.1 ADK 一起提供，并深入了解 CPU 上下文队列和 GPU 硬件队列之间发生的情况。收集此信息时，请使用 WPRUI 跟踪选项“GPU 活动”。
5. Intel® Graphics Performance Analyzer (Intel® GPA)
  1. 提供有关系统图形活动的信息，包括帧速率。
使用这些工具时需要问的问题
1. Intel Power Gadget 报告的封装（CPU 和 GPU）功耗是否远大于基线？
2. Windows Performance Analyzer 是否显示 CPU 使用率很高？
  - 场景是否有任何视觉更新？
  - 如果 CPU 使用率出现峰值，屏幕上发生了什么？也许每三秒发生一次的动画会导致 CPU 使用率每三秒增加一次。
3. GPUView 是否显示 CPU/GPU 队列已满？
4. Intel Performance Bottleneck Analyzer 在时间线视图中显示什么？
  - 按消耗 CPU 时间最多的模块进行筛选，并查看正在发生的模块/线程活动。
5. 应用程序是否将系统计时器滴答分辨率从 15.6 ms (Windows 默认) 更改为更小的值？
  - 如果应用程序将系统计时器滴答分辨率更改为更小的值，例如 1 ms，应用程序将过于频繁地执行 Update 和 Draw 调用，这可能会导致 CPU 上下文队列和/或 GPU 队列堆积。

现在，让我们看看这些工具是如何用于优化两个应用程序并回答上述一些问题的。

案例研究

对于这些特定的案例研究，我们使用高分辨率相机方法获得了约 200 ms 的平均响应时间。在这些情况下，应用程序不仅触摸响应缓慢，而且经常完全无法响应触摸手势。

一款具有糟糕触摸响应的休闲多人多点触控游戏应用程序

1. 问题陈述

这款 Windows 桌面应用程序的延迟约为 170 毫秒。但更糟糕的是，该应用程序经常根本没有响应（手势没有视觉更新）。由于这是一款体育游戏，这些触摸响应问题经常会导致不公平的计分。

2. 使用工具识别问题

我们使用的第一个工具是 Windows Perfmon，因为它收集的数据提供了应用程序运行时系统上发生情况的概述。查看应用程序在未执行触摸手势时的资源利用率，可以了解在发生触摸时导致大部分瓶颈的原因。我们可以在这里看到，CPU 使用率、上下文切换率、中断率等资源是否已经达到最大值（100% 利用率）或超过了根据先前工作负载分析获得阈值。

图 2. 应用程序空闲时，CPU 使用率达到 100%

图 2 显示单个 CPU 核心（处理器 0）被 100% 时间占用，这意味着这个单核应用程序在更新视觉上不变的场景时受 CPU 限制。

下一个工具 Intel Power Gadget 用于了解应用程序始终占用单个 CPU 核心 100% 所带来的影响。我们以管理员身份运行命令提示符，导航到安装目录，然后输入

PowerLog3.0.exe –duration <duration to run for in seconds> –file <log_file.csv>

运行命令后，我们键入 log_file.csv 的名称并按 Enter。图 3 显示了应用程序运行时和未处理触摸交互时系统的封装（CPU 和 GPU）功耗。x 轴是读取能量 MSR 的采样率，y 轴是处理器的功率（瓦特）[3]。

图 3. 应用程序空闲时封装（CPU 和 GPU）功耗（瓦特）

当执行触摸手势时，即使在有无触摸交互时功耗几乎相同的情况下，也发生了与 CPU 使用率图表中相同的行为。这清楚地表明有某些东西消耗了所有资源，使得触摸难以响应。应用程序未运行时系统的功耗约为 2.5 W，这意味着应用程序导致功耗增加了 9 W。是什么导致了这 9 W 的 CPU 和 GPU 功耗增加？

接下来，使用 Intel GPA，在应用程序不处理触摸手势时报告的渲染速率约为每秒 350 帧 (FPS)，而在执行触摸手势时约为每秒 210 帧。虽然这是一个持续的争论点，但普遍的共识是，人眼通常无法区分一个以 60 FPS 渲染的应用程序和一个以 120 FPS 渲染的应用程序之间的差异。这意味着用户在屏幕上看到的视觉更新将与应用程序以 60 FPS 渲染时相同。

接下来，使用 GPUView，它显示了高渲染速率导致 GPU 队列已满，因为应用程序正试图尽快将作业提交给 GPU 流水线。图 4 显示了带有双哈希标记的包行，这表示一个已准备好显示在屏幕上的 present 数据包。这种活动发生在应用程序显示一个没有视觉更新的屏幕时。

图 4. GPUView 工具生成的已满 GPU/CPU 队列的屏幕截图

是什么导致 CPU 使用率为 100% 且 CPU/GPU 队列堆积？

接下来使用 WPRUI，仅选择了 CPU 使用率跟踪选项以减少工具造成的开销。在收集空闲场景数据时，请考虑工具本身造成的开销量。此时，我们知道该应用程序正在导致 CPU/GPU 队列堆积，那么在图形模块之前调用了什么？通过检查应用程序到图形模块的调用堆栈，我们找到了一些关于导致这种不必要工作的调用的线索。

图 5. 应用程序的热调用堆栈

检查图 5 中的调用堆栈，发现在调用 D3D9 Present 调用之前不久调用了一个 Game::Tick 方法，该方法最终导致了图形模块 igdumd32.dll。这个 Game::Tick 方法无意中将系统的计时器滴答分辨率从 15.6 ms（Windows 默认）更改为 1 ms。参见图 6。

图 6. Game Tick 方法更改系统计时器分辨率

因此，每 1 毫秒，应用程序就会执行 Update 和 Draw 调用，因为这是 Game::Tick 被调用的时间。每毫秒调用这些方法还意味着 CPU 经常唤醒，不会进入更深的睡眠状态 (C-states)，并且 GPU 的忙碌程度超过了必要。

3. 最终结果

提供了 API 来确保应用程序不会更改系统的计时器滴答分辨率，并且应用程序已与 Vsync 同步。在使用这些类型的 API 后，CPU 不再将 100% 的执行时间花在 Update 和 Draw 调用上。

图 7. 优化后的应用程序 CPU 使用率

由于 CPU 不再每毫秒执行不必要的 Update 计算和 Draw 调用，CPU 上下文队列和 GPU 队列不再堆积。图 8 中的屏幕截图显示，由于显示器的刷新率为 60 Hz，因此以 60 FPS 提交工作。

图 8. 优化后的应用程序 CPU 和 GPU 队列活动

现在，应用程序的渲染速率被限制在 60 FPS，因为在具有 60 Hz 刷新率的显示器上，每个 Vsync 都会提交一个 present 数据包。通过优化应用程序在空闲场景（屏幕无视觉变化且未处理触摸手势）下的资源消耗，触摸响应更快、更流畅。优化后应用程序的平均触摸响应时间约为 110 毫秒，而之前平均约为 170 毫秒，并且不再丢失触摸（应用程序无响应）。

作为一项额外的好处（节能红利），该系统的封装功耗降低了约 8.5 W。现在用户可以在他们喜欢的 Windows 移动设备上更长时间地玩该应用程序，而无需充电。

总之，空闲应用程序的行为可能导致应用程序淹没触摸处理管道。通过优化版本，应用程序拥有更多的余量来处理额外的触摸手势，从而降低了触摸延迟。