抖音技术分享：抖音android端手机功耗问题的全面分析和详细优化实践 -凯发k8网页登录

本文由字节跳动技术团队高原、汤中峰分享，原题“抖音功耗优化实践”，本文有修订和改动。

功耗优化是应用体验优化的一个重要课题，高功耗会引发用户的电量焦虑，也会导致糟糕的发热体验，从而降低了用户的使用意愿。而功耗又是涉及整机的长时间多场景的综合性复杂指标，影响因素很多。不论是功耗的量化拆解，还是异常问题的监控，以及主动的功耗优化对于开发人员来说都是很有挑战性的。

本文结合抖音的功耗优化实践中产出了一些实验结论，优化思路，从功耗的基础知识，功耗组成，功耗分析，功耗优化等几个方面，对 android 应用的功耗优化做一个总结沉淀。

* 相关文章推荐阅读：

首先我们回顾一下功耗的概念，这里比较容易和能耗搞混。解释一下为什么手机上用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

从引言里我们已经了解到高功耗会引发用户的电量焦虑，也会导致糟糕的发热体验，从而降低了用户的使用意愿。

优化功耗除了可以我们带来更好的用户体验，提升用户使用时长外，降低应用耗电还具有很明显的社会价值。

用一个当前比较火的词，就是可以为碳中和事业贡献一份力量。

不同于 crash、anr 等常见的 apm 指标，功耗是一个综合性的课题，分析起来很容易让人无从下手。

用户反馈了耗电问题，可能是 cpu 出现高负载，又或者是后台频繁的网络访问，也可能是动画泄漏导致高功耗。或者我们自己的业务没什么变化，单纯就是环境因素影响，导致用户觉得耗电，比如低温导致的锂电池放电衰减。

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

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

5.1、概述

这里列举了手机硬件的基本形态，每个模块又是由复杂的器件构成。

如我们常说的耗电大头 soc 里就包含 cpu 的超大核、大核、小核、gpu、ddrc（内存接口），以及外设区的各种小 ip 核等。所以整机的功耗最终就可以拆解为各个器件的功耗，而应用的功耗就是计算其使用的器件产生的功耗。

以抖音的 feed 流场景为例：亮度固定 120nit、7 格音量、wifi 网络下，我们对抖音做了器件级的功耗拆解。可以看到抖音的 feed 功耗主要集中在 soc（cpu，gpu，ddr），display，audio，wifi 等四个模块。

5.2、器件功耗计算

那这些器件功耗是如何被拆解出来的呢？

原理是：先对器件进行耗电因子拆解，建立器件功耗模型，得到一个器件耗电的计算公式。通过运行时统计器件的使用数据，代入功耗模型，就可以计算出器件的功耗。应用的功耗则是从器件的总功耗里按应用使用的比较进行分配，这样就得到了应用的器件耗电。

由于影响器件功耗的耗电因子众多，这里复杂的就是如何对耗电因子进行拆解以及建模。有了精准的建模，后面就是厂商适配校准参数的过程了。

谷歌提供了一套通用的器件耗电模型和配置方案，oem 厂商可以按通用方案对自己的产品进行参数校准和配置。

如下图里 aosp 里的耗电配置里，以 wifi 的耗电计算为例：

（来源：）

谷歌提供的建模方案是对 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 耗电。这就要根据具体产品的硬件方案来确定了。

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

6.1、功耗评估

如前文功耗基础知识里所说，我们使用电流值来评估应用的功耗水平。

在线下场景：我们通过控制测试条件（如固定测试机型版本，清理后台，固定亮度，音量，稳定的网络信号条件等）来测得可信的准确电流值来评估应用的前后台功耗。

在线上场景：由于应用退后台时，用户使用场景的复杂性（指用户运行的前台应用不同），我们只采集前台整机电流来做线上版本监控，使用其他指标，如后台 cpu 使用率来监控后台功耗。

下面我们介绍一些常用功耗评估的手段。

6.1.1powermonitor

目前业界最通用的整机耗电评估方式是通过 powermonitor 外接电量计的方式，高频率高精度采集电流进行评估。常用需要精细化确认耗电情况，尤其是后台静置，灭屏等状态下的电流输出，厂商的准入测试等。

常用的 mosoon 公司的 powermonitoraaa10f，电流量程在 1ua ～ 6a 之间，电流精度 50ua，采样周期 200us (5khz)。

