企业官网建设流程全解析

做 Android 功耗排查这几年，我最大的感受是：CPU 功耗出问题，大家都会查，外设功耗出问题，很多人会卡很久。原因不是没有工具，而是没有把“外设耗电”这件事放进正确的分析框架里。外设功耗问题的隐藏性很强，它往往不像屏幕那样一眼可见，也不像 CPU 那样频繁更新运行状态，但它会通过中断、唤醒、供电轨悄悄把电池拉空。这次作为“Android 功耗系列专题理论”的第六篇，我把外设功耗的分析方法单独拿出来讲，因为这一块太容易被人忽略，又太值得单独整理成一套方法论。

这篇文章适合三类人：一是正在做整机功耗优化的系统工程师，二是排查 App 异常耗电的应用开发者，三是想搞清楚“为什么后台待机电流忽高忽低”的硬件/驱动同学。读完你能拿到一套可以照着执行的分析流程，以及我在真实项目中踩过的坑和验证过的判断。

1. 外设功耗问题的本质：电流发生在哪，账本记在谁头上

1.1 为什么 CPU 功耗正常，外设却在偷偷耗电

先明确一个概念：Android 系统里的“外设”，并不仅仅指插在 OTG 口上的 U 盘。它通常覆盖所有通过 I2C、SPI、UART、USB、GPIO 与应用处理器（AP）通信的外部硬件，比如传感器、触摸屏、指纹模组、GNSS 模块、蓝牙控制器、Wi-Fi/BT 模组、音频 Codec、Camera Sensor、NFC 等。这些器件要么由 AP 直接供电，要么挂在某个 PMIC 的 LDO/DC-DC 电源轨上。

CPU 功耗出现异常，你可以在top、systrace、CPU frequency里找到证据；但外设功耗异常时，CPU 可能全程都在深度睡眠，频率曲线很漂亮，systrace 上也看不到明显任务。可整机电流就是在上涨。原因很简单：外设的工作不由 CPU 执行指令来衡量，而是由“供电轨有没有开、器件有没有在工作状态、中断有没有频繁触发”来衡量。

我之前处理过一个典型案子：机器待机电流凭空多了 80mA，Battery Historian 显示整洁得接近完美——没有异常 WakeLock，没有音频占用，没有 GPS 请求。后来逐个关闭外设，才发现是某个 App 通过 SensorManager 把地磁传感器的采样频率拉到了 100Hz。屏幕是灭的，CPU 也只在传感器上报时才醒一下，但传感器模组本身被持续驱动，电流自然降不下来。

1.2 外设功耗的三条路径：硬件常供电、驱动请求、应用唤醒

分析外设功耗时，我习惯先回答三个问题：谁的电流在涨？谁在请求外设工作？谁允许了这次请求？这三个问题对应三条路径。

第一条是硬件常供电路径。某些外设只要电源轨不掉电，就会持续消耗静态电流。比如底部的 Codec 常供电用于耳机插拔检测，指纹模组待机用于触摸唤醒，GNSS LDO 如果驱动没有在休眠时关闭，模块就会一直处于搜索状态。这类问题通常在“设备重启后静置待机”的场景里最容易暴露。

第二条是驱动请求路径。外设驱动主动向 PMIC 申请电源，或者通过enable_irq_wake把中断注册为唤醒源。Android 的标准做法是，外设驱动的 resume/ suspend 要和设备的电源状态绑定，但厂商定制 ROM 里经常出现suspend回调没有关闭 LDO、runtime PM没配置好、或者regulator引用计数泄漏，导致外设永远处于 active。

第三条是应用唤醒路径。App 不直接操作硬件，但它可以通过 HAL 或 Framework 发起请求，比如SensorManager制定采样率、LocationManager请求 GPS、BluetoothAdapter开启扫描。应用层看起来只是“订阅了一下”，但驱动层为了满足订阅，会把器件强制拉高到 active 状态，耗电也随之产生。

所以外设功耗排查不能只看一个数据源。你要同时盯着“硬件状态、驱动行为、应用请求”这三层，才能把根因定位到具体环节。这也是后面所有分析方法的总纲。

2. 拿到这五类数据，外设功耗就有据可查

2.1 系统账本：dumpsys batterystats 的正确打开方式

提到 Android 功耗分析，绕不开dumpsys batterystats。它相当于系统维护的一份“功耗账本”，记录每个 UID 在各类硬件上的估算消耗。对外设排查来说，我关心的不是它的绝对数值，而是相对变化。

