万字长文 · Android 功耗优化指导规范

Hello，我是小木箱，欢迎来到小木箱成长营系列教程，今天将分享功耗优化 · 方案篇 · Android 功耗优化指导规范。小木箱从五个维度将 Android 功耗优化指导规范解释清楚。

Android 功耗优化指导规范第一部分内容是 5W2H 分析功耗优化。第二部分内容是功耗优化技术方案。第三部分内容是功耗优化方案分析。第四部分内容是功耗 APM 监控建设。最后一部分内容是总结与展望。

其中，功耗优化技术方案分为三部分内容，第一部分内容是功耗优化工具，第二部分内容是功耗优化指南，最后一部分内容是功耗优化 SOP。

其中，功耗优化方案分析主要分为六部分内容。第一部分内容是 CPU 异常 SOP，第二部分内容是 Camera 功耗，第三部分内容是低功耗，第四部分内容是热缓解，第五部分内容是动态帧率，最后一部分内容是 SurfaceView 替换 TextureView。

首先我们说说我们的第一部分内容，5W2H 分析功耗优化，5W2H 分析功耗优化提出了 6 个高价值问题：

• What : 功耗优化定义
• Why: 高功耗的原因
• How: 功耗优化流程
• Who: 功耗痛点治理
• How Much: 功耗优化价值
• Where: 方案使用场景

2.1 What: 功耗优化定义

Android 功耗优化是指优化 Android APP 在运行过程中的电量消耗，以获得更长的电池续航时间和更优秀的用户体验。功耗优化包括：设备的动态调频、网络优化、电池感知、界面优化、后台活动优化和内存优化等

2.2 How Much: 功耗优化价值

下面的思维导图小木箱从性能价值、用户价值和社会价值三个维度分析了功耗优化价值。

2.3 Why: 高功耗的原因

高功耗是因为设备在运行过程中需要使用大量的电力。

因为 CPU 高负载、高亮度显示器、频繁 GPS 定位、后台运行程序、高频率网络通信和不必要动画等原因会导致设备高功耗

下面思维导图小木箱简单总结高功耗 6 个原因。

2.4 Who: 功耗痛点治理

“

该如何做功耗优化呢?

”

首先， 高功耗任务要分析设备功耗优化的占比情况，然后逐一进行排查。

影响高功耗的设备主要有 NetWorrk、GPS、Audio、Camera、Display、GPU、BlueTooth 和 Sensor 等。详见下图:

小木箱将所有高功耗设备按照 MECE 原则进行分类如下表格:

小木箱建议大家使用 Android 的电池监控工具来监测 APP 的电池使用情况。

根据业务表现不同特征， 尽量使用系统 API、减少后台进程、避免让手机长时间处于高亮度模式、合理使用 GPS 和网络、优化图像和视频、尽量避免定时高功耗任务和避免频繁的唤醒 CPU 方式进行优化功耗。

Android 常见的高功耗设备可以参考下图:

“

那么， 该如何找出正在运行的高耗设备?

”

查找高功耗电 Android 设备，需要使用 Android 电池管理 API，详细代码如下:

首先，高功耗任务需要新增android.permission.BATTERY_STATS权限，方便使用电池管理 API。

然后，使用 Android 电池管理 API 获取 APP 的电池使用情况，并循环遍历每个 APP，最后， 确定它们对总电池使用情况的贡献。

最后，如果 APP 对总电池使用情况的贡献大于零，那么可以将该 APP 标识为消耗大量电力的 APP。

减少设备使用方式详见有如下思维导图:

下面我们逐一讲解着五种减少设备使用的方式。

2.4.1 降低亮度

在上面的代码中，通过获取当前窗口的布局参数，并将其中的屏幕亮度设置为 0.5F。请注意，此亮度值仅在 0 到 1 之间。

因此，如果希望更低的亮度，则可以将此值设置为更小的值。

请注意，需要在活动中调用此代码，以便更改当前活动的屏幕亮度。

此外，还需要检查是否具有 android.permission.WRITE_SETTINGS 权限，以便更改系统设置。

2.4.2 降低动画帧率

首先，请确保有SYSTEM_ALERT_WINDOW设置的权限。

然后，通过调用 setWindowAnimationsScale 方法并将其参数设置为 0.5f，可以降低当前活动的动画帧率，该值仅在 0 到 1 之间。

最后， 需要在 Activity 中调用上面的代码就可以更改当前 Activity 的动画帧率。

2.4.3 减少数据收发

减少数据收发的方式有四种，分别是：

以下是一个使用 Retrofit 和 OkHttp 实现网络请求的代码示例，并将数据缓存到本地：

2.4.4 降低音量

在 Android 代码层面，可以使用以下代码来降低音量，从而优化电池使用寿命：

该代码将音频流的音量设置为最低值，从而降低手机的音量。

2.4.5 治理 CPU 高负载

治理 CPU 高负载异常并优化电池使用寿命常见方式有四个：

检测 CPU 负载异常可以通过使用 Android 提供的两个工具。

第一， adb shell top

第二， adb shell dumpsys CPUinfo

分析负载异常原因方式也有两种：

第一使用 Android Studio 的“Profile GPU Rendering”

第二使用“Debug GPU Overdraw”功能。

如果分析结果是 APP 代码引起的负载异常，那么可以减少不必要的动画、使用多线程等来优化 CPU 负载。

如果分析结果表明是后台服务引起的负载异常，那么可以通过关闭服务来减少 CPU 负载。

小木箱后文会对 CPU 负载进行详细分析。

2.5 How: 功耗优化流程

