個人手機滅屏了，爲何還在耗電

讀者可能會有這種體會和感覺，昨晚的睡眠時間和平時至關，可是爲什麼早上起來特別困，以下來自健康手環的睡眠監測數據或許能夠給你答案。

可知整個夜間睡眠時間段，睡眠質量經過深睡、淺睡、清醒三種等級來表徵，你記憶中的夜間睡眠，實際狀況多是翻來覆去整我的都處於清醒的狀態，這種狀況越多，睡眠質量也就越差。該監測數據，可爲做息規劃與改善提供數據支撐。

對於手機而言，滅屏狀態下的表現其實與人的睡眠大致相似，當系統處於深度睡眠模式時，功耗會低不少；相反，當系統處於喚醒狀態時，功耗會大不少，此時手機天然也就耗電快。本文，咱們來介紹下手機滅屏耗電這回事。

當按下電源鍵時，系統就會觸發熄屏與休眠流程，概述以下：

在該流程中，PhoneWindowManager負責對電源鍵做出響應，而後經過goToSleepFromPowerButton->goToSleep調用向PowerManger傳遞休眠動做，做爲PowerManger中goToSleep的實現者PowerManagerService，則透過setHalAutoSuspendModeLocked -> mNativeWrapper.nativeSetAutoSuspend間接調用native suspend_control（android.system.suspend@1.0-service） 中的enableAutoSuspend關鍵函數。而suspend_control（android.system.suspend@1.0-service）則經過kernel pm core提供的各種sysfs節點對系統休眠條件與流程進行檢查和控制。在linux kernel pm core中，main這一部分與suspend相關的模塊有autosleep、wakeup count、task freeze、wakelock等，主要負責提供相應的用戶態接口以及處理與硬件無關的核心邏輯。以後pm driver則負責處理硬件相關的休眠工做，分device driver抽象層的邏輯控制，以及具體的平臺休眠實現與設備休眠實現。

再次轉到滅屏耗電這個維度，經過如上的信息，可知影響耗電的幾個主要關鍵維度：是否有觸發休眠動做、觸發休眠後是否執行成功、是否頻繁退出休眠狀態、平臺級的休眠狀態、外圍設備的耗電狀態等。

Android框架batterystats模塊對系統的耗電錶現有相對完整的理解和闡述，其對硬件耗電錶現（eg：cpu、wifi、gps、bluetooth）以及軟件行爲（eg：休眠、持鎖、凍結、喚醒、Job）都有豐富的數據統計。以應用軟件在cpu上的耗電錶現爲例，其統計該應用在每一個cluster上的cpu執行時間，結合cpu每一個頻點的功耗數據，加權累計後便可算出該應用的cpu耗電狀況，關鍵代碼段以及配置文件摘錄以下：

爲了便於開發人員調試分析，Batterystats的數據能夠經過dumpsys batterystats命令輸出，且谷歌開發了battery-historian工具以圖形界面的方式展現batterystats統計的關鍵信息。源代碼以及搭建方法在https://github.com/google/battery-historian官方網站中有闡述，效果示例以下：

對於手機滅屏下的表現，咱們能夠從圖中獲得不少耗電相關的信息，關鍵信息摘錄以下：

• CPU running：用於表徵系統是否有進入休眠狀態，並記錄喚醒源信息。休眠時間佔比越短，耗電會越差。

• Userspace wakelock：用於表徵當前是否存在用戶空間申請的wakelock，而且這裏會展現系統被喚醒後首次申請的wakelock。值得注意的是，用戶空間申請的wakelock的總時長和首次申請的wakelock並不存在必然的聯繫，若是要進一步確認總時長分別是哪些wakelock引發的，能夠執行dumpsys batterystats --enable full-history命令後獲得全部wakelock的過程記錄功能，從而找到答案。

• Long wakelocks：表徵是否存在長時間持有的wakelock。當持有時間超過1分鐘時，則會被標記，此類的狀況的出現會對滅屏功耗形成較大影響。

• Kernel only uptime：當全部用戶態的wakelock都釋放後，若是kernel未休眠，那麼這部分的時間會被記錄到這個字段。

• Screen：表徵當前的亮滅屏狀態。

• Doze：表徵android doze省電模式的狀態。值可爲off foze、light doze、full doze這幾種，當用戶一段時間內沒有使用手機且知足進入Doze的條件時，會限制應用的後臺活動，以達到減小功耗的目的。具體限制的動做好比暫停網絡訪問、忽略應用持有的WakeLock、再也不進行wifi掃描、不容許sync adapters和JobScheduler運行等。不過爲了保證基礎功能與用戶體驗，系統進程、核心應用、前臺服務進程並不會受到限制。

