android - 性能 - Perfetto - 功耗 分析教程及例子

Android Perfetto 功耗深度完整分析手册（超详细版）

包含：设备能力、抓包配置、UI轨道逐行解读、截图标注点位、5类真实耗电案例、SQL量化、排查SOP、踩坑大全

一、核心前置知识

1.1 Perfetto功耗分析能解决什么问题

1. 后台锁屏待机掉电快、一晚上耗电超标
2. 页面滑动、列表滚动手机明显发热
3. 退后台后进程频繁唤醒、CPU无法休眠
4. WakeLock长期持有导致整机无法深度挂起
5. 频繁GC、Binder频繁调用、Alarm广播心跳间接耗电
6. 前台高CPU计算导致大核高频拉高功耗

1.2 设备能力分级（最关键，决定分析精度）

等级1：Pixel 6+ / Android 10+（最强，硬件功耗轨）

支持 ODPM Power Rails 硬件电流采集，直接输出 mW 毫瓦实时功耗曲线，拆分独立模块耗电：

• CPU Big 大核功耗、CPU Little 小核功耗
• GPU、DDR内存、屏幕DISPLAY、WiFi、Modem、摄像头等
  可以做绝对值功耗量化，A/B版本对比耗电量。

等级2：国产绝大多数手机（小米/OPPO/vivo/荣耀等）

无硬件电流传感器，无法拿到mW数值，只能通过间接指标推断功耗根因：
CPU调频曲线、C-State深度休眠状态、WakeLock唤醒锁、系统suspend挂起/唤醒事件、线程Running活跃时长、GC触发次数、内核唤醒事件。
只能做相对功耗对比，优化前后看CPU休眠能力是否改善。

1.3 功耗测试铁律（不遵守数据完全无效）

1. 必须拔掉USB数据线：USB充电会强制CPU禁止进入深度Idle休眠，后台功耗数据彻底失真；
2. 测试前关闭省电模式、后台清理其他App，减少干扰；
3. 后台耗电录制时长≥120秒，前台操作≥60秒；
4. 亮度固定50%、关闭蓝牙/定位/5G，单一变量测试。

1.4 对比工具优劣

1.5 功耗四大底层根源（对号入座）

1. CPU持续活跃：线程死循环、高频轮询、大量计算，CPU无法进入C-State深度休眠；
2. WakeLock唤醒锁未释放：阻止系统整机Suspend挂起，手机一直浅休眠；
3. 频繁唤醒扰动：Alarm定时、心跳网络、广播、GC、Binder调用反复唤醒CPU；
4. 高频大核运行：重计算任务调度到大核高频运行，电压升高功耗指数上涨。

二、两种Trace抓取方案（附带录制页截图对应区域说明）

方式一：网页可视化录制（新手首选，界面分区标注）

2.1 打开地址

官方分析页：https://ui.perfetto.dev/

2.2 进入录制面板

左上角点击 Record new trace，页面分为三大区域（截图可直接对照查找）：

1. 左侧：Data Sources 数据源勾选区（核心配置）
2. 中上区域：包名过滤、录制时长、Buffer缓冲区大小
3. 右下区域：ADB设备选择、启动按钮

2.3 功耗分析全套必勾数据源（直接照搬）

模块1：功耗硬件与电源事件（核心）

Power 分类
✅ Battery drain & power rails  电池耗电曲线+硬件电源轨（Pixel生效）
✅ Android power events        WakeLock、挂起/唤醒、充电状态变更

模块2：功耗根源——CPU调度行为（必选）

Scheduling 调度分类
✅ CPU Scheduling        多核线程占用切片，看哪个核心满载
✅ CPU Frequency         CPU大小核动态调频折线，判断是否高频不降
✅ CPU Idle              C-State休眠状态，判断后台是否省电
✅ Thread states         线程R/S/D运行状态，区分真耗电/阻塞等待

模块3：定位具体耗电Java/Native代码

App 应用分类
✅ Java Method Sampling  Java方法采样，用于生成CPU耗时火焰图
✅ Atrace apps          勾选 view gfx activity input 追踪UI绘制耗时

