本文由字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)高原、湯中峰分享，原題“抖音功耗優(yōu)化實(shí)踐”，本文有修訂和改動(dòng)。

一、引言

功耗優(yōu)化是應(yīng)用體驗(yàn)優(yōu)化的一個(gè)重要課題，高功耗會(huì)引發(fā)用戶的電量焦慮，也會(huì)導(dǎo)致糟糕的發(fā)熱體驗(yàn)，從而降低了用戶的使用意愿。而功耗又是涉及整機(jī)的長(zhǎng)時(shí)間多場(chǎng)景的綜合性復(fù)雜指標(biāo)，影響因素很多。不論是功耗的量化拆解，還是異常問題的監(jiān)控，以及主動(dòng)的功耗優(yōu)化對(duì)于開發(fā)人員來說都是很有挑戰(zhàn)性的。

本文結(jié)合抖音的功耗優(yōu)化實(shí)踐中產(chǎn)出了一些實(shí)驗(yàn)結(jié)論，優(yōu)化思路，從功耗的基礎(chǔ)知識(shí)，功耗組成，功耗分析，功耗優(yōu)化等幾個(gè)方面，對(duì) Android 應(yīng)用的功耗優(yōu)化做一個(gè)總結(jié)沉淀。

* 相關(guān)文章推薦閱讀：

1. 微信團(tuán)隊(duì)分享：詳解iOS版微信視頻號(hào)直播中因幀率異常導(dǎo)致的功耗問題

2. 微信那么牛，為什么海外成功的卻是抖音？

3. 解密抖音春節(jié)紅包背后的技術(shù)設(shè)計(jì)與實(shí)踐

技術(shù)交流：

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4540-1-1.html）

二、功耗基礎(chǔ)知識(shí)介紹

首先我們回顧一下功耗的概念，這里比較容易和能耗搞混。解釋一下為什么手機(jī)上用mA（電流值）來表征功耗水平，用 mAh（物理意義上是電荷值）來表征能耗水平。

我們先來看幾個(gè)物理公式：

P = I × U， E = P × T

能耗（E）：即能量損耗，指計(jì)算機(jī)系統(tǒng)一段時(shí)間內(nèi)總的能量消耗，單位是焦耳（J）。

功耗（P）：即功率損耗，指單位時(shí)間內(nèi)的能量消耗，反映消耗能量的速率，單位是瓦特（W）。

電流（I）：指手機(jī)電池放電的電流值，手機(jī)常用 mA 為單位。

電壓（U）：指手機(jī)電池放電的電壓值，標(biāo)準(zhǔn)放電電壓 3.7V，充電截止電壓 4.35V，放電截止電壓 2.75V（以典型值舉例，不同設(shè)備的電池電壓數(shù)值有差異）。

電池容量 ：常用單位 mAh，從單位意義上看是電荷數(shù)，實(shí)際表征的是電池以典型電壓放電的時(shí)長(zhǎng)。

如下面的功耗測(cè)試圖所示，手機(jī)通常以恒定的典型電壓工作，為了計(jì)算方便，就把電壓恒定為 3.7V，那么?P = I × 3.7， E = I × 3.7 × T，即用 mA 表征功耗，mAh 表征能耗。

總結(jié)：對(duì)同一機(jī)型，我們用電池容量（mAh）變化的來表征一段時(shí)間總能耗，用平均電流（mA）來表征功耗水平。如 4000mAh 電池的手機(jī)刷抖音 1 小時(shí)耗電 11%，耗電量（能耗）440mAh，平均電流 440mA

三、為什么要做功耗優(yōu)化

從引言里我們已經(jīng)了解到高功耗會(huì)引發(fā)用戶的電量焦慮，也會(huì)導(dǎo)致糟糕的發(fā)熱體驗(yàn)，從而降低了用戶的使用意愿。

優(yōu)化功耗除了可以我們帶來更好的用戶體驗(yàn)，提升用戶使用時(shí)長(zhǎng)外，降低應(yīng)用耗電還具有很明顯的社會(huì)價(jià)值。

用一個(gè)當(dāng)前比較火的詞，就是可以為碳中和事業(yè)貢獻(xiàn)一份力量。

四、如何來做功耗優(yōu)化

不同于 Crash、ANR 等常見的 APM 指標(biāo)，功耗是一個(gè)綜合性的課題，分析起來很容易讓人無從下手。

用戶反饋了耗電問題，可能是 CPU 出現(xiàn)高負(fù)載，又或者是后臺(tái)頻繁的網(wǎng)絡(luò)訪問，也可能是動(dòng)畫泄漏導(dǎo)致高功耗?；蛘呶覀冏约旱臉I(yè)務(wù)沒什么變化，單純就是環(huán)境因素影響，導(dǎo)致用戶覺得耗電，比如低溫導(dǎo)致的鋰電池放電衰減。

我們的思路是從器件出發(fā)，應(yīng)用的耗電最終都可以分解為手機(jī)器件的耗電，所以我們先對(duì)抖音做器件耗電的拆解，看主要耗電的是哪些器件，再看如何減少器件的使用，這樣就做到有的放矢。

下面我們先從功耗組成，功耗分析，以及功耗優(yōu)化等方面來講述如何開展功耗優(yōu)化。

五、功耗組成

5.1、概述

這里列舉了手機(jī)硬件的基本形態(tài)，每個(gè)模塊又是由復(fù)雜的器件構(gòu)成。

如我們常說的耗電大頭 SoC 里就包含 CPU 的超大核、大核、小核、GPU、DDRC（內(nèi)存接口），以及外設(shè)區(qū)的各種小 IP 核等。所以整機(jī)的功耗最終就可以拆解為各個(gè)器件的功耗，而應(yīng)用的功耗就是計(jì)算其使用的器件產(chǎn)生的功耗。

以抖音的 Feed 流場(chǎng)景為例：亮度固定 120nit、7 格音量、WiFi 網(wǎng)絡(luò)下，我們對(duì)抖音做了器件級(jí)的功耗拆解?？梢钥吹蕉兑舻?feed 功耗主要集中在 SOC（CPU，GPU，DDR），Display，Audio，WIFI 等四個(gè)模塊。

?

5.2、器件功耗計(jì)算

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

原理是：先對(duì)器件進(jìn)行耗電因子拆解，建立器件功耗模型，得到一個(gè)器件耗電的計(jì)算公式。通過運(yùn)行時(shí)統(tǒng)計(jì)器件的使用數(shù)據(jù)，代入功耗模型，就可以計(jì)算出器件的功耗。應(yīng)用的功耗則是從器件的總功耗里按應(yīng)用使用的比較進(jìn)行分配，這樣就得到了應(yīng)用的器件耗電。

由于影響器件功耗的耗電因子眾多，這里復(fù)雜的就是如何對(duì)耗電因子進(jìn)行拆解以及建模。有了精準(zhǔn)的建模，后面就是廠商適配校準(zhǔn)參數(shù)的過程了。

谷歌提供了一套通用的器件耗電模型和配置方案，OEM 廠商可以按通用方案對(duì)自己的產(chǎn)品進(jìn)行參數(shù)校準(zhǔn)和配置。

如下圖里 AOSP 里的耗電配置里，以 Wifi 的耗電計(jì)算為例：

