跳到主要内容

能耗分析

功能概述​

能耗分析功能为研发团队提供应用程序耗电情况的实时监控和深度分析能力，帮助识别能耗瓶颈、改善用户体验。通过监控前台电流、电池温度、流量消耗等核心指标，全面评估应用的能耗表现，支撑应用能耗持续优化。

平台支持：能耗分析仅支持 Android 平台。

核心价值​

  • 能耗瓶颈识别：精准定位应用中的高能耗功能、模块和操作
  • 资源管理优化：合理管理 GPS、网络、传感器等硬件资源使用
  • 用户体验提升：减少耗电导致的卡顿、发热等性能问题
  • 应用质量保障：发现潜在问题，提升应用可靠性和稳定性

能耗分析的意义​

用户痛点

  • 应用耗电快，用户频繁充电
  • 设备发热严重，影响使用体验
  • 流量消耗大，增加用户成本

业务影响

  • 应用商店评分下降
  • 用户留存率降低
  • 负面评价增多

优化价值

  • 提升应用商店评分
  • 增加用户留存和使用时长
  • 减少用户投诉

使用场景​

场景一：定位服务优化​

应用频繁获取定位导致耗电和发热。

实践案例：

  • 设备温度监控显示使用时温度持续升高
  • 定位时长数据显示 10 分钟内定位超过 100 次
  • 定位到是定位更新频率设置过高
  • 优化为按需定位，定位次数降低 80%
  • 设备温度降低，用户反馈发热问题解决

场景二：版本能耗对比​

新版本发布前对比能耗表现，避免能耗退化。

实践案例：

  • 新版本前台电流值比旧版本高 30%
  • 归因分析发现新增的实时消息推送导致
  • 优化推送策略，采用长连接代替轮询
  • 前台电流值恢复正常水平

技术实现原理​

能耗指标采集实现​

电流采集​

采集策略

  • 每 5 秒获取一次电流值
  • 仅采集应用前台时的电流值
  • 仅采集手机非插电状态下的电流值

温度采集​

采集策略

  • 每 5 秒获取一次温度
  • 监听电池状态变化广播

流量采集​

采集策略

  • 每 5 分钟获取一次流量数据

能耗场景采集​

定位（Location）

  • 实现：获取定位次数和定位时长
  • 采集时机：调用 LocationManager 相关方法时实时获取
  • 监控指标：定位次数、单次定位时长、累计定位时长

Alarm

  • 实现：获取 Alarm 唤醒次数
  • 采集时机：调用 AlarmManager 相关方法时实时获取
  • 监控指标：Alarm 设置次数、WakeUp 类型唤醒次数

WakeLock

  • 实现：获取 WakeLock 次数和持有时长
  • 采集时机：调用 PowerManager 相关方法时实时获取
  • 监控指标：WakeLock 获取次数、单次持有时长、累计持有时长

能耗异常定义​

能耗异常是指以下三类指标超过设定阈值：

  • 获取 Location 时长超过阈值
  • AlarmManager 设置次数超过阈值
  • WakeLock 唤醒时长超过阈值

异常判定类型（8 种）

异常类型判定条件默认阈值
定位单次使用最长时长单次定位时长超过阈值120 秒
定位10分钟内获取次数10 分钟内定位次数超过阈值4 次
定位10分钟内查询时长10 分钟内定位累计时长超过阈值240 秒
Wake Lock 单次持有时长单次持有时长超过阈值5 秒
Wake Lock 10分钟内获取次数10 分钟内获取次数超过阈值240 次
Wake Lock 10分钟内持有时长10 分钟内累计持有时长超过阈值120 秒
Alarm（wake_up类型）10分钟内唤醒次数10 分钟内 WakeUp 类型唤醒超过阈值5 次
Alarm 10分钟内唤醒次数10 分钟内总唤醒次数超过阈值10 次

异常触发规则

  • 相同类型的异常在同一周期（10 分钟）内只触发一次
  • 下一个周期重新判定和触发

数据上报机制​

指标数据上报

  • 数据类型：电流、电池温度、流量、定位时长、Alarm 次数、WakeLock 时长
  • 上报频率：每 5 分钟上传一次
  • 失败处理：上传失败缓存本地，等待下个周期上传
  • 成功清理：上传成功后删除本地缓存

异常数据上报

  • 上报频率：每 1 分钟上传一次
  • 失败处理：上传失败缓存本地，等待下个周期上传
  • 成功清理：上传成功后删除本地缓存

