抖音看视频耗电快怎么解决(看抖音耗电快怎么办)

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

本文结合抖音的功耗优化实践中产出了一些实验结论，优化思路，从功耗的基础知识，功耗组成，功耗分析，功耗优化等几个方面，对 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

图 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 剩余能量，单位为纳瓦时

高频耗时函数治理

除了死循环问题，我们遇到的另外一种常见的就是高频的耗时函数。通过线上监控 CPU 异常，我们也找到很多可优化的点。如 md5 压缩算法的耗时，正则表达式的不合理使用，使用 cmd 执行系统命令的耗时等。这种就 case by case 的修复，就有很不错的收益。

后台资源规范使用

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，如果一直在执行状态不结束，就会导致系统无法休眠。

视频硬解替换软解

硬解通常是用手机平台自带的硬件解码器来做解码从而实现视频播放，基于专用芯片的硬解码速度快、功耗低；软解码方面，通常使用 FFMPEG 内置的 H.264 和 H.265 的软件解码库来做解码。

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

图片来源：http://www.noobyard.com/article/p-eedllxrr-qz.html

NETWORK

网络耗电是应用耗电的一个重要部分，一个数据包的收发，会同步拉动 CPU 和 Modem/WIFI 两大系统。由于 LTE 的 CDRX 特性（即没有数据包接收，维持一定时间的激活态，再进入睡眠，依赖运营商配置，通常为 10s），所以批量进行网络访问，减少频繁的网络唤醒对网络功耗很有帮忙。此外优化压缩算法，减少数据传输量也从基础上减少了网络耗电。

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

长链接心跳优化

对于应用的后台 PUSH 来说，使用厂商稳定的 push 链路替代自己的长链接可以减少功耗。如果不能替换，也可以优化长链接保活的心跳，根据不同的网络条件动态的调整心跳。根据经验，数据业务下通常是 5min，WIFI 网络下通常可以达到 20min 或更久。

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

Doze 模式适配

由于系统对后台应用有多种网络限制策略，最常见的是 Doze 模式，手机灭屏一段时间后会进入 doze，限制非白名单应用访问网络，并在窗口期解除限制，窗口期为每 10min 放开 30s。所以在后台进行网络访问前要特别注意进行网络可用的判断，选择窗口期进行网络访问，避免因为被限网而浪费了 CPU 资源。

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

AUDIO降低音量

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

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

10-15 ：1：30ma5-10：1：1.62ma0-5：1：1.36ma调整音频参数

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

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

CAMERA

Camera 是功耗大户，尤其是高分辨率高帧率的录制会带来快速的功耗消耗和温升。经过线下测算，开播场景，Camera 功耗 200mA+，占整机的 25%以上。

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

SENSOR

sensor 的典型功耗值很低，如我们常用到的 accelerometer(加速度计)的典型功耗只有 180uA。但 sensor 的开启会导致 cpu 的唤醒与负载增加，尤其是在应用退到后台，sensor 的滥用会显著增加待机功耗。可以在低电量时关闭不必要的 sensor，减少耗电。

GPS

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

降低精度

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

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

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

降低频率&提高间隔

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

https://developer.android.com/guide/topics/location/battery https://developer.huawei.com/consumer/cn/doc/development/HMSCore-References/location-description-0000001088559417

低功耗模式

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

在低功耗模式预研中，我们列举了很多可做的措施，通过 AB 实验，我们去掉了业务负向的降级手段，比如亮度降低，音量降低等。此外在功能触发的策略上，我们通过对比了低电量弹窗提醒，设置里增加开关+Toast 提醒，以及低电量自动进入，最终选择了对用户体验最好的 30%电量无打扰自动进入的触发方式。

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

总结

功耗优化是一个复杂的综合课题，既包含了利用工具对功耗做拆解评估，对异常的监控治理，也包含了主动挖掘优化点进行优化。上面列举的优化思路，我们也只是做了部分，还有部分待开展，包括功耗归因的工具建设上，我们也还有很多可以优化的点。我们会持续发力，产出更多的方案，在满足使用需求的前提下，消耗更少的物理资源，给抖音用户带来更好的功耗体验。

加入我们

抖音 Android 基础技术团队是一个深度追求极致的团队，我们专注于性能、架构、包大小、稳定性、基础库、编译构建等方向的深耕，保障超大规模团队的研发效率和数亿用户的使用体验。目前北京、上海、杭州、深圳都有大量人才需要，欢迎有志之士与我们共同建设亿级用户的 APP！ 感兴趣的同学可以点击“阅读原文”，进入字节跳动招聘官网查询「抖音基础技术 Android」相关职位，也可以邮件联系：gaoyuan.mmm@bytedance.com 咨询相关信息或者直接发送简历内推！

以上就是抖音看视频耗电快怎么解决的全部内容，希望能够对大家有所帮助。