实际操作中，先用adb shell dumpsys batterystats --reset清空历史，然后跑一段固定场景，最后导出带--checkin的键值对格式数据：

adb shell dumpsys batterystats --checkin

输出里可以按 UID 过滤：

adb shell dumpsys batterystats --checkin | grep -E "uid,1000|uid,10[0-9][0-9]|Gps|Sensor|Audio|Camera"

重点看Sensor、Gps、Audio、Camera和Bluetooth这几类条目的time和power字段。比如某个应用在后台长时间持有 GPS 定位请求，batterystats 会把它单独记录为gps运行时长；如果传感器采样频率异常，也会体现在sensor的累计时长里。

但有一点必须提醒：batterystats 是基于power_profile.xml的估算值，不是实测值。它的价值在于快速定位“谁在长时间使用某个外设”，而不是代替电流表。它能告诉你账记在谁头上，但账是不是准确，要靠物理测量来校准。

2.2 真实电流：从电源轨和 battery 节点取数

系统账本是软账，电流计才是硬账。很多外设功耗问题，最终都要回到“整机电流”或“某条电源轨电流”上验证。

最简单的方法是读电池节点：

cat /sys/class/power_supply/battery/current_now

current_now单位通常是微安（uA），每次读取代表瞬时电流。但要分析外设的行为变化，只看瞬时值不够，最好配合定时采集脚本，把一段时间内的电流曲线拉出来。可以参考下面的做法：

adb shell "while true; do date +%s.%N; cat /sys/class/power_supply/battery/current_now; sleep 0.5; done" > current.log

采集完再画成曲线，看电流有没有周期性突起，比如每隔几秒抬升一次。外设导致的异常电流往往有固定节律：GPS 每隔几秒重搜一次，蓝牙每隔几秒扫描一个信道，传感器每隔多少毫秒唤醒一次 CPU。

更精细的办法是抓电源轨。外设独立供电时，找 PMIC 对应的 LDO 输出点串电流表，或者用电源分析仪（如 Monsoon Power Monitor）直接看瞬态电流。我不建议一上来就拆板抓轨，成本太高，通常先用整机电流确定时间段，再有针对性地查外设状态。

2.3 中断与唤醒源：外设“下半夜加班”的案底

外设在待机状态下的耗电，很多不是持续供电，而是“频繁唤醒 AP”。每一次唤醒，Android 都要从 suspend 状态恢复，跑一段代码，再睡回去。这个过程虽然有十几毫秒到几十毫秒，但每小时几百次累积下来，电流非常可观。

排查唤醒类外设功耗问题，核心是看wakeup_sources：

adb shell cat /sys/kernel/debug/wakeup_sources

重点关注active_count和event_count的增量，以及wakeup_count是否在持续上涨。常见的外设唤醒源包括：

• qpnp-rtc或rtc_alarm：定时器唤醒，不一定是外设问题。
• bt_host_wake/bluetooth：蓝牙 HCI 唤醒，经常由 BLE 连接事件触发。
• sensorhub_wake：Sensor Hub 检测到 motion 事件。
• gnss/gps_wake：GNSS 模块上报定位数据。
• headset_irq：耳机检测中断异常抖动。

配合/proc/interrupts也能快速判断外设中断频率。在进入场景前和执行场景后各抓一次：

adb shell cat /proc/interrupts

比对某个外设中断号的irq次数增量。如果屏幕关闭、CPU 空闲时，某个 GPIO 中断以每秒几次的频率触发，那基本可以断定外设有问题。

2.4 外设服务状态：sensorservice / location / bluetooth / audio

系统账本只能告诉你“谁在用”，驱动状态才能告诉你“外设在干什么”。Android Framework 层提供了一些服务状态的 dump 接口，异常排查时很好用。

传感器直接查 SensorService：

adb shell dumpsys sensorservice

输出里能看到每个 sensor 的 active 状态、采样率、是否使能、最小延迟。注意看active sensor列表里有没有不该在待机阶段启用的传感器，尤其是加速度计、陀螺仪、地磁计。如果某个传感器一直处于 active，回到batterystats里基本都能对应到某个 UID。

定位服务查 LocationManager：

adb shell dumpsys location