6.1.2电池电量计

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

电池电量计负责估计电池容量。其基本功能为监测电压，充电/放电电流和电池温度，并估计电池荷电状态（soc）及电池的完全充电容量（fcc）。

有两种典型的电量计：

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

目前手机上使用的电量计主要是电流型电量计。

android 提供了 bms 的接口，通过属性提供了电池电量计的统计结果：

1）battery_property_charge_counter 剩余电池容量，单位为微安时；

2）battery_property_current_now 瞬时电池电流，单位为微安；

3）battery_property_current_average 平均电池电流，单位为微安；

4）battery_property_capacity 剩余电池容量，显示为整数百分比；

5）battery_property_energy_counter 剩余能量，单位为纳瓦时。

importandroid.os.batterymanager;

importandroid.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，所以说这种方案的功耗影响非常低，适合线上采集电流值。

6.1.3厂商自带耗电排行

厂商提供的耗电排行也可以用来查看一段时间内的应用耗电情况。

如下面华为的耗电排行里，对硬件和软件耗电进行了分拆，并给出了应用的具体耗电量。其他厂商 ov 也是支持具体的耗电量，小米则是提供耗电占比，并不会提供具体耗电量。

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

6.2、功耗归因

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

6.2.1battery historian

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

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

对于单个应用，由于对 wakelock，alarm，gps，job，syncservice，后台服务运行时长等统计的比较详细，比较适合做后台耗电的归因。对于网络异常，cpu 异常，只能看到消耗较多，无法归因到具体业务。（来源：）

6.2.2as 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 比较适合于线下固定某个业务场景的分析。（来源：）

6.2.3线程池监控

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

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

6.2.4线上 cpu 异常精准监控

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

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

此外还有业界的一些归因框架，在这里不展开介绍了：

• 1）facebook batterymetrics：从 cpu/io/location 等多种归因点采集数据，和系统 batterystatsservice 的统计行为类似，偏重于线下做 app 的耗电评估和器件分解；
• 2）wechat batterycanary：提供了线程和线程池归因能力，相对于其他工具，增加前后台，亮灭屏，充放电，前台服务统计的统计。

上面介绍了功耗的组成，以及如何分析我们应用的耗电。这里我们对功耗优化做一个整体性介绍。

我们把优化思路从器件角度展开，列举我们有哪些优化的思路和措施，可以减少器件的使用情况，进而降低功耗。

此外对于一些用户可感知的有损业务的降级，我们通过低功耗模式来做，在低电量时通过更激进的降级手段，缓解用户的电量焦虑，带来用户的使用时长的提升。

下图列举了各器件上的优化思路，有一些优化思路会对多个器件都有收益，在这里没有特别详细的区分，就划分在主要影响的器件上，如减少刷新区域，对 gpu，cpu，ddr 都有收益，主要收益在 gpu 绘制上，在下图里就列举在 gpu 上了。

同时我们列举了厂商侧的一些优化方案，应用通常无需关注，比如降低屏幕刷新率，tp 扫描频率，整机低分辨率等，这种可以通过厂商合作的方式进行更细致的调优，如分场景动态调整屏幕刷新率，在搜索列表场景使用 90hz 高刷，在短视频场景结合帧率对齐进行刷新率降低为 30hz，以获得更平衡的功耗和性能体验。

显示功耗的优化主要围绕对屏幕、gpu、cpu、视频解码器、tp 等器件降级使用或者减少处理，尽量使用硬件处理等实现的。对于屏幕而言主要是降低亮度，刷新率，tp 扫描频率等。

8.1、屏幕亮度

8.1.1概述

屏幕亮度是屏幕功耗的最大来源，亮度和功耗几乎是正比的关系。

参见下图:

可以看出无论是 ips 屏幕还是 oled 屏幕，随着屏幕亮度增加，功耗几乎是线性增加。针对 oled 屏幕则是白色内容的功耗更高，深色内容则功耗相对更低。应用通用的降低亮度的方式有进入应用后主动降低亮度，或者使用深色的 ui 模式，来达到屏幕亮度降低的效果。厂商会通过 foss 或者 cabc 的方案，降低屏幕亮度。

8.1.2深色模式