模块4：辅助联动耗电诱因（建议全勾）

IPC → Binder transactions      频繁跨进程调用唤醒CPU
Memory → Android ART GC        频繁GC内存抖动导致CPU临时唤醒
Graphics → Frame timeline      高帧率频繁刷新额外耗电

2.4 参数填写（截图输入框点位）

1. Package name filter：填写被测App包名，过滤所有无关进程；
2. Recording duration：前台操作60s，后台静置120s；
3. Buffer size：固定64MB，防止长时间trace数据截断；
4. Compress trace：勾选压缩，文件更小。

2.5 录制操作步骤

1. 点击 Add ADB device 选择已开启USB调试的手机；
2. 点击 Start Recording 开始抓包；
3. 分两个场景复现：
   • 前台：快速滑动RecyclerView、连续打开关闭页面、动画循环播放；
   • 后台：打开App → 返回桌面 → 锁屏静置，等待完整2分钟；
4. 录制结束自动下载 .perfetto-trace 文件，拖拽进网页打开分析。

方式二：ADB命令一键全量抓取（自动化回归、批量测试）

完整版功耗+CPU联合抓包脚本（直接复制执行）

adb shell perfetto -o /data/misc/perfetto-traces/power_full_analysis.trace -t 120s -a --txt <<EOF
buffers { size_kb: 65536 fill_policy: DISCARD }

# 1. 硬件功耗轨、电池采样（Pixel设备输出mW功耗）
data_sources {
  config {
    name: "android.power"
    android_power_config {
      battery_poll_ms: 200
      collect_power_rails: true
    }
  }
}

# 2. 内核电源FTrace事件：WakeLock、系统休眠、唤醒
data_sources {
  name: "linux.ftrace"
  ftrace_config {
    ftrace_events: "power/suspend_resume power/wakeup power/wake_lock power/clock"
  }
}

# 3. CPU全套调度数据（功耗根源）
data_sources { name: "linux.sched" }
data_sources { name: "linux.cpu_freq" }
data_sources { name: "linux.cpu_idle" }
data_sources { name: "linux.thread_state" }

# 4. Java方法采样定位耗时代码
data_sources {
  name: "android.java_hprof"
  java_hprof_config { sampling_interval_ms: 10 }
}

# 5. 辅助排查项
data_sources { name: "android.gc" }
data_sources { name: "android.binder" }
data_sources { name: "android.atrace" atrace_categories: "view gfx activity" }
EOF

# 拉取文件到本地电脑
adb pull /data/misc/perfetto-traces/power_full_analysis.trace ./

三、Perfetto UI 轨道逐层深度解读（每一层对应截图可见元素）

标准排查流水线（严格按顺序执行）

1. 功耗轨看峰值耗电 → 2. Power Events检查WakeLock异常持有 → 3. CPU Idle判断是否深度休眠 → 4. CPU Frequency看是否长期高频 → 5. 定位高活跃线程 → 6. 线程状态区分计算/阻塞 → 7. 火焰图锁定耗电函数 → 8. SQL量化统计验收

3.1 顶层功耗总览轨道（截图最上方区域）

轨道1：Power Rails 硬件电源轨（Pixel手机独有截图）

每条曲线代表硬件瞬时功耗，单位mW：

1. CPU Big 曲线冲高凸起 → 前台列表滑动、算法计算、图片解码等高负载耗电；
2. CPU Little 持续小幅抬升 → 后台轮询、心跳线程、死循环导致待机耗电；
3. DISPLAY 屏幕功耗居高不下 → 页面频繁invalidate刷新、高刷新率常驻；
4. MEMORY 内存功耗波动 → 频繁GC、内存抖动连带耗电。
   操作：鼠标框选峰值时间段，可查看平均功耗、峰值功耗。

轨道2：Battery 电池状态轨道

三条曲线：Voltage电压、Current电流、Charge剩余电量

• 后台静置阶段 Current 负值越大，放电越快，耗电越严重；
• 电压持续缓慢下跌代表整机持续耗电。