重点看active providers，GPS、Network、Fused 分别由谁请求，请求时间是多久，状态是ON还是OFF。GPS 模块在室内搜索卫星时，电流可能长时间停留在几十毫安以上，而用户根本感觉不到定位图标在闪烁。

蓝牙查 BluetoothManager：

adb shell dumpsys bluetooth_manager

关注AdapterState、isDiscovering、isScanning、连接设备列表。如果isScanning=true且没有应用前台界面在扫描，基本可以判定为后台扫描残留。

音频则查 AudioService：

adb shell dumpsys audio

看Record active的 uid、采样率、声道。麦克风常驻非常费电，而且还会联动 DSP/Codec 进入 active 状态。

2.5 内核 Trace：把时间轴和电流轴对齐

数据源再多，如果没有时间轴对齐，很难判断因果关系。我常用的做法是把systrace抓到的 CPU/中断事件和电流采样结果放在同一张图上观察。

抓 trace 的命令不复杂：

adb shell atrace --async_start -t 10 -b 8192 power freq idle sched adb shell atrace --async_stop -z > trace_output.trace

用 Perfetto 或 Systrace 打开后，把电流曲线的异常时间段切出来，看这个窗口内有没有对应的中断、唤醒、外设驱动执行。比如电流从 10mA 跳到 90mA，时间点上正好出现了一次sensorhub中断，随后一个小任务跑完又睡回去，那基本能把原因锁定在 Sensor Hub 上报路径上。

这一套组合我总结下来就是：batterystats 管“谁在用”、current_now 管“什么时候在耗”、wakeup_sources 管“谁在唤醒”、sensorservice/location/bluetooth 管“外设处于什么状态”、trace 管“最后的因果对齐”。五类数据凑齐，外设功耗问题基本就跑不掉了。

3. 四种高发外设耗电场景的根因拆解

3.1 GPS/位置服务：不是每次都定位，而是每次都在“捕获”

GPS 外设的功耗大头不在“已经定位成功后”，而在“捕获阶段”。冷启动捕获时，GNSS 模块要并行搜索多颗卫星信号，电流可能达到 80mA 到 200mA；定位成功后进入跟踪阶段，电流会下降到 30mA 左右，但依然不低。

所以 GPS 问题分析，关键不是看定位有没有成功，而是看“捕获动作发生了多少次”“持续了多久”。有些三方 App 在后台每隔几分钟请求一次singleUpdate，每次都会让 GNSS 模块重新冷启动。表面上每次定位只有两三秒，实际电流曲线里是一连串尖峰。

我建议的处理思路是，在dumpsys location里找到反复请求定位的 UID，然后看它的请求参数：power参数是POWER_LOW还是POWER_HIGH；interval是不是被设置成了 0。interval=0意味着尽快回调，驱动会直接启动 GNSS，根本不会等网络定位或融合定位。

另外要检查 GPS 状态机是否在定位结束后正常进入休眠。使用dumpsys location时如果 provider 状态一直是ON，说明驱动的stop没有真正关掉 GNSS LDO，这就是典型的驱动后门耗电。

3.2 蓝牙/BLE：扫描窗口、连接间隔与广播风暴

蓝牙外设功耗分析，比其他外设更依赖参数计算。BLE 的耗电不是“开没开”这种二元状态，而是由扫描窗口、扫描间隔、连接间隔、从机延迟共同决定。

先看扫描。标准的 BLE 扫描参数是scanWindow和scanInterval。如果某个 App 设置scanInterval=200ms、scanWindow=200ms，那意味着接收机在每个扫描周期内都在工作，功耗自然高。更合理的做法是拉大 interval、缩小 window，比如interval=1000ms、window=100ms，这样射频接收占空比只有 10%。

再看连接。BLE 主从连接事件到达越频繁，两端唤醒越频繁，电流越高。连接间隔从 7.5ms 到 4s 可调，但很多 App 默认用极短的连接间隔去换低时延，忽略了待机功耗。如果业务场景允许，把连接间隔拉到 100ms 以上，再辅以从机延迟（slave latency），电流能降一个数量级。

排查时，我会先通过bluetooth_manager的 dump 看当前扫描状态和连接参数，再通过/proc/interrupts里的蓝牙 HOST WAKE 中断次数确认唤醒频率。一个经验法则是：如果待机时蓝牙唤醒中断每秒超过几次，先检查是不是有设备在频繁广播、重连或者扫静态地址。

3.3 传感器/Sensor Hub：采样率、批处理与竞态唤醒