当执行高功耗任务时候，业务开发应该反思下面四个问题:

• 高功耗任务是否必须要做?
• 高功耗任务是否必须准时做?
• 高功耗任务是否必须保证效果?
• 高功耗任务必须的方案是否具有唯一性?

关于问题 1: 高功耗任务是否必须要做? 如果高功耗任务不是必须要做的，业务开发可以考虑延迟或不执行，达到动画泄漏治理，让后台高功耗任务延迟做。

关于问题 2: 高功耗任务是否必须准时做?如果高功耗任务不是必须准时做的，高功耗任务业务开发可以考虑分批减少频率，达到 MQTT 心跳降级，GPS 定位频率因此会降低。

关于问题 3: 高功耗任务是否必须保证效果?如果高功耗任务不是必须保证效果，高功耗任务业务开发可以考虑降低效果，常见的做法是算法降级如:定位降级为网络定位。

关于问题 4: 高功耗任务必须的方案是否具有唯一性?如果高功耗任务必须的方案不具有唯一性，高功耗任务业务开发可以考虑硬解密替代软解密，厂商 Push 代替自建长链接。

功耗设备降级的方式主要有异常治理、正面优化和业务降级四种。

异常治理有三种情况: 死循环治理、资源不释放治理和高频耗时函数优化。

正面优化有三种情况: 动态帧率和刷新率、绘制图层优化和长链接心跳优化。

业务降级有三种情况: 预加载降级、常驻动画降级和超分算法降级。

后文小木箱会逐一进行讲解。

2.6 Where: 方案使用场景

方案使用场景方案使用场景小木箱这里只会带大家了解一下异常治理和无损降级，后文会讲解有感降级。

2.6.1 异常治理

异常处理不是直接解决 Android 功耗优化的方法，但是通过异常处理可以避免不必要的资源浪费，从而减少功耗消耗。

高功耗任务可以通过避免不必要的资源分配、避免不必要计算、不必要数据库操作等异常处理解决 Android 功耗问题。

2.6.2 业务降级(无感知)

使用 JobScheduler 代替 AlarmManager：JobScheduler 可以在系统空闲时执行高功耗任务，因此可以降低功耗消耗。

使用后台服务降级：对于需要长时间运行的后台服务，可以通过降级方式（例如，从运行在前台的服务切换到后台定时高功耗任务）来减少功耗消耗。

使用 Doze 模式优化：Doze 模式可以在系统进入空闲状态时减少后台活动，从而减少功耗消耗。

使用 Firebase Cloud Messaging（FCM）代替定时高功耗任务：FCM 可以在系统空闲时向 APP 发送消息，从而减少功耗消耗。

功耗优化技术方案主要分为四个部分，第一个部分是功耗优化工具，第二个部分是功耗优化指南，第三个部分是功耗优化 SOP。

3.1 功耗优化工具

功耗优化工具有八个可以聊聊，分别是电流仪、Battery Historian、Energy Profiler、Dumpsys Batterystats、Battery-Metrics、BatteryCanary、Diggo、和 Systrace。

3.1.1 电流仪

优点

最准确的测试方法是稳压电源+电流仪， 稳压电源+电流仪优点是可以测试整机电流，并且数据精准。

缺点

因为稳压电源+电流仪需要准备硬件工具，稳压电源+电流仪测试操作复杂，并且稳压电源+电流仪不能测试 APP 消耗电量，一般没有人在移动开发中使用稳压电源+电流仪。

使用场景

ROM 厂商整机电流科学实验。

3.1.2 Battery Historian

“

传送门: 使用 Battery Historian 分析耗电情况

使用指南(待更新): https://space.bilibili.com/455432199

”

参数说明

Historian

App Selection

优点

缺点

使用场景

3.1.3 Energy Profiler

“

传送门: https://developer.android.com/studio/profile/android-profiler?hl=zh-cn

使用指南(待更新): https://space.bilibili.com/455432199

”

优点

• Energy Profiler 可以提供实时的电池消耗。
• Energy Profiler 可以针对特定的应用程序进行电池消耗分析，而不是整台设备。
• Android Studio 自带 Buff，无需安装插件。
• Energy Profiler 提供 CPU 使用情况、传感器使用情况和网络数据传输能力。
• Energy Profiler 支持历史数据分析。

缺点

• 无法多端复用。
• 只支持 Android 8.0 以上版本。
• 不提供高功耗解决方案。

使用场景

• 测试电池寿命。
• 比较不同版本的应用程序。
• 确认电池相关问题。

3.1.4 Dumpsys Batterystats

“

传送门: https://developer.android.com/studio/command-line/dumpsys?hl=zh-cn

使用指南(待更新): https://space.bilibili.com/455432199

”

优点

• Dumpsys Batterystats可以监测系统服务和其他应用程序等系统级别的电池消耗。
• Dumpsys Batterystats可以监测应用程序在使用电池时的功耗情况，并将其记录在日志文件中。
• Dumpsys Batterystats会生成应用程序、系统服务、电池消耗原因和耗电量使用情况报告。

缺点

• 无法检测应用程序和服务之间的相互影响。
• Dumpsys Batterystats测试只能在设备上运行一段时间后收集数据。
• Dumpsys Batterystats方式获取的是原始的耗电记录数据，需要人肉查找关键信息，可读性不高。

使用场景

• 电池寿命测试。
• 电源管理优化。
• Dumpsys Batterystats帮助用户排除设备电池故障。

3.1.5 Battery-Metrics

“

传送门: https://github.com/facebookincubator/Battery-Metrics