轨道3：Power Events 电源事件切片（后台耗电核心判定）

（1）WakeLock 唤醒锁色块（截图长条矩形标记）

• 正常：短时瞬间获取立刻释放；
• 异常：横跨十几秒甚至上百秒的长条 PARTIAL_WAKE_LOCK，直接判定为耗电元凶；
  点击色块可查看：持有进程包名、自定义TAG标签，直接定位代码中申请唤醒锁未释放的逻辑。

（2）suspend_resume 系统挂起/唤醒事件

• 正常静置：长时间维持suspend系统深度休眠；
• 异常耗电：频繁 resume 唤醒 → 短暂运行 → suspend 休眠，反复跳变，CPU不停启停，功耗大幅增加。

3.2 中间层：CPU功耗根源轨道（截图核心分析区）

轨道1：CPU Frequency CPU频率折线图

纵坐标为主频MHz，数值越高功耗越大：

• 健康后台：频率直接降到最低低频档位；
• 异常耗电：频率长期卡在中高频不降，说明线程一直在占用CPU Running运行；
  前台滑动时大核频率瞬间拉满属于合理，后台必须降频。

轨道2：CPU Idle C-State 内核休眠状态（判断后台是否省电的黄金标准）

CPU内核休眠等级：C0（活跃运行，最耗电）→ C1~C7深度休眠（内核断电，极低功耗）

1. 合格表现：后台长时间停留在C4/C6/C7深度Idle；
2. 耗电实锤：绝大多数时间停留在C0活跃态，线程不断唤醒CPU无法休眠。

轨道3：CPU Scheduling 多核调度色块轨道

每一行代表一个物理CPU核心，彩色色块=线程占用该核心运行的时间片：

1. 单个核心色块100%填满 → 死循环单核满载，CPU拉满发热；
2. 大量碎片化零散色块 → 线程频繁上下文切换，内核调度开销额外耗电；
3. 重任务全部调度到小核运行 → 执行时间拉长，总功耗反而更高。

轨道4：Thread States 线程状态小字标记（截图切片上R/S/D标签）

用来区分真耗电和假高CPU：

判定口诀：
Wall总耗时 ≈ CPU Running时长 → 纯计算耗电，改代码；
Wall总耗时 ≫ CPU Running时长 → 阻塞等待，解决锁/IO/Binder。

3.3 底层：定位具体耗电代码——CPU火焰图（截图右键操作步骤）

1. 在持续大量Running的异常线程切片上右键 → Open flamegraph；
2. 视图切换为 Time（CPU执行耗时）；
3. 纵向为调用栈，横向柱子宽度=占用CPU时间占比，最宽叶子节点即为耗电最高方法；
4. 右键 Focus 聚焦整条调用栈，复制方法名全局检索代码修改。

补充：Release混淆包方法名为a.b.c，需要上传mapping.txt文件做符号还原；Native层耗电需要Root设备抓取heapprofd栈。

3.4 高阶：Perfetto SQL 量化功耗数据（底部Query面板直接执行）

SQL1：统计App所有线程CPU总运行时长（TOP耗电线程）

SELECT
  thread.name AS 线程名称,
  SUM(sched.dur)/1e6 AS cpu运行总毫秒
FROM sched
JOIN thread USING (utid)
JOIN process USING (upid)
WHERE process.name = 'com.xxx.你的应用包名'
GROUP BY thread.utid
ORDER BY cpu运行总毫秒 DESC
LIMIT 20;

SQL2：统计异常WakeLock持有总时长

SELECT
  tag AS wakelock_tag,
  SUM(dur)/1e6 AS 持有总毫秒
FROM slice
WHERE name LIKE '%wakelock%' AND process_name LIKE 'com.xxx.%'
GROUP BY tag
ORDER BY 持有总毫秒 DESC;

SQL3：线程状态耗时占比，区分计算耗电/阻塞等待

