讀者可能會有這種體會和感受，昨晚的睡眠時間和平時相當，但是為何早上起來特別困，如下來自健康手環的睡眠監測數據或許可以給你答案。
可知整個夜間睡眠時間段，睡眠質量通過深睡、淺睡、清醒三種等級來表征，你記憶中的夜間睡眠，實際情況可能是翻來覆去整個人都處於清醒的狀態，這種情況越多，睡眠質量也就越差。該監測數據，可為作息規划與改善提供數據支撐。
對於手機而言，滅屏狀態下的表現其實與人的睡眠大體類似，當系統處於深度睡眠模式時，功耗會低很多；相反，當系統處於喚醒狀態時，功耗會大很多，此時手機自然也就耗電快。本文，我們來介紹下手機滅屏耗電這回事。
當按下電源鍵時，系統就會觸發熄屏與休眠流程，概述如下：
在該流程中，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級別達到某個級別以上（C1、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（工作態、空閑態、休眠態）以及特殊業務子系統進行硬件功耗優化、軟件算法優化、耗電策略改善等，提升用戶滅屏耗電體驗。