使用指南(待更新): https://space.bilibili.com/455432199

”

优点

• Battery-Metrics 可以检测到应用程序和服务之间的相互影响。
• Battery-Metrics 测试功耗方法和技术比 Batterystats 精准。
• Battery-Metrics 测试功耗能够检测用户 APP 使用习惯、网络连接质量、屏幕亮度、环境温度。
• Battery-Metrics 支持多种设备和操作系统版本。
• Battery-Metrics 可以通过 hook 和插桩的方式上报关键节点的电池和手机相关数据，可高度定制化。

缺点

Battery-Metrics 插件方案 Hook 点位受到 API 版本限制。

使用场景

不同领域和高功耗优化场景高可用。

3.1.6 BatteryCanary

“

传送门: https://github.com/MicroKibaco/BatteryCanary

使用指南(待更新): https://space.bilibili.com/455432199

”

BatteryCanary 也可以通过 hook 和插桩的方式上报关键节点的电池和手机相关数据，已实现关键点的插桩和 hook。

优点

• 实时监测
• 易于集成
• 精细化分析
• 易于定位问题
• 开源免费

缺点

• 对测试设备要求较高
• 有些数据可能不够准确
• 导致应用程序的安装包变得更大

使用场景

不同领域和高功耗优化场景高可用。

3.1.7 Diggo

“

传送门: https://github.com/bytedance/Fastbot_Android/blob/main/handbook-cn.md

使用指南(待更新): https://space.bilibili.com/455432199

”

优点

• Diggo 可以对应用程序的每个组件进行功耗采样和统计，得到精确的功耗数据，并可以将功耗数据可视化，便于开发人员分析和优化。
• Diggo 提供了一些自动化的功耗优化策略，例如优化启动过程、减少资源使用等。
• Diggo 可以与 Traceview、Jupyter 进行集成。

缺点

• 侵入业务代码
• 无法处理硬件功耗问题
• 可能会影响应用程序的性能
• 无法跨端使用

使用场景

• 开发人员和测试团队对 App 进行基准测试
• 优化应用程序的电池寿命

3.1.8 Systrace

“

传送门: https://blog.csdn.net/u011578734/article/details/109497064

使用指南(待更新): https://space.bilibili.com/455432199

”

优点

精确定位功耗问题：Systrace 可以提供精确到微秒级别的时间戳，定位功耗问题问题时间和位置。

缺点

Systrace 只能监测 Android 系统本身以及应用程序，但不能监测硬件功耗，例如屏幕、摄像头、传感器等硬件设备的功耗。

使用场景

识别瞬时功耗：Systrace 可以捕捉瞬时功耗事件，例如启动应用程序、打开相机等操作。

可以识别到不必要的系统服务或者过多的数据同步操作等后台功耗问题。

3.2 功耗优化指南

3.2.1 APP 功耗统计流程

厂商耗电排行

在 Android 手机上，可以按照 设置 → 电池 → 电池百分比 步骤查看耗电排行：

“耗电排行”显示的是自上次充满电后的一个累计情况，很难满足测试需求。

关于耗电有一个很重要的 API BatteryStatsHelper。

首先， BatteryStatsHelper 通过 createFromParcel 方法统一耗电口径，然后，再通过 addPhoneUsage，最后， 通过 refreshStats 显示最近数天甚至一周以上的 APP 的电量统计数据。详细源码调用链参考如下:

电量计算公式

Android APP 中，可以使用以下代码获取设备当前的电量信息：

通过上述代码获取到的电量和电池容量可以使用上面提到的公式计算剩余电量。

注意，电池容量的单位为毫安时（mAh），需要将其转换为标准单位（例如，使用瓦时，1 毫安时 = 0.001 瓦时）。

电量计算公式是:

耗电器件模块主要是 Android 设备的各种硬件模块，主要可以分为以下三类:

第一类，像 Camera/FlashLight/MediaPlayer/ 一般传感器等之类的模块，其工作功率基本和额定功率保持一致，所以模块电量的计算只需要统计模块的使用时长再乘以额定功率即可。

第二类，像 Wifi/Mobile/BlueTooth 这类数据模块，其工作功率可以分为几个档位。

比如，当手机的 Wifi 信号比较弱的时候，Wifi 模块就必须工作在比较高的功率档位以维持数据链路。

所以这类模块的电量计算有点类似于高功耗任务日常的电费计算，需要 “阶梯计费”。

第三类，也是最复杂的模块，CPU 模块除了每一个 CPU Core 需要像数据模块那样阶梯计算电量之外，CPU 的每一个集群（Cluster，一般一个集群包含一个或多个规格相同的 Core）也有额外的耗电，此外整个 CPU 处理器芯片也有功耗。

简单计算的话，CPU 电量 = SUM (各核心功耗) + 各集群（Cluster）功耗 + 芯片功耗 。

如果往复杂方向考虑的话，那么 CPU 功耗还要考虑超频以及逻辑运行的信息熵损耗等电量损耗（Android 系统 CPU 的电量统计只计算到芯片功耗层）。

屏幕模块的电量计算就更麻烦了，很难把屏幕功耗合理地分配给各个 APP， 因此 Android 系统只是简单地计算 APP 屏幕锁（WakeLock）的持有时长，按固定系数增加 APP CPU 的统计时长，粗略地把屏幕功耗算进 CPU 里面。

最后，需要特别注意的是，以上提到的各种功率和时间在 Android 系统上的统计都是估算的，可想而知最终计算出来的电量数值可能与实际值相差巨大，Facebook 的工程师对此也有所吐槽：Mistrusting OS Level Battery Levels。