传感器是外设功耗问题里最容易中招的，因为它的耗电藏在采样率和上报路径里，很难被普通人注意到。

传感器功耗由两个部分构成：器件本身的采样功耗，以及上报数据时 AP 的唤醒功耗。通常器件采样功耗不大，真正费电的是“数据一帧一帧把 CPU 唤醒”。Android 为了解决这个问题，引入了 Sensor batching（硬件 FIFO）机制，数据可以先在 Sensor Hub 里缓存，而不是每来一帧就唤醒 AP一次。

但实际项目里，下面两种场景经常出问题：

第一种，App 把采样率调得很高。加速度计调到 200Hz，CPU 如果每帧都被唤醒，电流立刻涨。处理办法是应用层调低采样率，或者开启硬件批处理。

第二种，Sensor HAL 的 batch 参数没有正确传给驱动，硬件 FIFO 没有生效。dumpsys sensorservice里看每个 sensor 的maxDelay和当前请求的batch时间，如果minDelay很短、maxDelay又很大，但实际上报仍然是逐帧唤醒，基本可以判定 HAL 层没有启用硬件 FIFO。

另外还要注意竞态唤醒。比如一个低功耗的“抬手亮屏”场景，加速度计会一直处于后台运行模式。它虽然单次电流低，但会导致 AP 频繁从 suspend 恢复，整机功耗反而变高。这类功能设计时就要权衡好“事件检测”和“系统睡眠时间”的比例。

3.4 音视频外设：音频通路、Camera Sensor 与麦克风常驻

音频和 Camera 外设的功耗，经常被归到“多媒体功耗”里面，很少有人把它当外设问题单独排查。但从电源轨角度看，它们同样符合外设功耗的规律。

音频方面最典型的是麦克风常驻。Android 的语音唤醒、录音权限、甚至某些“偷听”类应用，都会让 Mic 通路保持开启。Mic 通路一旦开启，Codec 就要上电，Audio DSP 可能也要跟着跑。dumpsys audio里如果看到Record active的背景时间特别长，且来源不是通话或语音助手，就要警惕。

Camera 方面要区分“Sensor 上电”和“ISP 工作”。Camera Sensor 上电后即使没在出流，也会消耗一定的电源；而真正出流时，Sensor+ISP 的组合电流可能达到几百毫安。排查时我习惯先看dumpsys media.camera的摄像头状态，再结合 Camera HAL 的 log 确认 preview/capture session 有没有被异常持有。

一个容易被忽略的点是：某些 App 在后台申请了 Camera 权限，但没有真的 preview，而是通过CameraDevice.StateCallback保持 Session 打开。硬件层面摄像头可能一直处于上电待命状态，整机电流长期维持在高位。这种问题在 batterystats 里通常归类为camera时间，但如果不看外设状态，很难猜到是 Session 泄漏。

4. 一次完整的外设功耗排查，我是这么做的

4.1 环境固定与基线采集

外设功耗问题最怕变量太多，所以我每次都会先做环境固定。具体来说：

• 手机充到 80% 以上，拔掉充电器，用电池供电。
• 关闭自动亮度，固定 30% 屏幕亮度，或者直接灭屏测试。
• 关闭系统动画，避免 UI 渲染干扰。
• 把 Wi-Fi、移动数据、蓝牙等统一到一个固定状态，不建议全关，因为全关可能导致某些外设进入不可用状态，掩盖问题。
• 确认没有后台下载、系统更新等杂活。

固定环境后，先静置 10 分钟，采集基线电流。基线电流和异常场景电流之间的差值，就是我们要分析的外设增量。这一步不能省，因为很多外设本来就有一个“基础工作电流”，只有先知道基线，才能判断增量的量级。

4.2 场景重现与增量定位

接下来是场景重现。如果是后台耗电类问题，就用一个干净应用列表跑同样的操作，比如灭屏待机 30 分钟；如果是某个高耗电场景，就在固定亮度下跑那个场景，同时记录系统 log 和电流采样。

场景重现过程中，我建议同时开三路数据：

adb logcat -v threadtime > logcat.log adb shell dumpsys batterystats --checkin > bs.txt adb shell "while true; do cat /sys/class/power_supply/battery/current_now; sleep 0.2; done" > current.log

