Android 性能优化专项学习路线

定位：从"会用 Profiler 看一看"到"能建立体系化性能治理机制"的资深/专家级方向。
适用对象：3 年以上 Android 开发，希望往性能优化专项深耕，建立难以被 AI 替代的核心竞争力。
抗替代性逻辑：性能问题的定位依赖 真机环境 + 多变量归因 + 现场复现，AI 目前只能辅助分析日志，无法独立完成"发现→定位→验证→治理"的完整闭环。

一、能力地图

性能优化专项工程师需要在 5 个子领域 建立体系化能力：

子领域	核心问题	关键工具
启动性能	冷/温/热启动为什么慢	Perfetto、Systrace、App Startup
渲染性能	为什么卡顿/掉帧	Profiler、dumpsys gfxinfo、Choreographer
内存性能	为什么 OOM/泄漏/抖动	LeakCanary、Memory Profiler、MAT
包体性能	为什么包太大、下载转化低	APK Analyzer、R8
电量与网络性能	为什么发热掉电快、弱网体验差	Battery Historian、网络抓包

核心方法论（贯穿全部子领域）：

现象 → 工具定位 → 归因（排除变量）→ 制定方案 → 数据验证 → 建立基线/门禁 → 持续监控

不建立这个闭环思维，学再多工具也只是"点状救火"，无法成为"体系化治理专家"。

二、学习路线总览（建议 10～14 个月）

阶段 0：性能分析基础工具链              → 1 月
阶段 1：启动性能优化                    → 2 月
阶段 2：渲染与卡顿优化                  → 2～3 月
阶段 3：内存优化                        → 2～3 月
阶段 4：包体积优化                      → 1 月
阶段 5：电量与网络性能（选修）          → 1～2 月
阶段 6：体系化治理与项目化              → 持续

三、阶段 0：性能分析基础工具链（1 月）

3.1 必须打通的工具

工具	用途	优先级
Android Studio Profiler	CPU/内存/网络/能耗基础分析	必须
Perfetto	系统级全链路追踪，取代 Systrace	必须
Systrace（了解）	历史工具，部分老项目仍用	了解即可
dumpsys gfxinfo / meminfo	快速命令行诊断	必须
LeakCanary	自动化内存泄漏检测	必须
Macrobenchmark / Microbenchmark	官方基准测试框架	进阶
Baseline Profile	AOT 预编译优化关键路径	进阶

3.2 实操练习

# 用 Perfetto 抓取一次冷启动 trace
adb shell perfetto -o /data/misc/perfetto-traces/trace_file.perfetto-trace \
  -t 10s sched freq idle am wm gfx view

# 查看渲染信息
adb shell dumpsys gfxinfo <package_name>

# 查看内存快照
adb shell dumpsys meminfo <package_name>

3.3 阶段产出

[ ] 独立完成一次 Perfetto trace 抓取并能读懂时间轴上的线程活动
[ ] 能用 dumpsys 系列命令快速做初步诊断
[ ] 搭建 LeakCanary 到一个真实项目并复现一次内存泄漏

四、阶段 1：启动性能优化（2 月）

4.1 核心概念

冷启动：进程不存在，从零创建
温启动：进程存在，Activity 需要重新创建
热启动：进程和 Activity 都存在，仅需恢复

4.2 冷启动完整链路（背诵级）

点击图标
  → Zygote fork 新进程
  → ActivityThread.main() 建立主线程 Looper
  → Application.onCreate()
  → 目标 Activity 创建：onCreate → onStart → onResume
  → 首帧测量布局绘制
  → Choreographer 等 VSYNC 提交
  → 首帧上屏（TTID：Time To Initial Display）
  → 页面完全可交互（TTFD：Time To Full Display）

4.3 常见瓶颈与治理手段

瓶颈	定位方法	治理手段
Application.onCreate 过重	Perfetto 看主线程耗时分布	延迟初始化、异步初始化、App Startup 库统一编排
过多 ContentProvider 自动初始化	查看 Manifest + trace	合并/延迟 Provider 初始化
首屏布局层级过深	Layout Inspector	扁平化布局、ConstraintLayout、异步 Inflate
反射/动态代理滥用	方法耗时采样	减少反射，编译期生成代码替代
主线程 IO/网络请求	trace 中主线程阻塞点	移到子线程，首屏用缓存兜底

4.4 实战项目