利用 amoled 屏幕本身的原理，黑色功耗最低，所以可以尽量采用较暗的主题颜色等，最终获取较低的功耗，可以保持用户使用时间更长。

为什么说 amoled 屏幕显示黑色界面会消耗更少的电量呢？这要从它与传统的 lcd 屏幕之间的发光原理区别上来说。

lcd 背光显示屏，主要是靠背光层，发光层由大量 led 灯泡组成，显示白光，通过液晶层偏振控制，显示出 rgb 颜色。在这种情况下，黑色与其它颜色的像素并没有什么不同，虽然看起来并没有光亮，但是依然还是处于发光的状态。

amoled 屏幕根本就没有背光一说。相反，每个小的亚像素只是发出微弱的 rgb 光，如果屏幕需要显示黑色，只需要通过调整电压使得液晶分子排列旋转从而遮蔽住背光就可以实现黑色的效果，不会额外点亮任何颜色。

下面引用测试应用为 reddit sync 的不同场景下彩色和黑色模式功耗对比。（参考链接：）

从上面的图表我们可以很清楚的看到，在黑色背景的情况下，amoled 屏幕在能耗上的确要比普通颜色背景少了很多，在 reddit sync 的测试中，平均耗电量要降低 40%左右。

应用可以设计自己的深色模式主题，同步手机系统深色模式开关的切换。目前抖音背景设置有两种模式如下图，可以看到经典模式就是深色模式，正好对应于深色主题，这个也可以和手机平台的深色模式也结合起来。

8.1.3foss

foss （fidelity optimized signal scaling，保真优化信号缩放）是芯片厂商提供的一种对 amoled 屏幕调节的低功耗方案。

lcd 屏幕上对应的是 cabc （content adaptive brightness control，内容适应背光控制)。

一方面降低屏幕亮度，一方面调节显示内容灰度值，从而使显示效果差异不大，由于降低了屏幕亮度，所以获取的功耗收益较大。一般大约是 0.2 小时左右，即平均可延长手机使用时间 0.2 小时左右。

已知的情况是厂商的 foss 方案在某些参数情况下会导致个别场景出现变色或闪烁问题。如果遇到未确认闪烁问题，在内部定位无法确认原因时，可以跟厂商咨询进行排除。

8.2、降低刷新率

目前市面上部分手机支持 60hz、90hz、120hz、144hz 等，高的刷新率带来了流畅度提高，用户的体验更好，但是功耗更高。

通常来讲在系统应用界面比如桌面、设置、刷新率会跟当前系统设置保持一致，而在具体应用中，刷新率会根据不同场景做调整。比如抖音，即使在高刷屏幕上，平台系统一般选择让抖音运行在 60hz 刷新率，从而相对功耗较低。

针对不同的刷新率，phonearena 就做了一个比较有参考性的数据来验证这个观点。他们选取了两个品牌四款产品，都是高刷新率的机型，在同一条件下进行 60hz 刷新率和 120hz 刷新率的测试，结果 120hz 刷新率下手机续航相比 60hz 下的确缩短了至少 10%，即便是支持 90hz 的一加 8 也是比 60hz 刷新率要差。

8.3、降低 tp 扫描频率

通常游戏中为了提高点击响应速度会提高 tp 扫描频率，其他场景都采用默认的扫描频率。抖音一般使用默认的 tp 扫描帧率。

gpu 的优化思路主要在减少不必要的绘制或者降低绘制面积，这体现在更低的分辨率，更低的帧率，更少的绘制图层等方面。此外视频应用使用 surfaceview 替换 textureview 也有显著的功耗收益。对于复杂的运算，我们可以选择更高能效比的器件来进行，比如使用硬件绘制代替软件绘制，使用 npu 代替 gpu 执行复杂算法，对整体功耗都有明显降低。

9.1、降低分辨率

9.1.1应用低分辨率

通常该模式下游戏和特定应用一般以较低分辨率运行。缩小了 gpu 绘制区域和传输区域大小，降低了 gpu 和 cpu 以及传输 ddr 的功耗。功耗收益在游戏场景下比较大，线下测试特定平台下1080p->720p约20ma左右，1440p->720p约40ma左右。

其原理如下，应用图层在低分辨率下绘制，通过 hwc 通道放大到屏幕分辨率并跟其余图层合成后送显。