SELECT
  CASE thread_state
    WHEN 'Running' THEN 'CPU运行(真正耗电)'
    WHEN 'S' THEN '休眠等待(不耗电)'
    WHEN 'D' THEN '磁盘IO阻塞'
    ELSE '其他状态'
  END AS 状态分类,
  SUM(dur)/1e6 AS 耗时总ms
FROM thread_state
JOIN thread USING (utid)
WHERE process_name = 'com.xxx.你的包名'
GROUP BY 状态分类;

SQL4：查询主线程所有超过16ms耗时方法（前台发热卡顿）

SELECT name, dur/1e6 AS cost_ms
FROM slice
WHERE utid = (
  SELECT utid FROM thread
  WHERE process_name = 'com.xxx.app' AND name = 'main'
) AND dur > 16000000
ORDER BY dur DESC;

四、5个真实功耗问题实战案例（Trace截图特征+错误代码+完整修复）

案例1：后台子线程死循环无限轮询（待机耗电TOP1）

现象

App退到桌面锁屏，一晚掉电8%~15%，手机轻微发热。

Perfetto Trace截图特征

1. CPU Idle 几乎无法进入C4+深度休眠，长期停留在C0活跃态；
2. CPU Frequency 后台维持中高频，无法降频；
3. 自定义轮询线程在Little小核持续铺满Running色块；
4. Power Events无WakeLock，纯线程空跑唤醒CPU耗电。

错误代码

// Activity销毁未终止死循环，后台无限占用CPU
new Thread(() -> {
    while (isCheck) {
        pollNetworkStatus();
        // 无任何sleep，100%单核占用
    }
}).start();

修复方案

1. onDestroy() 中将 isCheck = false 终止循环；
2. 循环内增加 Thread.sleep(500) 降低轮询频率；
3. 替换为 Handler.postDelayed、WorkManager 定时任务，避免裸线程死循环。

案例2：WakeLock申请后忘记release，整机无法深度休眠

现象

只要打开过App，整机待机耗电暴增，Battery Historian可看到长期Partial WakeLock。

Trace截图特征

Power Events轨道出现超长不间断PARTIAL_WAKE_LOCK长条色块，附带自定义TAG标签。

错误代码

PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "UPLOAD_FILE_TAG");
wakeLock.acquire();
// 上传完成忘记调用 release()

修复

1. 任务finally块强制 wakeLock.release()；
2. onPause/onDestroy兜底释放；
3. 使用超时自动释放：wakeLock.acquire(30000) 30秒自动解锁。

案例3：RecyclerView onBind大量计算，前台滑动发热高功耗

现象

上下滑动列表手机发烫，帧率下降、掉帧，CPU占用飙升。

Trace截图特征

1. Power Rails CPU Big大核功耗曲线明显冲高；
2. CPU Frequency 大核拉满最高频率；
3. Main主线程大量Running状态，火焰图最宽模块为onBindViewHolder；
4. 内部包含同步Bitmap解码、Html.fromHtml富文本解析、正则替换。

错误代码片段

@Override
public void onBindViewHolder(VH holder, int position) {
    // 主线程同步解码大图，CPU密集操作
    Bitmap bitmap = BitmapFactory.decodeFile(imgPath);
    // 实时解析富文本，CPU消耗极大
    CharSequence richText = Html.fromHtml(item.getContent());
}

修复方案

1. 图片全部使用Glide/Coil异步加载，禁止主线程decode；
2. 富文本、正则、JSON解析在子线程预计算并缓存；
3. 使用DiffUtil局部刷新，替换notifyDataSetChanged()全局刷新，减少onBind频繁调用；
4. 简化Item布局层级，降低measure/layout耗时。

案例4：频繁GC内存抖动，微小但持续耗电+滑动卡顿

现象

滑动轻微掉帧，后台静置小幅异常耗电，无明显高CPU线程。

Trace截图特征

1. ART GC轨道密密麻麻连续竖线标记；
2. Dalvik堆内存频繁锯齿状上涨回落；
3. CPU短暂被唤醒执行GC，打断Idle休眠。

根因

onBind中循环new临时对象、频繁创建String、未复用Drawable/Bitmap，触发频繁STW垃圾回收。