（來源：https://source.android.com/devices/tech/power/values）

谷歌提供的建模方案是對(duì) WIFI 分狀態(tài)計(jì)算耗電，WIFI 不同狀態(tài)下的耗電差異非常明顯。這里分為了 wifi.on（對(duì)應(yīng) wifi 打開的基準(zhǔn)電流）, wifi.active（對(duì)應(yīng) wifi 傳輸數(shù)據(jù)時(shí)的基準(zhǔn)電流）, wifi.scan（對(duì)應(yīng) wifi 單次掃描的基準(zhǔn)耗電）, wifi 數(shù)據(jù)傳輸?shù)暮碾姡╟ontroller.rx，controller.tx, controller.idle）。根據(jù) wifi 收發(fā)數(shù)據(jù)的那計(jì)算 wifi 的耗電，通過統(tǒng)計(jì)這幾個(gè)狀態(tài)的時(shí)長(zhǎng)或次數(shù)，乘以對(duì)應(yīng)的電流，就得到 wifi 器件的耗電了。

由于谷歌是按照通用性來設(shè)計(jì)的器件耗電模型，通常只能大致計(jì)算出器件的耗電水平，具體到某個(gè)產(chǎn)品上可能誤差很大。各 OEM 廠商通常有基于自身硬件的耗電統(tǒng)計(jì)方案，可以對(duì)耗電做更加精細(xì)準(zhǔn)確的計(jì)算。

這里還用 wifi 舉例：如 OEM 廠商可以分別按照 2.4G，5GWIFI 單獨(dú)建模，并引入天線信號(hào)的變化對(duì)應(yīng)的基準(zhǔn)電流變化，以及統(tǒng)計(jì) wifi 芯片所工作的頻點(diǎn)時(shí)長(zhǎng)，按頻點(diǎn)細(xì)化模型等等，OEM 廠商可以設(shè)計(jì)出更符合自己設(shè)備的精準(zhǔn)功耗模型，計(jì)算出更精準(zhǔn)的 wifi 耗電。這就要根據(jù)具體產(chǎn)品的硬件方案來確定了。

六、功耗分析

通過上面的功耗組成的介紹，我們可以看到功耗影響因素是多種多樣。在做應(yīng)用功耗分析時(shí)，我們既要有方法準(zhǔn)確評(píng)估應(yīng)用的耗電水平，又要有方法來分解出耗電的組成，以找到優(yōu)化點(diǎn)。下面就分為功耗評(píng)估和功耗歸因分析這兩部分來介紹。

6.1、功耗評(píng)估

如前文功耗基礎(chǔ)知識(shí)里所說，我們使用電流值來評(píng)估應(yīng)用的功耗水平。

在線下場(chǎng)景：我們通過控制測(cè)試條件（如固定測(cè)試機(jī)型版本，清理后臺(tái)，固定亮度，音量，穩(wěn)定的網(wǎng)絡(luò)信號(hào)條件等）來測(cè)得可信的準(zhǔn)確電流值來評(píng)估應(yīng)用的前后臺(tái)功耗。

在線上場(chǎng)景：由于應(yīng)用退后臺(tái)時(shí)，用戶使用場(chǎng)景的復(fù)雜性（指用戶運(yùn)行的前臺(tái)應(yīng)用不同），我們只采集前臺(tái)整機(jī)電流來做線上版本監(jiān)控，使用其他指標(biāo)，如后臺(tái) CPU 使用率來監(jiān)控后臺(tái)功耗。

下面我們介紹一些常用功耗評(píng)估的手段。

6.1.1PowerMonitor

目前業(yè)界最通用的整機(jī)耗電評(píng)估方式是通過 PowerMonitor 外接電量計(jì)的方式，高頻率高精度采集電流進(jìn)行評(píng)估。常用需要精細(xì)化確認(rèn)耗電情況，尤其是后臺(tái)靜置，滅屏等狀態(tài)下的電流輸出，廠商的準(zhǔn)入測(cè)試等。

常用的 Mosoon 公司的 PowerMonitorAAA10F，電流量程在 1uA ～ 6A 之間，電流精度 50uA，采樣周期 200us (5KHZ)。

6.1.2電池電量計(jì)

PowerMonitor 雖然測(cè)量結(jié)果最準(zhǔn)確。但是需要拆機(jī)比較麻煩。我們還可以通過谷歌 BatteryManager 提供的接口直接讀取電池電量計(jì)的統(tǒng)計(jì)結(jié)果來獲得電流值。

電池電量計(jì)負(fù)責(zé)估計(jì)電池容量。其基本功能為監(jiān)測(cè)電壓，充電/放電電流和電池溫度，并估計(jì)電池荷電狀態(tài)（SOC）及電池的完全充電容量（FCC）。

有兩種典型的電量計(jì)：

• 1）電壓型電量計(jì)：簡(jiǎn)單講就是檢測(cè)當(dāng)前電壓，然后查詢電壓-電池容量對(duì)應(yīng)表，獲得電量估算；

• 2）電流型電量計(jì)：也叫庫侖計(jì)，原理是在電池的充電/放電路徑上的連接一個(gè)檢測(cè)電阻。ADC 量測(cè)在檢測(cè)電阻上的電壓，轉(zhuǎn)換成電池正在充電或放電的電流值。實(shí)時(shí)計(jì)數(shù)器（RTC）則提供把該電流值對(duì)時(shí)間作積分，從而得知流過多少庫倫。

目前手機(jī)上使用的電量計(jì)主要是電流型電量計(jì)。

Android 提供了 BMS 的接口，通過屬性提供了電池電量計(jì)的統(tǒng)計(jì)結(jié)果：

1）BATTERY_PROPERTY_CHARGE_COUNTER?剩余電池容量，單位為微安時(shí)；

2）BATTERY_PROPERTY_CURRENT_NOW?瞬時(shí)電池電流，單位為微安；

3）BATTERY_PROPERTY_CURRENT_AVERAGE?平均電池電流，單位為微安；

4）BATTERY_PROPERTY_CAPACITY?剩余電池容量，顯示為整數(shù)百分比；

5）BATTERY_PROPERTY_ENERGY_COUNTER?剩余能量，單位為納瓦時(shí)。

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 為例，該機(jī)型使用了 MAX17050 電流型電量計(jì)，解析度 156.25uA，更新周期 175.8ms。

從實(shí)踐結(jié)果上看：由于不同的手機(jī)使用的電量計(jì)不同，導(dǎo)致直接讀取出來的電流值單位也不同，需要做數(shù)據(jù)轉(zhuǎn)化。為了簡(jiǎn)化電池?cái)?shù)據(jù)的獲取，我們開發(fā)了 Thor SDK，只保留電流、電壓、電量等指標(biāo)的采集過程，針對(duì)不同機(jī)型做了數(shù)據(jù)歸一處理，用戶可以不用關(guān)心內(nèi)部實(shí)現(xiàn)，只需要提供需要采樣的數(shù)據(jù)類型、采樣周期就可以定時(shí)返回所需要的功耗相關(guān)的數(shù)據(jù)，我們用 Thor 對(duì)比 PowerMonitor 進(jìn)行了數(shù)據(jù)一致性的校驗(yàn)，誤差<5mA，滿足線上監(jiān)控需求。

