性能预算防劣化
# 性能预算与防劣化体系
📊 学习成本预估 ｜ 难度：⭐⭐⭐⭐（4/5）｜ 阅读：约 25 分钟 ｜ 实操：1 小时 🔗 前置阅读：卷零·02-03 ｜ ➡️ 后续延伸：卷一全部
性能优化最大的悲剧：辛辛苦苦优化半年，三个版本被业务功能堆回去。
本文回答："如何让性能改进持久？"答案是把性能从"专项治理"升级为"工程纪律"。
# 目录介绍
# 01.性能劣化的必然性
# 1.1 为何劣化是默认状态
性能与业务复杂度天然冲突：
| 业务诉求 | 性能代价 |
|---|---|
| 增加新功能 | 更多代码 / 更多初始化 |
| 更丰富的 UI | 更多视图 / 更多动画 |
| 更精准的埋点 | 更多采集开销 |
| 更智能的推荐 | 更多预加载 / 模型推理 |
| 更安全 | 加密 / 加固 / 校验 |
结论：在没有约束的情况下，性能劣化是默认状态。每个版本都会"自然变慢"。
性能优化不是一次性项目，而是持续对抗熵增的工程纪律。
# 1.2 三种典型劣化模式
# A. 渐进式劣化（最常见）
每个版本慢一点点，每次都不过阈值，但 12 个版本累计劣化 30%。
特征：单点改动看不出问题，需要长期趋势监控。
# B. 阶跃式劣化
某次大重构 / 大功能上线，性能突变。
特征：明显跳变，相对容易归因。
# C. 长尾劣化
均值不变，但 P95 / P99 显著恶化。
特征：常被均值监控漏掉，需要分布监控。
对应防御：
| 劣化模式 | 防御手段 |
|---|---|
| 渐进式 | 长期趋势 + 累积阈值 |
| 阶跃式 | 单版本对比阈值 + CI 卡口 |
| 长尾 | 分布监控（直方图）+ P99 单独告警 |
# 02.性能预算（Performance Budget）
# 2.1 性能预算的定义
借鉴 Web 领域的 Performance Budget 概念：
性能预算：在产品 / 项目层面，预先定义关键性能指标的上限值，并把它视为与功能、质量同等的"产品需求"。
核心思想：不是"尽量快"，而是"必须在 X 之内"。
示例：
| 指标 | 预算 |
|---|---|
| 冷启动 P95（中端机） | ≤ 1.8s |
| 首页 5s 内丢帧率 | ≤ 5% |
| APK 体积 | ≤ 80MB |
| 主线程长任务（>50ms）次数 / 会话 | ≤ 3 |
| 首页内存峰值 | ≤ 250MB |
关键约定：
- 预算超出 = 质量 Bug，必须在版本内解决，不可延期。
- 预算不允许"借未来"（不允许"先上线，下版本优化"）。
# 2.2 预算的设定方法
# 方法 A：基于业务影响
1. 找到关键业务指标（留存、转化、付费）与性能指标的相关性。
例：启动每慢 100ms，次留下降 0.3%
2. 业务可接受的退化上限对应的性能值即为预算。
2
3
# 方法 B：基于竞品对标
分析竞品同类指标，取头部 30% 的水位作为预算。
（注意：不同业务类型不可直接对比）
2
# 方法 C：基于设备分档
高端机：1.0s
中端机：1.8s
低端机：3.0s
按 DAU 加权后整体目标 ≤ 1.6s
2
3
4
5
推荐：B + C 组合，每季度根据 A 校准。
# 2.3 预算的分解与归属
总预算需要分解到模块，否则无法追责：
冷启动总预算：1800ms
├── 进程创建 → Application.onCreate 200ms (系统 + 框架)
├── Application.onCreate 300ms (基础组件团队)
│ ├── 日志 SDK 50ms
│ ├── 网络 SDK 80ms
│ ├── 数据库 SDK 70ms
│ └── 业务初始化 100ms
├── MainActivity.onCreate → 首帧 500ms (首页业务团队)
└── 首帧 → TTI 800ms (首页业务团队)
2
3
4
5
6
7
8
9
预算分解的原则：
- 可归属：每段预算有明确 owner。
- 可度量：每段在线下 / 线上都能采集。
- 可调整：模块间可在总预算内交易（A 借给 B）。
# 03.防劣化的三道防线
性能劣化必须在三个时机分别拦截：
开发期 ──► 编译期 ──► 测试期 ──► 上线期 ──► 运行期
│ │ │
▼ ▼ ▼
[Lint / IDE] [CI 卡口 / 自动化] [线上 SLO 守护]
2
3
4
# 3.1 第一道：编码期 Lint
通过静态检查在写代码时阻止已知反模式：
| 反模式 | Lint 检查 |
|---|---|
| 主线程同步 IO | 自定义 Lint：在标记 @MainThread 方法中调用 IO API 警告 |
| 主线程网络请求 | 自定义 Lint：在 onCreate / onResume 中调用网络 API 警告 |
| 列表项中创建 SimpleDateFormat / Gson 等重对象 | 警告 |
| 启动阶段使用反射 / 类加载 | 警告 |
| 大图片同步加载 | 警告 |
实现：
- Android：Android Lint Custom Rules / Detekt
- iOS：SwiftLint / 自定义 SourceKit 规则
- Web：ESLint + AST 自定义规则
优势：成本最低，IDE 即时反馈；劣势：只能检测已知模式。
# 3.2 第二道：CI 卡口
在合并代码前自动跑性能用例，超过阈值则阻塞合并：
PR 提交
│
▼
CI 性能流水线
├─ 构建产物
├─ 在标准设备 / 模拟器上跑基准用例集
├─ 与基线对比
└─ 超过阈值 ──► 阻塞合并 + 评论 PR
2
3
4
5
6
7
8
关键设计：
| 维度 | 推荐做法 |
|---|---|
| 用例覆盖 | 启动 / 首页滚动 / 关键页面打开（5-10 个核心场景） |
| 设备 | 高 / 中 / 低各 1 台真机（云测平台） |
| 重复次数 | 每用例 ≥ 30 次 |
| 阈值 | 单版本退化 > 3% 警告，> 5% 阻塞 |
| 噪声处理 | 用 Mann-Whitney U 检验剔除噪声波动 |
坑点：
- 不要用模拟器跑性能（数值不可信）。
- 阈值过严会被绕过（开发者写
// skip-perf）；过松形同虚设。 - 必须对应"真实用户路径"，不能只测 Hello World。
# 3.3 第三道：线上 SLO 守护
CI 即使覆盖完整，仍可能漏掉真实用户场景的问题。线上守护是最后一道防线：
版本灰度 ──► 实时监控 SLO ──► 异常自动回滚
关键能力：
- 灰度期间 5 分钟级监控 SLO 偏离。
- 自动对比当前版本 vs 上一稳定版本。
- 触发阈值后告警 / 自动暂停灰度 / 自动回滚。
- 用户分群守护（不同机型 / 网络分别守护）。
# 04.自动化性能回归
# 4.1 基准用例集
性能回归测试不是"跑一遍 App"，而是精心设计的基准用例。
好用例的标准：
- 代表真实用户路径：覆盖 80% 用户会做的事。
- 可重复执行：每次执行环境一致，结果稳定。
- 可量化：输出明确的数值指标（不依赖人工观察）。
- 关键路径覆盖：覆盖业务核心场景。
典型用例集：
| 用例 | 度量指标 |
|---|---|
| 冷启动 → 首页 | 进程创建 → 首屏 / TTI |
| 首页滚动 60s | FPS / P99 帧时长 / 大卡顿次数 |
| 进入详情页 | 点击 → 首屏 |
| 列表加载更多 | 触发 → 新数据可见 |
| 切换 Tab × N 次 | 平均切换耗时 / 内存增长 |
| 后台 5 分钟回前台 | 恢复耗时 |
# 4.2 设备矩阵
仅在一台设备上跑无意义。最少配置：
| 档位 | 代表机型示例 | 关注问题 |
|---|---|---|
| 旗舰 | 当前主流旗舰 | 极限性能、上限 |
| 中端 | 销量最大的中端机 | 主流用户体验 |
| 低端 | 最低支持的入门机 | 兜底体验、OOM |
| 老机型 | 3-5 年前的设备 | 退化最快的人群 |
建议：
- Android：每档至少 2 个不同 SoC（高通 / 联发科）。
- iOS：覆盖 SE 老款（性能最弱）+ 主流 + Pro。
- Web：低端 Android Chrome + 高端桌面 Chrome + Safari。
- 嵌入式：标准开发板 + 实际目标硬件。
# 4.3 阈值判定与告警
| 维度 | 推荐 |
|---|---|
| 主指标超过阈值 X% 的判定 | 单 PR 退化 > 5% 阻塞，> 3% 警告 |
| 累计退化 | 连续 3 个版本 > 1% 累计 → 启动专项治理 |
| 长尾退化 | P99 单独监控，> 8% 即阻塞 |
| 护栏退化 | 同时检查内存、包体、CPU 总耗时 |
# 4.4 偶发噪声处理
性能数据天然有噪声，处理不当会导致：
- 假阳性：CI 频繁误报，团队失去信心 → 直接绕过。
- 假阴性：把真实退化淹没在噪声中。
对策：
| 方法 | 说明 |
|---|---|
| 重复多次取分布 | 至少 30 次 |
| 非参数检验 | Mann-Whitney U 替代 t 检验（性能数据非正态） |
| 多版本基线 | 用近 5 个版本均值作为基线，避免单版本抖动 |
| 设备健康检查 | 测试前检查温度 / 电量 / 后台 |
| 异常样本剔除 | 剔除明显的离群点（前 1% / 后 1%） |
# 05.线上守护体系
# 5.1 监控分层
┌─────────────────────────────┐
│ L1 业务感知（黄金信号） │ ← 5 分钟告警
│ Crash / ANR / 启动 / 卡顿 │
├─────────────────────────────┤
│ L2 资源监控 │ ← 15 分钟告警
│ CPU / 内存 / IO / 网络 │
├─────────────────────────────┤
│ L3 模块级 SLO │ ← 小时级告警
│ 各模块自有指标 │
├─────────────────────────────┤
│ L4 长期趋势 │ ← 日 / 周报
│ 版本对比 / 设备分布趋势 │
└─────────────────────────────┘
2
3
4
5
6
7
8
9
10
11
12
13
# 5.2 告警设计
好告警的标准：
| 标准 | 含义 |
|---|---|
| 可操作 | 收到告警知道做什么，不是"我看到了" |
| 不疲劳 | 告警频率 < 每天 1 次 / on-call 人 |
| 不漏报 | 真实问题必被触发 |
| 可静默 | 已知问题可临时屏蔽，但有过期时间 |
告警阈值的两种设定：
| 类型 | 含义 | 例子 |
|---|---|---|
| 静态阈值 | 固定值 | 启动 P95 > 2s 告警 |
| 动态基线 | 与历史对比 | 较 7 天均值劣化 > 10% 告警 |
生产环境推荐：静态 + 动态组合。静态保证不超下限，动态捕捉异常波动。
# 5.3 错误预算与发布速度
借鉴 SRE 的"错误预算"机制：
SLO：本季度冷启动 P95 ≤ 2.0s 占比 ≥ 99%
错误预算：1% 时段
2
预算消耗速度决定发布节奏：
| 状态 | 行动 |
|---|---|
| 预算充足（消耗 < 50%） | 可激进上线、可做实验 |
| 预算紧张（消耗 50%-90%） | 高风险变更需评审 |
| 预算耗尽（> 90%） | 冻结新功能，专注治理 |
这是让"业务团队"和"性能团队"对齐目标的最有力机制。业务想多上线 → 必须维持 SLO。
# 06.治理闭环：从发现到沉淀
# 6.1 劣化发现
发现渠道（互为补充）：
- 自动化报告：日报 / 周报对比上周。
- 用户反馈：客服 / 应用商店 / 内部社群。
- 灰度异常：上线时 SLO 触发。
- 主动巡检：每月专项排查。
# 6.2 责任到人
劣化必须有人负责。机制：
- 代码归属：通过 git blame + CODEOWNERS 自动定位变更人。
- 模块归属：每个模块有明确性能 owner。
- 闭环 SLA：劣化发现到修复有明确时限。
反模式：
- "大家一起优化" → 无人负责。
- "性能团队负责" → 业务无激励，劣化反复。
# 6.3 复盘与知识沉淀
每次重大劣化必须复盘，输出三件物：
| 产物 | 价值 |
|---|---|
| 根因分析（RCA） | 让团队理解 |
| 防御措施 | 加 Lint / CI 规则 / 监控指标 |
| 案例文档 | 沉淀到知识库，避免重复犯错 |
复盘的"5 Why"模板：
1. 现象：启动 P95 从 1.5s 涨到 1.9s
2. Why 1：因为 X 模块初始化新增 350ms
3. Why 2：因为 X 模块加载了 5MB 模型文件
4. Why 3：因为模型加载未异步
5. Why 4：因为开发者没意识到 Application.onCreate 是关键路径
6. Why 5：因为我们没有"启动关键路径"的代码标记 / Lint 规则
→ 防御：加 Lint 规则 + 启动阶段调用清单
2
3
4
5
6
7
8
# 07.团队协作与文化
# 7.1 性能不是某个人的事
错误模型：
"性能优化是性能团队的工作。"
正确模型：
性能团队：建设方法论、工具、监控、CI 卡口。
业务团队：在自己模块的预算内对自己负责。
架构 / 平台团队：保障基础设施性能水位。
# 7.2 让性能"可见"
- 大屏看板：办公区或 Wiki 首屏展示当前 SLO、错误预算、版本对比。
- PR 评论：CI 性能结果直接评论到 PR，作者第一时间看到。
- 版本周报：每个版本发布后，性能数据作为发布报告的一部分。
- 专项展示：性能优化大版本对外宣传（让团队有成就感）。
# 7.3 OKR 与考核
把性能纳入团队 OKR：
O：保障用户极致体验
KR1：冷启动 P95 ≤ 1.8s（中端机），稳定 4 个版本
KR2：错误预算消耗 ≤ 70%
KR3：性能 Lint / CI 规则覆盖率 ≥ 80% 关键路径
2
3
4
关键：性能指标要纳入业务 OKR，而不是仅在性能团队 OKR。否则"业务向前冲，性能在后面救火"的循环永远无法打破。
# 一句话总结
性能不是优化出来的，是守护出来的。
当性能纪律成为工程文化的一部分，"性能优化"就不再需要作为一个独立项目存在。
