Android喚醒鎖檢測及功耗優(yōu)化機制①

來慶波， 陳 博， 茆 蕾， 汪福翔， 司俊超

(中國科學技術(shù)大學 軟件學院(蘇州市中國科學技術(shù)大學蘇州研究院)， 蘇州 215123)

社交網(wǎng)絡的快速發(fā)展， 使得智能手機已深度融入生活. 另一方面， 頻繁的交互操作使得手機功耗問題凸顯. 為延長待機時間， 許多智能手機系統(tǒng)使用睡眠策略來節(jié)省電量， 但有些應用需要手機在某些關(guān)鍵計算時保持運行狀態(tài). 例如銀行應用程序， 當用戶在線轉(zhuǎn)賬時，交易可能需要一段時間才能完成. 若手機在等待服務器消息時被置于休眠， 造成沒能及時響應， 則轉(zhuǎn)賬將會失敗. 為解決此問題， Android系統(tǒng)設計了喚醒鎖， 使某些硬件在計算時保持運行狀態(tài) .

然而， 在現(xiàn)實中， 很多開發(fā)者存在濫用喚醒鎖的問題， 在不必要的時候仍占用喚醒鎖， 這加重電能消耗，嚴重影響用戶體驗.

為解決喚醒鎖誤用帶來的電耗增加問題， 本論文研究了常見的喚醒鎖誤用類型， 在此基礎上， 總結(jié)出了兩種判定誤用的策略: 第一種是根據(jù)CPU占用率模式，第二種是根據(jù)源碼分析建立黑名單. 并利用PowerManager提供的服務接口來檢測與釋放喚醒鎖.

1 背景知識介紹

1.1 Linux休眠機制簡介

Linux存在兩種電源管理方案: 高級電源管理(APM)和高級配置電源界面(ACPI). 缺省情況下運行ACPI. ACPI在節(jié)電方面有很多機制， 可以讓你把機器處于Suspend(懸掛)或Standby(備用)狀態(tài). 還可以讓你把外設(如: 顯示器、顯卡、PCI總線)單獨斷電.

Linux的休眠機制可概括為以下三個步驟:

(1)凍結(jié)用戶態(tài)進程和內(nèi)核態(tài)任務；

(2)調(diào)用注冊的設備的Suspend的回調(diào)函數(shù)， 其調(diào)用順序是按照驅(qū)動加載時的注冊順序；

(3)休眠核心設備和使CPU進入休眠態(tài). 凍結(jié)進程是內(nèi)核把進程列表中所有的進程的狀態(tài)都設置為停止， 并且保存下所有進程的上下文.

1.2 Android休眠機制簡介

標準的Linux電源管理機制是給帶有外接電源的電腦設計的， 睡眠機制有一些缺陷(如， 所有模塊必須同時睡眠或喚醒)， 這會導致不必要的能耗. 這些機制并不適用于電池容量有限的移動平臺， 因此Android在Linux休眠機制的基礎上衍生出了獨特的WakeLock機制來管理和節(jié)省電源.

其基本原理如下: 當啟動一個應用程序的時候， 它可以申請一個wake_lock， 每當申請成功之后都會在內(nèi)核中注冊一下(通知系統(tǒng)內(nèi)核， 現(xiàn)在已經(jīng)有鎖被申請)，當應用程序在某種情況下釋放wake_lock的時候， 會注銷之前所申請的wake_lock. 特別要注意的是: 只要系統(tǒng)中有一個wake_lock， 系統(tǒng)此時都不能進行睡眠.只有當系統(tǒng)中所有的wake_lock都被釋放之后， 系統(tǒng)才會進入真正的睡眠狀態(tài).

圖1描述了Android喚醒鎖調(diào)用的內(nèi)部設計. 內(nèi)核喚醒鎖是只能通過Linux內(nèi)核內(nèi)部獲取或釋放.Android開發(fā)人員無法直接控制內(nèi)核喚醒鎖， 但應用程序可能會間接觸發(fā)這些喚醒鎖. 當通過PowerManager的API創(chuàng)建和獲取喚醒鎖時， 該請求將通過綁定IPC機制傳遞到名為PowerManagerService的系統(tǒng)服務. 如果該請求是PARTIAL_WAKE_LOCK實例， Power-ManagerService將調(diào)用Android_os_power.cpp的方法，通過JNI讀取/寫入Linux內(nèi)核系統(tǒng)處理請求. 否則，PowerManagerService本身將以不同于部分喚醒鎖定的方式處理請求. PowerManagerService記錄PARTIAL_WAKE_LOCK的數(shù)目. 當應用程序獲取PARTIAL_WAKE_LOC實例時， PowerManagerService會將計數(shù)增加1， 并在釋放喚醒鎖時減少1. 最后， 如果PARTIAL_WAKE_LOCK的計數(shù)為零， PowerManagerService將通知Linux電源管理系統(tǒng)， 設備已經(jīng)可以進入休眠模式.