硬件电量统计

功率：power_profile.xml，Android 系统使用此文件来描述设备各个硬件模块的额定功率，包括上面提到的多档位功率和 CPU 电量算需要到的各种参数值。

时长：StopWatch & SamplingCounter，其中 StopWatch 是用来计算 APP 各种硬件模块的使用时长，而 SamplingCounter 则是用来采样统计 APP 在不同 CPU Core 和不同 CPUFreq 下的工作时长。

计算：PowerCalculators，每个硬件模块都有一个相应命名的 PowerCalculator 实现，主要是用来完成具体的电量统计算法。

存储：batterystats.bin，电量统计服务相关数据的持久化文件。

3.2.2 APP 功耗配置文件

通常，power_profile.xml 位于/system/framework/framework-res.apk 中，这是一个 android 设备的系统 apk，高功耗任务可以通过。

获取当前系统的 framework-res apk，这步不需要 root 即可进行，接着高功耗任务可以通过反编译工具，apktool 或者 jadx 都可以，对该 apk 进行反编译处理，高功耗任务所需要的功耗文件就在 /res/xml/power_profile.xml 中。

3.2.3 APP 功耗优化模式

Android 的 Doze 模式是一种省电模式，旨在减少设备的能耗。当设备进入 Doze 模式时，Android 会暂停一些不必要的后台活动，包括网络访问、同步、定位和其他不必要的服务。这样可以降低设备的能耗并延长电池寿命。Doze 模式分为两种：一种是 Light Doze，一种是 Deep Doze。

Doze 模式

Light Doze 会在设备未使用时激活，比如用户长时间未操作设备或将设备放置不用，它会限制 APP 的后台活动和一些系统服务。

而 Deep Doze 则需要设备完全静止一段时间，只有当设备完全静止一段时间后，才会激活 Deep Doze。在 Deep Doze 下，所有 APP 和系统服务都将被暂停，直到设备被唤醒。

需要注意的是，Doze 模式并不会完全关闭设备，而只是将设备进入一种低功耗状态。当用户开始使用设备时，设备会自动退出 Doze 模式，并恢复正常的工作状态。

Deep Doze

系统处于息屏状态，并且 30 分钟不移动的情况下，就会进入到 Deep Doze 模式，Deep Doze 机制中有七种状态，分别如下：

Light Doze

从上面可以看到想要进入 Doze 模式的条件是很苛刻，需要在手机息屏并且没有移动的状态下才能进入，所以 Android7.0 开始引入了 Light Doze，处于息屏状态，但仍处于移动状态可进入 Light Doze，LightDoze 有 7 个状态，分别如下：

根据上图，他们的转换关系总结如下:

Standby 模式

Android Standby 模式是一种类似于 Doze 模式的省电模式，它会在设备没有活动时将设备置于低功耗状态。在 Standby 模式下，APP 的后台活动和系统服务将被暂停，但仍可以使用特定的 API 允许部分后台活动和网络访问。

以上代码获取了 PowerManager 对象，并使用 isIgnoringBatteryOptimizations()方法检查 APP 是否允许忽略电量优化。

如果已经允许，则可以开始执行后台高功耗任务和网络访问。如果没有允许，则需要使用 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent 请求用户允许 APP 忽略电量优化。

需要注意的是，与 Doze 模式类似，启用 Standby 模式并不意味着所有后台活动和网络访问都将被暂停。

APP 需要使用特定的 API 允许必要的后台活动和网络访问，以确保在 Standby 模式下能够正常工作。

3.2.4 APP 功耗工作流程

BatteryStatsService 的工作流程大致可以分为两个部分：时长统计 & 功耗计算。

BatteryStatsService 时长统计流程

BatteryStats

BatteryStatsService 框架的核心是 BatteryStatsService 持有的一个叫 BatteryStats 的类，BatteryStats 又持有一个 Uid [] 数组，每一个 Uid 实例实际上对应一个 APP，当高功耗任务安装或者卸载 APP 的时候，BatteryStats 就会更新相应的 Uid 元素以保持最新的映射关系。同时 BatteryStats 持有一系列的 StopWatch 和 SamplingCounter，当 APP 开始使用某些硬件模块的功能时，BatteryStats 就会调用相应 Uid 的 StopWatch 或 SamplingCounter 来统计其硬件使用时长。

Wifi 模块

这里以 Wifi 模块来举例：当 APP 通过 WifiManager 系统服务调用 Wifi 模块开始扫描的时候，实际上会通过 WifiManager#startScan () --> WifiScanningServiceImp --> BatteryStatsService#noteWifiScanStartedFromSource () --> BatteryStats#noteWifiScanStartedLocked (uid) 等一连串的调用，通知 BatteryStats 开启 APP 相应 Uid 的 Wifi 模块的 StopWatch 开始计时。当 APP 通过 WifiManager 停止 Wifi 扫描的时候又会通过类似的流程调用 BatteryStats#noteWifiScanStoppedLocked (uid) 结束 StopWatch 的计时，这样一来就通过 StopWatch 完成 APP 对 Wifi 模块使用时长的统计。

BatteryStatsService 功耗计算流程

BatteryStatsHelper

具体电量计算方面，BatteryStats 是通过 BatteryStats 依赖的一个 BatteryStatsHelper 的辅助类来完成的。BatteryStatsHelper 通过组合使用 Uid 里的时长数据、PoweProfile 里的功率数据（power_profile.xml 的解析实例）以及具体各个模块的 PowerCalculator 算法，计算出每一个 APP 的综合电量消耗，并把计算结果保存在 BatterySipper [] 数组里（按计算值从大到小排序）。

