1. 卡顿现象定义与用户感知模型
卡顿是用户最直观的负面体验，在移动端表现为界面滑动停顿、点击无响应或动画跳变。要将主观的“卡顿”转化为可量化的排查指标，必须从三个维度进行定义：掉帧阈值、ANR超时和卡顿频率。本章围绕「现象识别」环节，建立从用户感受到技术指标的映射模型。
1.1 核心指标定义与阈值
| 指标 | 定义 | 业阈值 | 用户感知影响 |
|---|---|---|---|
| 掉帧 (Frame Drop) | 单帧渲染耗时超过预期帧间隔（如16.67ms）导致丢帧 | ≥1 丢帧/连续帧即视为卡顿 | 滑动/动画出现轻微抖动 |
| ANR (Application Not Responding) | 主线程阻塞超过系统超时时间 | 输入事件 5s / 广播 10s / 服务 20s | App 无响应，弹窗“强制关闭” |
| 卡顿频率 (Jank Rate) | 单位时间内掉帧次数或卡顿帧占比 | 每 60s 掉帧 > 3 次转为 高卡顿 | 频繁卡顿降低整体流畅度 |
现象识别要点：掉帧反映渲染性能局部抖动，ANR 反映主线程长期阻塞，卡顿频率刻画连续体验退化。三者互补，使用
Profiler 的 Frame Rendering 视图和 Logcat 可快速识别。
1.2 用户感知模型：从操作到指标
用户操作（触摸、滑动、动画）触发 UI 更新，经过 输入响应 → 布局计算 → 渲染管线 → 帧呈现 链路。若任一阶段超出阈值，即产生感知卡顿。模型将主观体验映射为三个技术指标：
- 掉帧检测：帧时间 > 16.67ms → 记录一次掉帧，累积形成曲线。
- ANR 监控：主线程消息循环连续超时 → 触发 ANR 日志生成。
- 卡顿频率统计：聚合掉帧事件计算单位时间内的卡顿次数。
实践建议：在 Profiler 中打开 Frame Timeline，观察绿色/红色竖条（绿色表示帧时间 < 16ms，红色表示掉帧）。红色竖条密集出现即表明需要进一步定位。
1.3 现象识别实操：使用 Profiler 快速定位
在 Android Studio Profiler 中，打开 CPU 或 Frame 标签页，通过 点击“Record & Detect Jank” 即可实时捕获掉帧事件。同时，观察 Logcat 中的 ANR 日志，典型片段如下：
I/ActivityManager: ANR in com.example.app (com.example.app/.MainActivity)
PID: 12345
Reason: Input dispatching timed out (Waiting to send non-key event...
Load: 10.12 / 0.8 / 0.5
CPU usage from 532ms to 0ms ago:
com.example.app: 25% = 15% user + 10% kernel / faults: 1234 minor 0 major
...
注意：掉帧事件不会直接产生 ANR 日志，但长时间掉帧积累可能导致主线程负载过高而触发 ANR。因此，同时跟踪掉帧频率和 ANR 日志是识别卡顿场景的黄金组合。
本章定义的掉帧阈值、ANR 超时、卡顿频率构成了后续 数据采集 → 原因定位 → 修复动作 环节的量化基础。在进入下一章节前，请确保能在 Profiler 中熟练切换掉帧检测视图和 ANR 日志过滤。