功耗基础知识介绍

首先我们回顾一下功耗的概念，这里比较容易和能耗搞混。解释一下为什么手机上用mA(电流值)来表征功耗水平，用 mAh(物理意义上是电荷值)来表征能耗水平。我们先来看几个物理公式。

P = I × U， E = P × T

能耗（E）：即能量损耗，指计算机系统一段时间内总的能量消耗，单位是焦耳(J)

功耗（P）：即功率损耗，指单位时间内的能量消耗，反映消耗能量的速率，单位是瓦特(W)

电流（I）：指手机电池放电的电流值，手机常用 mA 为单位

电压（U）：指手机电池放电的电压值，标准放电电压 3.7V，充电截止电压 4.35V，放电截止电压 2.75V（以典型值举例，不同设备的电池电压数值有差异）

电池容量 ：常用单位 mAh，从单位意义上看是电荷数，实际表征的是电池以典型电压放电的时长。
如下面的功耗测试图所示，手机通常以恒定的典型电压工作，为了计算方便，就把电压恒定为 3.7V，那么 P = I × 3.7， E = I × 3.7 × T，即用 mA 表征功耗，mAh 表征能耗。

总结：对同一机型，我们用电池容量(mAh)变化的来表征一段时间总能耗，用平均电流(mA)来表征功耗水平；如 4000mAh 电池的手机刷抖音 1 小时耗电 11%，耗电量(能耗)440mAh，平均电流 440mA

图 1. 功耗测试图

为什么要做功耗优化

从摘要里我们已经了解到高功耗会引发用户的电量焦虑，也会导致糟糕的发热体验，从而降低了用户的使用意愿。优化功耗除了可以我们带来更好的用户体验，提升用户使用时长外，降低应用耗电还具有很明显的社会价值，用一个当前比较火的词，就是可以为碳中和事业贡献一份力量。

如何来做功耗优化

不同于 Crash、ANR 等常见的 APM 指标，功耗是一个综合性的课题，分析起来很容易让人无从下手。用户反馈了耗电问题，可能是 CPU 出现高负载，又或者是后台频繁的网络访问，也可能是动画泄漏导致高功耗。或者我们自己的业务没什么变化，单纯就是环境因素影响，导致用户觉得耗电，比如低温导致的锂电池放电衰减。

我们的思路是从器件出发，应用的耗电最终都可以分解为手机器件的耗电，所以我们先对抖音做器件耗电的拆解，看主要耗电的是哪些器件，再看如何减少器件的使用，这样就做到有的放矢。

下面我们先从功耗组成，功耗分析，以及功耗优化等方面来讲述如何开展功耗优化。

功耗组成

这里列举了手机硬件的基本形态，每个模块又是由复杂的器件构成。如我们常说的耗电大头 SoC 里就包含 CPU 的超大核，大核，小核，GPU，DDRC(内存接口)，以及外设区的各种小 IP 核等。所以整机的功耗最终就可以拆解为各个器件的功耗，而应用的功耗就是计算其使用的器件产生的功耗。

以抖音的 Feed 流场景为例，亮度固定 120nit、7 格音量、WiFi 网络下，我们对抖音做了器件级的功耗拆解。可以看到抖音的 feed 功耗主要集中在 SOC(CPU，GPU，DDR)，Display，Audio，WIFI 等四个模块。

器件功耗计算

那这些器件功耗是如何被拆解出来的呢？原理是：先对器件进行耗电因子拆解，建立器件功耗模型，得到一个器件耗电的计算公式。通过运行时统计器件的使用数据，代入功耗模型，就可以计算出器件的功耗。应用的功耗则是从器件的总功耗里按应用使用的比较进行分配，这样就得到了应用的器件耗电。由于影响器件功耗的耗电因子众多，这里复杂的就是如何对耗电因子进行拆解以及建模。有了精准的建模，后面就是厂商适配校准参数的过程了。

谷歌提供了一套通用的器件耗电模型和配置方案，OEM 厂商可以按通用方案对自己的产品进行参数校准和配置。如下图里 AOSP 里的耗电配置里，以 Wifi 的耗电计算为例。https://source.android.com/devices/tech/power/values

谷歌提供的建模方案是对 WIFI 分状态计算耗电，WIFI 不同状态下的耗电差异非常明显。这里分为了 wifi.on（对应 wifi 打开的基准电流）, wifi.active（对应 wifi 传输数据时的基准电流）, wifi.scan（对应 wifi 单次扫描的基准耗电）, wifi 数据传输的耗电(controller.rx，controller.tx, controller.idle)。根据 wifi 收发数据的那计算 wifi 的耗电，通过统计这几个状态的时长或次数，乘以对应的电流，就得到 wifi 器件的耗电了。