WIFI 模块

还是以 Wifi 模块来举例：当需要计算 APP 电量消耗的时候，BatteryStats 会通过调用 BtteryStatsHelper#refreshStats () --> #processAPPUsage () 来刷新 BatterySipper [] 数组以计算最新的 APP 电量消耗数据。而其中 Wifi 模块单独的电量统计就是在 processAPPUsage 方法中通过 WifiPowerCalculator 来完成的：Wifi 模块电量 = PowerProfile 预置的 Idle 功率 × Uid 统计的 Wifi Idle 时间 + 上行功率 × 上行时间 + 下行功率 × 下行时间。

Audio 模块

Activity 状态改变

3.3 功耗优化 SOP

3.3.1 统计指标

• app 处于前台时，提供电流作为耗电指标。
• 通过采集 app 的 CPU、流量和 GPS 等的使用，来计算出一个加权和作为耗电指标。
• 电池温度，作为衡量耗电的辅助参考。

3.3.2 线下监测

3.3.2.1 监测专项

3.3.2.2 监测 SOP

监测时间段内，在游戏回播业务播放同一个测试回播资源 20 分钟。

监测时间内，确保应用走完倍速、音量梯度调整等播放主流程。

监测时间内，测量时间段内确保游戏回播全程播放。

监测时间内，确保游戏回播不切换视频资源。

监测过程中，屏幕保持常亮状态，亮度中等。因为屏幕唤醒本身就会有耗电开销。

监测过程中，使用 WiFi 网络，因为蜂窝测试数据不具备公正性。

监测过程中，把没有用到的传感器关掉，且不要充电。

3.3.2.3 监测结论

异常: 电池温度骤增，发热明显。

3.3.2.4 监测数据

3.3.2.4.1 手机硬件运行状况及电量消耗曲线图

• 测量过程中，耗电 1%需要的时间大概 xxx 分钟。
• 测量过程中，应用耗电曲线平滑，耗电波动稳定。
• 测量过程中，保持屏幕常亮，长时间开启 Audio 和 Screen 无法进入深度休眠，导致手机耗电严重。

3.3.2.4.2 手机各应用及硬件耗能

以上数据为部分应用及硬件的耗电估算数据，仅供参考。

3.3.2.5 问题分析

监测期间影响 APP 高功耗的三个原因是 CPU、Audio 和 Screen 三个组件，可从中寻求优化方案。

3.3.3 功耗归因

• 高 CPU 可以通过 CPU 菜单查看高耗 CPU 的堆栈。
• GPS(location)、Alarm 和 WakeLock 使用在超过指定持有时间和频次后，会上报当时的采集堆栈。

3.3.4 治理目标

1. 消除主流手机的高功耗提醒。
2. 建立健全的功耗监控及防劣化体系。

3.3.5 耗电治理

3.3.5.1 分模块治理

模块的耗电治理主要体现在下面几个方面：

3.3.5.1.1 CPU

死循环函数、高频函数、高耗时函数和无效函数等不必要的 CPU 消耗或消耗较多的函数治理。

CPU 使用率较高的场景及业务治理。

3.3.5.1.2 GPU&Display

过度绘制、过多的动画和不可见区域的动画等浪费 GPU 的场景治理。

主动降低屏幕亮度，使用深色 UI 等方案降低屏幕电量消耗。

3.3.5.1.3 NetWork

不影响业务和性能前提下，降低网络访问频率。

Doze 状态时减少无效的网络请求。

3.3.5.1.4 GPS

对使用 GPS 的场景，如小程序等，合理的降低精度，减少请求频率。

3.3.5.1.5 Audio、Camera、Video 等

3.3.5.2 分状态治理

除了分模块治理，还针对状态进行治理，主要状态有这几种：

3.3.5.2.1 Foreground 状态

渲染场景优化

音视频等场景优化

……

3.3.5.2.2 Background 状态

task 任务降频或者丢弃。

网络访问降频，适配 Doze 模式。

减少 CPU 消耗较多的函数执行。

减少 GPS 等高功耗场景。

3.3.5.3 防腐化建设

为了能更好的进行治理，完善的功耗分析和监控体系是不可避免的，不然就会出现无的放矢的状态。在这一块主要建设的点有。

3.3.5.3.1 CPU 监控

前后台高 CPU 消耗场景监控，高 CPU 消耗线程监控。

高频 task、高耗时 task 和后台 task 监控。

消耗较高、耗时较高的函数监控。

3.3.5.3.2 GPU&Display 监控

动画场景、过度绘制检测、View 层级检测和屏幕电量消耗监控等。

3.3.5.3.3 NetWork 监控

Rust、OkHttp 及其他网络请求场景，频率，消耗监控。

后台网络访问监控。

3.3.5.3.4 GPS 监控

GPS 使用场景、时长、电量消耗监控。

3.3.5.3.5 Audio、Camera、Video 等监控

使用场景、时长、电量消耗监控。

3.3.5.3.6 Global 电量监控

4.1 CPU 异常 SOP

4.1.1 CPU 异常归因

CPU 高负载异常是最常见的一类功耗问题。引起 CPU 高负载的原因有很多，通常是业务开发的不规范导 致的。高功耗任务主要通过线下和线上的工具，识别出 CPU 异常，进行进行 Case by case 的优化。

除了使用 Android Profiler 工具之外，也可以使用代码来实现 CPU 使用率的监控。以下是一个简单的示例代码，可以在应用程序中实现 CPU 使用率的实时监控：

