扒一扒 UI 卡顿的那些事

一、背景

PC 端的测试过程中会碰到一些性能问题，例如 UI 卡顿，内存泄漏等等，为了找到原因，做了很多的调研和尝试，也总结了一些方法。本文以一个企点融合工作台测试中发现的案例说明如何获得 UI 卡顿数据，以及如何分析数据，定位问题

二、案例介绍

点击工作台拨号盘时，数字按钮的响应可以感觉到明显的卡顿。以下是修复前和修复后的效果对比

修复前

修复后

三、工具介绍

目前业界用的比较多的 Windows 性能测试工具主要有：

• WPT(Windows performance toolkit)：微软官方的性能测试工具，集成在 Windows SDK 中

• UIforETW：开源工具，下载地址

在前期的调研中，WPT 可以说是 “举步维艰“，而 UIforETW 则是“纵享丝滑”，基于以下原因，最终选择了 UIforETW:

其实无论是 WPT 还是 UIforETW 都是基于 Xperf 的工具，而 Xperf 的基础又是 ETW（Event Tracing for Windows），ETW 是一个生产者消费者模式的系统，它提供了内核级的事件跟踪能力。

ETW 有三个成员组成：

1.Controllers，负责启动停止 Event Tracing Session，负责启用停止 Providers。

2.Providers，负责向 Event Tracing Session 中输出事件。

3.Consumers，从 Event Tracing Session 中获取事件。

具体的原理请参考 Xperf 原理

四、案例分析

只要 UI 线程 Delay 时间超过 200 ms，Microsoft-Windows-Win32k Provider 就会记录事件，并在 UI Delay 图中显示

1、测试场景

鼠标点击工作台拨号盘任意数字按钮 5 次

2、数据获取

点击 Start Tracing 后，复现卡顿现场，接着点击 Save Trace Buffers 即可，生成的数据文件显示在 Traces 栏

双击打开数据文件，左侧的 Graph Explorer 展示了获取到的图形列表，包含了 System Activity，CPU Usage，File I/O 等，找到 UI Delay 图形

双击大图展示如下：

从图中可以看到，QiDian(7320)的 3840 线程总共有 5 次卡顿，每次卡了约 0.5s，共约 2.7s

3、卡顿分析

选择 5 次卡顿的任意一次进行分析，打开 CPU（Precise）图形，找到 QiDian.exe（7320）和 3840 线程

简单介绍一下图中表格列的含义：

• New Thread Id： 即将开始执行线程（即将切换到运行状态的线程）Id

• New Thread Stack ：即将开始执行线程的调用栈

• Time Since Last ：线程处于准备状态和等待状态的时间和

• Count：上下文切换次数

• CPU Usage(in view):CPU 耗时

结合 UI Delay 图和 CPU 图形可知，线程 3840 卡了约 0.5 s，其中只有 10 ms 消耗了 CPU，所以这个线程是空闲挂起状态。

为了查看具体的调用栈，在 Trace 下配置 PDB 符号表路径并加载符号表

将 Time Since Last 排序后，查看 New Thread Stack 列，依次展开

可以很清楚的看到，上图中 CCicEvent:Wait 进行了 1 次上下文切换, 将 UI 线程从 533 ms 的挂起的状态切换到运行状态

继续往 New Thread Stack 的上面看，从图中可以很清楚的看到，企点应用层调用了 LoadKeyboardLayoutW 方法，消耗了约 0.54 s

找到源代码：

通过分析得知，这部分代码是开关输入法，由于工作台拨号盘限制输入的类型为英文，所以在点击按钮时会调用 LoadKeybordLayout 和 ActivateKeyboardLayout 装载并激活输入法，导致了 UI 上的卡顿。

定位原因后，解决方案：直接在输入法编辑状态过滤，避免开关输入法

五、总结

本文以一个案例介绍了如何分析客户端卡顿问题的思路和方法，另一方面，Windows 性能问题除了 UI 卡顿外，还包括内存泄漏，磁盘读取等等，而 UIforETW 是一个十分强大的工具，对其他的 windows 性能问题也能够很好的支持,目前对它的了解只是冰山一角，还需要继续的探索和实践。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/yGCttxA6AhhRTYxCSDI0GQ