可靠性保障

  • 本地缓存确保数据不丢失
  • 批量上传减少网络开销
  • 成功删除避免重复上传

核心功能​

1. 指标分析​

趋势分析​

展示能耗核心指标的时间趋势变化。

核心指标

指标说明采集频率
前台电流值功率值是设备耗电的核心指标，由电压与电流决定。设备电压一般处于稳定状态，电流值的趋势能反映设备的耗电状况。App 前台时，耗电主要来源于该 App每 5 秒
电池温度设备的电池温度，温度越高说明设备耗电越高每 5 秒

分位值分析

趋势图默认展示平均值，可切换查看不同分位值：

  • P25、P50、P75、P90、P99
  • 默认展示：P75

数据列表​

展示各页面的前台电流值和电池温度分布：

功能特性

  • 按页面统计电流和温度指标
  • 支持页面名称搜索过滤
  • 支持导出列表数据
  • 展示各分位值数据

应用场景

  • 识别耗电最高的页面
  • 对比不同页面的能耗差异
  • 优先优化高频高耗电页面

详情页面​

展示单个页面的能耗详细数据：

维度分析

  • 按 App 版本、设备型号、操作系统全称的维度过滤
  • 识别特定维度下的能耗问题

详情列表

  • 展示该页面的能耗明细数据
  • 单样本级别的能耗分析

2. 归因分析​

过滤条件​

支持多维度数据过滤：

  • 应用版本、设备、操作系统、渠道等

趋势分析​

展示能耗归因指标的时间趋势，帮助定位能耗根因。

归因指标

指标说明采集方式
流量流量使用情况（移动流量 + WiFi 流量）每 5 分钟
获取 Location 时长定位使用时长实时（调用时）
AlarmManager 设置次数WakeUp 类型的 Alarm 唤起次数实时（调用时）
WakeLock 唤醒时长WakeLock 被持有的时间长度实时（调用时）

分位值分析

  • 趋势图默认展示平均值
  • 可切换查看：P25、P50、P75、P90、P99

分布分析

  • 趋势图右侧可按不同维度过滤
  • 查看归因指标的分布状况

3. 异常分析​

过滤条件​

支持多维度数据过滤：

  • 应用版本、设备、操作系统、渠道等

趋势分析​

展示能耗异常指标的时间趋势。

异常指标

指标说明计算公式
异常次数过滤条件下发生耗电异常的次数-
异常率耗电异常占应用启动的比例耗电异常次数 / 总启动次数
影响设备数发生耗电异常的设备数去重统计
影响设备占比受影响设备的比例发生耗电异常的设备数 / 总活跃设备数

异常列表​

展示发生能耗异常的明细数据。

智能聚合

  • 按采集的异常线程堆栈首行 App 调用栈进行聚合归类
  • 相同根因的问题归为一组
  • 减少重复排查工作

过滤维度

  • 异常堆栈、异常 ID、userID
  • 处理人、标签
  • 异常类型、异常状态

功能特性

  • 支持导出异常列表
  • 点击异常问题查看详情

异常详情​

异常类型、信息

展示异常的基本信息：

  • 异常类型（Location、Alarm、WakeLock）
  • 异常触发条件
  • 异常次数和影响范围

异常列表

发生异常的明细数据列表：

  • 异常发生时间
  • 影响的设备和用户
  • 异常详细信息

上下文信息

异常发生时的完整环境信息：

用户信息

  • UserID、设备 ID
  • 异常发生时间、会话时长

应用信息

  • 应用版本
  • UI 朝向

设备信息

  • 设备型号、操作系统
  • CPU 型号、CPU 指令集
  • 设备内存、剩余内存
  • 应用占用内存、剩余存储空间

网络信息

  • 地域、运营商、接入方式

堆栈信息

发生异常的线程调用栈信息：

  • 完整的方法调用链路
  • 定位具体的代码位置
  • 支持符号化/反混淆

异常溯源

发生异常时触发的操作轨迹：

  • 用户操作路径
  • 页面跳转序列
  • 网络请求记录

自定义信息

通过 SDK API 设置的自定义信息：

NBSAppAgent.setUserCrashMessage(String key, String value);

用途

  • 记录业务相关参数
  • 保存用户操作状态
  • 辅助问题定位

能耗异常阈值设置​

设置路径：应用列表 → 设置 → 能耗设置

默认阈值​