以上代码在每隔 1 秒钟获取一次 CPU 使用率数据，并调用handleCpuUsage方法来处理 CPU 使用率。可以根据具体需求，来修改代码中的处理逻辑。

在 Android 操作系统中，可以通过代码的方式获取 CPU 使用率数据，并根据数据来确定异常 CPU 使用率的阈值。下面是一个简单的示例代码：

以上代码通过读取/proc/stat文件获取 CPU 使用率数据，然后计算 CPU 使用率，并根据预设的阈值来判断 CPU 使用率是否异常。这里假设异常阈值为 80%。

注意，实际使用时需要考虑到多种因素，如不同的设备、不同的 Android 版本等，可能需要做一定的兼容性处理。

4.1.2 CPU 异常治理

4.1.2.1 死循环

Bad Case

死循环类:循环退出条件达不到。

handler 消息循环

异常分支处理不当

4.1.2.2 资源不释放

动画泄漏

Bad Code

以下代码将创建一个持续运行的动画，但是没有停止或释放它，这可能会导致电池的损耗和性能问题：

Good Case

请注意，在实际使用中，应该在动画不再需要时停止或释放它，以避免泄漏和性能问题。例如：

Solution

通过正确停止和释放动画，可以帮助确保设备的电池寿命和性能。

音频泄漏

Bad Code

以下代码将创建一个 MediaPlayer 并不会释放它，这可能会导致电池的损耗和性能问题：

Good Case

请注意，在实际使用中，应该在不再需要音频时释放 MediaPlayer，以避免泄漏和性能问题。例如：

Solution

正确释放 MediaPlayer，可以帮助确保设备的电池寿命和性能。

WakeLock 不释放

Bad Code

以下是一段示例代码，该代码演示了如何使用 WakeLock 来保持设备唤醒，并且不释放 WakeLock 导致电池损耗和性能问题。

Good Case

在这段代码中，在 onCreate 方法中获取了一个 WakeLock，但是在 onDestroy 方法中没有释放该 WakeLock。这样做会导致电池损耗和性能问题，因为设备将一直处于唤醒状态。

Solution

为了解决这个问题，必须在不再需要该 WakeLock 时立即释放它，可以在 onDestroy 方法中添加以下代码实现，当该 Activity 不再需要保持设备唤醒时，就可以立即释放 WakeLock，以避免电池损耗和性能问题。

4.1.2.3 高频调用耗时函数

高频调用 md5 校验耗时函数

Bad Code

这段代码是模拟高频率调用 MD5 校验函数导致电池损耗和性能问题的情形：

这段代码会一直循环，不断地调用 MD5 校验函数，这将导致大量的 CPU 计算和内存使用，最终将导致电池损耗和性能问题。因此，在实际开发中，应该避免这样的高频率调用，控制对系统资源的使用。

Good Case

Solution

对高频调用 md5 校验耗时函数进行临界条件判断。

高频调用网络建链耗时函数

Bad Code

这段代码是模拟高频率调用网络建连耗时函数导致电池损耗和性能问题的情形：

“

NetworkNotAvaliabeException: network not avaliable

”

Good Case

这段代码会一直循环，不断地调用网络建连函数，这将导致大量的网络数据传输和系统资源使用，最终将导致电池损耗和性能问题。因此，在实际开发中，应该避免这样的高频率调用，控制对系统资源的使用。

Solution

对高频调用网络建链耗时函数进行临界条件判断。

高频调用正则表达式耗时函数

正则表达式是一种非常强大的工具，但是使用不当也可能导致性能问题。高频调用正则表达式的函数可能会占用大量的 CPU 资源，从而导致电池损耗和性能问题。

Bad Case

这段代码中，当用户点击按钮时，将会使用正则表达式频繁地匹配字符串。如果该操作被频繁调用，可能会导致电池损耗和性能问题。

Good Case

这段代码使用了 indexOf 方法代替正则表达式，以找到所需的数字。因为这种方法不需要使用正则表达式，因此它可以提高性能并减少电池损耗。

Solution

1. 优化正则表达式：尽量简化正则表达式，避免使用不必要的重复匹配。
2. 缓存结果：如果正在匹配相同的字符串，可以考虑缓存结果，以避免多次调用正则表达式。
3. 使用其他技术：使用字符串函数代替正则表达式，以提高性能。

4.1.3 CPU 异常结论

• 手机电池温度一般在 37 度以下，不会触发 CPU 温控限制。
• 手机未充电且 30%电量以上，CPU 使用率比较稳定。
• 手机省电模式对 CPU 影响较大。
• 手机网络类型对 CPU 影响很小。

4.1.4 CPU 异常阈值

• 手机电池电量>=30，电池温度<=37 度。
• 不同 CPU 型号 * 不同场景。
• CPU 劣化组的 P90 使用率。

4.2 Camera 功耗

Camera 功耗原因

Camera 功耗主要是由相机传感器，图像处理芯片，液晶显示器和自动对焦等组件造成的。

对于直播 APP 而言，最快捷的方式是限制相机的帧率，以减少图像处理所需的时间和电。

因为高分辨率高帧率的录制会带来快速的功耗消耗和温升，像抖音的开播场景，Camera 功耗 200mA+，占整机的 25%以上。

Camera 功耗场景

抖音在开播请求的采集帧率是 30fps，但只使用了 15fps。

Camera 优化手段

那么可以主动下调采集帧率。

30FPS 下调到15FPS后CPU下降13% ，整机功耗下降120mA

请注意，某些设备可能不支持 15 FPS，因此在代码中应该加入错误处理逻辑。此外，如果要使用相机，请务必注意遵循 Android 平台的隐私和权限规则。

