內容來源：2018 年 1 月 20 日，華為手機功耗架構師錢華君在“走進網易：移動測試與安全實踐”進行《低功耗設計和開發方法探討》演講分享。IT 大咖說（微信id：itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：2756 | 7分鐘閱讀
摘要
本次演講將介紹常見的高耗電設計場景，功耗異常的場景舉例，並結合Android機制，介紹為何導致耗電，以及推薦的設計方法；接下來講解編譯技術在低功耗開發中的應用，如何基於LLVM編譯器來開發構建一個靜態程式碼分析工具，檢測常見的錯誤編碼方式，深入淺出介紹如何通過編譯器來檢測持鎖未釋放的場景；最後是機器學習在低功耗設計中的應用展望，通過機器學習瞭解使用者的行為，在應用開發中既滿足使用者體驗，又節省功耗。
高耗電設計場景舉例
Push
Push即notification訊息的一個互動，是一種訊息推送機制，iOS有唯一的Push通道，所有應用的服務端要與應用互動的訊息都必須通過這個Push通道，避免了通知訊息喚醒應用。Android則存在多個Push通道，谷歌有GCM；每個廠商也有自己的通道，比如華為Push；除此之外應用有自己的獨立通道，如微信。這種情況下就導致應用被頻繁喚醒，整個系統其實是沒有休眠的，沒辦法像iOS的通道這樣控制行為。
Wakelock長時間持鎖
上圖是Android的休眠機制，剛開始的時候系統被頻繁的喚醒，在息屏後一段時間會進入淺睡眠，這時網路訪問就沒有了、Syncs以及Jobs Deferred都不推薦使用，但是定期還是會有一個維護視窗，這段時間應用程式是可以被喚醒的。再持續一段時間後就進入了深度睡眠模式，這時不僅沒有網路連線，GPS等也被禁止，這其實是理想的睡眠狀態，實際是比較難進入這種狀態的。
為了不讓系統的休眠導致應用程式結束，一般需要設定Wakelock。Wakelock有兩種使用形式，一種是採用PowerMananger申請Wakelock鎖，這段時間內系統不會進入休眠狀態；另一種是直接使用底層的wake_lock或wake_unlock介面來避免系統進入休眠狀態。
Wakelock持鎖如果忘記釋放，會導致系統一直被頻繁喚醒無法進入淺睡眠而一直處於異常耗電狀態。程式獲持鎖之後異常退出會導致wake_lock一直被開啟，這時也系統也是處於異常耗電狀態。
編譯技術在低功耗開發中的應用
編譯技術的應用
理論上的所有把一種程式語言轉換為另一種語言或格式的都叫編譯。第一種常見的編譯是把程式語言直接編譯為機器碼，典型的如C/C++的編譯器；第二種是把程式語言編譯為位元組碼，由虛擬機器執行；第三種是領域特定語言（DSL）的編譯器。
在產品中應用編譯技術的幾種可行方面
- 研究編譯器選項，或者通過迭代編譯獲得最佳選項，從而在產品中獲得效能提升。
- 增加編譯器擴充套件（pragma，_attribute_），進行額外的編譯檢查和輔助程式碼生成。
- 基於編譯器前端生成的抽象語法樹（AST）進行程式碼靜態分析，以及基於AST重寫進行自動化的程式碼重構。
- 基於編譯器後端輸入的中間表示式（IR）進行跨函式/跨TU的分析。
- 基於編譯指令修改的執行時錯誤發現。
CLAN & LLVM
應用編譯技術不需要所有從頭自己寫，可以合理選擇已有的編譯器基礎軟體。
LLVM不是虛擬機器，而是一套編譯優化（全時優化）的基礎庫，Clang是一個前端，支援C（包括C99/C11、大部分GCC擴充套件）、C++（已經完全支援到C++14）、Object-C、OpenCL。Clang和LLVM的紐帶在於LLVMIR（Intermediate Representation）,這也是LLVM的核心。
相對GCC來說Clange&LLVM學習曲線更平緩，並且它們使用的是BSD License，相比GPL更加優化；高度的模組化，比GCC更容易擴充套件和二次開發；另外它們有設計良好的介面和模式，便於訪問內部資料，如：訪問抽象語法樹（AST）節點、獲取控制流圖節點（CFG Node）、進行上下文符號獲取等等；Clang對C++標準的支援更完整、更快；它們還有良好的GCC相容性，包括GCC內建擴充套件語法、內建關鍵字的支援；無論是編譯速度、記憶體開銷、部分平臺上程式碼執行效率Clang和LLVM都超過了GCC。
程式碼的靜態分析
程式碼的靜態分析中被分析程式不需要執行起來，不依賴執行環境，通過對程式的原始碼或者某種形式的中間程式碼進行分析來發現程式碼中的缺陷，在大型軟體分析中，是非常有價值的。
靜態分析同樣也面臨著諸多挑戰，首先程式碼中的各種分支路徑均需要分析；而且要根據上下文分析，比如變數的取值範圍和條件；另外各種分支組合會帶來演算法複雜度的指數級增長，尤其是跨函式分析；最後靜態分析需要儘可能的清除誤報。
符號執行
Symbolic Execution
- 根據AST構造控制流程圖CFG
- 從CFG的根節點開始，沿著圖的各條邊進行語句的虛擬執行，對所有可能的Path都需要進行遍歷，使用符號來表示結果，而不是向執行時記錄實際的值。
- 在遍歷每條路徑是，在每個點上收集所有在這個點上可見的符號值。
- 對於“資源洩露”這類問題，就轉化為圖的可達性判斷問題。
在路徑的遍歷分析中用記錄變數的Symbolic Value
- FITE* f在所有路徑都可見
- 路徑的所有節點（語句）上均記錄f的Symbolic Value
- 達到Sink節點時，根據f的Symbolic Value來判斷是否殘留控制程式碼未關閉
Analysis Checker
- 在CFG遍歷過程中，每個stmt訪問時觸發，是一種典型的控制反轉（Ioc）模式。
- 開發者可以在不同的觸發點上註冊自己的檢查。
- Checker會參與並影響到Exloded Graph的建立。
- 為了減少路徑爆炸，Checker可以通過建立Sink Node來做路徑支剪。
機器學習在低功耗中的應用展望
機器學習應用場景
一般開發中的耗電量統計是基於程式的角度，不能進一步檢視到程式下每個函式的耗電量，通過機器學習就能基於線性迴歸統計函式級別的功耗。
Android即將到來的p版本中機器學習將應用於場景分析，比如智慧亮度控制，auto-awesome Battery。而iOS 11整合了機器學習框架Core ML，當前用於視覺和自然語言處理。