修复

1. 对象池复用列表实体类；
2. Bitmap页面销毁主动recycle，开启inBitmap内存复用；
3. 循环字符串拼接使用StringBuilder，减少临时String创建。

案例5：频繁Alarm/心跳网络导致CPU反复唤醒耗电

现象

锁屏后每几十秒CPU短暂唤醒一次，累积一晚上耗电可观。

Trace截图特征

1. suspend_resume事件高频交替出现，短时间唤醒立刻休眠；
2. CPU Idle无法长时间停留在深度C-State；
3. Binder轨道频繁出现AlarmManager事务调用。

修复

1. 合并多个Alarm定时任务，拉长间隔；
2. 使用批量心跳、批量网络请求，减少单次唤醒次数；
3. 前台活跃时开启心跳，退后台降低频率或暂停。

五、全界面截图点位汇总（打开Perfetto直接对应查找）

1. 录制配置页截图点：Record new trace → Power数据源勾选框、Scheduling调度全勾选、Java Method Sampling勾选、包名过滤输入框；
2. 硬件功耗截图点：Power Rails多条硬件功耗曲线、耗电峰值凸起区域；
3. 电源事件截图点：WakeLock超长色块标记、suspend/resume系统唤醒标记；
4. CPU功耗截图点：CPU Frequency频率折线、CPU Idle深度休眠色块、多核调度彩色切片；
5. 线程与火焰图截图点：Thread State R/S/D小字标签、线程切片右键打开CPU耗时火焰图；
6. SQL统计截图点：底部Query输入框执行功耗统计结果表格；
7. 辅助联动截图点：ART GC密集竖线、Binder长条事务块、FrameTimeline红色丢帧块。

六、高频踩坑避坑终极清单

1. 非Pixel设备无数值功耗，只看CPU休眠能力、WakeLock、调频做相对对比，不要强行量化mW；
2. 功耗测试绝对不能插USB线抓包，充电会锁死CPU浅休眠，数据完全作废；
3. Java Method Sampling为抽样采集，极短微小函数无法捕获，重度循环、长耗时函数100%命中；Release包务必上传mapping.txt还原混淆方法名；
4. 严格区分Running真耗电（改代码）和S/D阻塞假耗电（解决锁、IO、Binder）；
5. 后台耗电排查优先级（从上到下）：WakeLock未释放 → 死循环轮询线程 → Alarm频繁唤醒 → GC内存抖动 → Binder频繁调用；
6. 大小核调度异常：重任务被扔到小核，虽然单核占用不高，但运行时间翻倍，总功耗更高，需要通过线程优先级轻微干预；
7. 偶发单帧、单次唤醒无需优化，持续性、高频次触发才需要整改。

七、团队标准化功耗排查SOP（可直接落地执行）

步骤1：环境准备

拔掉USB，关闭多余后台App，亮度固定，分别录制前台操作60s、后台锁屏静置120s两段Trace。

步骤2：宏观功耗判定

1. Pixel查看Power Rails是否存在CPU大/小核持续功耗凸起；
2. 所有机型检查Power Events是否存在超长WakeLock，有则优先修复。

步骤3：CPU休眠能力判定

查看CPU Idle能否长时间进入C4/C6/C7深度休眠，不能则定位持续活跃线程。

步骤4：代码根因定位

对高活跃Running线程右键打开CPU火焰图，优化热点耗时代码；阻塞类线程排查IO、同步锁、Binder调用。

步骤5：复测验证与量化验收

优化后重新抓包：

1. 后台CPU可长期深度Idle休眠，频率降至最低；
2. 无异常WakeLock长期持有；
3. SQL统计CPU总运行时长、WakeLock时长显著下降；
4. 前台滑动功耗峰值明显降低，无成片红色丢帧。

附加交付（需要我可以直接给你）

1. AI可直接绘图的每一步标注示意图描述文案；
2. Windows一键抓取功耗Trace批处理 .bat 脚本；
3. WakeLock、Alarm心跳、Native层so死循环三类专项排查细则。