• 其它：gps狀態、通話狀態、聯網狀態與類型、wifi狀態等，都與滅屏表現息息相關，篇幅有限，不詳細闡述。

上文batterystats模塊中」cpu running「指標闡述的是休眠與否這個狀態。然而，linux系統可分爲三種狀態：工做態、空閒態、休眠態。系統工做態與空閒態這兩種狀態下的運行表現，對滅屏功耗一樣起着相當重要的影響。

如上圖所示，滅屏下系統處於喚醒狀態時（持有wakelock未休眠或者睡眠後被喚醒），若是cpu沒有被關閉，那麼處理deadline、real time、fair調度類上的任務時認爲cpu處於工做態。爲了改善滅屏工做態的功耗，每每經過減小任務量、下降硬件功耗兩方面來制定策略，好比凍結與清理非核心的任務、job策略優化、下降cpu的工做頻率、關閉能效差的cpu等。此時batterystats模塊又充分展現出」對耗電工做的主動與積極性「，對滅屏下的各個應用的cpu使用狀況作了詳細的統計，這對滅屏耗電分析與調試、優化效果呈現等方面起到必定的輔助做用，結果示例以下：

當deadline、realtime、fair調度類上無任務須要處理時，kernel則會執行idle調度類上的任務，該任務的職責是走cpu idle流程以節省功耗。另外，能夠選擇不一樣的idle governor好比menu governor、ladder governor、平臺定製的governor等以知足不一樣的應用場景。爲了快速便捷的瞭解各cpu的idle執行狀況，可經過idlestat開源工具（源碼參考網址https://github.com/scheduler-tools/idlestat）來分析、統計各個cpu在每一個idle c-state下的停留時間、進入次數等信息，也可經過busybox powertop工具（源碼參考網址https://busybox.net/）來分析cpu的irq、timer表現以找出top類的idle喚醒源。

另外，當cpu的idle級別達到某個級別以上（C一、C2 ….），或者處於idle的cpu數量達到某個條件，亦或者其它特殊的條件（不一樣平臺表現不一）獲得知足時，SOC每每會進入深度定製的省電模式以將idle狀態下的耗電下降到極致。其中，這裏說起的特殊條件的知足，依賴的條件每每比較多，各個設備模塊每每充分利用內核提供的runtime pm框架，在合適的時機儘量的釋放相應的資源以提供必要條件。runtime pm狀態描述以下：

關鍵函數示例以下：

以i2c控制器爲例，在不須要傳輸數據的時候及時釋放clock，代碼示例以下：

如上所述，滅屏狀況下的kernel休眠態、工做態、空閒態表現對滅屏功耗均起到關鍵的影響，所以，策略設計不合理、運行邏輯出現異常，都會形成滅屏耗電不理想。

回到前面提到的幾個維度，kernel是否有觸發休眠動做、是否頻繁退出休眠狀態、觸發休眠後是否執行成功等關鍵信息能夠在batterystats模塊統計的信息中找到線索。然而，平臺級別的休眠狀態、外圍器件的休眠狀態，因爲終端設備之間的差別性比較大，batterystas的覆蓋還不夠。

對於整機硬件系統，除了cpu以外，modem子系統、sensor子系統、audio子系統、wireless子系統每每也不可或缺，這些子系統對滅屏耗電影響也很大。

• Modem子系統：負責處理與基站相關的通訊業務，承擔着電話、短信、上網等業務。形成該子系統休眠差的緣由有多種，好比業務聯網頻繁、小區切換頻繁、無服務搜網、RRC鏈接不釋放、弱信號重傳多等。

• Sensor子系統：負責傳感器業務需求、基礎功能的支撐（好比擡手檢測、計步檢測、開合檢測等），出於耗電的考慮，愈來愈多的傳感器算法會轉移到sensor子系統來實現。應用調用sensor是否合理、sensor的採樣頻率、省電模式的配置、算法實現的複雜度，是影響sensor子系統休眠與耗電錶現的重要因素。

• Audio子系統：處理音頻相關業務，好比音頻播放、錄音、特效算法等。三方應用的不合理使用（例如後臺持續播放、錄音行爲）每每是形成audio子系統異常耗電的主要緣由。

• Wireless子系統：該子系統每每集成了wifi、bt、gps、fm等無線功能模塊，相應模塊的做業狀態直接影響該子系統的耗電錶現。

隨着業務需求的發展，手機終端的集成度愈來愈高，功能也愈來愈複雜，不管是硬件、底層設備驅動仍是應用軟件，在設計與實現時都須要充分考慮耗電影響，以本文說起的滅屏爲例，圍繞AP（工做態、空閒態、休眠態）以及特殊業務子系統進行硬件功耗優化、軟件算法優化、耗電策略改善等，提高用戶滅屏耗電體驗。