指标名称默认值单位说明
定位单次使用最长时长120秒定位单次使用多久当作异常上报
定位10分钟内获取次数4次定位10分钟内使用几次当作异常上报
定位10分钟内查询时长240秒定位10分钟内使用多久当作异常上报
Wake Lock 单次持有时长5秒Wake Lock 单次持有多久当作异常上报
Wake Lock 10分钟内获取次数240次Wake Lock 10分钟内获取几次当作异常上报
Wake Lock 10分钟内持有时长120秒Wake Lock 10分钟内持有多久当作异常上报
Alarm（wake_up类型）10分钟内唤醒次数5次Alarm（wake_up类型）10分钟内唤醒几次当作异常上报
Alarm 10分钟内唤醒次数10次Alarm 10分钟内唤醒几次当作异常上报

阈值调整建议​

按应用类型调整

应用类型定位阈值WakeLock 阈值Alarm 阈值
地图导航类放宽（持续定位）标准标准
社交通讯类标准放宽（消息推送）放宽（推送唤醒）
工具效率类收紧（很少定位）收紧收紧
内容娱乐类标准标准标准

调整策略

  1. 建立基线：使用默认阈值运行一段时间
  2. 分析数据：查看异常率和影响设备占比
  3. 合理设定：根据业务特点调整阈值
  4. 持续优化：定期 review 和调整

能耗分析指标采集支持矩阵​

指标支持系统版本说明
前台电流量Android 5+通过 BatteryManager 获取
电池温度Android 5+通过系统广播获取
AlarmManagerAndroid 5+Hook 方式采集
WakeLockAndroid 5+Hook 方式采集
流量Android 6+NetworkStatsManager 或 proc 文件
LocationManagerAndroid 5 ~ 12Hook 方式采集

注意：LocationManager 在 Android 13+ 上采集方式可能受限，建议关注后续版本支持。

性能优化指南​

常见能耗问题​

问题一：定位耗电高​

现象：定位次数或时长超过阈值

常见原因

  • 定位精度设置过高（GPS 精度）
  • 定位更新频率过高
  • 后台持续定位未停止
  • 定位监听器未及时移除

优化建议

  1. 按需定位

    • 根据业务需求选择定位精度
    • 网络定位优于 GPS 定位（耗电更低）
    • 非必要场景使用低精度定位

  2. 优化更新频率

    • 降低定位更新频率
    • 使用距离触发代替时间触发
    • 静止时停止定位更新

  3. 后台管理

    • 应用进入后台停止定位
    • 及时移除定位监听器
    • 使用后台定位 API（受限定位）

问题二：WakeLock 持有时长过长​

现象：WakeLock 持有时长或次数超过阈值

常见原因

  • WakeLock 持有后未释放
  • 后台任务持有 WakeLock 时间过长
  • 多个模块重复获取 WakeLock
  • 代码异常导致未释放

优化建议

  1. 及时释放

    PowerManager.WakeLock wakeLock = powerManager.newWakeLock(
        PowerManager.PARTIAL_WAKE_LOCK, "MyApp::WakeLock");

    try {
        wakeLock.acquire(10*60*1000L); // 10分钟超时
        // 执行任务
    } finally {
        if (wakeLock.isHeld()) {
            wakeLock.release();
        }
    }

  2. 设置超时

    • 使用 acquire(timeout) 设置超时时间
    • 防止异常情况下长时间持有

  3. 合理使用

    • 评估是否真的需要 WakeLock
    • 缩短持有时间
    • 使用 JobScheduler 替代部分场景

问题三：Alarm 唤醒次数过多​

现象：Alarm 唤醒次数超过阈值

常见原因

  • 定时任务设置过于频繁
  • 使用了 WakeUp 类型的 Alarm
  • 多个模块独立设置 Alarm
  • 未取消不再需要的 Alarm

优化建议

  1. 降低频率

    • 评估任务的实际需求
    • 延长 Alarm 触发间隔
    • 合并多个定时任务

  2. 使用非 WakeUp 类型

    // 优先使用非 WakeUp 类型
    alarmManager.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME,  // 非 WakeUp
        triggerAtMillis,
        intervalMillis,
        operation
    );

  3. 使用 WorkManager

    • 替代 AlarmManager 进行后台任务调度
    • 系统自动优化电池消耗
    • 更好的兼容性和可靠性

问题四：流量消耗过高​

现象：流量消耗异常增加，间接增加能耗

常见原因

  • 频繁的网络请求
  • 大文件下载未优化
  • 实时数据同步策略不合理
  • 未使用数据压缩

