Android Profiler 全解：内存、卡顿、耗电与 ANR 排查

面试开场：「列表滑动掉帧，你会怎么定位是 bind 慢还是 layout 慢？」

这道题表面问工具，实际在考察你是否能把 现象 → 复现 → Trace 定帧 → 对症修改 → 回归验证 走通。Android Studio Profiler 是官方标准答案之一，但不是唯一路径——Systrace 导出 Perfetto、StrictMode、JankStats 往往更轻量。

这篇按 Profiler 总览 → 四大面板深入 → ANR → 实战取舍 → 工具链扩展 展开，并保留对「Profiler 本身也很卡」的真实工程判断。

一、Android Profiler 是什么

Android Studio 内置的 Profiler 是连接调试进程与可视化分析面板的入口，实时采集：

┌──────────────┐    attach     ┌─────────────────────────────────────┐
│  Debug 进程   │ ────────────► │  Android Studio Profiler            │
│  (你的 App)   │               │  Memory │ CPU │ Energy │ Network    │
└──────────────┘               └──────────────────┬──────────────────┘
                                                  │
                    ┌─────────────────────────────┼─────────────────────────────┐
                    ▼                             ▼                             ▼
              Heap Dump /                    System Trace /                  请求瀑布图 /
              Allocation                      Perfetto 导出                   电量归因

1.1 如何打开

1. 用 Debug 而非 Run 启动 App（Profiler 需 JDWP 连接）
2. 底部工具栏 View → Tool Windows → Profiler，或 Run 窗口旁 Profiler 标签
3. 选择目标进程（多进程 App 注意选 :push 等子进程）
4. 点击对应面板 Record 开始采集

注意：Release 包默认不可调试；性能测试建议用 debuggable 的 profile 构建（android { buildTypes { release { debuggable true } } } 仅内测，勿上架）。

1.2 与 Layout Inspector / Database Inspector 的区别

卡顿排查常 Profiler（Trace）+ Layout Inspector（层级） 组合使用。

二、排查决策：先经验，再工具

真实项目里，测试往往只给：问题描述 + 复现视频（有时连步骤都没有）。开发侧的合理路径：

RecyclerView 滑动卡顿 的常见直觉路径（详见 RecyclerView 全解）：

1. onBindViewHolder 里是否有 IO、解码、复杂计算
2. Glide 是否未 override 尺寸、是否在主线程等磁盘
3. Item 布局层级、wrap_content 嵌套是否过深
4. 是否滥用 notifyDataSetChanged 导致全量 rebind + GC

经验能解决八成；Profiler 的价值在 剩下两成——帧级证据、泄漏引用链、WakeLock 谁没释放。

三、内存分析（Memory Profiler）

3.1 面板读法

Memory 面板实时曲线通常分：

曲线 锯齿上升 + 突然回落 多为 GC；持续上升不回落 要怀疑泄漏或缓存无上限。

3.2 常用操作

3.3 Heap Dump 分析步骤

1. 复现泄漏场景（如反复进出 Activity）
2. 手动 GC 一次（垃圾桶图标），再 Dump heap
3. 在 Class Name 搜索 Activity、Presenter、Listener、Bitmap
4. 按 Retained Size 排序，点开 Dominator 树
5. 看 References 链：谁持有了不该持有的 Context

典型泄漏链：

修法方向：WeakReference、Application Context（仅适合无 UI 依赖）、生命周期感知（LifecycleObserver）、LeakCanary 自动化。

3.4 与 LeakCanary 的分工

生产环境用 Firebase Crashlytics / 自定义 OOM 上报 抓 heap 摘要，不要用 Profiler。

3.5 本地存储相关的内存点

若 Room / 大 JSON 缓存 使用不当，Memory 曲线会在列表页暴涨：

• 一次加载万条 Entity 到内存而非 Paging
• 图片未压缩、Glide 未 override
• SP/DataStore 里塞整段 JSON 并在内存重复 parse

四、卡顿分析（CPU / System Trace）

卡顿的本质：主线程在一帧内（16.6ms @ 60Hz）没干完 Choreographer 的 traversal + draw。

4.1 CPU Profiler 两种模式

日常卡顿优先 System Trace（见下），方法级热点再用 Sampled。

4.2 System Trace（核心）

路径：CPU Profiler → Record → System Trace（或 Profiler → + → System Trace）。

录制 5～10 秒复现卡顿 → 停止 → 在时间轴上：

1. 找到 Frames 轨道里 红色 / 超 16ms 的帧
2. 对齐 main 线程，展开该帧时间窗
3. 看大块切片名称：
   • RecyclerView / onBindViewHolder → bind 过重
   • measure / layout → 布局复杂
   • DrawFrame / Record View#draw → 过度绘制
   • GC / HeapTaskDaemon → 分配过多

