124 lines
8.1 KiB
Markdown
124 lines
8.1 KiB
Markdown
---
|
||
title: "如何正确高效的查找游戏「卡顿」原因？"
|
||
source: "知乎"
|
||
url: "https://www.zhihu.com/question/28824284/answer/1965456096262096583"
|
||
date: 2026-06-10 22:23
|
||
tags: [zhihu, saved]
|
||
---
|
||
|
||
# 如何正确高效的查找游戏「卡顿」原因？
|
||
|
||
> 来源：知乎
|
||
> 链接：https://www.zhihu.com/question/28824284/answer/1965456096262096583
|
||
|
||
---
|
||
|
||
专栏文章汇总，持续更新：
|
||
|
||
高通 Adreno GPU 最佳实践 0--汇总 - 知乎
|
||
|
||
|
||
|
||
|
||
参考：Game Developer Guide - Snapdragon Game Toolkit Documentation
|
||
|
||
|
||
|
||
|
||
应用的帧率是多少？
|
||
|
||
在使用骁龙分析器（Snapdragon Profiler）之前，你可能已经察觉到应用存在性能问题。即便尚未察觉，也建议先分析应用当前的整体性能，以定位性能瓶颈。
|
||
|
||
帧率是分析的理想起点。游戏的最佳运行帧率通常为30帧/秒（fps）或60帧/秒，而虚拟现实（VR）和扩展现实（XR）应用的目标帧率有时会更高。
|
||
|
||
帧率分析需关注两个维度：
|
||
|
||
平均帧率：衡量应用的平均运行速度；
|
||
|
||
帧率稳定性：即便平均帧率接近目标值，若偶尔出现“长帧”（单帧耗时过长），仍可能达不到目标帧率。这会导致用户体验卡顿、画面异常，运动效果不流畅，此时应用亟需优化。
|
||
|
||
若应用未经优化，平均帧率可能低于目标值，无法达到理想性能水平；若已完成初步优化，平均帧率可能更接近目标，但仍会周期性出现帧率峰值波动。这些波动会影响动画流畅度，因此需要定位问题根源并修改代码，以实现帧率平稳。
|
||
|
||
无论上述哪种情况，骁龙分析器都能直接显示应用的实时帧率性能。下方截图中，浅蓝色线条代表平均帧率，数值为42.022帧/秒。
|
||
|
||
虽然42帧/秒的平均帧率可能勉强可用，但蓝色线条（实时帧率）会周期性降至37.322帧/秒的低点。这表明应用存在丢帧现象，会对性能造成负面影响。
|
||
|
||
另需注意：应用应选择与平台垂直同步（Vsync）速率成“约数”或“倍数”的帧率作为目标。由于多数平台的垂直同步速率为60Hz，因此30Hz（60Hz的约数）或60Hz（与垂直同步速率一致）是仅有的合理目标帧率。
|
||
|
||
探究潜在性能瓶颈
|
||
|
||
单一指标无法完整揭示性能问题的位置及解决方案，但骁龙分析器可提供数十种指标，帮助你理解应用与硬件的交互方式。
|
||
|
||
在追踪捕获（Trace Capture）模式的截图中，以下三个重要指标可作为分析起点：
|
||
|
||
1. 渲染阶段（Rendering Stage）
|
||
|
||
骁龙分析器中的“渲染阶段”指标，代表应用在GPU上的执行过程。每个数据轨道（track）都是该指标的一个子集，轨道数量会因应用而异。在下方截图中，绿色、品红色和紫色区块代表各个独立的表面（surface），而“表面”区块下方的轨道则对应相关的渲染阶段。
|
||
|
||
2. GPU活动（GPU Activity）
|
||
|
||
这是一项系统级指标，用于展示CPU与GPU之间的交互情况。
|
||
|
||
3. CPU调度（“Trace Kernel - Sched CPU”）
|
||
|
||
同样是系统级指标，可概览应用在每个CPU核心上的执行状态。通过该指标，你能查看应用的不同模块在哪个核心上运行，以及是否存在调度问题或线程竞争问题。
|
||
|
||
借助上述指标，可探究性能可能受限的三个核心领域：GPU、CPU 和 垂直同步（Vsync，即显示器的垂直同步刷新机制）。
|
||
|
||
受GPU限制的应用（GPU-bound application）
|
||
|
||
对于图形密集型应用，建议优先排查是否受GPU性能限制。
|
||
|
||
在骁龙分析器的实时视图（Real-Time view） 中，“GPU利用率（GPU % Utilization）”是核心指标。下方第一张截图显示，GPU利用率在26%-38%之间波动：
|
||
|
||
对比下方第二张截图——GPU利用率稳定在98%-100%：
|
||
|
||
后者强烈表明，应用正受GPU性能限制（即GPU处理能力不足，成为性能瓶颈）。
|
||
|
||
除实时视图外，骁龙分析器的追踪捕获模式也能提供参考依据：若应用不受GPU限制，GPU活动轨道中可能会出现“空闲间隙”（无GPU任务执行的时间段），如下所示：
|
||
|
||
若应用受GPU限制，则GPU执行可能会延迟，且GPU可能处于持续渲染表面的状态，如下所示：
|
||
|
||
受CPU限制的应用（CPU-bound app）
|
||
|
||
若应用不受GPU限制，则需进一步判断是否受CPU性能限制。
|
||
|
||
与GPU受限不同，实时视图中的“CPU利用率（CPU % Utilization）”并非判断应用是否受CPU限制的可靠指标。
|
||
|
||
第一张图中应用的平均CPU利用率为16%，第二张图为23%。实际上，第一张图中的应用是受CPU限制的，但两者的利用率差异远不如GPU受限场景中那么显著，因此单看利用率可能误以为应用不受CPU限制。
|
||
|
||
判断应用是否受CPU限制，有两个核心标准：
|
||
|
||
应用不受GPU限制；
|
||
平均帧时间超过16毫秒（对应60帧/秒的目标帧率，1秒÷60≈16.67毫秒）。
|
||
|
||
此外，还需结合应用的多线程特性及CPU架构综合判断。除“CPU利用率”外，分析“CPU频率”“线程调度”等指标也会对排查有帮助。
|
||
|
||
在下方追踪捕获模式的截图中，“Sched CPU 6”（即第6号CPU核心）上的线程似乎成为了CPU的性能瓶颈：
|
||
|
||
下一步需深入分析该线程，定位“热点函数”（执行耗时较长的函数），并判断是否可通过多线程优化。骁龙分析器的采样捕获模式（Sampling capture mode） 可按固定时间间隔对CPU程序计数器进行采样，识别CPU的“热点执行路径”。该模式会以统计形式展示CPU活动，包括在每个函数和库中花费的时间，从而帮助你找到代码中执行耗时最长的函数。
|
||
|
||
下方采样结果展示了CPU上用于渲染布料纹理的“函数列表”及“函数调用顺序”。红色和橙色区块代表应用代码中的热点（即执行耗时最长的部分）：
|
||
|
||
在本案例中，CPU采样结果显示SatisfyConstraints()是最大的热点函数，占用了98%的CPU活动时间。
|
||
|
||
若需进一步深入分析，骁龙分析器支持“用户标记（user markers）”和Android NDK中内置的“原生追踪API（Native Tracing API）”。Android开发者可通过该API在应用代码中插入追踪标记，随后在骁龙分析器中查看相关数据。
|
||
|
||
在下方示例中，可使用android/trace.h对SatisfyConstraints()调用进行插桩（instrument），并追踪到该函数的调用源自“主线程”（一个工作线程函数）：
|
||
|
||
渲染帧中的某一纹理，需为每块布料调用一次该函数，并根据耗时动态调整执行频率。当修改应用代码，将该函数的执行分配到多个线程后，骁龙分析器可同时显示所有活动的“完整关联视图”：
|
||
|
||
此时，布料计算已在多个线程中并行执行。从“CPU调度”指标可看到更多线程活动，应用不再受CPU限制，CPU会等待绘制任务的分发（而非因CPU能力不足导致绘制延迟）。
|
||
|
||
以上流程是使用骁龙分析器识别、诊断并解决性能问题的典型案例。
|
||
|
||
受垂直同步限制的应用（Vsync-bound app）
|
||
|
||
若确定应用既不受CPU限制，也不受GPU限制，则可能受垂直同步（Vsync）限制——即应用的运行速度已达到显示硬件的最大刷新能力。在骁龙分析器的追踪捕获模式中，可能会看到类似下方的画面：
|
||
|
||
需注意：此时单帧时间恰好约为16毫秒（对应60帧/秒，1秒÷60≈16.67毫秒），且在帧周期末尾会出现一段“间隙”——期间CPU和GPU均处于等待状态，等待可用的表面（surface）以进行下一帧渲染。
|
||
|
||
尽管许多应用的目标是“尽可能达到显示硬件的最大刷新速度”，但即便应用受垂直同步限制，仍存在优化空间，且优化收益不仅限于提升帧率。
|
||
|
||
移动应用的多数性能问题最终都与“功耗/电池续航”相关。即便应用通过“受垂直同步限制”（而非受CPU或GPU限制）达到了目标帧率，仍建议优化代码：若能通过修改代码降低功耗、减少设备发热，应用可在“完成更少工作”的同时维持目标帧率，还可能在低端设备上实现更优性能。
|