优化建议

  1. 请求优化

    • 合并请求，减少请求次数
    • 增量更新代替全量更新
    • 数据缓存，避免重复请求

  2. 数据压缩

    • 启用 GZIP 压缩
    • 使用更高效的数据格式（Protocol Buffers）
    • 图片压缩和适配

  3. 智能同步

    • WiFi 下才同步大文件
    • 弱网环境降低数据质量
    • 后台限制同步频率

最佳实践​

1. 建立能耗基线​

核心指标

  • 前台电流值 P75/P90
  • 电池温度 P75/P90
  • 异常率、影响设备占比

监控策略

  • 按设备档位建立不同基线
  • 定期对比基线数据
  • 及时发现能耗退化

2. 版本发布前能耗检查​

检查项

  • 对比新旧版本的前台电流值
  • 检查是否有新增能耗异常
  • 验证定位、Alarm、WakeLock 使用
  • 评估流量消耗变化

发布标准

  • 前台电流值不增加 > 15%
  • 能耗异常率 < 2%
  • 无严重的定位或 WakeLock 问题

3. 低功耗模式适配​

场景识别

  • 检测设备是否开启省电模式
  • 检测电量是否低于 20%

降级策略

  • 降低定位精度和频率
  • 延长后台任务执行间隔
  • 减少非必要的网络请求
  • 暂停非关键的后台同步

4. 持续优化机制​

定期巡检

  • 每周查看能耗异常 Top 10
  • 每月进行能耗专项分析
  • 每季度优化能耗策略

优化目标

  • 短期：修复严重能耗异常
  • 中期：优化高频能耗场景
  • 长期：建立低功耗设计规范

常见问题 FAQ​

Q1：为什么只监控前台电流？​

A：基于以下考虑：

1. 数据准确性

  • 前台时 App 是主要耗电来源
  • 后台时系统和其他应用也在耗电，难以准确归因
  • 前台电流更能反映 App 真实耗电

2. 样本代表性

  • 样本量足够大时，可抵消个体差异
  • 前台场景更统一，数据更稳定

3. 分析可行性

  • 前台场景可定位到具体页面和操作
  • 便于优化和验证效果

Q2：电池温度高一定是应用问题吗？​

A：不一定，需要综合分析：

可能原因

  1. 应用导致

    • 高 CPU 消耗
    • 频繁 GPU 渲染
    • 持续网络传输

  2. 设备问题

    • 设备散热设计
    • 电池老化
    • 环境温度高

  3. 系统问题

    • 系统更新
    • 系统服务异常

判断方法

  • 对比前台电流值：高电流 + 高温度 = 应用问题
  • 对比其他应用：仅本应用温度高 = 应用问题
  • 对比设备分布：特定设备温度高 = 设备问题

Q3：能耗分析如何与其他分析结合？​

A：关联分析，综合优化：

能耗 + CPU

  • 高 CPU 导致高能耗
  • CPU 优化同时降低能耗

能耗 + 网络

  • 频繁网络请求增加能耗
  • 优化网络策略降低能耗

能耗 + 用户体验

  • 高能耗可能导致卡顿、发热
  • 影响用户满意度和留存

综合优化路径

发现能耗高 → 查看 CPU/网络/定位指标
            ↓
         定位具体原因
            ↓
         制定优化方案
            ↓
         验证多个指标的改善

Q4：如何针对不同设备优化能耗？​

A：设备分级优化策略：

高端设备

  • 标准能耗策略
  • 追求功能完整性

中端设备

  • 平衡策略
  • 适度优化能耗

低端设备

  • 激进优化策略
  • 降低定位精度
  • 减少后台任务
  • 限制流量消耗

老旧设备

  • 检测电池健康度
  • 提示用户开启省电模式
  • 主动降级功能

Q5：能耗分析采集是否影响性能？​

A：影响极小，已充分优化：

性能开销

  • Hook 方式采集，轻量级实现
  • 异步处理，不阻塞主线程
  • CPU 开销 < 0.3%

能耗开销

  • 监控本身的能耗 < 0.5%
  • 采集频率已优化（5秒/5分钟）
  • 数据批量上传减少网络开销

可控性

  • 可远程关闭能耗监控
  • 可调整采集频率
  • 低电量时自动降级采集

总结​

能耗分析功能通过：

全面的指标体系 - 电流、温度、流量、定位、Alarm、WakeLock
精准的根因定位 - 归因分析、异常堆栈、上下文信息
智能的异常检测 - 8 种异常类型，自动聚合分类
完善的优化指导 - 从发现到解决的全流程支持

帮助研发团队优化应用能耗，提升电池续航，改善用户体验！