第2章 Android Profiler简介：功能模块、启动方式、数据采集原理
现象识别：何时需要引入Profiler？
在实际内存泄漏排查中，通常先出现以下一类或多类现象，才触发Profiler的使用决策：
| 现象类别 | 典型表现 | 初步判断 |
|---|---|---|
| OOM崩溃 | App闪退，日志包含OutOfMemoryError | 堆内存持续上涨或大对象无法回收 |
| UI卡顿 | 列表滑动时掉帧，主线程被GC频繁挂起 | GC Alloc/Concurrent标记过多存活对象 |
| 后台驻留异常 | App切到后台后内存不下降或反而升高 | Service/Activity被意外持有引用 |
| 设备发烫 | 长时间使用后机身明显发热 | 对象反复创建、GC压力大或线程泄漏 |
决策规则：连续3次GC后内存不回落，或单次堆分配超过最大堆的70%，即可启动Profiler进行数据采集。
数据采集：功能模块与启动方式
Android Profiler 是 Android Studio 内置的性能分析工具，支持CPU、内存、网络、能耗四大面板。本节聚焦内存面板（Memory Profiler）。
| 功能模块 | 能力 | 采集原理 |
|---|---|---|
| 实时堆视图 | 显示Java堆/Native堆/图形内存/代码资源 | 通过Debug.startMethodTracing和dumpHprofData获取快照 |
| 时间线 | 展示分配速率、GC事件、内存变化曲线 | 每100ms从ART运行时获取计数器 |
| 分配跟踪 | 记录每个对象的分配堆栈 | 启用后ART在每个alloc时记录调用栈，类似AllocationTracker |
| 堆转储 | 导出.hprof文件 | 调用Debug.dumpHprofData()，生成标准HPROF二进制 |
| 引用链 | 从GC Root到泄漏对象的路径 | 解析.hprof后分析strong reference chain |
启动方式：
- 在Android Studio中连接设备/模拟器，选择进程（需debuggable）。
- 点击底部工具栏 Profiler 图标（或
View → Tool Windows → Profiler）。 - 进入Memory面板，选择要监控的进程。
- 点击 Record 开始分配跟踪（会降低性能，仅用于定位泄漏点）。
注意：分配跟踪仅在Android 7.0以上设备支持堆栈记录；低版本需使用
Allocation Tracker旧接口。生产包需要android:debuggable="true"或root权限。
原因定位：从曲线异常到快照对比
典型排查流程遵循“现象→时间线→堆转储→引用链”四步。故障树如下：
修复动作：基于引用链执行代码修改
通过Profiler的Reference Tree面板，定位到泄漏对象的最短GC Root路径。常见的修复动作包括：
- 解除匿名内部类对外部Activity的隐式持有（改为静态内部类+弱引用）。
- 在
onDestroy()中反注册Listener、停止Handler、清理Bitmap。 - 使用
LeakCanary自动捕获快照补充验证。
典型案例：一个Handler内部类持有外部Activity引用，导致Activity无法在finish后被回收。修复前Profiler中可见Activity实例数不断增长，修复后Activity在销毁后立刻被GC回收，内存曲线平稳。
复测：验证修复有效性
- 清除已有快照，应用修复代码并重新部署。
- 执行相同的用户操作路径（如反复打开/关闭页面20次）。
- 在Profiler中观察内存曲线是否在每次关闭后回落到基线附近。
- 手动触发两次GC，若堆占用稳定且无异常增长，则判定修复通过。
常见陷阱：仅修复一个泄漏点后，其他未修复的泄漏对象仍可能使内存上升。建议多轮复测，每次定位一个泄漏根因。
预防：纳入CI门禁与Profiler自动化
| 措施 | 实施方式 | 工具 |
|---|---|---|
| 自动化内存基线 | 在CI中运行Monkey测试后采集.hprof，与基线对比增长 | Gradle插件 + Perfetto SDK |
| 泄漏检测入库 | 每次MR自动触发LeakCanary集成测试 | LeakCanary + JUnit |
| 人工审查清单 | Code Review时检查静态变量、单例、内部类 | Lint规则 + 团队规范 |