圖1 Android喚醒鎖調(diào)用的內(nèi)部設計圖

2 相關(guān)工作

近年來很多人開展了有關(guān)喚醒鎖的研究. 對于誤用喚醒鎖檢測方面， Pathak等人進行了第一次的相關(guān)研究， 并采用數(shù)據(jù)流分析技術(shù)檢測喚醒鎖泄漏[1]. 后來相繼出現(xiàn)了其他靜態(tài)和動態(tài)分析技術(shù)， 為喚醒鎖誤用的檢測提供了眾多方法. 例如: Vekris等人提出了一種驗證Android應用程序中是否存在喚醒鎖泄漏的靜態(tài)分析技術(shù)[2]； 以及在一篇介紹 WLCleaner的論文中， 設計了一種動態(tài)分析技術(shù)， 檢測由應用程序引起的喚醒鎖誤用， 并采取措施糾正這些誤用[3]. 這些研究集中于研究喚醒鎖引起的能耗問題. 在資源管理和泄漏檢測方面， Jindal等人通過研究識別了Android設備驅(qū)動程序中的四種睡眠沖突類型， 并提出了一種避免這種沖突的運行時調(diào)試系統(tǒng)[4]. Relda采用資源安全策略檢查的思想來檢測Android應用程序中的資源泄漏， 包括喚醒鎖資源的泄漏[5].

據(jù)Android官方稱Android 8.0 (API26)為了改善電池壽命， 引入了一種新的機制[6]. 當某個應用程序進入緩存狀態(tài)、沒有活動的組件時， 系統(tǒng)會自動釋放此應用程序持有的所有喚醒鎖. 但是根據(jù)Google發(fā)布的數(shù)據(jù)， Android 8.0目前的市場占有率僅有5%左右； 且目前很多在用的手機， 制造商不會提供Android 8.0的系統(tǒng). 所以研究Android 8.0之前版本的功耗優(yōu)化目前仍具有現(xiàn)實意義.

3 喚醒鎖誤用原因分析

喚醒鎖誤用是指程序本來應該釋放喚醒鎖而因為各種原因未能正確釋放喚醒鎖. 導致這一問題的原因非常復雜， 下面分析幾種常見的情景.

3.1 某些運行路徑上未能釋放喚醒鎖

由于Android程序?qū)儆谑录?qū)動型的， 不同的用戶交互行為或不同的硬件環(huán)境會導致不同的運行路徑，在代碼動態(tài)運行過程中， 會出現(xiàn)開發(fā)者未能預料到的運行路徑. 即使經(jīng)驗豐富的開發(fā)者也難以避免這一情況. 原因在于: 觸發(fā)這一情況的條件比較苛刻. 只有在特定的使用場景下才會發(fā)生. 如， 特定的用戶交互行為或特定的使用環(huán)境(如GPS信號弱)， 而這些情況是很少出現(xiàn)的.

如下面的代碼段:

上面的示例代碼是一段典型的可能存在喚醒鎖泄漏的情況， 關(guān)鍵任務run_cal()被喚醒鎖保護， 以保證CPU在執(zhí)行此任務時不會進入休眠狀態(tài). 按照開發(fā)者的設想， 執(zhí)行完run_cal()任務后， 喚醒鎖就被會被釋放掉. 但是如果在run_cal()執(zhí)行過程中， 發(fā)生了異常錯誤， 比如數(shù)學運算時產(chǎn)生了除零錯誤、傳送文件時網(wǎng)絡斷開、打開的文件不存在、GPS信號弱等， 這時拋出的異常被catch語句塊捕獲并產(chǎn)生相應的處理. 導致wkl.release語句不能被執(zhí)行， 從而使CPU不能進入休眠狀態(tài). 一個解決方法是: 在finally語句塊中加入wkl.release()語句. 這樣， 即使run_cal()任務在執(zhí)行過程中發(fā)生了異常， 喚醒鎖也會被正確釋放.