与 Handler 消息循环 对照：Choreographer#doFrame 在 main 线程执行，Trace 里应能看到 traversal 阶段。

4.3 导出 Perfetto（推荐）

AS 内嵌 Trace 查看器在低配 Mac 上 交互 lag 明显。更轻量的做法：

1. System Trace 录制完成 → Export trace（.perfetto-trace 或 .trace）
2. 打开 Perfetto UI 拖入文件
3. 使用 SQL 或切片搜索 sched, binder, RV OnBindView 等

这也是原文提到的现实：Profiler 开着 AS 已经卡，再嵌一层分析更卡——导出离线看往往更顺手。

4.4 其他卡顿工具

五、耗电量分析（Energy Profiler）

Energy 面板按 系统归因 展示耗电来源（不同 API 级别粒度略有差异）：

5.1 排查步骤

1. 充至固定电量，关闭其他 App 干扰（理想实验环境）
2. Energy Record → 后台静置 / 典型用户路径 10～30 分钟
3. 看 WakeLock 与 Network 峰是否与 AlarmManager、FCM、自研推送重合
4. 对照代码：WorkManager 约束是否 RequiresBatteryNotLow、Doze 下是否仍唤醒

5.2 与 Battery Historian

Google 曾推 Battery Historian（解析 bugreport）。Energy Profiler 适合 调试期短链路；Historian 适合 整机长时间 日志。二者互补。

六、网络流量分析（Network Profiler）

Network 面板以 时间线 展示 TCP/HTTP 请求（HTTPS 可见元数据，body 需额外配置）。

6.1 读图要点

6.2 与 Charles / Proxyman 的分工

接口逻辑错误用抓包；与帧卡顿叠加（等网络 callback 在主线程更新 UI）用 Profiler 时间轴更直观。

七、ANR 分析

ANR（Application Not Responding）是 主线程长时间未处理输入（通常 5s）或 BroadcastReceiver / Service 超时。

7.1 获取 traces

traces.txt 里找 "main" prio=5 tid=1 的 Java 栈，看阻塞点：

• BinderProxy.transact → 主线程同步 IPC
• SQLiteDatabase.lock → 主线程查库
• Object.wait / synchronized → 死锁或等锁
• Native 解码 / IO

7.2 与 Profiler 的关系

ANR 发生 当时 很少正好开着 Profiler。标准做法是：

1. traces 定 代码栈
2. System Trace / Perfetto 看 是否有 IO on main、锁竞争、慢 bind
3. StrictMode + 单元测试防回归

7.3 常见 ANR 类型

八、实战侧栏：Profiler 很好，但别神话

原文的坦诚判断值得写进文档：Android Profiler 把流程标准化，对棘手问题帮助很大；但它本身也吃资源。

典型开发机：M2 + 16GB Mac mini，同时开 Android Studio、企业微信、浏览器、代码加密/agent 软件——AS 已经常卡，再 attach Profiler 录制 Trace，体验是一万个不情愿。

没有 32GB 以上机器、团队也不重视性能，个人不必强行当「性能警察」——把证据链（复现视频、Trace 一帧截图、改前后对比）留给 真正要优化时 再用 Profiler 一击中的。

这并不否定 Profiler，而是 工具服从场景与硬件。

九、标准排查清单（可贴 Sprint）

9.1 滑动卡顿

• 复现路径 + 机型 API
• System Trace 录 5～10s，导出 Perfetto
• 找 >16ms 帧，区分 bind / layout / draw / GC
• Layout Inspector 看 Item 层级
• 改完 Macrobenchmark 或手动对比 FPS

9.2 内存 / OOM

• LeakCanary 是否已报
• 进出页面 Heap Dump + GC 后对比实例数
• Bitmap 尺寸与 Glide 配置
• 列表是否 Paging、缓存是否有上限

9.3 耗电

• Energy Record 对照 WakeLock / Network
• Doze 下行为、Alarm 是否精确重复
• 定位 / 传感器是否 unregister

9.4 ANR

• traces.txt main 栈
• 是否主线程 Binder / DB / 锁
• Broadcast / Service 是否超重

十、与旧图对照：Profiler 侧边栏

早期笔记里留过一张 Profiler 侧边栏截图，便于对照 AS 界面位置：

新版 Android Studio 将部分能力收拢到 App Inspection，菜单位置可能略有变化，但 Memory / CPU / Network / Energy 四类能力未变。

十一、延伸阅读

一句话总结： Android Profiler 是 「标准流程化」的性能法庭——内存看引用链、卡顿看帧预算、耗电看 WakeLock、网络看时间线；ANR 靠 traces.txt 定主因。日常先用经验与 StrictMode 筛大类，棘手时再上 Trace，能导出 Perfetto 就别死磕 AS 里拖时间轴；机器内存不够时，别和工具较劲，和团队要性能预算。