由于谷歌是按照通用性来设计的器件耗电模型，通常只能大致计算出器件的耗电水平，具体到某个产品上可能误差很大。各 OEM 厂商通常有基于自身硬件的耗电统计方案，可以对耗电做更加精细准确的计算。这里还用 wifi 举例：如 OEM 厂商可以分别按照 2.4G，5GWIFI 单独建模，并引入天线信号的变化对应的基准电流变化，以及统计 wifi 芯片所工作的频点时长，按频点细化模型等等，OEM 厂商可以设计出更符合自己设备的精准功耗模型，计算出更精准的 wifi 耗电。这就要根据具体产品的硬件方案来确定了。

功耗分析

通过上面的功耗组成的介绍，我们可以看到功耗影响因素是多种多样。在做应用功耗分析时，我们既要有方法准确评估应用的耗电水平，又要有方法来分解出耗电的组成，以找到优化点。下面就分为功耗评估和功耗归因分析这两部分来介绍。

功耗评估

如前文功耗基础知识里所说，我们使用电流值来评估应用的功耗水平。在线下场景，我们通过控制测试条件（如固定测试机型版本，清理后台，固定亮度，音量，稳定的网络信号条件等）来测得可信的准确电流值来评估应用的前后台功耗。在线上场景，由于应用退后台时，用户使用场景的复杂性(指用户运行的前台应用不同)，我们只采集前台整机电流来做线上版本监控，使用其他指标，如后台 CPU 使用率来监控后台功耗。下面我们介绍一些常用功耗评估的手段。

PowerMonitor

目前业界最通用的整机耗电评估方式是通过 PowerMonitor 外接电量计的方式，高频率高精度采集电流进行评估。常用需要精细化确认耗电情况，尤其是后台静置，灭屏等状态下的电流输出，厂商的准入测试等。常用的 Mosoon 公司的 PowerMonitorAAA10F，电流量程在 1uA ～ 6A 之间，电流精度 50uA，采样周期 200us (5KHZ)。

电池电量计

PowerMonitor 虽然测量结果最准确。但是需要拆机比较麻烦。我们还可以通过谷歌 BatteryManager 提供的接口直接读取电池电量计的统计结果来获得电流值。

电池电量计负责估计电池容量。其基本功能为监测电压，充电/放电电流和电池温度，并估计电池荷电状态(SOC)及电池的完全充电容量（FCC）。有两种典型的电量计：电压型电量计和电流型电量计，目前手机上使用的电量计主要是电流型电量计。

• 电压型电量计：简单讲就是检测当前电压，然后查询电压-电池容量对应表，获得电量估算
• 电流型电量计：也叫库仑计，原理是在电池的充电/放电路径上的连接一个检测电阻。ADC 量测在检测电阻上的电压，转换成电池正在充电或放电的电流值。实时计数器（RTC）则提供把该电流值对时间作积分，从而得知流过多少库伦。

Android 提供了 BMS 的接口，通过属性提供了电池电量计的统计结果

• BATTERY_PROPERTY_CHARGE_COUNTER 剩余电池容量，单位为微安时
• BATTERY_PROPERTY_CURRENT_NOW 瞬时电池电流，单位为微安
• BATTERY_PROPERTY_CURRENT_AVERAGE 平均电池电流，单位为微安
• BATTERY_PROPERTY_CAPACITY 剩余电池容量，显示为整数百分比
• BATTERY_PROPERTY_ENERGY_COUNTER 剩余能量，单位为纳瓦时

import android.os.BatteryManager;
import android.content.Context;
BatteryManager mBatteryManager = (BatteryManager)Context.getSystemService(Context.BATTERY_SERVICE);
Long energy = mBatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);
Slog.i(TAG, "Remaining energy = " + energy + "nWh");

以下面的 Nexus9 为例，该机型使用了 MAX17050 电流型电量计，解析度 156.25uA，更新周期 175.8ms。

从实践结果上看，由于不同的手机使用的电量计不同，导致直接读取出来的电流值单位也不同，需要做数据转化。为了简化电池数据的获取，我们开发了 Thor SDK，只保留电流、电压、电量等指标的采集过程，针对不同机型做了数据归一处理，用户可以不用关心内部实现，只需要提供需要采样的数据类型、采样周期就可以定时返回所需要的功耗相关的数据，我们用 Thor 对比 PowerMonitor 进行了数据一致性的校验，误差<5mA，满足线上监控需求。

此外我们做了 Thor 采集功能本身的功耗影响，可以看到 1s 采集 1 次的情况下，平均电流上涨了 0.59mA，所以说这种方案的功耗影响非常低，适合线上采集电流值。