在 youku 3.0[7]中， 開發(fā)者僅在 DownloadListenerImpl類的onFinished()回調(diào)函數(shù)中釋放了喚醒鎖，這樣當在下載過程中出錯或取消下載時， 就會發(fā)生喚醒鎖泄漏. 正確的做法是在onCancel()和onException()兩個回調(diào)函數(shù)中增加釋放喚醒鎖的語句.

在mytracks[8]中， 程序在后臺中執(zhí)行記錄蹤跡任務時， 需要獲取喚醒鎖. 當任務完成正常返回時， 調(diào)用onPostExecute()函數(shù)釋放喚醒鎖. 當如果在任務執(zhí)行時， 發(fā)生了用戶取消任務或程序異常， 就會發(fā)生喚醒鎖泄漏. 正確的做法是在onCance()回調(diào)函數(shù)和finally語句塊中增加釋放喚醒鎖的語句.

3.2 僅在用戶回調(diào)函數(shù)中釋放喚醒鎖

Android程序的入口不是單一的main函數(shù)， 而是若干個回調(diào)函數(shù). 這些回調(diào)函數(shù)可分為系統(tǒng)回調(diào)函數(shù)和用戶回調(diào)函數(shù). 系統(tǒng)回調(diào)函數(shù)包含組件的生命周期函數(shù) (如: onCreate()， onStart()， onResume()， onPause()，onStop()， onDestroy())和一些安卓框架函數(shù)(如Thread類里的run()). 用戶回調(diào)函數(shù)通常是UI事件觸發(fā)的， 如鼠標點擊事件onClick()、觸摸事件onTouch()、鍵盤事件onKey()、狀態(tài)變換事件onFocusChange()等.

如果開發(fā)者僅僅在用戶回調(diào)函數(shù)中設置了釋放喚醒鎖的語句， 而未在系統(tǒng)回調(diào)函數(shù)中設置釋放語句. 釋放喚醒鎖的語句很可能因為用戶沒有執(zhí)行預設動作而未能觸發(fā). 這一情況在經(jīng)驗不足的開發(fā)者中經(jīng)常出現(xiàn).如， 在BaiduMap 5.0中開發(fā)者僅在用戶回調(diào)函數(shù)中設置了釋放LocationManager和AudioManager的語句.

在相應的系統(tǒng)回調(diào)函數(shù)(如onPause()， onStop())中增加釋放喚醒鎖的語句， 可有效解決此類問題.

3.3 在不合適的生命周期函數(shù)上釋放喚醒鎖

安卓的四大組件都有相應的一組函數(shù)來處理生命周期事件. 圖2描述了Activity組件的生命周期[9].

圖2 Activity生命周期示意圖

Activity生命周期有三個嵌套循環(huán)， 分別對應完整生命期、可見生命期、前臺生命期.

生命周期函數(shù)都有固定的調(diào)用順序. 如在Activity組件被創(chuàng)建時， onCreate()、onStart()、onResume()會相繼被調(diào)用. 如果開發(fā)者對上述生命周期的調(diào)用順序理解不足， 可能會造成以下誤用: 喚醒鎖的釋放早于喚醒鎖的獲取， 這將會釋放不存在的喚醒鎖， 導致系統(tǒng)崩潰. 如ConnetBot[10]就存在此類誤用.

另外， 安卓系統(tǒng)在前臺退出一個進程時， 為方便下次啟動更快速， Android后臺并沒有完全退出， 在內(nèi)存足夠的情況下系統(tǒng)還會把它留在內(nèi)存里. 只有當手機內(nèi)存不足以啟動一個新進程時， Android才會把不用的進程徹底停掉. 也就是說， 在前臺退出進程時onDestroy()并沒有被調(diào)用. 如果開發(fā)者對上述知識理解不足， 可能會僅在onDestroy()中釋放喚醒鎖而沒有在onPasuse()中釋放喚醒鎖. 這會導致系統(tǒng)長時間不能進入休眠狀態(tài)， 從而引起電耗增加.

3.4 喚醒鎖的類型設定不合理