该功能通常平台侧设置，非游戏应用无需关注，游戏应用可以自己选择设置低分辨率。

部分游戏比如腾讯系游戏（如 qq 飞车、王者荣耀和和平精英等）内部也有不同分辨率的设置，默认以低分辨率运行，从而可以实现较低功耗。

9.1.2整机低分辨率

所有应用都运行在低分辨率下。同样也缩小了 gpu 绘制区域和传输区域大小，降低了 gpu 和 cpu 以及传输 ddr 的功耗。功耗收益跟应用低分辨率相同，普通应用在该模式下也有功耗收益。用户从系统设置菜单中切换，应用本身通常无需关注。

其原理如下，所有图层都在低分辨率下绘制，并在低分辨率下进行合成。合成后经过 scaler 一次性放大到屏幕分辨率，然后进行送显。其中 scaler 是放缩硬件，由芯片平台提供。

9.2、减少刷新区域

应用布局动画位置相近，布局出来一个较小的区域，绘制区域最小，刷新区域最小, 从而功耗最低。不同场景，收益不同。

如下图两种情况，可以看到左侧图，有 3 个动画区域（红色框住区域），最终形成的 dirty 区域为大的红框区域，整个面积较大。而对比中间图，动画两个红色区域，经过运算后形成的 dirty 大红框区域就较小，gpu 的绘制区域跟刷新的传输区域都较小，从而相对而言，功耗较低。从最右侧功耗数据图中可以看出收益较大。

可以在开发者选项中打开：设置 -> 开发者选项 -> 显示gpu视图更新，当刷新范围与动画范围明显不一致时便是动画布局不合理。这种情况需要具体到代码层面分析写法的问题并修改。

9.3、降低绘制频率

通常在游戏或应用动画中使用，可以降低 gpu 绘制频率和后面的刷新频率。通过降低动画绘制频率，可以降低 gpu，cpu 及 ddr 功耗。

不同帧率功耗情况对比如下，可以看到低帧率下相比高帧率，功耗明显低了很多。

在抖音应用中，低绘制帧率可以通过在抖音内部主动降低动画等帧率实现。在抖音推荐界面音乐转盘动画和音符动画中降低帧率，可以显著的降低功耗。

此外也可以通过厂商侧提供 soft vsync 实现 30hz 绘制，这部分抖音与厂商合作，surfaceflinger 控制 app vsync，降帧时 surfaceflinger vsync 输出降为 30fps，在特定条件下主动降低帧率，以延长使用时长。

9.4、帧率对齐

在抖音推荐页面中，通过视频和降低频率后的动画达到同步，可以实现整个界面以30hz 绘制和刷新。

否则，如果视频30hz和动画30帧正好交错，最终形成的绘制/刷新频率还是60帧，没有达到最优。

我们通过调节各种动画的绘制流程，将动画整体绘制对齐，整体帧率明显降低。

9.5、减少过度绘制

过度绘制（overdraw）描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 ui 结构里面，如果不可见的 ui 也在做绘制的操作，会导致某些像素区域被绘制了多次，同时也会浪费大量的 cpu 以及 gpu 资源。

可以通过如下来调试过度绘制：打开手机，设置 -> 开发者选项 -> 调试 gpu 过度绘制 -> 显示 gpu 过度绘制。

过度绘制的存在会导致界面显示时浪费不必要的资源去渲染看不见的背景，或者对某些像素区域多次绘制，就会导致界面加载或者滑动时的不流畅、掉帧，对于用户体验来说就是 app 特别的卡顿。为了提升用户体验，提升应用的流畅性，优化过度绘制的工作还是很有必要做的。

抖音的 feed 页的过度绘制非常的严重，抖音存在 5 层过度绘制。下图左侧是优化前的过渡绘制情况，右侧是优化后的过度绘制情况，可以看出优化后明显改善。

9.6、使用 surfaceview 视频播放

textureview 和 surfaceview 是两个最常用的播放视频控件。

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

控件位置差异如下，可以看出 surfaceview 拥有独立的 surface 位于单独的图层上，而 textureview 位于主图层上。

bufferqueue 是 android 图形架构的核心，其一侧是生产者，另一侧是消费者。从这方面看，surfaceview 和 textureview 的差异如下。容易看出，surfaceview 流程更短，内存使用更少，也没有 gpu 绘制，功耗更省。

 

