耗电优化（上）：Android App 耗电分析

本文主要是介绍耗电优化（上）：Android App 耗电分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1. 电量和硬件

1.1 App 通过使用硬件模块消耗相应的电能

应用程序不会直接去消耗电池，而是通过使用硬件模块消耗相应的电能，下图是手机中一些比较耗电的硬件模块

CPU、屏幕、WiFi 和数据网络、GPS 以及音视频通话都是我们日常的耗电大户。

坦白说，智能手机硬件的飞速提升，许多其实都是厂商叫卖的噱头。绝大部分硬件对于我们来说都已经处于性能过剩的状态，但多余的性能同时也在消耗电量

1.2 资源调度机制是厂商功耗优化最重要的手段

eg：

• CPU 芯片会分大小核架构，会灵活地为不同任务分配相应的运算资源
• 手机基带、GPS 这些模块在不使用时也会进入低功耗或者休眠模式，达到降低功耗的目的
• 现在越来越多厂商利用深度学习的本地 AI 来优化资源的调度，对 GPU、运行内存等资源进行合理分配，确保可以全面降低耗电量。厂商需要在高性能跟电量续航之间寻找一个平衡点，有的厂商可能倾向于用户有更好的性能，有的厂商会倾向于更长的续航

2. 电量和应用程序

2.1 评估不同应用程序的耗电情况

根据物理学的知识，电能的计算公式为:

电能 = 电压 * 电流 * 时间

对于手机来说电压一般不会改变，所以在电压恒定的前提下，只需要测量电流和时间就可以确定耗电。

最终不同模块的耗电情况可以通过下面的这个公式计算：

模块电量(mAh) = 模块电流(mA) * 模块耗时(h)

模块耗时比较容易理解，但是模块电流应该怎样去获取呢？Android 系统要求不同的厂商必须在 /frameworks/base/core/res/res/xml/power_profile.xml 中提供组件的电源配置文件

power_profiler.xml 文件定义了不同模块的电流消耗值以及该模块在一段时间内大概消耗的电量，你也可以参考 Android Developer 文档《Android 电源配置文件》。

当然电流的大小和模块的状态也有关系，例如屏幕在不同亮度时的电流肯定会不一样

Android 系统的电量计算 PowerProfile 也是通过读取 power_profile.xml 的数值而已，不同的厂商具体的数值都不太一样，我们可以通过下面的方法获取：

• 从手机中导出 /system/framework/framework-res.apk文件
• 使用反编译工具（如 apktool）对导出文件framework-res.apk进行反编译。
• 查看power_profile.xml文件在framework-res反编译目录路径：/res/xml/power_profile.xml。

对于系统的电量消耗情况，我们可以通过 dumpsys batterystats 导出:

adb shell dumpsys batterystats > battery.txt
// 各个Uid的总耗电量，而且是粗略的电量计算估计。
Estimated power use (mAh):Capacity: 3450, Computed drain: 501, actual drain: 552-587...Idle: 41.8Uid 0: 135 ( cpu=103 wake=31.5 wifi=0.346 )Uid u0a208: 17.8 ( cpu=17.7 wake=0.00460 wifi=0.0901 )Uid u0a65: 17.5 ( cpu=12.7 wake=4.11 wifi=0.436 gps=0.309 )...// reset电量统计
adb shell dumpsys batterystats --reset

BatteryStatsService 是对外的电量统计服务，但具体的统计工作是由 BatteryStatsImpl 来完成的，而 BatteryStatsImpl 内部使用的就是 PowerProfile。BatteryStatsImpl 会为每一个应用创建一个 UID 实例来监控应用的系统资源使用情况，统计的系统资源包括下面图里的内容

结论：把电量的测量转化为功能模块的使用时间或者次数

电量的使用也会跟环境有关，例如在零下十度的冬天电量会消耗得更快一些，系统提供的电量测量方法只是提供一个参考的数值。不过通过上面的这个方法，我们可以成功把电量的测量转化为功能模块的使用时间或者次数。

2.2 尽可能准确的测量电量