此外：我們做了 Thor 采集功能本身的功耗影響，可以看到 1s 采集 1 次的情況下，平均電流上漲了 0.59mA，所以說這種方案的功耗影響非常低，適合線上采集電流值。

6.1.3廠商自帶耗電排行

廠商提供的耗電排行也可以用來查看一段時(shí)間內(nèi)的應(yīng)用耗電情況。

如下面華為的耗電排行里，對(duì)硬件和軟件耗電進(jìn)行了分拆，并給出了應(yīng)用的具體耗電量。其他廠商 OV 也是支持具體的耗電量，小米則是提供耗電占比，并不會(huì)提供具體耗電量。

功能入口：設(shè)置->電池->耗電排行

6.2、功耗歸因

從功耗評(píng)估我們可以判斷應(yīng)用的整體耗電情況，但具體到某個(gè) case 高耗電的原因是什么，就要具體問題選擇不同的工具來進(jìn)行分析了。目前可以直接歸因到業(yè)務(wù)代碼的主要是 CPU 相關(guān)的工具，這也是我們目前分析問題的主要方向，后續(xù)我們也會(huì)建設(shè)流量歸因等能力，下面我列舉了常用的分析工具。

6.2.1Battery Historian

谷歌官方提供的分析工具，需要先進(jìn)行功耗測(cè)試，再通過 adb 抓取 bugreport.zip，再通過網(wǎng)頁工具打開，可提供粗粒度的功耗歸因。

本質(zhì)上是對(duì) systemserver 里的各種服務(wù)統(tǒng)計(jì)信息+手機(jī)狀態(tài)+內(nèi)核統(tǒng)計(jì)信息（kernel 喚醒）的展示，應(yīng)用耗電的估算依賴廠商配置的?power_profile.xml。比較適合對(duì)整機(jī)耗電問題做耗電歸因，如歸因到某應(yīng)用耗電較高。

對(duì)于單個(gè)應(yīng)用，由于對(duì) wakelock，alarm，gps，job，syncservice，后臺(tái)服務(wù)運(yùn)行時(shí)長(zhǎng)等統(tǒng)計(jì)的比較詳細(xì)，比較適合做后臺(tái)耗電的歸因。對(duì)于網(wǎng)絡(luò)異常，CPU 異常，只能看到消耗較多，無法歸因到具體業(yè)務(wù)。（來源：https://developer.android.com/to ... -historian?hl=zh-cn）

?

6.2.2AS Profiler

相比于 BatteryHistorian 需要先手動(dòng)測(cè)試，再 adb 抓取的操作繁瑣，AS 自帶的 Profiler 提供了 Energy 的可視化展示。使用 debug 版本的應(yīng)用，可以直觀的看到功耗的消耗情況，方便了線下測(cè)試。需要注意的是這里展示的功耗值是通過 GPS+網(wǎng)絡(luò)+CPU 計(jì)算的擬合值，并不是真實(shí)功耗值，只表征功耗水平。

Profiler 同步展示了 CPU 使用率，網(wǎng)絡(luò)耗電，內(nèi)存信息。支持 CPU 和線程級(jí)別的跟蹤。通過主動(dòng)錄制 Trace，可以分析各線程的 CPU 使用情況，以及耗時(shí)函數(shù)。對(duì)于容易復(fù)現(xiàn)的 CPU 高負(fù)載問題或者固定場(chǎng)景的耗時(shí)問題，這種方式可以很容易看到根因。但 trace 的展示方式并不適合偶現(xiàn)的 CPU 高負(fù)載，信息量特別多反而讓人難以抓住重點(diǎn)。

網(wǎng)絡(luò)耗電可以很方便抓取到上行下行的網(wǎng)絡(luò)請(qǐng)求，可以展示網(wǎng)絡(luò)請(qǐng)求的 api 細(xì)節(jié)，并且劃分到線程上。對(duì)于頻繁的網(wǎng)絡(luò)訪問，很容易找到問題點(diǎn)。但目前只支持通過 HttpURLConnection 和 OkHttp 的網(wǎng)絡(luò)請(qǐng)求，使用其他的網(wǎng)絡(luò)庫，Profiler 追蹤不到。

可以看到官方出品的工具，功能比較完善，但只支持 debug 版本的 app 分析，如果要分析 release 版本的 app，需要使用 root 手機(jī)。總體而言，Profiler 比較適合于線下固定某個(gè)業(yè)務(wù)場(chǎng)景的分析。（來源：https://developer.android.com/studio/profile/energy-profiler）

6.2.3線程池監(jiān)控

使用上面的工具監(jiān)控單個(gè)線程的 CPU 異常是可以的。但是對(duì)于線程池，Handler，AsyncTask 等異步任務(wù)不太容易歸因具體的業(yè)務(wù)，尤其是網(wǎng)絡(luò)庫的線程池，由于執(zhí)行的網(wǎng)絡(luò)請(qǐng)求邏輯是一樣的，只靠抓線程堆棧是不能歸因到具體業(yè)務(wù)的。需要統(tǒng)計(jì)提交任務(wù)的源頭代碼才能抓到真正問題點(diǎn)。

我們可以通過多種機(jī)制，如改造線程池，java hook 等，對(duì)提交任務(wù)方進(jìn)行了詳細(xì)記錄和聚合，可以幫忙我們分析線程池里的耗時(shí)任務(wù)。

6.2.4線上 CPU 異常精準(zhǔn)監(jiān)控

除了線下的 CPU 分析，我們?cè)谶M(jìn)行線上 CPU 異常監(jiān)控的建設(shè)時(shí)，我們考慮到單純使用 CPU 使用率閾值不能精準(zhǔn)的判斷進(jìn)程是否處于 CPU 異常。比如不同的 CPU 型號(hào)本身的性能不同，在某些低端 CPU 上的使用率就是比較高。又比如系統(tǒng)有不同的溫控策略，省電策略，會(huì)對(duì)手機(jī)進(jìn)行限頻，對(duì)任務(wù)進(jìn)行 CPU 核心遷移。在這種情況下，應(yīng)用也會(huì)有更高的 CPU 使用率。

因此我們基于不同的變量因素（如 CPU 型號(hào)，進(jìn)程/線程的 CPU 時(shí)長(zhǎng)在不同核，不同頻點(diǎn)的分布，充電，電量，內(nèi)存，網(wǎng)絡(luò)狀態(tài)等），將 CPU 的使用閾值進(jìn)行精細(xì)判定，針對(duì)不同場(chǎng)景、不同設(shè)備、不同業(yè)務(wù)制定精細(xì)化的 CPU 異常閾值，從而實(shí)現(xiàn)了高精度的 CPU 異常抓取。

此外還有業(yè)界的一些歸因框架，在這里不展開介紹了：

• 1）Facebook BatteryMetrics：從 CPU/IO/Location 等多種歸因點(diǎn)采集數(shù)據(jù)，和系統(tǒng) BatteryStatsService 的統(tǒng)計(jì)行為類似，偏重于線下做 App 的耗電評(píng)估和器件分解；

• 2）WeChat BatteryCanary：提供了線程和線程池歸因能力，相對(duì)于其他工具，增加前后臺(tái)，亮滅屏，充放電，前臺(tái)服務(wù)統(tǒng)計(jì)的統(tǒng)計(jì)。