找一个真实/练习项目，测量冷启动 TTID/TTFD 基线
用 Perfetto 找出 Top 3 耗时点并逐一优化
用 Macrobenchmark 建立自动化启动耗时回归测试
引入 Baseline Profile，对比优化前后数据

4.5 阶段产出

[ ] 一份《启动优化报告》：基线数据 → 归因 → 方案 → 优化后数据对比
[ ] 搭建 Macrobenchmark 自动化基线测试，接入 CI
[ ] 能背诵完整冷启动链路并画图讲解

五、阶段 2：渲染与卡顿优化（2～3 月）

5.1 核心链路

measure → layout → draw（应用侧生成 DisplayList）
  ↓
Choreographer 等待 VSYNC 信号
  ↓
RenderThread 执行 GPU 渲染指令
  ↓
SurfaceFlinger 合成多个 Layer
  ↓
显示到屏幕

掉帧本质：从 VSYNC 到下一个 VSYNC（通常 16.6ms/60Hz 或 11.1ms/90Hz）之间，应用没能完成一帧的全部工作。

5.2 常见卡顿原因与排查

原因	排查工具	治理手段
主线程耗时任务	Profiler CPU Trace	移到子线程/协程，UI 更新回主线程
过度绘制	`dumpsys gfxinfo` / GPU 呈现模式分析	减少重叠背景、优化层级
布局嵌套过深	Layout Inspector	用 ConstraintLayout 扁平化
RecyclerView 频繁 measure	Profiler + 自定义埋点	ViewHolder 复用优化、预取、DiffUtil
GC 频繁触发	Memory Profiler	减少临时对象分配，对象池
大图解码在主线程	trace 中 decode 耗时	异步解码 + 采样压缩

5.3 实战项目

制造一个人为的卡顿场景（如复杂列表 + 主线程阻塞）
用 Perfetto 定位是「应用侧慢」还是「GPU 侧慢」
用 dumpsys gfxinfo 输出的 Total frames rendered / Janky frames 建立卡顿率基线
优化后用同样工具验证收益

5.4 阶段产出

[ ] 能解释 VSYNC 掉帧的完整链路，画出时间轴图
[ ] 完成至少 2 次真实卡顿定位案例（人为构造或真实项目）
[ ] 建立"卡顿率"监控指标定义与采集方式

六、阶段 3：内存优化（2～3 月）

6.1 内存问题三大类型

类型	特征	定位工具
内存泄漏	对象该释放却未释放，持续增长	LeakCanary、Memory Profiler Heap Dump
内存抖动	频繁分配/回收小对象，触发 GC	Allocation Tracker
OOM	瞬时或持续超过可用内存上限	Heap Dump + 大对象分析，注意 OOM 不等于泄漏

6.2 常见泄漏场景（背诵级）

- 静态变量持有 Activity/Context
- 匿名内部类/Handler 持有外部类隐式引用
- 未注销的监听器/回调（EventBus、观察者）
- 单例持有短生命周期对象
- 资源未关闭（Cursor、Bitmap、Stream）

6.3 排查方法论

1. LeakCanary 捕获泄漏对象 → 看引用链
2. 判断引用链上哪个节点"生命周期该结束但没结束"
3. Memory Profiler 做 Before/After 堆快照对比，定位增长的对象类型
4. 用 MAT (Eclipse Memory Analyzer) 分析更复杂的 dump 文件
5. 区分「一次性峰值」和「持续增长」——只有持续增长才是真泄漏

6.4 图片内存计算（面试高频，务必掌握）

Bitmap 内存 = 宽(px) × 高(px) × 每像素字节数
ARGB_8888: 每像素 4 字节
RGB_565:   每像素 2 字节

示例：1080×1920 的 ARGB_8888 图片
= 1080 × 1920 × 4 ≈ 7.9 MB

6.5 阶段产出

[ ] 独立复现并修复至少 3 种不同类型的内存泄漏
[ ] 完成一次 OOM 分析报告（现象→Heap Dump→归因→方案）
[ ] 能现场计算任意分辨率/格式图片的内存占用

七、阶段 4：包体积优化（1 月）

7.1 分析工具

APK Analyzer（Android Studio 内置）：查看 DEX、资源、So 库占比
R8 / ProGuard：代码压缩、混淆、Tree Shaking

7.2 常见优化手段

类别	手段
代码	R8 精简、移除未用依赖、避免重复库
资源	图片压缩、WebP、矢量图替代多套 DPI 资源、资源去重
So 库	按 ABI 拆分、动态下发、移除未用架构
动态化	Dynamic Feature Module 按需下载