4.3 低功耗

4.3.1 低功耗背景

低电量情况下，用户对功耗更加敏感，高功耗任务需要更激进的功耗优化措施：

• 未充电的情况下，剩余电量<=5%，单次停留时长开始显著下降。
• 剩余最低电量在 2%-5%的，会话占比 1.2%，时长在 15-18 分钟左右，对比 剩余 10%的平均时长 27 分钟，要损失约 11 分钟。

4.3.2 低功耗模式

Animation 暂停

Android 为了电池优化会在设备电量较低时自动减少某些可视化效果，例如动画、滚动和转场效果等。如果需要手动暂停动画，可以使用以下代码：

该代码会在 Android 4.4 及以上版本中启用硬件加速，并且会自动暂停所有正在运行的动画，以降低电量消耗。需要注意的是，这个方法可能会导致某些视图出现问题，因此需要根据具体情况决定是否使用。

超分算降级

超分辨率算法是将低分辨率图像恢复到高分辨率图像的过程。相反，降分辨率则是将高分辨率图像转换为低分辨率图像。下面是一个使用 OpenCV 库进行图像降采样的 Python 代码示例：

在上面的代码中，cv2.imread函数读取高分辨率图像，cv2.pyrDown函数对其进行降采样，最后， 使用cv2.imwrite函数将降采样后的图像保存到磁盘上。需要注意的是，降采样会丢失图像的某些细节，因此应该谨慎使用。

定位服务降级

以下是一个简单的示例代码，用于在定位服务中使用省电模式：

在这个示例代码中，高功耗任务首先获取了定位管理器的实例，然后，创建了一个定位请求，该请求使用了较低的电量优先级。

然后，高功耗任务检查了 GPS 是否可用，如果可用，高功耗任务就使用 GPS 请求位置更新。否则，高功耗任务使用网络提供商请求位置更新。

在这种情况下，高功耗任务使用了一个较长的位置更新间隔（30 秒）和较短的最快更新间隔（15 秒），以便在省电模式下更好地优化电量消耗。

Senor 降级

以下是一个简单的示例代码，用于在 Sensor 服务中使用低功耗模式：

在这个示例代码中，高功耗任务获取了 SensorManager 的实例，然后，获取了一个加速度传感器的实例。

接着，任务创建了一个 SensorEventListener 来监听传感器数据的变化。

最后，高功耗任务使用 SensorManager 的 registerListener 方法注册了这个传感器监听器，使用了较慢的 SENSOR_DELAY_NORMAL 模式，以便在低功耗模式下更好地优化电量消耗。

这样，高功耗任务就实现了 Sensor 降级的效果。需要注意的是，在不需要使用传感器的时候，应该及时取消注册传感器监听器，以免造成资源浪费。

视频码率降级

以下是一个简单的示例代码，用于在视频播放中降低码率以减少数据流量消耗：

在这个示例代码中，高功耗任务首先获取了 MediaPlayer 的实例，然后，设置了视频的数据源，接着设置了视频的播放画质为低画质。

最后，高功耗任务调用 prepare 方法准备 MediaPlayer，然后，调用 start 方法开始播放视频。

这样，就实现了在视频播放中降低码率的效果，以减少数据流量消耗。

需要注意的是，在选择降低码率的同时，也会降低视频的清晰度和流畅度，需要根据具体场景进行权衡。

Off-Screen Rendering

以下是一个简单的示例代码，用于关闭离屏渲染（Off-screen rendering）：

在这个示例代码中，高功耗任务获取了当前 View 的硬件加速类型，然后，使用 setLayerType 方法将硬件加速类型设置为 LAYER_TYPE_NONE，即关闭硬件加速，从而关闭离屏渲染。

需要注意的是，关闭硬件加速可能会降低视图渲染的性能和效率，因此在实际 APP 中，应该根据具体需求和场景来决定是否关闭硬件加速。

MediaPlayer 降级

以下是一个简单的示例代码，用于在视频播放器中实现降级：

在这个示例代码中，高功耗任务首先获取了 MediaPlayer 的实例。然后，设置了视频的数据源。

接着，高功耗任务尝试开启硬件解码器，如果硬件解码器不可用，就使用软件解码器。最后，高功耗任务调用 prepare 方法准备 MediaPlayer。然后，调用 start 方法开始播放视频。

这样，就实现了在视频播放器中进行降级的效果。需要注意的是，软件解码器通常会比硬件解码器消耗更多的 CPU 和内存资源，因此在实际 APP 中，应该根据具体需求和场景来决定是否使用软件解码器。

4.3.3 生效的场景

非充电情况下电量低于 30%

易发热机型增加开启时长

4.3.4 低功耗收益

降低 xxxmA

4.4 热缓解

4.4.1 热缓解背景

手机发热会影响用户体验，并且系统会通过限制设备的使用，减少发热量。前台 APP 不及时进行调整的话很可能会出现卡顿。

4.4.2 热缓解方案

监控手机发热，在发热前主动进行激进的降级手段，减少资源消耗，减少发热以及卡顿的发生。

以上图片来源于字节技术沙龙

4.4.3 热状态代码

Google 官方在 N 版本以上提供了热缓解框架，热缓解框架热状态码详见下表:

虽然Google热缓解框架需要各 OEM 厂商适配，但 OEM 并没有适配热缓解框架，而是通过开放 SDK 里提供了类似的能力，支持度和灵敏度，兼容性更优于 Google热缓解框架

4.4.4 收拢厂商 SDK 兼容 热缓解