七、功耗優(yōu)化實(shí)踐概述

上面介紹了功耗的組成，以及如何分析我們應(yīng)用的耗電。這里我們對(duì)功耗優(yōu)化做一個(gè)整體性介紹。

我們把優(yōu)化思路從器件角度展開，列舉我們有哪些優(yōu)化的思路和措施，可以減少器件的使用情況，進(jìn)而降低功耗。

此外對(duì)于一些用戶可感知的有損業(yè)務(wù)的降級(jí)，我們通過低功耗模式來做，在低電量時(shí)通過更激進(jìn)的降級(jí)手段，緩解用戶的電量焦慮，帶來用戶的使用時(shí)長(zhǎng)的提升。

下圖列舉了各器件上的優(yōu)化思路，有一些優(yōu)化思路會(huì)對(duì)多個(gè)器件都有收益，在這里沒有特別詳細(xì)的區(qū)分，就劃分在主要影響的器件上，如減少刷新區(qū)域，對(duì) GPU，CPU，DDR 都有收益，主要收益在 GPU 繪制上，在下圖里就列舉在 GPU 上了。

同時(shí)我們列舉了廠商側(cè)的一些優(yōu)化方案，應(yīng)用通常無需關(guān)注，比如降低屏幕刷新率，TP 掃描頻率，整機(jī)低分辨率等，這種可以通過廠商合作的方式進(jìn)行更細(xì)致的調(diào)優(yōu)，如分場(chǎng)景動(dòng)態(tài)調(diào)整屏幕刷新率，在搜索列表場(chǎng)景使用 90HZ 高刷，在短視頻場(chǎng)景結(jié)合幀率對(duì)齊進(jìn)行刷新率降低為 30HZ，以獲得更平衡的功耗和性能體驗(yàn)。

八、功耗優(yōu)化實(shí)踐1：DISPLAY

顯示功耗的優(yōu)化主要圍繞對(duì)屏幕、GPU、CPU、視頻解碼器、TP 等器件降級(jí)使用或者減少處理，盡量使用硬件處理等實(shí)現(xiàn)的。對(duì)于屏幕而言主要是降低亮度，刷新率，TP 掃描頻率等。

8.1、屏幕亮度

8.1.1概述

屏幕亮度是屏幕功耗的最大來源，亮度和功耗幾乎是正比的關(guān)系。

參見下圖:

可以看出無論是 IPS 屏幕還是 OLED 屏幕，隨著屏幕亮度增加，功耗幾乎是線性增加。針對(duì) OLED 屏幕則是白色內(nèi)容的功耗更高，深色內(nèi)容則功耗相對(duì)更低。應(yīng)用通用的降低亮度的方式有進(jìn)入應(yīng)用后主動(dòng)降低亮度，或者使用深色的 UI 模式，來達(dá)到屏幕亮度降低的效果。廠商會(huì)通過 FOSS 或者 CABC 的方案，降低屏幕亮度。

8.1.2深色模式

利用 AMOLED 屏幕本身的原理，黑色功耗最低，所以可以盡量采用較暗的主題顏色等，最終獲取較低的功耗，可以保持用戶使用時(shí)間更長(zhǎng)。

為什么說 AMOLED 屏幕顯示黑色界面會(huì)消耗更少的電量呢？這要從它與傳統(tǒng)的 LCD 屏幕之間的發(fā)光原理區(qū)別上來說。

LCD 背光顯示屏，主要是靠背光層，發(fā)光層由大量 LED 燈泡組成，顯示白光，通過液晶層偏振控制，顯示出 RGB 顏色。在這種情況下，黑色與其它顏色的像素并沒有什么不同，雖然看起來并沒有光亮，但是依然還是處于發(fā)光的狀態(tài)。

AMOLED 屏幕根本就沒有背光一說。相反，每個(gè)小的亞像素只是發(fā)出微弱的 RGB 光，如果屏幕需要顯示黑色，只需要通過調(diào)整電壓使得液晶分子排列旋轉(zhuǎn)從而遮蔽住背光就可以實(shí)現(xiàn)黑色的效果，不會(huì)額外點(diǎn)亮任何顏色。

下面引用測(cè)試應(yīng)用為 Reddit Sync 的不同場(chǎng)景下彩色和黑色模式功耗對(duì)比。（參考鏈接：https://m.zol.com.cn/article/4895723.html#p4）

從上面的圖表我們可以很清楚的看到，在黑色背景的情況下，AMOLED 屏幕在能耗上的確要比普通顏色背景少了很多，在 Reddit Sync 的測(cè)試中，平均耗電量要降低 40%左右。

應(yīng)用可以設(shè)計(jì)自己的深色模式主題，同步手機(jī)系統(tǒng)深色模式開關(guān)的切換。目前抖音背景設(shè)置有兩種模式如下圖，可以看到經(jīng)典模式就是深色模式，正好對(duì)應(yīng)于深色主題，這個(gè)也可以和手機(jī)平臺(tái)的深色模式也結(jié)合起來。

8.1.3FOSS

FOSS （Fidelity Optimized Signal Scaling，保真優(yōu)化信號(hào)縮放）是芯片廠商提供的一種對(duì) AMOLED 屏幕調(diào)節(jié)的低功耗方案。

LCD 屏幕上對(duì)應(yīng)的是 CABC （Content Adaptive Brightness Control，內(nèi)容適應(yīng)背光控制)。

一方面降低屏幕亮度，一方面調(diào)節(jié)顯示內(nèi)容灰度值，從而使顯示效果差異不大，由于降低了屏幕亮度，所以獲取的功耗收益較大。一般大約是 0.2 小時(shí)左右，即平均可延長(zhǎng)手機(jī)使用時(shí)間 0.2 小時(shí)左右。

已知的情況是廠商的 FOSS 方案在某些參數(shù)情況下會(huì)導(dǎo)致個(gè)別場(chǎng)景出現(xiàn)變色或閃爍問題。如果遇到未確認(rèn)閃爍問題，在內(nèi)部定位無法確認(rèn)原因時(shí)，可以跟廠商咨詢進(jìn)行排除。

8.2、降低刷新率

目前市面上部分手機(jī)支持 60HZ、90HZ、120HZ、144HZ 等，高的刷新率帶來了流暢度提高，用戶的體驗(yàn)更好，但是功耗更高。

通常來講在系統(tǒng)應(yīng)用界面比如桌面、設(shè)置、刷新率會(huì)跟當(dāng)前系統(tǒng)設(shè)置保持一致，而在具體應(yīng)用中，刷新率會(huì)根據(jù)不同場(chǎng)景做調(diào)整。比如抖音，即使在高刷屏幕上，平臺(tái)系統(tǒng)一般選擇讓抖音運(yùn)行在 60HZ 刷新率，從而相對(duì)功耗較低。

針對(duì)不同的刷新率，PhoneArena 就做了一個(gè)比較有參考性的數(shù)據(jù)來驗(yàn)證這個(gè)觀點(diǎn)。他們選取了兩個(gè)品牌四款產(chǎn)品，都是高刷新率的機(jī)型，在同一條件下進(jìn)行 60Hz 刷新率和 120Hz 刷新率的測(cè)試，結(jié)果 120HZ 刷新率下手機(jī)續(xù)航相比 60HZ 下的確縮短了至少 10%，即便是支持 90Hz 的一加 8 也是比 60HZ 刷新率要差。