下面是一些 surfaceview 替换 textureview 后的收益数据：

• 1）cpu数据上看：surfaceview 要比 textureview 优化 8%-13%；
• 2）功耗数据上看：surfaceview 要比 textureview 平均功耗低 20ma 左右。

9.7、硬件绘制和软件绘制

硬件绘制是指通过 gpu 绘制，android 从 3.0 开始支持硬件加速绘制，它在 ui 显示和绘制效率方面远高于软件绘制，但是 gpu 功耗相对较高。目前是系统默认的绘制方式。

软件绘制是指通过 cpu 实现绘制，android 上面使用 skia 图形库来进行绘制。

两者差异参见下图：

目前默认是开硬件加速的，可以通过设置 activity、application、窗口、view 等方式来指定软件绘制。如果应用需要单独指定某些场景的软件绘制方式，需要对性能、功耗等做好评估。（参考链接：）

9.8、复杂算法用 npu 代替 gpu

现在的较新的 soc 平台都带有专门进行 ai 运算的 npu 芯片，使用 npu 代替 gpu 运行一些复杂算法，可以有效的节省 gpu 功耗。

如视频的超分算法，可以给用户带来很好的体验。但是超分开启对 gpu 的耗电影响很大，在某些平台测试整机功耗可以高出 100ma，选择用 npu 替换 gpu 是一种优化方式。

10.1、概述

cpu 的优化是功耗优化里最常见的，我们遇到的大部分的 cpu 异常都是出现了死循环。

这里使用上面介绍过的功耗归因工具，都可以很容易的发现死循环问题。此外高频的耗时函数，效果和死循环类似，很容易让 cpu 大核跑到高频点，带来 cpu 功耗增加。

另外一个典型的 cpu 问题，就是动画泄漏，泄漏动画大概能带来 20ma 的功耗增加。

由于 cpu 工作耗电很高，手机平台大多会增加各种低功耗的 dsp 来分担 cpu 的工作，减少耗电，如常见视频解码，使用硬解会有更好的功耗表现。

10.2、cpu 高负载优化

10.2.1死循环治理

死循环是我们遇到的最明显的 cpu 异常，通常表现为某一个线程占满了一个大核。线程使用率达到了 100%，手机会很容易发热，卡顿。

这里举一个实际修复的死循环例子：在一段循环打包日志的代码逻辑里，所有 log打包完了，才会break跳出循环。当db query出现了异常，异常处理分支并没有做break，导致出现了死循环。

// 方法逻辑有裁剪，仅贴出主要逻辑

privatejsonarray packmisclog() {

    do{

        ......

        try{

            cursor = mdb.query(......);

            intn = cursor.getcount();

            ......

            if(start_id >= max_id) {

                break;

            }

        } catch(exception e) {

        } finally{

            safeclosecursor(cursor);

        }

    } while(true);

    returnret;

}

对于死循环治理，我们通过实际解决的问题，总结了几种常见的死循环套路。

// 边界条件未满足，无法break

while(true) {

    ...

    if(shouldexit()) {

        break

    }

}

 

// 异常处理不妥当，导致死循环

while(true) {

    try{

       dosometing;

       break;

    } catch(e) {

    }

}

 

// 消息处理不当，导致handler线程死循环

voidhandlemessage(message msg) {

    //do something

    handler.sendemptymessage(msg)

}

10.2.2高频耗时函数治理

除了死循环问题，我们遇到的另外一种常见的就是高频的耗时函数。

通过线上监控 cpu 异常，我们也找到很多可优化的点。如 md5 压缩算法的耗时，正则表达式的不合理使用，使用 cmd 执行系统命令的耗时等。这种就 case by case 的修复，就有很不错的收益。

10.3、后台资源规范使用：alarm、wakelock、jobscheduler 的规范使用

最常见的后台 cpu 耗电就是对后台资源的不合理使用。

alarm 的频繁唤醒，wakelock 的长时间不释放，jobscheduler 的频繁执行，都会使 cpu 保持唤醒状态，造成后台耗电。

这种行为很容易让系统判断应用为后台异常耗电，通常会被系统清理，或者发出高耗电提醒。

我们可以通过 dumpsys alarm & dumpsys power & dumpsys jobscheduler 查看相关的统计信息，也可以通过 bh 的后台统计来分析自身的使用情况。

