电量消耗的全过程分析
手机设备会执行各种任务和各种复杂计算，如秀自拍图片上传朋友圈、秀直播等等，为了完成这些设备硬件会快速消耗手机电池电量。很明显，任务处理的越复杂，电量就会消耗的越多和越快，一眨眼的功夫电量就消耗完了，这个时候用户的手机顿时变成个累赘的砖头了，用户就会怀疑谁(哪个app)这么耗电，然后把它卸了！
写出耗电量低的应用的关键是要透彻理解它的全部过程。
在电子编程世界，这种硬件消耗电量 来执行任务的过程，叫做超时电流消耗，任何电子编程专业的人都会告诉你，你的设备的各项活动在相同时间内，消耗的电量是不同的。
比如，很多手机号称待机好几天，这个确实是真的，不过就是使用飞行模式放在家里什么都不干，确实可以甚至可以坚持10多天。但是我们一旦使用它，比如使用蜂窝式无线数据交换(3G4G)、屏幕保持唤醒状态等，手机电量就会很快被消耗掉。
作为开发者，我们很想知道我的应用执行的哪些任务消耗的电量是最多的？这个问题确实会很棘手。因为电量消耗的计算与统计是一件麻烦而且矛盾的事情，记录电量消耗本身也是一个费电量的事情（所以很多设备都把这个监测电量的功能阉割掉了）。
唯一可行的方案是使用第三方监测电量的设备，这样才能够获取到真实的电量消耗（因为第三方硬件监测的时候是用的自己的供电而不是用的手机的电量）。
耗电情况，例如：打开屏幕，所有要使用CPU/GPU工作的动作都会唤醒屏幕，都会消耗电量。这和应用程序唤醒设备还不一样。比如使用叫醒闹钟(wake clock)、AlarmManager、JobSchedulerAPI。
手机哪些地方最耗电?
唤醒屏幕
当用户点亮屏幕的时候，意味着系统的各组件要开始进行工作，界面也需要开始执行渲染。
待机状态的电量消耗:
使用和唤醒屏幕后:
当设备从休眠状态中，被应用程序唤醒时，可以看到在第一次唤醒时，出现一条电量使用高峰线。
CPU唤醒使用
CUP 唤醒时的高峰线:
接下来就是后续的一些执行的消耗了:
当工作完成后，设备会主动进行休眠，这非常重要，在不使用或者很少使用的情况下，长时间 保持屏幕唤醒会迅速消耗电池的电量。
蜂窝式无线
当设备通过无线网发送数据的时候，为了使用硬件，这里会出现一个唤醒耗电高峰。接下来还 有一个高数值，这是发送数据包消耗的电量，然后接受数据包也会消耗大量电量 也看到一个峰值。
通常情况下，使用3G移动网络传输数据，电量的消耗有三种状态:
-
Full power： 能量最高的状态，移动网络连接被激活，允许设备以最大的传输速率进
行操作。 - Low power： 一种中间状态，对电量的消耗差不多是 Full power 状态下的 50%。
- Standby： 最低的状态，没有数据连接需要传输，电量消耗最少。
Battery-Historian 电量分析工具的使用
要进行电量优化，我们首先得知道电都消耗到哪里去了，我们可以通过 google 开源的 Battery-Historian 来进行分析。
工具开源地址: https://github.com/google/battery-historian
Battery History 工具安装
根据 gitbub 上面介绍，Battery History
工具的安装有两种方式:
方式1： 通过安装 Docker 环境来安装。(这种方式很简单，Docker 真心好用)
- 按照 Docker 网站上的说明安装 Docker Community Edition。
- 使用以下命令运行 Battery Historian 镜像:
docker --run -p port_number:9999 gcr.io/android-battery-historian:2.1 --port 9999
方式2 通过编译 gitbub 上面的源码来安装。
- GO 环境安装:具体可以参考 Mac os 安装 golang 开发环境(https://www.jianshu.com/p/79bdd20c46cf)
- 安装 git.
- 安装 Python。仅支持 python2.7 (https://www.python.org/ )
- 安装Java环境
下载 Battery Historian 源码并且运行
输入如下命令行 下载到GOPATH 配置目录下。
go get -d -u github.com/google/battery-historian/...
进入到$GOPATH/src/github.com/google/battery-historian目录下方
cd $GOPATH/src/github.com/google/battery-historian
运行 Battery Historian
1.执行命令：
go run setup.go
Compile Javascript files using the Closure compiler
2.接着在执行命令：
go run cmd/battery-historian/battery-historian.go [--port <default:9999>]
Run Historian on your machine (make sure GOBIN)
3.登录网址http://localhost:9999查看battery-historian是否运行。
到此Battery-historian的环境就整好了。
电量数据收集
Android 5.0 及以上的设备, 允许我们通过 adb 命令 dump 出电量使用统计信息。
1.因为电量统计数据是持续的, 会非常大, 统计待测试的 App 之前需要连上设备，因此需要reset(重置)电池数据收集。命令行执行:
$ adb shell dumpsys batterystats --resetBattery stats reset
2.断开usb连接的测试设备, 操作要测试的App。
3.重新连接设备, 使用 adb 命令导出相关统计数据:
- Android 7.0 及以上执行如下命令:
adb bugreport > [path/]bugreport.zip
- Android 5.0/ 6.0执行如下命令:
adb bugreport > [path/]bugreport.txt
导出的统计数据存储到 bugreport.zip(bugreport.txt), 借助 battery-historian 工具来图形化 展示电池的消耗情况.
上传 bugreport.zip(bugreport.txt)文件至 http://localhost:9999：
battery-historian电量分析结果：
分析指标
下图是使用 adb 命令将采集的电量数据上传至 Battery Historian 而得到电量的分析情况。（我们可以通过包名过滤具体应用的耗电情况）
各指标的含义
- 横坐标： 横坐标就是一个时间范围，咱们的例子中统计的数据是以重置为起点，获取 bugreport 内容时 刻为终点。我们一共采集了多长时间的数据；
- 纵坐标： 关键数据点说明如下。
| 数据项 | 说明 |
|---|---|
| battery_level | 电量，可以看出电量的变化 |
| plugged | 充电状态，这一栏显示是否进行了充电，以及充电的时间范围 |
| screen | 屏幕是否点亮，这一点可以考虑到睡眠状态和点亮状态下电量的使用信息 |
| top | 该栏显示当前时刻哪个 app 处于最上层，就是当前手机运行的 app，用来判断某个 app 对手机电量的影响，这样也能判断出该 app 的耗电量信息。该栏记录了应用在某 一个时刻启动，以及运行的时间，这对我们比对不同应用对性能的影响有很大的帮助 |
| wake_lock | wake_lock 该属性是记录 wake_lock 模块的工作时间。是否有停止的时候等 |
| running | 界面的状态，主要判断是否处于 idle 的状态。用来判断无操作状态下电量的消耗 |
| Job | 后台的工作，比如服务 service 的运行 |
| data_conn | 数据连接方式的改变，上面的 edge 是说明采用的 gprs 的方式连接网络的。此数据可 以看出手机是使用 2g，3g，4g 还是 wifi 进行数据交换的。这一栏可以看出不同的连 接方式对电量使用的影响 |
| status | 电池状态信息，有充电，放电，未充电，已充满，未知等不同状态 |
| phone_signal_strength | 手机信号状态的改变。 这一栏记录手机信号的强弱变化图，依次来判断手机信号对电 量的影响 |
| health | 电池健康状态的信息，这个信息一定程度上反映了这块电池使用了多长时间 |
| plug | 充电方式，usb 或者插座，以及显示连接的时间 |
| Sync | 是否跟后台同步 |
| phone_in_call | 是否进行通话 |
| gps | gps 是否开启 |
如何进行电量优化?
了解手机关键耗电的地方及分析耗电的工具后。接下来就是我们的核心，如何来进行电量的优 化?首先我们先简单总结汇总一下耗电的相关因素
- 屏幕亮暗相关
- 设备 awake,sleep 的切换,尤其是唤醒.
- CPU 运行相关
- 网络
- 传感器
我们都知道屏幕的渲染及 CPU 的运行是耗电的主要因素之一。所以当我们在做内存优化、渲染优化、计算优化的时候，就已然在做电量优化。所以在平时的开发中，我们要注意点滴性能 的优化积累，实际上当我们来做电量分析的时候，也是在找自己挖的坑。所以尽量有意识在项 目的开发过程中尽量少挖坑，这一点是我们在分析其他优化项首先要提到的一个点。
监听手机充电状态
我们可以通过下面的代码来获取手机的当前充电状态:
得到充电状态信息之后，我们可以有针对性的对部分代码做优化。比如我们可以判断只有当前 手机为 AC 充电状态时 才去执行一些非常耗电的操作。可以通过下面的方法判断手机当前的充 电状态。
这里我们就需要思考，根据具体的业务，考虑将一些不需要及时地和用户交互的操作放到充电 的时候去做。比如：360 手机助手，当充上电的时候，才会自动清理手机垃圾，自动备份上传图片、联系人 等到云端，从而避免当用户手机低电量时，任然继续进行耗电操作。
屏幕唤醒
当 Android 设备空闲时，屏幕会变暗，然后关闭屏幕，最后会停止 CPU 的运行，这样可以防 止电池电量掉的快。但有些时候我们需要改变 Android 系统默认的这种状态:比如玩游戏时我 们需要保持屏幕常亮，比如一些下载操作不需要屏幕常亮但需要 CPU 一直运行直到任务完成。
保持屏幕常亮比较好的方式是在 Activity 中使用 FLAG_KEEP_SCREEN_ON 的 Flag。
这个方法的好处是不像唤醒锁(wake locks)，需要一些特定的权限(permission)。并且能 正确管理不同 app 之间的切换，不用担心无用资源的释放问题。
另一个方式是在布局文件中使用 android:keepScreenOn 属性:
android:keepScreenOn = “true”的作用和 FLAG_KEEP_SCREEN_ON 一样，使用代码的好 处是你允许你在需要的地方关闭屏幕。
注意:一般不需要人为的去掉 FLAG_KEEP_SCREEN_ON 的 flag，windowManager 会管理好程序进入 后台回到前台的的操作。如果确实需要手动清掉常亮的 flag，使用
所以这里我们需要根据自己的 APP 实际情况，根据业务来控制好是否保持屏幕常量。比如 APP 需要支持视频播放。那么在播放的界面需要控制好不熄屏，当退出播放时，当然就没有了 这个设置。
WakeLock
wake_lock 锁主要是相对系统的休眠而言的，意思就是程序给 CPU 加了这个锁那系统就不会 休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些 问题。
需要使用 PowerManager 这个系统服务的唤醒锁(wake locks)特征来保持 CPU 处于唤醒状 态。唤醒锁允许程序控制宿主设备的电量状态，创建和持有唤醒锁对电池的续航有较大的影 响，所以，除非是真的需要唤醒锁完成尽可能短的时间在后台完成的任务时才使用它。比如在 Acitivity 中就没必要用了。如果需要关闭屏幕，使用上述的 FLAG_KEEP_SCREEN_ON。
只有一种合理的使用场景，使用后台服务在屏幕关闭情况下 hold 住 CPU 完成一些工作，需要 使用唤醒锁，如果不使用唤醒锁来执行后台服务，不能保证因 CPU 休眠未来的某个时刻任务 会停止，这不是我们想要的。
唤醒锁可划分并识别为四种用户唤醒锁:
| 标记值 | CPU | 屏幕 | 键盘 |
|---|---|---|---|
| PARTIAL_WAKE_LOCK | 开启 | 关闭 | 关闭 |
| SCREEN_DIM_WAKE_LOCK | 开启 | 变暗 | 关闭 |
| SCREEN_BRIGHT_WAKE_LOCK | 开启 | 变亮 | 关闭 |
| FULL_WAKE_LOCK | 开启 | 变亮 | 变亮 |
注意:自 API 等级 17 开始，FULL_WAKE_LOCK 将被弃用。 应用应使用 FLAG_KEEP_SCREEN_ON。
1.添加唤醒锁权限:
2.直接使用唤醒锁:
注意:在使用该类的时候，必须保证 acquire 和 release 是成对出现的。不然当我们业务已经不需要时， 当 CPU 处于唤醒状态，这个时候就会损耗多余的电量。
JobScheduler
自 Android 5.0 发布以来，JobScheduler 已成为执行后台工作的很好的方式，其工作方式有 利于用户在适当的时机执行正确的事情。应用可以在安排作业的同时允许系统基于内存、电源 和连接情况进行优化。JobSchedule 的宗旨就是把一些不是特别紧急的任务放到更合适的时机 批量处理。这样做有两个好处:
- 避免频繁的唤醒硬件模块，造成不必要的电量消耗。
- 避免在不合适的时间(例如低电量情况下、弱网络或者移动网络情况下的)执行过多的
任务消耗电量。
GPS
选择合适的 Location Provider
Android 系统支持多个 Location Provider:
- GPS_PROVIDER: GPS 定位，利用 GPS 芯片通过卫星获得自己的位置信息。定位精准度高，一般在 10 米左右， 耗电量大;但是在室内，GPS 定位基本没用。
-
NETWORK_PROVIDER: 网络定位，利用手机基站和 WIFI 节点的地址来大致定位位置，这种定位方式取决于服务器，
即取决于将基站或 WIF 节点信息翻译成位置信息的服务器的能力。 - PASSIVE_PROVIDER: 被动定位，就是用现成的，当其他应用使用定位更新了定位信息，系统会保存下来，该应用接 收到消息后直接读取就可以了。
如果 App 只是需要一个粗略的定位那么就不需要使用 GPS 进行定位，既耗费电量，定位的耗 时也久。
及时注销定位监听
在获取到定位之后或者程序处于后台时，注销定位监听，此时监听 GPS 传感器相当于执行 no- op(无操作指令)，用户不会有感知但是却耗电。
多模块使用定位尽量复
多个模块使用定位，尽量复用上一次的结果，而不是都重新走定位的过程，节省电量损耗;例 如:在应用启动的时候获取一次定位，保存结果，之后再用到定位的地方都直接去取。
传感器
使用传感器，选择合适的采样率，越高的采样率类型则越费电。
- SENSOR_DELAY_NOMAL (200000 微秒)
- SENSOR_DELAY_UI (60000 微秒)
- SENSOR_DELAY_GAME (20000 微秒)
- SENSOR_DELAY_FASTEST (0 微秒)
在后台时注意及时注销传感器监听
Doze and App Standby
最后提这一点，理论上不是电量优化，而是做电量优化要注意的一个坑。Doze and App Standby 是 Android 6.0 以后，提供了两种省电延长电池寿命的功能。
具体可参考 google 官方介绍文档。
如果大家有什么好的意见或建议，欢迎关注我的公众号“程序员驿站”进行留言，谢谢！
扫一扫 关注我的公众号
如果你有好的文章需要和广大网友分享，欢迎投稿，谢谢！
参考资料：https://github.com/google/battery-historian#wakelock-analysis
有疑问加站长微信联系（非本文作者）