8.3、降低 TP 掃描頻率

通常游戲中為了提高點(diǎn)擊響應(yīng)速度會(huì)提高 TP 掃描頻率，其他場(chǎng)景都采用默認(rèn)的掃描頻率。抖音一般使用默認(rèn)的 TP 掃描幀率。

九、功耗優(yōu)化實(shí)踐2：GPU

GPU 的優(yōu)化思路主要在減少不必要的繪制或者降低繪制面積，這體現(xiàn)在更低的分辨率，更低的幀率，更少的繪制圖層等方面。此外視頻應(yīng)用使用 SurfaceView 替換 TextureView 也有顯著的功耗收益。對(duì)于復(fù)雜的運(yùn)算，我們可以選擇更高能效比的器件來進(jìn)行，比如使用硬件繪制代替軟件繪制，使用 NPU 代替 GPU 執(zhí)行復(fù)雜算法，對(duì)整體功耗都有明顯降低。

9.1、降低分辨率

9.1.1應(yīng)用低分辨率

通常該模式下游戲和特定應(yīng)用一般以較低分辨率運(yùn)行?？s小了 GPU 繪制區(qū)域和傳輸區(qū)域大小，降低了 GPU 和 CPU 以及傳輸 DDR 的功耗。功耗收益在游戲場(chǎng)景下比較大，線下測(cè)試特定平臺(tái)下1080p->720p約20mA左右，1440p->720p約40mA左右。

其原理如下，應(yīng)用圖層在低分辨率下繪制，通過 HWC 通道放大到屏幕分辨率并跟其余圖層合成后送顯。

該功能通常平臺(tái)側(cè)設(shè)置，非游戲應(yīng)用無需關(guān)注，游戲應(yīng)用可以自己選擇設(shè)置低分辨率。

部分游戲比如騰訊系游戲（如 QQ 飛車、王者榮耀和和平精英等）內(nèi)部也有不同分辨率的設(shè)置，默認(rèn)以低分辨率運(yùn)行，從而可以實(shí)現(xiàn)較低功耗。

9.1.2整機(jī)低分辨率

所有應(yīng)用都運(yùn)行在低分辨率下。同樣也縮小了 GPU 繪制區(qū)域和傳輸區(qū)域大小，降低了 GPU 和 CPU 以及傳輸 DDR 的功耗。功耗收益跟應(yīng)用低分辨率相同，普通應(yīng)用在該模式下也有功耗收益。用戶從系統(tǒng)設(shè)置菜單中切換，應(yīng)用本身通常無需關(guān)注。

其原理如下，所有圖層都在低分辨率下繪制，并在低分辨率下進(jìn)行合成。合成后經(jīng)過 scaler 一次性放大到屏幕分辨率，然后進(jìn)行送顯。其中 scaler 是放縮硬件，由芯片平臺(tái)提供。

9.2、減少刷新區(qū)域

應(yīng)用布局動(dòng)畫位置相近，布局出來一個(gè)較小的區(qū)域，繪制區(qū)域最小，刷新區(qū)域最小, 從而功耗最低。不同場(chǎng)景，收益不同。

如下圖兩種情況，可以看到左側(cè)圖，有 3 個(gè)動(dòng)畫區(qū)域（紅色框住區(qū)域），最終形成的 Dirty 區(qū)域?yàn)榇蟮募t框區(qū)域，整個(gè)面積較大。而對(duì)比中間圖，動(dòng)畫兩個(gè)紅色區(qū)域，經(jīng)過運(yùn)算后形成的 Dirty 大紅框區(qū)域就較小，GPU 的繪制區(qū)域跟刷新的傳輸區(qū)域都較小，從而相對(duì)而言，功耗較低。從最右側(cè)功耗數(shù)據(jù)圖中可以看出收益較大。

可以在開發(fā)者選項(xiàng)中打開：設(shè)置 -> 開發(fā)者選項(xiàng) -> 顯示GPU視圖更新，當(dāng)刷新范圍與動(dòng)畫范圍明顯不一致時(shí)便是動(dòng)畫布局不合理。這種情況需要具體到代碼層面分析寫法的問題并修改。

9.3、降低繪制頻率

通常在游戲或應(yīng)用動(dòng)畫中使用，可以降低 GPU 繪制頻率和后面的刷新頻率。通過降低動(dòng)畫繪制頻率，可以降低 GPU，CPU 及 DDR 功耗。

不同幀率功耗情況對(duì)比如下，可以看到低幀率下相比高幀率，功耗明顯低了很多。

在抖音應(yīng)用中，低繪制幀率可以通過在抖音內(nèi)部主動(dòng)降低動(dòng)畫等幀率實(shí)現(xiàn)。在抖音推薦界面音樂轉(zhuǎn)盤動(dòng)畫和音符動(dòng)畫中降低幀率，可以顯著的降低功耗。

此外也可以通過廠商側(cè)提供?soft vsync?實(shí)現(xiàn) 30HZ 繪制，這部分抖音與廠商合作，SurfaceFlinger 控制 APP vsync，降幀時(shí) SurfaceFlinger vsync 輸出降為 30fps，在特定條件下主動(dòng)降低幀率，以延長(zhǎng)使用時(shí)長(zhǎng)。

9.4、幀率對(duì)齊

在抖音推薦頁面中，通過視頻和降低頻率后的動(dòng)畫達(dá)到同步，可以實(shí)現(xiàn)整個(gè)界面以30HZ 繪制和刷新。

否則，如果視頻30hz和動(dòng)畫30幀正好交錯(cuò)，最終形成的繪制/刷新頻率還是60幀，沒有達(dá)到最優(yōu)。

我們通過調(diào)節(jié)各種動(dòng)畫的繪制流程，將動(dòng)畫整體繪制對(duì)齊，整體幀率明顯降低。

9.5、減少過度繪制

過度繪制（Overdraw）描述的是屏幕上的某個(gè)像素在同一幀的時(shí)間內(nèi)被繪制了多次。在多層次重疊的 UI 結(jié)構(gòu)里面，如果不可見的 UI 也在做繪制的操作，會(huì)導(dǎo)致某些像素區(qū)域被繪制了多次，同時(shí)也會(huì)浪費(fèi)大量的 CPU 以及 GPU 資源。

可以通過如下來調(diào)試過度繪制：打開手機(jī)，設(shè)置 -> 開發(fā)者選項(xiàng) -> 調(diào)試 GPU 過度繪制 -> 顯示 GPU 過度繪制。

過度繪制的存在會(huì)導(dǎo)致界面顯示時(shí)浪費(fèi)不必要的資源去渲染看不見的背景，或者對(duì)某些像素區(qū)域多次繪制，就會(huì)導(dǎo)致界面加載或者滑動(dòng)時(shí)的不流暢、掉幀，對(duì)于用戶體驗(yàn)來說就是 App 特別的卡頓。為了提升用戶體驗(yàn)，提升應(yīng)用的流暢性，優(yōu)化過度繪制的工作還是很有必要做的。

抖音的 feed 頁的過度繪制非常的嚴(yán)重，抖音存在 5 層過度繪制。下圖左側(cè)是優(yōu)化前的過渡繪制情況，右側(cè)是優(yōu)化后的過度繪制情況，可以看出優(yōu)化后明顯改善。