Android系統(tǒng)提供了四種喚醒鎖. PARTIAL_WAKE_LOCK: 保持CPU運轉(zhuǎn)， 屏幕和鍵盤燈有可能是關(guān)閉的. SCREEN_DIM_WAKE_LOCK: 保持CPU運轉(zhuǎn)， 允許保持屏幕低亮度顯示， 允許關(guān)閉鍵盤燈. SCREEN_BRIGHT_WAKE_LOCK: 保持CPU運轉(zhuǎn)， 允許保持屏幕高亮顯示， 允許關(guān)閉鍵盤燈. FULL_WAKE_LOCK: 保持 CPU 運轉(zhuǎn)， 保持屏幕高亮顯示， 鍵盤燈也保持常亮. 使用PARTIAL_WAKE_LOCK鎖，無論屏幕的狀態(tài)是什么， 或者用戶按了電源按鈕， CPU都會繼續(xù)工作. 如果是其它的喚醒鎖， 設備會在用戶按下電源鈕后停止工作進入休眠狀態(tài).

表1 Android喚醒鎖類型

如果開發(fā)者對以上所述的喚醒鎖類型理解不到位，使用了不合適的喚醒鎖類型， 就會造成誤用. 例如在記步軟件中， 進程在后臺獲取位置信息的時候并不需要屏幕保持常亮， 使用PARTIAL_WAKE_LOCK保持CPU運轉(zhuǎn)就可以了. 如果開發(fā)者使用了FULL_WAKE_LOCK類型的鎖讓屏幕保持常亮， 就會造成不必要的電量消耗.

4 喚醒鎖檢測及優(yōu)化的實現(xiàn)

4.1 Wlresolver概述

本文研究了喚醒鎖檢測及電耗優(yōu)化機制， 并開發(fā)一款Android應用程序“Wlresolver”， 來實現(xiàn)這些機制.

在Android系統(tǒng)中可以通過PowerManager提供的服務接口來獲取與釋放WakeLock， 然而用戶無法直接訪問WakeLock的相關(guān)數(shù)據(jù). PowerManagerService位于應用框架層， 提供與電源管理相關(guān)的一系列接口，是整個系統(tǒng)的電源管理核心， 在應用框架層之下的硬件抽象層有一個power.c文件， 通過上層傳遞的參數(shù)，向/sys/power/wake_lock或者/sys/power/wake_unlock文件寫入數(shù)據(jù)來與內(nèi)核進行通信， Wlresolver在Android系統(tǒng)層次結(jié)構(gòu)中的位置如圖3.

圖3 Wlresolver在Android系統(tǒng)層次結(jié)構(gòu)圖中的位置圖

4.2 主要模塊設計及喚醒鎖檢測機制

Wlresolver主要由三個部分組成: WakeLock檢測模塊、WakeLock處理模塊、用戶交互界面模塊.

當手機屏幕關(guān)閉后延時觸發(fā)處理模塊從檢測模塊中獲取數(shù)據(jù)并處理其中誤用的WakeLock. 當屏幕關(guān)閉動作產(chǎn)生時， Android系統(tǒng)會向所有應用發(fā)出廣播， 在軟件中添加廣播接收器接收系統(tǒng)廣播， 當收到系統(tǒng)發(fā)出的屏幕關(guān)閉廣播時觸發(fā)啟動后臺服務的代碼， 此時處理模塊開始運行， 當屏幕點亮時， 另一個廣播接收器接收到廣播， 關(guān)閉處理模塊.

WakeLock檢測模塊通過adb shell命令“dumpsys power”獲取 WakeLock 相關(guān)的信息， 如圖 5， 并且將得到的原始文本數(shù)據(jù)轉(zhuǎn)換所成需要的數(shù)據(jù)， 轉(zhuǎn)換出的數(shù)據(jù)包含三個部分的信息: WakeLock對應的軟件名稱、WakeLock類型、uid、pid.

4.3 工作流程及喚醒鎖釋放策略

Wlresolver的工作流程圖如圖6所示.

圖4 Wlresolver的主要模塊示意圖

圖5 Wlresolver獲取數(shù)據(jù)

圖6 Wlresolver工作流程圖

當程序被觸發(fā)時， 首先導出系統(tǒng)中的WakeLock數(shù)據(jù)， 并將原始數(shù)據(jù)解析為我們所需要的數(shù)據(jù). 接著過濾掉 uid＞10000 的數(shù)據(jù)， 因為 uid＞10000 的是系統(tǒng)程序， 系統(tǒng)程序在屏幕關(guān)閉時可能需要一直運行， 強行關(guān)閉系統(tǒng)程序可能導致系統(tǒng)崩潰.

