第2章 掉帧现象与影响

调优前必须理解什么是“掉帧”以及它如何被用户感知。本章从定义、感知机制、卡顿分类和量化影响四个层次建立完整的掉帧认知体系，为后续监控工具选型与定位策略提供理论基础。

2.1 掉帧定义

掉帧（Frame Drop / Jank）指渲染管线未能在预期时间窗口内完成一帧的合成与提交，导致显示器重复显示上一帧或插入空白帧的现象。从系统角度，掉帧本质是帧时间（Frame Time）超出了刷新间隔。

2.2 用户感知：平均 FPS 的陷阱

用户对流畅度的主观感受并不等同于平均帧率。两段 60 秒的视频，一段稳定 60 FPS（帧时间方差小），另一段在 55~65 FPS 间剧烈波动（帧时间方差大），后者即使平均帧率接近也会被用户评价为“卡顿”。感知的黄金指标是 帧时间稳定性，而非平均值。

2.3 卡顿分类

根据持续时间、频率和根本原因，卡顿可分为三种典型类型。理解分类有助于在帧时间曲线中快速定位问题模式。

2.4 对用户体验的量化影响

行业常用以下几个量化指标衡量掉帧对体验的伤害：

• 帧时间方差（Jitter）：帧时间序列的标准差。方差越低，视觉流畅度越高。
• P95 / P99 帧时间：95% 或 99% 的帧能控制在多少 ms 以内。超过 16.67 ms 的比例直接对应丢帧率。
• 丢帧率（Frame Drop Rate）：掉帧帧数 / 总帧数。超过 5% 用户通常能察觉。
• 卡顿指数（Jank Score）：Android 平台的 SysTrace 和 GPU Profiler 输出的综合评分。

以下是从一台 60 Hz 设备上采集的真实帧时间日志（单位 ms）：

FrameTiming (ms): 16.2, 16.8, 17.1, 16.5, 16.9, 58.4, 16.3, 16.7, 16.4, 16.6
第 6 帧耗时 58.4 ms → 掉帧约 2.5 帧 (58.4 / 16.67 ≈ 3.5 个刷新间隔, 丢失 2.5 帧)
丢帧率 = 1 / 10 = 10%  (超出16.67ms的帧数为1)

2.5 掉帧损伤模型

从用户输入到屏幕输出的全链路中，掉帧的累积效应可用以下流程描述：

2.6 真实案例数据

以下日志来自某二次元手游在骁龙 8 Gen2 上的帧时间记录。注意周期性尖刺：

# adb shell dumpsys gfxinfo com.example.game | grep "TotalFrameCount\|JankyFrames\|FrameTiming"
TotalFrameCount: 3620
JankyFrames: 187
FrameTiming (ms): 16.2, 16.9, 17.0, 16.5, 45.1, 16.7, 16.3, 47.6, 16.4, 16.8, ...
# 丢帧率 = 187 / 3620 ≈ 5.17%  (超过5%用户可感知)
# P99帧时间 = 52.3ms (远超16.67ms阈值)

将上述日志可视化后，35~55 ms 的尖刺每 1.5 s 出现一次，与后台资源预加载任务吻合。这类周期性卡顿属于“可定位型”，后续章节将演示如何利用 Systrace 追踪其根源。