场景结束后，再把wakeup_sources和/proc/interrupts各抓一遍。把这四份数据放到一起，先找“电流上升窗口”。比如从电流日志看到 300 秒处开始多出 50mA，再到 logcat 对应时间段找有没有外设相关的 HAL 调用，最后到 batterystats 里确认这个窗口里哪个 UID 消耗了哪个外设。

4.3 逐项开关法定位“嫌疑外设”

如果数据源没有直接把嫌疑对象指出来，那就用最笨但最可靠的方法：逐项开关。我通常把外设分成几组，比如传感器组、GNSS 组、蓝牙组、音频组、Camera 组、NFC 组，然后按“先软件、后硬件”的顺序逐一关闭。

软件层面的关闭方式：

• 传感器：adb shell cmd sensorservice set_sensor_state不好直接操作，可以用adb shell settings put secure location_mode 0之类的间接方式，或者在开发者选项里关闭“传感器”相关权限。更实在的做法是禁用相关应用再跑一轮。
• GNSS：adb shell settings put secure location_mode 0后，如果电流不变，再用飞行模式下关闭 RF 的方式验证纯 GNSS 电源轨。
• 蓝牙：adb shell svc bluetooth disable，或者直接关掉系统蓝牙开关。
• 音频：杀掉所有有录音权限的 App，再临时禁用系统语音唤醒服务。
• Camera：退到桌面确认没有应用持有摄像头，再看电流。

每关掉一组，等两分钟，看电流曲线是否下降。如果关闭蓝牙后电流降了 50mA，嫌疑范围立刻缩小到蓝牙子系统。这种二分法虽然费时，但在多外设同时工作的场景里，它是唯一不会误判的方法。

4.4 从根因到修复：驱动层、框架层、应用层

定位到外设本身只是第一步，真正的难点在于判断该改哪一层。我一般用下面的表格来分配责任：

修复后一定要重新跑一遍基线，再用相同场景对比电流曲线。不要只看峰值电流降了没有，还要看“平均电流”和“唤醒次数”是否同时下降。很多修复只降了单次电流，但唤醒频率反而更高了，整机功耗不降反升，这是我最常见的一个误判陷阱。

5. 关于外设功耗的理论模型，我保留的几个实操观点

5.1 不要盲信 power_profile.xml

Android 的功耗估算依赖frameworks/base/core/res/res/xml/power_profile.xml，里面每个外设都被赋了一个power数值，单位是 mA。但这个文件本质上只是“出厂配置”，不同硬件的实际电流差异很大。比如同样加速度计，某个厂商的模组采样电流可能是 0.5mA，另一个厂商可能是 2mA。

所以我在项目里从来不用batterystats显示的 mAh 作为验收依据，只把它当“排序工具”。真正的功耗指标，一定要以实测电流为准。否则你会为了一个理论值调半天驱动，结果拿电流表一测，问题根本不在那个方向。

5.2 外设功耗一定是“场景相关”的

外设功耗最忌讳只看静态数据。一颗 GPS 芯片，静置时电流不到 1mA，但进入捕获模式后冲到 150mA；一颗蓝牙 SoC，休眠时可能是微安级别，连接后却要十几毫安。脱离场景谈外设功耗没意义。

我在分析报告里会固定写清楚“什么场景、什么采样率/间隔/参数、电流多少”。这样后续维护的人看到数据就能复现，不至于像我刚入行时那样，拿一个待机数据去解释所有问题，越解释越乱。

5.3 先降唤醒次数，再降单次电流

最后分享一个我踩过很多次坑之后的体会：外设功耗优化，优先级应该先是“减少唤醒次数”，其次是“降低单次工作电流”，最后才是“优化寄存器配置”。因为 Android 系统的主要待机功耗往往来自反复 suspend/resume，CPU 每次醒来都会带动总线、电源管理、调度器一起活动，这个损耗远大于外设本身。

所以拿到一个外设功耗问题，先别急着调外设的低功耗模式。先看它是不是把 AP 唤醒得太频繁。如果每秒唤醒几十次，即使每次只跑 2ms，积少成多也比保持外设一直工作更费电。把唤醒频率降下来，把数据攒批处理，再去看外设本身的采样电流，往往能收到比预期更好的效果。

外设功耗排查方法说穿了不复杂：数据、场景、逻辑。先拿到足够多的账本，再固定场景做增量分析，最后用逐项开关锁定嫌疑对象。只要你把这两三年的思路沉淀下来，任何一台手机的外设耗电问题都不会再是无头悬案。