1. 课程概述与卡顿指标

本章是整门课程的起点，帮助你建立对移动端卡顿的统一定义，理解FPS、ANR、掉帧三个核心指标的技术含义，并明确Firebase Performance在卡顿监控中的定位与价值。学完本章后，你将能够准确描述卡顿问题，并为后续的Trace采集、阈值配置、自定义指标埋点打下共同的概念基础。

1.1 课程交付物

本课程采用技术实现型教学方式，每章均配有可直接落地的产出物。下表列出你在完成全部30章后将获得的核心交付物。

1.2 学习路径

本课程按照概念 → 集成 → 埋点 → 分析 → 优化 → 部署的递进路线组织。下面是你将经历的核心学习步骤。

1. 建立卡顿认知模型（第1章）：统一术语，理解FPS/ANR/掉帧的本质差异。
2. 集成Firebase Performance SDK（第2–4章）：完成Android/iOS双端接入，验证数据上报。
3. 配置Trace与自定义指标（第5–9章）：对启动、页面切换、列表滑动、网络请求等场景实施埋点。
4. 设定阈值与报警规则（第10–13章）：根据业务特征配置卡顿阈值，对接实时通知。
5. 分析仪表板与归因定位（第14–20章）：使用Firebase Console、BigQuery、自定义REST API进行卡顿归因。
6. 实战优化与防劣化（第21–28章）：针对ANR、帧率骤降、长任务等6类典型问题进行修复。
7. 部署与团队推广（第29–30章）：编写监控SOP，推动卡顿治理流程落地。

在进入第2章之前，建议先完成以下SDK依赖的添加，为后续集成做准备：

// app/build.gradle (Android)
dependencies {
    implementation platform('com.google.firebase:firebase-bom:32.7.0')
    implementation 'com.google.firebase:firebase-perf'
}

1.3 卡顿定义与核心指标

移动端卡顿的官方定义是：用户感知到的界面响应延迟或视觉不流畅。在技术层面，我们将卡顿量化为三个互有重叠但侧重点不同的指标。下表给出它们的对比。

1.4 FPS / ANR / 掉帧 技术解读

FPS（Frames Per Second） 衡量屏幕每秒刷新的帧数。60Hz 屏幕的理想帧率为 60 FPS；当帧率降到 30 以下时，人眼能明显感知到画面停顿。Firebase Performance 通过自动采集 Screen Rendering Trace 来记录每个渲染阶段的帧率分布。

ANR（Application Not Responding） 是Android系统对主线程阻塞超过5秒的检测机制。触发时会弹出“应用无响应”对话框，严重时直接杀死进程。Firebase Performance 的 ANR Rate 指标能按版本、机型、OS 版本聚合ANR发生率，并提供ANR Trace详情用于堆栈定位。

掉帧（Frame Drop / Jank） 指单帧渲染耗时超过16.67ms（60Hz）或11.11ms（90Hz）。掉帧是卡顿的微观表现，一次掉帧可能只有几十毫秒，但高频掉帧会让用户感觉“屏幕在抖”。Firebase Performance 使用 Slow Frame Threshold 和 Frozen Frame Threshold 来区分普通掉帧和严重掉帧。

1.5 性能监控的商业与技术价值

投入卡顿监控不只为技术指标好看，更是直接的产品力投资。以下四个维度说明了为什么卡顿监控是移动团队的刚需。

• 用户留存：卡顿是应用卸载的第二大原因（仅次于崩溃）。帧率每提升10%，7日留存率平均上升3–5%。
• 转化率：购物类应用中，ANR 会导致下单流程中断，直接损失GMV。实时监控 ANR 能缩短故障恢复时间。
• 版本迭代效率：通过 Firebase Performance 的版本对比视图，可以在新版本发布后24小时内发现是否引入了回归性卡顿。
• 团队研发效能：统一的卡顿指标和Trace归因体系，能减少“你觉得卡我觉得不卡”的争吵，让优化工作有据可依。