9.6、使用 SurfaceView 視頻播放

TextureView 和 SurfaceView 是兩個(gè)最常用的播放視頻控件。

TextureView 控件位于主圖層上，解碼器將視頻幀傳遞到 TextureView 對(duì)象還需要 GPU 做一次繪制才能在屏幕上顯示，所以其功耗更高，消耗內(nèi)存更大，CPU 占用率也更高。

控件位置差異如下，可以看出 SurfaceView 擁有獨(dú)立的 Surface 位于單獨(dú)的圖層上，而 TextureView 位于主圖層上。

BufferQueue 是 Android 圖形架構(gòu)的核心，其一側(cè)是生產(chǎn)者，另一側(cè)是消費(fèi)者。從這方面看，SurfaceView 和 TextureView 的差異如下。容易看出，SurfaceView 流程更短，內(nèi)存使用更少，也沒有 GPU 繪制，功耗更省。

?

下面是一些 SurfaceView 替換 TextureView 后的收益數(shù)據(jù)：

• 1）CPU數(shù)據(jù)上看：SurfaceView 要比 TextureView 優(yōu)化 8%-13%；

• 2）功耗數(shù)據(jù)上看：SurfaceView 要比 TextureView 平均功耗低 20mA 左右。

9.7、硬件繪制和軟件繪制

硬件繪制是指通過 GPU 繪制，Android 從 3.0 開始支持硬件加速繪制，它在 UI 顯示和繪制效率方面遠(yuǎn)高于軟件繪制，但是 GPU 功耗相對(duì)較高。目前是系統(tǒng)默認(rèn)的繪制方式。

軟件繪制是指通過 CPU 實(shí)現(xiàn)繪制，Android 上面使用 Skia 圖形庫來進(jìn)行繪制。

兩者差異參見下圖：

目前默認(rèn)是開硬件加速的，可以通過設(shè)置 Activity、Application、窗口、View 等方式來指定軟件繪制。如果應(yīng)用需要單獨(dú)指定某些場(chǎng)景的軟件繪制方式，需要對(duì)性能、功耗等做好評(píng)估。（參考鏈接：https://developer.android.com/gu ... hics/hardware-accel）

9.8、復(fù)雜算法用 NPU 代替 GPU

現(xiàn)在的較新的 SoC 平臺(tái)都帶有專門進(jìn)行 AI 運(yùn)算的 NPU 芯片，使用 NPU 代替 GPU 運(yùn)行一些復(fù)雜算法，可以有效的節(jié)省 GPU 功耗。

如視頻的超分算法，可以給用戶帶來很好的體驗(yàn)。但是超分開啟對(duì) GPU 的耗電影響很大，在某些平臺(tái)測(cè)試整機(jī)功耗可以高出 100mA，選擇用 NPU 替換 GPU 是一種優(yōu)化方式。

十、功耗優(yōu)化實(shí)踐3：CPU

10.1、概述

CPU 的優(yōu)化是功耗優(yōu)化里最常見的，我們遇到的大部分的 CPU 異常都是出現(xiàn)了死循環(huán)。

這里使用上面介紹過的功耗歸因工具，都可以很容易的發(fā)現(xiàn)死循環(huán)問題。此外高頻的耗時(shí)函數(shù)，效果和死循環(huán)類似，很容易讓 CPU 大核跑到高頻點(diǎn)，帶來 CPU 功耗增加。

另外一個(gè)典型的 CPU 問題，就是動(dòng)畫泄漏，泄漏動(dòng)畫大概能帶來 20mA 的功耗增加。

由于 CPU 工作耗電很高，手機(jī)平臺(tái)大多會(huì)增加各種低功耗的 DSP 來分擔(dān) CPU 的工作，減少耗電，如常見視頻解碼，使用硬解會(huì)有更好的功耗表現(xiàn)。

10.2、CPU 高負(fù)載優(yōu)化

10.2.1死循環(huán)治理

死循環(huán)是我們遇到的最明顯的 CPU 異常，通常表現(xiàn)為某一個(gè)線程占滿了一個(gè)大核。線程使用率達(dá)到了 100%，手機(jī)會(huì)很容易發(fā)熱，卡頓。

這里舉一個(gè)實(shí)際修復(fù)的死循環(huán)例子：在一段循環(huán)打包日志的代碼邏輯里，所有 log打包完了，才會(huì)break跳出循環(huán)。當(dāng)db query出現(xiàn)了異常，異常處理分支并沒有做break，導(dǎo)致出現(xiàn)了死循環(huán)。

// 方法邏輯有裁剪，僅貼出主要邏輯

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;

}

對(duì)于死循環(huán)治理，我們通過實(shí)際解決的問題，總結(jié)了幾種常見的死循環(huán)套路。

// 邊界條件未滿足，無法break

while(true) {

????...

????if(shouldExit()) {

????????break

????}

}

?

// 異常處理不妥當(dāng)，導(dǎo)致死循環(huán)

while(true) {

????try{

???????dosometing;

???????break;

????} catch(e) {

????}

}

?

// 消息處理不當(dāng)，導(dǎo)致Handler線程死循環(huán)

voidhandleMessage(Message msg) {

????//do something

????handler.sendEmptyMessage(MSG)

}

10.2.2高頻耗時(shí)函數(shù)治理

除了死循環(huán)問題，我們遇到的另外一種常見的就是高頻的耗時(shí)函數(shù)。

通過線上監(jiān)控 CPU 異常，我們也找到很多可優(yōu)化的點(diǎn)。如 md5 壓縮算法的耗時(shí)，正則表達(dá)式的不合理使用，使用 cmd 執(zhí)行系統(tǒng)命令的耗時(shí)等。這種就 case by case 的修復(fù)，就有很不錯(cuò)的收益。

10.3、后臺(tái)資源規(guī)范使用：Alarm、Wakelock、JobScheduler 的規(guī)范使用

最常見的后臺(tái) CPU 耗電就是對(duì)后臺(tái)資源的不合理使用。

Alarm 的頻繁喚醒，wakelock 的長(zhǎng)時(shí)間不釋放，JobScheduler 的頻繁執(zhí)行，都會(huì)使 CPU 保持喚醒狀態(tài)，造成后臺(tái)耗電。

這種行為很容易讓系統(tǒng)判斷應(yīng)用為后臺(tái)異常耗電，通常會(huì)被系統(tǒng)清理，或者發(fā)出高耗電提醒。

我們可以通過 dumpsys alarm & dumpsys power & dumpsys jobscheduler 查看相關(guān)的統(tǒng)計(jì)信息，也可以通過 BH 的后臺(tái)統(tǒng)計(jì)來分析自身的使用情況。

參考綠盟的功耗標(biāo)準(zhǔn)，滅屏 Alarm 觸發(fā)小于過 12 次/h，即 5min 一次，5min 一次在數(shù)據(jù)業(yè)務(wù)下可以保證長(zhǎng)鏈接存活，廠商的后臺(tái)功耗優(yōu)化也通常會(huì)強(qiáng)制對(duì)齊 Alarm 為 5min 觸發(fā)一次。

