From 43704c724c2150bc25c6aa94a109d4ed4dffe4df Mon Sep 17 00:00:00 2001
From: Zane <zane@zanecloud.host>
Date: Wed, 10 Jun 2026 22:23:28 +0800
Subject: [PATCH] =?UTF-8?q?Add=20Zhihu:=20=E5=A6=82=E4=BD=95=E6=AD=A3?=
 =?UTF-8?q?=E7=A1=AE=E9=AB=98=E6=95=88=E7=9A=84=E6=9F=A5=E6=89=BE=E6=B8=B8?=
 =?UTF-8?q?=E6=88=8F=E3=80=8C=E5=8D=A1=E9=A1=BF=E3=80=8D=E5=8E=9F=E5=9B=A0?=
 =?UTF-8?q?=EF=BC=9F?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 InBox/如何正确高效的查找游戏_卡顿_原因_.md | 123 +++++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 InBox/如何正确高效的查找游戏_卡顿_原因_.md

diff --git a/InBox/如何正确高效的查找游戏_卡顿_原因_.md b/InBox/如何正确高效的查找游戏_卡顿_原因_.md
new file mode 100644
index 0000000..501fd4b
--- /dev/null
+++ b/InBox/如何正确高效的查找游戏_卡顿_原因_.md
@@ -0,0 +1,123 @@
+---
+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限制）达到了目标帧率，仍建议优化代码：若能通过修改代码降低功耗、减少设备发热，应用可在“完成更少工作”的同时维持目标帧率，还可能在低端设备上实现更优性能。