一、背景

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

二、案例介绍

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

修复前

修复后

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

在前期的调研中，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线程

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

结合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