后臺(tái)的 Partial Wakelock 通常會(huì)被重點(diǎn)限制，非可感知的場(chǎng)景（音樂，導(dǎo)航，運(yùn)動(dòng)）等會(huì)被廠商強(qiáng)制釋放 wakelock。按照綠盟的標(biāo)準(zhǔn)，滅屏下每小時(shí)累計(jì)持鎖小于 5min，從實(shí)際經(jīng)驗(yàn)上看，持 Partial 鎖超過 1min 就會(huì)被標(biāo)為 Long 的 wakelock，如果是應(yīng)用在后臺(tái)無可感知業(yè)務(wù)并且頻繁持鎖，導(dǎo)致系統(tǒng)無法休眠的，系統(tǒng)會(huì)觸發(fā) forcestop 清理。

某些定時(shí)任務(wù)可以使用 JobScheduler 來替代 Alarm，Job 的好處是可以組合多種觸發(fā)條件，選擇一個(gè)最恰當(dāng)?shù)臅r(shí)刻讓系統(tǒng)調(diào)度自己的后臺(tái)任務(wù)。這里建議使用充電+網(wǎng)絡(luò)可用狀態(tài)下處理自己的后臺(tái)任務(wù)，對(duì)功耗體驗(yàn)是最好的。如果是非充電場(chǎng)景下，設(shè)置條件頻繁觸發(fā) job，同樣會(huì)帶來耗電問題。值得一提的是 Job 執(zhí)行完要及時(shí)結(jié)束。因?yàn)?JobScheduler 在執(zhí)行時(shí)會(huì)持有一個(gè)*job/*開頭的 wakelock，最長(zhǎng)執(zhí)行時(shí)間 10min，如果一直在執(zhí)行狀態(tài)不結(jié)束，就會(huì)導(dǎo)致系統(tǒng)無法休眠。

10.4、視頻硬解替換軟解

硬解碼：通常是用手機(jī)平臺(tái)自帶的硬件解碼器來做解碼從而實(shí)現(xiàn)視頻播放，基于專用芯片的硬解碼速度快、功耗低。

軟解碼：通常使用 FFMPEG 內(nèi)置的 H.264 和 H.265 的軟件解碼庫來做解碼。

下表是三星手機(jī)和蘋果手機(jī)分別在軟硬解情況下的功耗，可以看出硬解功耗比軟解功耗顯著降低，目前抖音默認(rèn)使用硬解。

（圖片來源：http://www.noobyard.com/article/p-eedllxrr-qz.html）

十一、功耗優(yōu)化實(shí)踐4：NETWORK

11.1、概述

網(wǎng)絡(luò)耗電是應(yīng)用耗電的一個(gè)重要部分，一個(gè)數(shù)據(jù)包的收發(fā)，會(huì)同步拉動(dòng) CPU 和 Modem/WIFI 兩大系統(tǒng)。

由于 LTE 的 CDRX 特性（即沒有數(shù)據(jù)包接收，維持一定時(shí)間的激活態(tài)，再進(jìn)入睡眠，依賴運(yùn)營(yíng)商配置，通常為 10s），所以批量進(jìn)行網(wǎng)絡(luò)訪問，減少頻繁的網(wǎng)絡(luò)喚醒對(duì)網(wǎng)絡(luò)功耗很有幫助。

此外：優(yōu)化壓縮算法，減少數(shù)據(jù)傳輸量也從基礎(chǔ)上減少了網(wǎng)絡(luò)耗電。

另外：弱信號(hào)條件下的網(wǎng)絡(luò)請(qǐng)求會(huì)提高天線的功率，也會(huì)觸發(fā)頻繁的搜網(wǎng)，帶來更高的網(wǎng)絡(luò)功耗。根據(jù)網(wǎng)絡(luò)質(zhì)量進(jìn)行網(wǎng)絡(luò)請(qǐng)求調(diào)度，提前預(yù)緩存網(wǎng)絡(luò)資源，可以減少網(wǎng)絡(luò)耗電。

11.2、長(zhǎng)鏈接心跳優(yōu)化

對(duì)于應(yīng)用的后臺(tái) PUSH 來說，使用廠商穩(wěn)定的 push 鏈路替代自己的長(zhǎng)鏈接可以減少功耗。如果不能替換，也可以優(yōu)化長(zhǎng)鏈接?；畹男奶?，根據(jù)不同的網(wǎng)絡(luò)條件動(dòng)態(tài)的調(diào)整心跳。

根據(jù)經(jīng)驗(yàn)，數(shù)據(jù)業(yè)務(wù)下通常是 5min，WIFI 網(wǎng)絡(luò)下通常可以達(dá)到 20min 或更久。

抖音對(duì)于長(zhǎng)鏈接進(jìn)行了的心跳優(yōu)化，進(jìn)入后臺(tái)的長(zhǎng)鏈接心跳時(shí)間間隔?[4min, 28min]，初始心跳 4min。采用動(dòng)態(tài)心跳試探策略，每次步進(jìn) 2min，確定最大心跳間隔。

11.3、Doze 模式適配

由于系統(tǒng)對(duì)后臺(tái)應(yīng)用有多種網(wǎng)絡(luò)限制策略，最常見的是 Doze 模式，手機(jī)滅屏一段時(shí)間后會(huì)進(jìn)入 doze，限制非白名單應(yīng)用訪問網(wǎng)絡(luò)，并在窗口期解除限制，窗口期為每 10min 放開 30s。

所以在后臺(tái)進(jìn)行網(wǎng)絡(luò)訪問前要特別注意進(jìn)行網(wǎng)絡(luò)可用的判斷，選擇窗口期進(jìn)行網(wǎng)絡(luò)訪問，避免因?yàn)楸幌蘧W(wǎng)而浪費(fèi)了 CPU 資源。

這里舉一個(gè) Doze 未適配的后臺(tái)耗電例：用戶反饋抖音自上次手機(jī)充滿電（24h）后，沒有在前臺(tái)使用過，耗電占比 31%，分析日志發(fā)現(xiàn)：在 Doze 限制網(wǎng)絡(luò)期間，會(huì)觸發(fā)輪詢判斷網(wǎng)絡(luò)是否及時(shí)恢復(fù)，此邏輯在后臺(tái)未適配 Doze 的窗口期模式，導(dǎo)致了后臺(tái)頻繁嘗試網(wǎng)絡(luò)請(qǐng)求帶來的 CPU 耗電。

十二、功耗優(yōu)化實(shí)踐5：AUDIO

12.1、降低音量

音頻的耗電最終體現(xiàn)在 Codec 和 SmartPA（連接喇叭的功率放大器）兩部分。減少 Audio 耗電最明顯的就是減少音頻的音量，這直接反應(yīng)到喇叭的響度上。

用?0-15?級(jí)的音量進(jìn)行測(cè)試，可以看到音量對(duì)功耗的影響巨大，尤其是超過 10 之后，整體增幅非常巨大。每一級(jí)幾乎與功耗成百分比上漲。

具體是：

• 1）10-15 ：1：30ma；

• 2）5-10：1：1.62ma；

• 3）0-5：1：1.36ma。

12.2、調(diào)整音頻參數(shù)

由于用戶對(duì)音量的感受很明顯，直接全局降低音量會(huì)帶來不好的體驗(yàn)。廠商通常會(huì)針對(duì)不同的場(chǎng)景，設(shè)計(jì)不同的音頻參數(shù)，如電影場(chǎng)景，游戲場(chǎng)景，導(dǎo)航場(chǎng)景，動(dòng)態(tài)調(diào)節(jié)音頻的高低頻配置參數(shù)，兼顧了效果和功耗。

從這個(gè)角度出發(fā)，可以選擇和廠商合作，根據(jù)播放視頻的內(nèi)容，精細(xì)化調(diào)整音頻參數(shù)，如電影剪輯類型視頻就使用電影場(chǎng)景的參數(shù)，游戲視頻就切換為游戲場(chǎng)景的配置參數(shù)，從而達(dá)到用戶無感調(diào)節(jié)音量節(jié)省功耗的目的。

十三、功耗優(yōu)化實(shí)踐6：CAMERA

Camera 是功耗大戶，尤其是高分辨率高幀率的錄制會(huì)帶來快速的功耗消耗和溫升。

經(jīng)過線下測(cè)算，開播場(chǎng)景，Camera 功耗 200mA+，占整機(jī)的 25%以上。

優(yōu)化Camera功耗的思路主要是從業(yè)務(wù)降級(jí)的角度上進(jìn)行，如降低錄制的分辨率，降低錄制幀率等。之前抖音直播和生產(chǎn)端都是使用30幀，但最終只使用15幀，在開播端主動(dòng)下調(diào)采集幀率，按需設(shè)置幀率為15幀，功耗顯著降低了120ma。

十四、功耗優(yōu)化實(shí)踐7：SENSOR

sensor 的典型功耗值很低，如我們常用到的 accelerometer（加速度計(jì)）的典型功耗只有 180uA。

但 sensor 的開啟會(huì)導(dǎo)致 cpu 的喚醒與負(fù)載增加，尤其是在應(yīng)用退到后臺(tái)，sensor 的濫用會(huì)顯著增加待機(jī)功耗。

可以在低電量時(shí)關(guān)閉不必要的 sensor，減少耗電。

十五、功耗優(yōu)化實(shí)踐8：GPS

精確度、頻率、間隔是影響 GPS 耗電的三個(gè)主要因素。其中精度影響定位的工作模式，頻率和間隔是影響工作時(shí)長(zhǎng)，我們可以通過優(yōu)化這三者來減少 GPS 的耗電。

15.1、降低精度

Android 原生定位提供 GPS 定位和網(wǎng)絡(luò)定位兩種模式。

GPS 定位支持離線定位，依靠衛(wèi)星，沒有網(wǎng)絡(luò)也能定位，精度高，但功耗大，因需要開啟移動(dòng)設(shè)備中的 GPS 定位模塊，會(huì)消耗較多電量。

Network 定位（網(wǎng)絡(luò)定位），定位速度快，只要具備網(wǎng)絡(luò)或者基站要求，在任何地方都可實(shí)現(xiàn)瞬間定位，室內(nèi)同樣滿足；功耗小，耗電量小。但定位精度差，容易受干擾，在基站或者 WiFi 數(shù)量少、信號(hào)弱的地方定位質(zhì)量較差，或者無法定位；必須連接網(wǎng)絡(luò)才能實(shí)現(xiàn)定位。

我們可以在滿足定位要求的情況下，主動(dòng)使用低精度的網(wǎng)絡(luò)定位，減少定位耗電，抖音在進(jìn)入低功耗模式時(shí)，進(jìn)行了 GPS 降級(jí)為網(wǎng)絡(luò)定位，并且擴(kuò)大了定位間隔。

15.2、降低頻率 & 提高間隔

這里除了業(yè)務(wù)上主動(dòng)控制頻率與間隔外，還推薦使用廠商的定位服務(wù)。

為了優(yōu)化定位耗電，海外 gms 以及國(guó)內(nèi)廠商都提供了位置服務(wù) SDK，本質(zhì)上是通過系統(tǒng)服務(wù)統(tǒng)一管理位置請(qǐng)求，根據(jù)電量，信號(hào)，請(qǐng)求方的延遲精度要求，進(jìn)行動(dòng)態(tài)調(diào)整，達(dá)到功耗與定位需求的平衡。提供了諸如被動(dòng)位置更新，獲取最近一次定位的位置信息，批量后臺(tái)位置請(qǐng)求等低功耗定位能力。

比如：

• 1）https://developer.android.com/guide/topics/location/battery；

• 2）https://developer.huawei.com/consumer/cn/doc/development/HMSCore-References/location-description-0000001088559417。

十六、功耗優(yōu)化實(shí)踐9：低功耗模式

上述的優(yōu)化措施，有些在常規(guī)模式下已經(jīng)實(shí)施。但有一部分是有損用戶體驗(yàn)的，我們選擇在低電量場(chǎng)景下去做，降低功耗，減少用戶的電量焦慮，獲得用戶在低電量下更多使用時(shí)長(zhǎng)。

在低功耗模式預(yù)研中，我們列舉了很多可做的措施，通過 AB 實(shí)驗(yàn)，我們?nèi)サ袅藰I(yè)務(wù)負(fù)向的降級(jí)手段，比如亮度降低，音量降低等。

此外在功能觸發(fā)的策略上，我們通過對(duì)比了低電量彈窗提醒，設(shè)置里增加開關(guān)+Toast 提醒，以及低電量自動(dòng)進(jìn)入，最終選擇了對(duì)用戶體驗(yàn)最好的 30%電量無打擾自動(dòng)進(jìn)入的觸發(fā)方式。

經(jīng)過實(shí)驗(yàn)發(fā)現(xiàn)：一些高發(fā)熱機(jī)型，通過低功耗模式全程開啟，也可以拿到業(yè)務(wù)收益。說明部分有損的降級(jí)，用戶在易發(fā)熱的情況下也是接受的，可以置換出業(yè)務(wù)收益，目前低功耗模式線下測(cè)試功耗收益穩(wěn)定在 20mA 以上。

十七、本文小結(jié)

功耗優(yōu)化是一個(gè)復(fù)雜的綜合課題，既包含了利用工具對(duì)功耗做拆解評(píng)估，對(duì)異常的監(jiān)控治理，也包含了主動(dòng)挖掘優(yōu)化點(diǎn)進(jìn)行優(yōu)化。

上面列舉的優(yōu)化思路，我們也只是做了部分，還有部分待開展，包括功耗歸因的工具建設(shè)上，我們也還有很多可以優(yōu)化的點(diǎn)。

我們會(huì)持續(xù)發(fā)力，產(chǎn)出更多的方案，在滿足使用需求的前提下，消耗更少的物理資源，給抖音用戶帶來更好的功耗體驗(yàn)。

十八、相關(guān)資料

[1]?微信團(tuán)隊(duì)分享：詳解iOS版微信視頻號(hào)直播中因幀率異常導(dǎo)致的功耗問題

[2]?移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析

[3]?移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制

[4]?微信那么牛，為什么海外成功的卻是抖音？

[5]?解密抖音春節(jié)紅包背后的技術(shù)設(shè)計(jì)與實(shí)踐

[6]?移動(dòng)端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測(cè)方案

[7]?微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化

（本文已同步發(fā)布于：http://www.52im.net/thread-4540-1-1.html）