為了判斷應用程序是否有誤用， 第一個策略是: 檢測持有喚醒鎖的進程的CPU使用率. 如果某進程一直持有喚醒鎖， 但是在某段時間內(nèi)(如50 s)未使用CPU，可以判定為該進程申請的喚醒鎖為非必要的持有， 可以將其釋放. 因為根據(jù)統(tǒng)計數(shù)據(jù)[11]， 有70%的持有喚醒鎖的進程會一直使用CPU， 其它的持有喚醒鎖的進程也會在5 s以內(nèi)使用CPU(由于程序運行中可能會因為一些操作中斷例如I/O或者用戶交互， 在這種情況下它將在短時間內(nèi)恢復運行).

另一個釋放喚醒鎖的策略是: 先利用反向工程取得應用程序的源碼， 然后利用elite進行靜態(tài)分析[12]， 預先識別出存在誤用的應用程序. 進而在Wlresolver中建立一個黑名單列表. 黑名單內(nèi)的進程如果持續(xù)持有喚醒鎖超過某個時間就釋放該進程的喚醒鎖.

5 評測

5.1 實驗方法概述

為評估Wlresolver的使用效果和本文提出的優(yōu)化策略的有效性， 我們開展了相關(guān)實驗.

本文使用HUAWEI GRA-TL00型號手機作為測試平臺， Android版本為5.0.1. 為了保證整個測試過程的一致性， 手機關(guān)閉了wifi信號、蜂窩信號等使用頻次不確定的服務.

本文使用Google開發(fā)的battery-historian來檢測電量消耗. Android為了方便開發(fā)人員分析整個系統(tǒng)平臺和某個進程在運行時間內(nèi)的所有信息， 專門開發(fā)了bugreport工具. 在終端執(zhí)行: adb bugreport ＞bugreport.txt， 即可生成 bugreport文件. Google 針對Android 5.0(api 21)以上的系統(tǒng)開發(fā)了一個叫做battery historian的分析工具， 用來解析bugreport.txt文本文件，并用Web圖形的形式展現(xiàn)出來， 從而獲得詳細的電池耗電情況[13].

本文從華為應用商店下載了70個安卓應用程序，并且從Google Code、Github、SourceForge等開源倉庫下載了40個開源軟件， 進行測試.

5.2 實驗結(jié)果與分析

在手機中運行測試軟件， Wlresolver檢測到了6個進程(pedometer、悅動圈、網(wǎng)易云音樂等)在運行時持有喚醒鎖. Wlresolver開啟服務后， 有一個進程(悅動圈)被殺掉. 說明根據(jù)Wlresolver的策略判定悅動圈持有的喚醒鎖為誤用. 我們對悅動圈的使用情況進行了分析， 發(fā)現(xiàn)此進程在用戶不記步的情況下仍然持有喚醒鎖， 消耗大量電能， 確實存在誤用的情況.

此后， 我們進行了電量消耗速率進行了多組測試.選取了四組實驗數(shù)據(jù)繪圖， 四組實驗在Wlresolver未開啟服務的情況下分別運行1 h/5 h/12 h/24 h， 接著在Wlresolver開啟服務的情況下分別運行1 h/5 h/12 h/24 h. 使用battery-historian獲得電量消耗數(shù)據(jù)， 進行電量消耗對比. 從圖9可以看出開啟服務后電量消耗速率均有所下降， 平均下降了1.85%. 下降幅度取決于存在喚醒鎖誤用的進程數(shù)量. 如果手機運行時存在喚醒鎖誤用的進程越多， 電耗下降效果就會越明顯.

圖7 Wlsolver運行時截圖

圖8 利用battery-historian顯示電池消耗數(shù)據(jù)

圖9 根據(jù)battery-historian數(shù)據(jù)繪制的電耗速率對比圖

6 結(jié)語

本文首先介紹了Linux和Android的休眠機制. 然后分析了Android開發(fā)者在實際編碼過程中可能存在的喚醒鎖誤用類型及原因. 最后研究了喚醒鎖檢測及電耗優(yōu)化機制并通過Wlresolver實現(xiàn)了上述機制， 開啟服務后， 軟件會自動按照既定策略運行， 不需要用戶手動干預； 經(jīng)過實驗驗證， Wlresolver啟動服務后成功的清除了誤用的喚醒鎖， 系統(tǒng)電量消耗有所下降.