参考绿盟的功耗标准，灭屏 alarm 触发小于过 12 次/h，即 5min 一次，5min 一次在数据业务下可以保证长链接存活，厂商的后台功耗优化也通常会强制对齐 alarm 为 5min 触发一次。

后台的 partial wakelock 通常会被重点限制，非可感知的场景（音乐，导航，运动）等会被厂商强制释放 wakelock。按照绿盟的标准，灭屏下每小时累计持锁小于 5min，从实际经验上看，持 partial 锁超过 1min 就会被标为 long 的 wakelock，如果是应用在后台无可感知业务并且频繁持锁，导致系统无法休眠的，系统会触发 forcestop 清理。

某些定时任务可以使用 jobscheduler 来替代 alarm，job 的好处是可以组合多种触发条件，选择一个最恰当的时刻让系统调度自己的后台任务。这里建议使用充电 网络可用状态下处理自己的后台任务，对功耗体验是最好的。如果是非充电场景下，设置条件频繁触发 job，同样会带来耗电问题。值得一提的是 job 执行完要及时结束。因为 jobscheduler 在执行时会持有一个*job/*开头的 wakelock，最长执行时间 10min，如果一直在执行状态不结束，就会导致系统无法休眠。

10.4、视频硬解替换软解

硬解码：通常是用手机平台自带的硬件解码器来做解码从而实现视频播放，基于专用芯片的硬解码速度快、功耗低。

软解码：通常使用 ffmpeg 内置的 h.264 和 h.265 的软件解码库来做解码。

下表是三星手机和苹果手机分别在软硬解情况下的功耗，可以看出硬解功耗比软解功耗显著降低，目前抖音默认使用硬解。

（图片来源：）

11.1、概述

网络耗电是应用耗电的一个重要部分，一个数据包的收发，会同步拉动 cpu 和 modem/wifi 两大系统。

由于 lte 的 cdrx 特性（即没有数据包接收，维持一定时间的激活态，再进入睡眠，依赖运营商配置，通常为 10s），所以批量进行网络访问，减少频繁的网络唤醒对网络功耗很有帮助。

此外：优化压缩算法，减少数据传输量也从基础上减少了网络耗电。

另外：弱信号条件下的网络请求会提高天线的功率，也会触发频繁的搜网，带来更高的网络功耗。根据网络质量进行网络请求调度，提前预缓存网络资源，可以减少网络耗电。

11.2、长链接心跳优化

对于应用的后台 push 来说，使用厂商稳定的 push 链路替代自己的长链接可以减少功耗。如果不能替换，也可以优化长链接保活的心跳，根据不同的网络条件动态的调整心跳。

根据经验，数据业务下通常是 5min，wifi 网络下通常可以达到 20min 或更久。

抖音对于长链接进行了的心跳优化，进入后台的长链接心跳时间间隔 [4min, 28min]，初始心跳 4min。采用动态心跳试探策略，每次步进 2min，确定最大心跳间隔。

11.3、doze 模式适配

由于系统对后台应用有多种网络限制策略，最常见的是 doze 模式，手机灭屏一段时间后会进入 doze，限制非白名单应用访问网络，并在窗口期解除限制，窗口期为每 10min 放开 30s。

所以在后台进行网络访问前要特别注意进行网络可用的判断，选择窗口期进行网络访问，避免因为被限网而浪费了 cpu 资源。

这里举一个 doze 未适配的后台耗电例：用户反馈抖音自上次手机充满电（24h）后，没有在前台使用过，耗电占比 31%，分析日志发现：在 doze 限制网络期间，会触发轮询判断网络是否及时恢复，此逻辑在后台未适配 doze 的窗口期模式，导致了后台频繁尝试网络请求带来的 cpu 耗电。

12.1、降低音量

音频的耗电最终体现在 codec 和 smartpa（连接喇叭的功率放大器）两部分。减少 audio 耗电最明显的就是减少音频的音量，这直接反应到喇叭的响度上。

用 0-15 级的音量进行测试，可以看到音量对功耗的影响巨大，尤其是超过 10 之后，整体增幅非常巨大。每一级几乎与功耗成百分比上涨。

具体是：

• 1）10-15 ：1：30ma；
• 2）5-10：1：1.62ma；
• 3）0-5：1：1.36ma。

12.2、调整音频参数

由于用户对音量的感受很明显，直接全局降低音量会带来不好的体验。厂商通常会针对不同的场景，设计不同的音频参数，如电影场景，游戏场景，导航场景，动态调节音频的高低频配置参数，兼顾了效果和功耗。

从这个角度出发，可以选择和厂商合作，根据播放视频的内容，精细化调整音频参数，如电影剪辑类型视频就使用电影场景的参数，游戏视频就切换为游戏场景的配置参数，从而达到用户无感调节音量节省功耗的目的。

camera 是功耗大户，尤其是高分辨率高帧率的录制会带来快速的功耗消耗和温升。

经过线下测算，开播场景，camera 功耗 200ma ，占整机的 25%以上。

优化camera功耗的思路主要是从业务降级的角度上进行，如降低录制的分辨率，降低录制帧率等。之前抖音直播和生产端都是使用30帧，但最终只使用15帧，在开播端主动下调采集帧率，按需设置帧率为15帧，功耗显著降低了120ma。

sensor 的典型功耗值很低，如我们常用到的 accelerometer（加速度计）的典型功耗只有 180ua。

但 sensor 的开启会导致 cpu 的唤醒与负载增加，尤其是在应用退到后台，sensor 的滥用会显著增加待机功耗。

可以在低电量时关闭不必要的 sensor，减少耗电。

精确度、频率、间隔是影响 gps 耗电的三个主要因素。其中精度影响定位的工作模式，频率和间隔是影响工作时长，我们可以通过优化这三者来减少 gps 的耗电。

15.1、降低精度

android 原生定位提供 gps 定位和网络定位两种模式。

gps 定位支持离线定位，依靠卫星，没有网络也能定位，精度高，但功耗大，因需要开启移动设备中的 gps 定位模块，会消耗较多电量。

network 定位（网络定位），定位速度快，只要具备网络或者基站要求，在任何地方都可实现瞬间定位，室内同样满足；功耗小，耗电量小。但定位精度差，容易受干扰，在基站或者 wifi 数量少、信号弱的地方定位质量较差，或者无法定位；必须连接网络才能实现定位。

我们可以在满足定位要求的情况下，主动使用低精度的网络定位，减少定位耗电，抖音在进入低功耗模式时，进行了 gps 降级为网络定位，并且扩大了定位间隔。

15.2、降低频率 & 提高间隔

这里除了业务上主动控制频率与间隔外，还推荐使用厂商的定位服务。

为了优化定位耗电，海外 gms 以及国内厂商都提供了位置服务 sdk，本质上是通过系统服务统一管理位置请求，根据电量，信号，请求方的延迟精度要求，进行动态调整，达到功耗与定位需求的平衡。提供了诸如被动位置更新，获取最近一次定位的位置信息，批量后台位置请求等低功耗定位能力。

比如：

• 1）；
• 2）。

上述的优化措施，有些在常规模式下已经实施。但有一部分是有损用户体验的，我们选择在低电量场景下去做，降低功耗，减少用户的电量焦虑，获得用户在低电量下更多使用时长。

在低功耗模式预研中，我们列举了很多可做的措施，通过 ab 实验，我们去掉了业务负向的降级手段，比如亮度降低，音量降低等。

此外在功能触发的策略上，我们通过对比了低电量弹窗提醒，设置里增加开关 toast 提醒，以及低电量自动进入，最终选择了对用户体验最好的 30%电量无打扰自动进入的触发方式。

经过实验发现：一些高发热机型，通过低功耗模式全程开启，也可以拿到业务收益。说明部分有损的降级，用户在易发热的情况下也是接受的，可以置换出业务收益，目前低功耗模式线下测试功耗收益稳定在 20ma 以上。

功耗优化是一个复杂的综合课题，既包含了利用工具对功耗做拆解评估，对异常的监控治理，也包含了主动挖掘优化点进行优化。

上面列举的优化思路，我们也只是做了部分，还有部分待开展，包括功耗归因的工具建设上，我们也还有很多可以优化的点。

我们会持续发力，产出更多的方案，在满足使用需求的前提下，消耗更少的物理资源，给抖音用户带来更好的功耗体验。

[1] 

[2] 

[3] 

[4] 

[5] 

[6] 

[7] 

（本文已同步发布于：）