7.3 阶段产出

[ ] 对一个真实项目做完整包体积分析，输出 Top 5 占比项
[ ] 完成一次包体积优化，记录优化前后数据

八、阶段 5：电量与网络性能（选修，1～2 月）

8.1 电量分析

Battery Historian / dumpsys batterystats
常见耗电源：唤醒锁滥用、频繁定位、后台网络轮询、传感器未释放

8.2 网络性能

弱网模拟工具、请求合并与重试策略
离线缓存与预加载策略设计

8.3 阶段产出

[ ] 完成一次耗电异常排查案例
[ ] 设计一套弱网降级策略

九、阶段 6：体系化治理与项目化（持续）

9.1 从"救火"到"治理机制"的升级

救火思维：出问题 → 修 → 结束
治理思维：出问题 → 修 → 建立基线/门禁 → 防止同类问题再发生 → 定期巡检

9.2 必须建立的机制

机制	内容
性能基线	启动耗时、卡顿率、内存峰值、包体积的量化标准
CI 门禁	关键指标超出阈值时构建失败或告警
线上监控大盘	分版本/机型/地域的性能数据可视化
专项复盘机制	每次线上性能问题的根因记录与知识沉淀

9.3 简历/面试表述框架

不要写：「做了启动优化」
要写：
「建立 App 冷启动性能基线与 CI 回归门禁，通过异步化初始化、Baseline Profile
和布局扁平化，将冷启动 TTID 从 XXXms 降至 XXXms（-XX%），
并接入 Macrobenchmark 实现持续监控，防止性能劣化。」

十、能力自检清单（24 项）

打勾 ≥ 17 项，可视为具备资深性能优化工程师水平：

工具

[ ] 熟练使用 Perfetto 分析全链路 trace
[ ] 熟练使用 Memory Profiler 做 Before/After 对比
[ ] 会用 Macrobenchmark 搭建自动化基线测试
[ ] 会用 Baseline Profile 优化关键路径

启动

[ ] 能画出完整冷启动链路图
[ ] 完成过至少 1 次真实启动优化并有数据对比
[ ] 理解 App Startup 库的编排原理

渲染

[ ] 能解释 VSYNC 与掉帧的关系
[ ] 完成过至少 1 次卡顿定位与优化案例
[ ] 理解过度绘制的成因与排查方法

内存

[ ] 独立修复过 3 种以上不同类型泄漏
[ ] 能现场计算 Bitmap 内存占用
[ ] 完成过至少 1 次 OOM 分析报告
[ ] 理解内存抖动与 GC 的关系

包体与其他

[ ] 完成过包体积分析与优化
[ ] 了解电量分析基本方法

体系化能力（区分资深/专家的关键）

[ ] 建立过性能基线文档
[ ] 推动过性能相关 CI 门禁
[ ] 主导过一次跨团队性能专项治理
[ ] 有可量化的优化数据作为简历支撑

十一、常见误区

误区	正确认知
只在模拟器测性能	必须真机，尤其中低端机型，模拟器数据失真严重
优化没有数据支撑	一切优化必须有"优化前/优化后"量化对比
只做一次性优化	必须建立基线和监控，防止劣化回归
遇到问题就换框架/重写	先定位根因，很多性能问题是使用不当而非框架问题
OOM 都是内存泄漏	也可能是瞬时大对象分配、内存碎片、总量超限

十二、最短路径

1. 打通 Perfetto + Memory Profiler + dumpsys 工具链（1个月）
2. 做一次完整启动优化案例并写报告（2个月）
3. 做一次卡顿定位 + 一次内存泄漏修复案例（2个月）
4. 建立性能基线文档，接入 CI 门禁（1个月）
5. 用真实数据整理 2～3 个案例，作为面试/晋升素材

一句话总结：

性能优化的护城河不是"知道更多工具"，而是"建立现象→定位→归因→验证→治理"的完整闭环能力，这个闭环必须在真机上跑通，AI 只能辅助分析日志，不能替你在真实设备上验证结果。

十三、关联文档

../Android高级架构师学习路线.md — 性能与稳定性章节的进一阶展开
../Android移动开发方向抗替代性与薪酬分析.md — 本方向的替代率与薪酬定位
../十年以上Android开发面试问题.md — 性能优化相关面试题

01-Android 性能优化专项学习路线