游戏显示九十多帧，却在转身或进入新区域时突然停一下，平均 FPS 并没有失效，只是它回答的问题比较粗：这段时间总共生成了多少帧。每一帧是否按接近相同的节奏到来，需要另看时间分布。
要分析这种体验，先看帧时间，再判断哪里值得继续测。仅凭一个瓶颈百分比或一次 GPU 占用率下降，还不能决定换哪块硬件。
一次长帧，可以藏在不错的平均值里
在均匀输出的理想情况下，帧间隔毫秒数约等于 1,000 ÷ FPS。因此，60 FPS 对应约 16.67 ms，120 FPS 对应约 8.33 ms。这是时间换算，不是某台电脑的测试成绩。
假设连续记录 100 帧，其中 99 帧各耗时 10 ms，另有一帧耗时 100 ms。总时间是 99 × 10 + 100 = 1,090 ms，以总帧数除以总时长计算，帧率约为 91.74 FPS。平均数字看起来不低，但其中仍有一次明显更长的等待。
图：人工构造的帧时间演算与复核流程；不是游戏跑分截图。
逐帧瞬时FPS的算术平均，与总帧数除以总时长的结果也有区别。采样区间、加载画面是否计入，以及工具选用的统计口径，都会改变最终数字。
这里还有一个比“最低帧数”更直观的量：慢帧占用了多少时间。假设60秒记录中有6次各100 ms的长帧，单是这6帧就占去0.6秒，即整段时间的1%。这仍是人工演算，但它能保留百分位数可能略去的少量停顿。
图：100帧的人工样本。横轴是帧序号，不是等距时间；第50帧耗时100 ms，其余99帧各10 ms。
先弄清楚记录的是哪一种帧
NVIDIA 的 FrameView 官方说明列出帧率、帧时间、功耗等记录能力，并支持把结果写入日志。[1] 它能帮助保留事件发生时的数据，但记录工具本身无法证明“这就是 CPU 瓶颈”。
比较两份报告前，检查它们统计的是渲染帧还是显示帧，帧生成是否开启，垂直同步和帧率上限是否相同。生成帧与基础渲染帧混在一起比较，数字变大也不一定意味着输入响应按同样比例改善。显示链路的问题还可能在渲染日志之外，所以日志平稳也不能排除所有视觉卡顿。
“1% low”适合辅助观察低帧表现，但不同软件可能采用不同计算方法。引用这个数字时，应同时保留工具名称、版本、指标定义和录制时长；不要默认它就是最慢一帧，也不要把不同工具的数值拼成排行榜。
CapFrameX 的指标说明特意区分了按帧排序的百分位与持续时间。[3] 比如“99%的帧达到某个门槛”，不能严格改写成“99%的游玩时间都很流畅”：少量慢帧本身可能占去较长时间。它还讨论了百分位值与最慢一部分帧的汇总方法，所以报告中只有“1% low”标签而没有算法说明时，应保留这个缺口。
日志里哪些字段值得一起看
打开CSV，先核对表头。PresentMon 的控制台文档列有以下字段定义；实际输出取决于版本和采集参数。[2]
| 字段 | 文档含义 | 能帮助回答的问题 |
|---|---|---|
MsBetweenPresents |
相邻两次Present调用的时间间隔 | 应用提交节奏有没有突然拉长 |
MsCPUBusy |
CPU在本帧提交前工作的时间 | 长帧附近CPU侧工作是否变化 |
MsGPUBusy |
GPU为目标进程该帧执行工作的活跃时间 | 图形工作是否随场景变重 |
DisplayLatency |
从本帧开始到显示的时间 | 等待是否出现在显示链路中 |
DisplayedTime |
本帧在屏幕上的显示时长；未显示可记为NA | 某帧是否持续显示较久 |
这些时间描述不同区段，CPU与GPU又可能并行处理工作，不应把几列直接相加，要求它恰好等于一帧总时长。MsGPUBusy也不是任务管理器的GPU利用率百分比。先按列定义读数据，才能判断两个数字是否适合比较。
若提交间隔拉长，同时GPU活跃时间明显增加，图形工作值得进一步检查；若GPU活跃时间短而等待较长，锁帧、CPU供给或调度都可能参与其中。后者只缩小排查范围，不能直接判为CPU性能不足。项目文档还列有不同API和硬件调度下的测量限制，缺失或受限字段应保留原状。[4]
用一次可重复的短路线保留证据
选一段能重复走过的路线，固定分辨率、画质、视角移动方式与帧率限制。先记录原始设置，再开始日志采集，结束后保存文件。给文件写上游戏版本、显卡驱动、测试场景和设置，便于下一次对照。
观察尖峰时，记下它发生在什么位置：第一次进入区域、突然转动镜头、后台程序启动，还是经过同一地点每次都出现。同步查看可用的 CPU、GPU、内存和存储指标，但不要把没有采集到的传感器字段填成零。
先重复三次，分别保存结果。若差别很大，核对场景、温度、缓存和后台任务，再决定是否延长或增加测试。只选最好的一次，会把需要解释的波动删掉。
以下是一份起步记录模板。60秒和3次是演示安排，不保证对所有游戏都足够。
| 记录项 | 示例写法 |
|---|---|
| 片段 | 固定存档出发，沿同一路线走60秒 |
| 冷启动记录 | 第一次进入场景，单独保留 |
| 重复记录 | 同设置3次，分别保存CSV |
| 排除部分 | 菜单、加载页是否计入，在开测前决定 |
| 本轮变量 | 只降低阴影档位，其余不变 |
冷启动与已经走过一次的场景可以分别比较。首次载入卡顿也应有对应记录；若要比较持续运行的图形负载，又不能把一组首次载入与另一组预热后的记录混在一起。
PresentMon 提供按进程名选择采集对象、设定采集时长和指定CSV输出文件等选项。[2] 使用图形界面或命令行都应先确认目标进程，避免把启动器和游戏的帧混入同一组统计。这里没有执行实际游戏采集，配图均为指标演算。
每次只改变一个条件
若怀疑图形负载，降低一项明确的渲染负担，再跑同一路线。若怀疑后台干扰，关闭一个已知程序后复测。不要同时换驱动、降画质、解锁帧率和重启游戏，否则改善后很难判断哪个变化起了作用。
降低画质后平均 FPS 上升，而同一处尖峰仍然存在，说明平均渲染负担与该次卡顿可能不是同一个问题。第一次经过时卡、以后减轻，可能与资源加载或缓存有关，但仅有这种现象还不够锁定原因。GPU 利用率低也可能来自锁帧、等待 CPU 或其他限制，不能直接解读成显卡性能不足。
最终值得保存的结论应具体到条件，例如“同一路线的三次记录都在进入区域时出现尖峰，降低阴影后尖峰仍在”，而不是“电脑有 30% 瓶颈”。继续测试时，可以直接检查尖峰位置和降低阴影后的差别，而无需从头猜测。
参考资料
-
NVIDIA FrameView 官方页面。可记录帧率、帧时间与日志；不代表本次实测、所有显卡功耗字段一致或已安装软件。
-
PresentMon Console Application官方文档。2026-09-27读取main分支快照；定义CSV字段、采集进程和时长选项；版本不同字段会变，不代表进行了本机采集。
-
CapFrameX：Explanation of different performance metrics。Taxxor，2020-05-31；解释百分位和x% low的区别。引用指标思想，不把旧版本界面作为当前截图。
-
PresentMon项目说明及限制。2026-09-27核对；图形API与硬件调度等可影响测量，记录环境而非直接推断瓶颈。