因为没法磨平厂商的差异性，因此高功耗任务需要对各厂商的 SDK 进行适配，提供统一的温控级别，并对各个厂商的 SDK 进行收拢，下图可以看到字节对华为、小米、Vivo 和 OPPO 的厂商热缓解框架 SDK 收拢架构图。

以上图片来源于字节技术沙龙

4.4.4.1 厂商的热缓解SDK 优点

提供壳温，高热识别更灵敏。

4.4.4.2 厂商的热缓解 SDK缺点

老机型不支持，需要升级版本，覆盖率不高。

4.4.5 电池温度 VS 壳温相关性分析

系统在壳温平均 43 度左右会开启温控限制，39 度左右解除限制。

壳温与电池温度相关，壳温高于电池温度约 2 度。

4.5 动态帧率

4.5.1 背景

绘制帧率可以很明显的影响 GPU 功耗。抖音大部分的视频帧率都是 30fps，叠加上各种动画(音乐转盘，跑马灯，进度条，活动动画)，绘制帧率会处于 60fps，降低绘制帧率可以有效优化 GPU 耗电。

以上图片来源于字节技术沙龙

4.5.2 优化方向

4.5.2.1 帧率优化

动画帧率控制

动画帧率对齐

动画与播放器帧率对齐

4.5.2.3 厂商合作

调节 vsync 回调频率，实现动态帧率。

4.5.2.4 Kita 框架

Kita 框架通过托管多种动画的绘制流程，将整体的动 画调度逻辑在 kita controller 中进行统一管理，通过降帧，对齐后，实现了整体绘制帧率的降低。

以上图片来源于字节技术沙龙

厂商通过调节 Vsync 的回调频率或者利用 LTPO 屏幕的动态刷新率能力，都可以从系统侧实现对 APP 绘制帧率的控制，高功耗任务和厂商合作。

以上图片来源于字节技术沙龙

在视频推荐页通知系统降低帧率到 30fps，在部分场景恢复正常帧率(如弹幕，高帧率视频场景)，可以在保证用户体验的情况下获取更大的功耗收益。

4.6 SurfaceView 替换 TextureView

4.6.1 背景

TextureView 和 SurfaceView 是两个最常用的播放视频控件。

以上图片来源于字节技术沙龙

TextureView 控件位 于主图层上，解码器将视频帧传递到 TextureView 对象还需要 GPU 做一次绘制才能在屏幕上显示，所以其功耗更高，消耗内存更大，CPU 占用率也更高。

以上图片来源于字节技术沙龙

以下是 TextureView 和 SurfaceView 对比图:

以上图片来源于字节技术沙龙

4.6.2 收益

CPU -xxx%

“

技术需求: 将前台的 WakeLock、Location、Alarm、CPU、Net 和 Sensor 等器件的消费时间和启动次数，以及前台总耗电、前台单位时长总耗电、前台模块单位时间耗电、前台总时长进行计算并将结果存储到 SD 卡上的 JSON 配置文件。后台读取 JSON 配置文件的消费时间、启动次数、前台总耗电、前台单位时长总耗电、前台模块单位时间耗电、前台总时长等字段后并进行上报，监控系统可以进行多样化消费阈值的定义。如果超过消费阈值，那么飞书机器人告警。

”

简单列举一下 WakeLock 监控，其他器件参考 WakeLock 监控完成。实现思路如下:

在上面的代码中，我们创建了一个 ClassVisitor 的子类，该子类用于访问类中的方法，并在必要时修改字节码。在 visitMethod 方法中，我们检查每个方法的名称和描述符，如果它们匹配 acquire 和 release 方法的名称和描述符，就创建相应的 MethodVisitor。

在 WakeLockAcquireMethodVisitor 中，我们在方法的开头插入代码，以获取当前时间，并将其保存在局部变量中。这个时间将在释放 WakeLock 时使用。

在 WakeLockReleaseMethodVisitor 中，我们在方法的开头插入代码，以获取当前时间，并计算 WakeLock 的使用时间。然后，我们将时间和计数器保存到 JSON 对象中，然后将 JSON 对象写入 SD 卡上的文件中。

最后，在主程序中，我们需要在应用程序启动时加载 WakeLockPlugin，并且每隔一段时间读取 SD 卡上的 JSON 配置文件，并将其写入数据库或发送到服务器。

在上面的代码中，我们在应用程序启动时加载 WakeLockPlugin，并将其转换为 Dex 格式的字节码。然后，我们启动一个后台服务 ConfigService，该服务将定期读取 SD 卡上的 JSON 配置文件，并将其写入数据库或发送到服务器。

以上就是在 Android 应用程序中使用 ASM 完成字节码插桩，实现 WakeLock 的监控并将其保存到 SD 卡上的 JSON 配置文件中的基本步骤。请注意，这只是一个示例，实际应用程序可能需要根据具体需求进行更改和调整。

Android 功耗优化指导规范就讲解完毕了，简单的总结一下: Android 功耗优化指导规范主要分为五部分内容，第一部分内容是 5W2H 分析功耗优化。第二部分内容是功耗优化技术方案。第三部分内容是功耗优化方案分析。第四部分内容是功耗 APM 监控建设。最后一部分内容是总结与展望。

针对常见功耗问题，目前主要从两个视角发现问题，第一个视角是从设备角度出发寻找功耗优化手段，第二个视角是从体验角度出发，衡量如何使用降级手段，如低功耗模式和热缓解等。

针对常见功耗问题，未来我们不但要建立完善不同器件的功耗异常检测框架，同时也要完善功耗防劣化能力。