📚 课程目录第1章课程导入

1. 课程导入

在移动端体验竞争日益激烈的今天，用户对“流畅”的容忍度越来越低。一次明显的掉帧、一次点击后两秒无响应、一次冷启动白屏过久，都可能直接导致卸载。对 Android 工程师而言，卡顿（Jank）、ANR（Application Not Responding）与系统级稳定性问题，既是高频线上故障，也是最能体现工程深度的领域。本课程的目标，是带你从“会看日志”进阶到“能定位根因、能设计防线、能度量收益”的系统稳定性工程师。

本课程的学习目标可以概括为四句话：看得见——建立完整的卡顿与ANR可观测体系；说得清——能从主线程、渲染、Binder、系统服务等链路定位根因；改得动——掌握从代码、架构到系统参数的多层优化手段；守得住——用监控、灰度、防劣化机制把稳定性变成可持续的工程能力。

一、核心概念：卡顿、ANR与稳定性不是一回事

很多初学者把卡顿和ANR混为一谈，实际上它们处于同一条因果链的不同阶段。卡顿是“帧未按时产出”的体验表现，ANR是“主线程在规定时间内未响应输入或广播”的系统判定，而稳定性工程关注的是崩溃、ANR、内存、功耗、系统服务异常等更广的可用性问题。理解三者的边界，是后续所有分析的前提。

从系统视角看，Android 的流畅性依赖一条严格的时序链：VSYNC 信号触发、UI 线程完成 measure/layout/draw、RenderThread 提交 GPU、SurfaceFlinger 合成上屏。任何一环超时，都会表现为掉帧。而 ANR 的触发条件则更“硬”：输入事件 5 秒、前台广播 10 秒、后台广播 60 秒、Service 20 秒等超时阈值。卡顿是“慢”，ANR 是“死”，稳定性工程要同时治理这两类问题。

二、方法流程：从现象到根因的定位路径

面对一个线上卡顿或ANR问题，切忌直接猜代码。推荐遵循“先定界、再定链、后定因”的三步法。第一步定界：确认是全局卡顿还是特定页面、特定机型、特定版本；第二步定链：通过 Trace、Perfetto、ANR Trace 判断阻塞发生在主线程、渲染线程还是系统服务；第三步定因：结合代码与系统状态锁定具体耗时点。

# 典型 ANR Trace 关键信息
"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72c8f0
  | sysTid=12345 nice=-10 cgrp=default sched=0/0 handle=0x7f8a
  | state=S schedstat=( 123456789 987654321 1234 ) utm=12 stm=8 core=2 HZ=100
  at com.example.app.DataManager.query(DataManager.java:88)
  - waiting to lock <0x0a1b2c3d> (a java.lang.Object) held by thread 12
  at com.example.app.MainActivity.onClick(MainActivity.java:45)

这段 Trace 直接告诉我们：主线程在等一把被 12 号线程持有的锁。若只看“卡顿”表象，很容易误判为渲染问题。因此，掌握 Trace 阅读能力，是本课程的核心基本功之一。

三、整体知识框架与实战路线图

本课程共 30 章，按“认知—工具—定位—优化—体系”五段式推进。下表给出整体路线图，帮助你建立学习地图。

阶段	核心内容	关键产出
认知筑基	卡顿/ANR定义、VSYNC与渲染时序、ANR阈值	建立统一术语与判定标准
工具链	Systrace/Perfetto、TraceView、ANR Trace、StrictMode	能独立采集与分析 Trace
定位实战	主线程阻塞、锁竞争、Binder、GC、布局、IO	形成根因定位清单
优化手段	异步化、布局优化、内存治理、启动优化、系统参数	可落地的优化方案库
体系防线	线上监控、灰度、防劣化、稳定性度量	可持续的稳定性工程能力

四、案例与场景：一个真实的ANR复盘

某电商 App 在详情页点击“加入购物车”后偶发 ANR。初看日志只看到主线程 Blocked，团队一度怀疑是网络请求。深入 Trace 后发现：主线程在等待一个被后台线程持有的 SharedPreferences 锁，而后台线程正在执行一次全量写入。根因是 SharedPreferences 的 apply/commit 使用不当，加上详情页频繁读写，导致锁竞争。修复方案是将配置读写迁移到独立线程并做内存缓存，ANR 率下降 92%。

常见误区：把 ANR 简单归因于“手机卡”或“系统问题”。实际上，绝大多数 ANR 都能在应用代码或架构层面找到可优化点。另一个误区是只优化“看得见的页面”，忽略后台线程、广播、Service 对主线程的间接影响。

学习建议：每学完一章，回到自己的项目里找一个对应场景做一次实测。稳定性工程是“手感”学科，只看不练，遇到真实 Trace 依然会无从下手。

从本章开始，你将逐步建立起一套完整的 Android 稳定性工程方法论。它不依赖某个特定框架，而是围绕“可观测—可定位—可优化—可防守”的闭环展开。无论你当前负责的是电商、社交还是系统应用，这套方法都能直接迁移。