参考 《大众点评 App 的短视频耗电量优化实战》，

bug report结合 Battery Historian 是最好的排查方法

3. Android 耗电的演进历程

3.1 野蛮生长：Pre Android 5.0

在 Android 5.0 之前，系统并不是那么完善，对于电量优化相对还是比较少的。

特别没有对应用的后台做严格的限制，多进程、fork native 进程以及广播拉起等各种保活流行了起来。用户手机用电如流水，会明显感受到下面几个问题：

• 耗电与安装应用程序的数量有关。用户安装越多的应用程序，无论是否打开它们，手机耗电都会更快。
• App 耗电量与 App 使用时间无关。用户希望 App 的耗电量应该与它的使用时间相关，但是有些应用即使常年不打开，依然非常耗电。
• 电量问题排查复杂。无论是电量的测量，还是耗电问题的排查都异常艰难。

3.2 逐步收紧：Android 5.0～Android 8.0

3.2.1 Android 5.0

• Volta 项目
• Job Scheduler – 适应各种场景的任务（无线网络，充电时…）
• dumpsys batterystats
• Battery Historian
• 修复 native fork 进程保活
  • 原理就是通过 JNI fork出一个 c 进程，c 进程监控主进程是否存活，主要通过管道和文件监控的方式实现监控，发现主进程死后，通过调起一个 service 将主进程拉活

3.2.2 Android 6.0

• Doze and App Standby
• Doze (低电耗模式)：如果用户拔下设备的电源插头，并在屏幕关闭后的一段时间内使其保持不活动状态，设备会进入低电耗模式，在该模式下设备会尝试让系统保持休眠状态。在该模式下，设备会定期短时间恢复正常工作，以便进行应用同步，还可让系统执行任何挂起的操作。
• App Standby (应用待机模式)：应用待机模式允许系统判定应用在用户未主动使用它时处于空闲状态。当用户有一段时间未触摸应用时，系统便会作出此判定。如果拔下了设备电源插头，系统会为其视为空闲的应用停用网络访问以及暂停同步和作业。

总结：

• Doze 手机会在一段时间未检测到移动时，让应用休眠清杀后台进程减少功耗，谷歌表示，当屏幕处于关闭状态，平均续航时间提高30%
• 墓碑机制优化内存 (没什么太大关系，只是想起就放这了)

3.2.3 仍然存在的问题

Android 6.0 开始，Google 开始着手清理后台应用和广播来进一步优化省电。在这个阶段还存在以下几个问题：

• 省电模式不够省电。Doze 低功耗模式限制得不够严格，例如屏幕关闭还可以获取位置、后台应用的网络权限等。

• 用户对应用控制力度不够。用户不能简单的对某些应用做更加细致的电量和后台行为的控制，但是其实国内很多的厂商已经提前实现了这个功能。

• Target API 开发者响应不积极。为了不受新版本的某些限制，大部分国内的应用坚持不把 Target API 升级到 Oreo 以上，所以很多省电的功能事实上并没有生效。

3.2.5 导致的各种骚操作 App 保活

• Android 进程保活手段分析
• 怎么让 Android 程序一直后台运行，像 QQ 一样不被杀死？
• 关于 Android 进程保活，你所需要知道的一切 --> 黑，白，灰 保活

坏孩子：

• Android进程保活的一般套路
• 2017 - Android APP杀不死（最大存活方法）
• 2020 - [讨论] 有关App保活，最近发现一家清理APP非常流氓，不管什么方式都杀不死，很恐怖

3.3 最严限制：Android 9.0

• Android 9.0 开始，Google 对电源管理引入了几个更加严格的限制

• 通过应用待机分组功能，我们可以确保应用使用的电量和它们的使用时间成正比，而不是和手机上安装的应用数量成正比。对于不常用的应用，它们可以“作恶”的可能性更小了。

• 通过省电模式和应用后台限制，用户可以知道哪些应用是耗电的应用，我们也可以对它们做更加严格的限制

这篇关于耗电优化（上）：Android App 耗电分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---