厂商自带耗电排行

耗电排行

厂商提供的耗电排行也可以用来查看一段时间内的应用耗电情况。如下面华为的耗电排行里，对硬件和软件耗电进行了分拆，并给出了应用的具体耗电量。其他厂商 OV 也是支持具体的耗电量，小米则是提供耗电占比，并不会提供具体耗电量。

入口：设置->电池->耗电排行

功耗归因

从功耗评估我们可以判断应用的整体耗电情况，但具体到某个 case 高耗电的原因是什么，就要具体问题选择不同的工具来进行分析了。目前可以直接归因到业务代码的主要是 CPU 相关的工具，这也是我们目前分析问题的主要方向，后续我们也会建设流量归因等能力，下面我列举了常用的分析工具。

Battery Historian

谷歌官方提供的分析工具，需要先进行功耗测试，再通过 adb 抓取 bugreport.zip，再通过网页工具打开，可提供粗粒度的功耗归因。

本质上是对 systemserver 里的各种服务统计信息+手机状态+内核统计信息(kernel 唤醒)的展示，应用耗电的估算依赖厂商配置的 power_profile.xml。比较适合对整机耗电问题做耗电归因，如归因到某应用耗电较高。

对于单个应用，由于对 wakelock，alarm，gps，job，syncservice，后台服务运行时长等统计的比较详细，比较适合做后台耗电的归因。对于网络异常，CPU 异常，只能看到消耗较多，无法归因到具体业务。https://developer.android.com/topic/performance/power/setup-battery-historian?hl=zh-cn

AS Profiler

相比于 BatteryHistorian 需要先手动测试，再 adb 抓取的操作繁琐，AS 自带的 Profiler 提供了 Energy 的可视化展示。使用 debug 版本的应用，可以直观的看到功耗的消耗情况，方便了线下测试。需要注意的是这里展示的功耗值是通过 GPS+网络+CPU 计算的拟合值，并不是真实功耗值，只表征功耗水平。

Profiler 同步展示了 CPU 使用率，网络耗电，内存信息。支持 CPU 和线程级别的跟踪。通过主动录制 Trace，可以分析各线程的 CPU 使用情况，以及耗时函数。对于容易复现的 CPU 高负载问题或者固定场景的耗时问题，这种方式可以很容易看到根因。但 trace 的展示方式并不适合偶现的 CPU 高负载，信息量特别多反而让人难以抓住重点。

网络耗电可以很方便抓取到上行下行的网络请求，可以展示网络请求的 api 细节，并且划分到线程上。对于频繁的网络访问，很容易找到问题点。但目前只支持通过 HttpURLConnection 和 OkHttp 的网络请求，使用其他的网络库，Profiler 追踪不到。

可以看到官方出品的工具，功能比较完善，但只支持 debug 版本的 app 分析，如果要分析 release 版本的 app，需要使用 root 手机。总体而言，Profiler 比较适合于线下固定某个业务场景的分析。https://developer.android.com/studio/profile/energy-profiler

线程池监控

使用上面的工具监控单个线程的 CPU 异常是可以的。但是对于线程池，Handler，AsyncTask 等异步任务不太容易归因具体的业务，尤其是网络库的线程池，由于执行的网络请求逻辑是一样的，只靠抓线程堆栈是不能归因到具体业务的。需要统计提交任务的源头代码才能抓到真正问题点。

我们可以通过多种机制，如改造线程池，java hook 等，对提交任务方进行了详细记录和聚合，可以帮忙我们分析线程池里的耗时任务。

线上 CPU 异常精准监控

除了线下的 CPU 分析，我们在进行线上 CPU 异常监控的建设时，我们考虑到单纯使用 CPU 使用率阈值不能精准的判断进程是否处于 CPU 异常。比如不同的 CPU 型号本身的性能不同，在某些低端 CPU 上的使用率就是比较高。又比如系统有不同的温控策略，省电策略，会对手机进行限频，对任务进行 CPU 核心迁移。在这种情况下，应用也会有更高的 CPU 使用率。

因此我们基于不同的变量因素（如 CPU 型号，进程/线程的 CPU 时长在不同核，不同频点的分布，充电，电量，内存，网络状态等），将 CPU 的使用阈值进行精细判定，针对不同场景、不同设备、不同业务制定精细化的 CPU 异常阈值，从而实现了高精度的 CPU 异常抓取。

好了，这篇文章的内容营销圈就和大家分享到这里，如果大家对网络推广引流和网络创业项目感兴趣，可以添加微信：Sum8338 备注：营销圈引流学习，我拉你进直播课程学习群，每周135晚上都是有实战的推广引流技术和网络创业项目课程分享，当然是免费学！