楊紅麗　姜　皓　秦勝潮　張　健　嚴　俊

1(北京工業(yè)大學計算機學院　北京 100124)2(深圳大學計算機與軟件學院　廣東 深圳 518060)3(中國科學院軟件研究所　北京 100190)

?

Android 應用能耗漏洞分析技術綜述

楊紅麗1姜皓1秦勝潮2張健3嚴俊3

1(北京工業(yè)大學計算機學院北京 100124)2(深圳大學計算機與軟件學院廣東 深圳 518060)3(中國科學院軟件研究所北京 100190)

隨著移動互聯(lián)網技術的迅速發(fā)展，Android手機以其強大的功能為人們的日常生活提供便捷的服務。然而Android手機的電池能源非常有限，應用耗電行為將直接影響其電池的使用壽命，因此Android應用的能耗漏洞問題受到研究者的廣泛關注。研究者們已經提出并實現(xiàn)了很多分析技術和相關工具。針對Android應用能耗漏洞分析，對相關研究方法和工具作了綜述，概括了現(xiàn)有研究工作中的問題，討論了未來研究方向。

Android應用能耗漏洞程序分析移動互聯(lián)網

0　引　言

隨著移動互聯(lián)網技術的迅速發(fā)展，諸如智能手機和平板電腦這樣的移動設備已經進入人們的生活，幫助人們開展日?；顒?，如工作和娛樂。目前市場流行的移動設備操作系統(tǒng)分別是Android、iOS以及Windows。然而在Strategy Analytics[1]公布的2014年第二季度智能設備操作系統(tǒng)市場份額報表中，Android操作系統(tǒng)的全球市場份額已達84.6%，占據著市場主導地位。另外，Android應用市場為用戶們提供了層出不窮的Android應用。截止到2014年，Google Play已經發(fā)布了近1 430 000個應用[2]。為了提高用戶體驗，Android系統(tǒng)為應用提供了多樣化的組件，例如傳感器、多媒體服務以及文件讀取的IO組件等。因此，Android應用可以為人們帶來豐富而又便捷的服務，改變人們的生活方式。Android系統(tǒng)為應用開發(fā)提供充分的系統(tǒng)接口支持，吸引了廣大的應用開發(fā)者。

由于有限的電池容量、CPU使用率和內存空間等眾多因素限制，移動設備的資源顯得及其重要，尤其是手機。Android應用與用戶交互的過程會時刻占用系統(tǒng)硬件資源，如果應用誤調用系統(tǒng)接口導致資源管理不當，就會引發(fā)能耗問題。這些造成電池壽命下降的現(xiàn)象被稱為能耗漏洞[3]，這些漏洞會造成系統(tǒng)不必要的能源開銷，使得電池電量很快耗盡。為了改善應用能耗問題，越來越多的研究者開始關注Android應用能耗研究，檢測能耗問題并提出相應的分析方法。本文以Android平臺為背景，針對Android應用中的能耗漏洞概括并總結現(xiàn)有的研究工作，提出進一步的研究展望。

1　Android應用能耗成因

Android系統(tǒng)以其豐富的功能改變了世界，但是隨著其功能的逐漸強大，系統(tǒng)能耗的代價也逐漸上升。Android手機存在大量的組件、傳感器以及服務， 例如GPS、Camera、WiFi、Screen、Bluetooth等，然而每一個組件或服務的使用都會消耗電池能源。手機的能耗與其組件的使用情況有直接關系。例如，地圖應用會通過GPS導航系統(tǒng)進行地理位置追蹤；指南針應用會使用方向傳感器確定方向；新聞應用會通過WiFi、3G、4G網絡數(shù)據傳輸時刻更新當前新聞消息等。Abhijeet等人[4]通過解析Android手機中的power_profile.xml文件獲取手機組件在不同狀態(tài)下的耗電情況，如圖1所示，可以看出屏幕、GPS、Wifi等組件都是高耗電組件。不同類別的應用會根據業(yè)務需求使用不同的組件，不同使用場景導致了手機不同程度的耗電現(xiàn)象。因此，如何在電池能源有限的情況下提高Android手機的能源使用效率，避免不必要的耗電現(xiàn)象，成為了提高用戶體驗的重要因素，也是解決應用高耗電問題的有效措施。

圖1　LG L3 E400手機組件能耗圖

2　Android應用能耗漏洞分類

在能源極其有限的Android手機中，系統(tǒng)資源需要被合理使用。系統(tǒng)資源被合理使用時，能耗會呈現(xiàn)平穩(wěn)趨勢，在釋放階段逐漸下降直到系統(tǒng)回到休眠狀態(tài)，如圖2(a)所示。如果應用出現(xiàn)能耗漏洞，那么系統(tǒng)能源將會被嚴重消耗，手機電量也將會被迅速耗盡。在應用市場中，很多應用因為錯誤的設計導致能耗漏洞的出現(xiàn)。能耗漏洞問題嚴重影響了用戶體驗，并成為開發(fā)者們關注的焦點。如果應用在運行過程中使得手機能耗大幅度上漲，那么該應用潛在或存在某種能耗漏洞。在現(xiàn)有的研究工作中，能耗漏洞可以分為能耗熱點和能耗泄漏兩大類[4-8]。

2.1能耗熱點

能耗熱點指的是應用運行過程中造成能源熱點消耗。在圖2(b)中可以明顯看出，應用處于資源使用階段時，能耗出現(xiàn)大幅度增長的趨勢。在現(xiàn)有研究工作中，能耗熱點主要包括以下幾種情況：

(1) 資源申請與釋放時機錯誤：資源在應用使用時申請過早或者在應用退出時釋放過晚會消耗更多的能源。

(2) 高能耗的后臺服務：為了提高用戶體驗，應用會嘗試使用高能耗的服務，例如提高GPS的位置更新頻率。然而不必要的高頻率更新會造成能源的異常消耗。

(3) 循環(huán)能耗：循環(huán)或者迭代的方式代表應用程序中不斷重復執(zhí)行的行為，由循環(huán)產生的漏洞可能出現(xiàn)在某些特定場景中。例如作為客戶端的Android應用向一個不可達的服務器發(fā)送連接請求，周期性請求連接的行為將會產生大量能源的消耗。

(4) 無用代碼：表示源碼中定義或者聲明卻未被使用的代碼，甚至可以是分支結構中永遠不可到達的代碼塊。虛擬機運行程序機器指令時同樣會將這些無用代碼加載到內存中執(zhí)行，造成多余的能源耗費。

(5) 過多的數(shù)據操作：過多的數(shù)據移動或儲存如頻繁的I/O讀寫、SQLite數(shù)據庫操作將會嚴重消耗內存使用[9]。

(6) 應用的布局加載：在應用啟動時，需要將布局文件與相應的Activity進行綁定，即調用setContentView方法為此Activity顯示指定布局。布局在顯示的過程中需要系統(tǒng)讀取并解析布局文件，在布局文件相當復雜時，系統(tǒng)不得不消耗更多內存以及更長時間展開布局。

2.2能耗泄漏

能耗泄漏指的是應用的某些行為阻礙手機進入空閑狀態(tài)，導致能源的持續(xù)消耗。如圖2(c)所示，雖然應用在資源使用階段處于平穩(wěn)的狀態(tài)，但是應用進入后臺或者應用進程結束時沒有釋放相應的資源，使得資源不能及時釋放，導致應用在資源釋放階段仍持續(xù)耗電。相關的能耗泄漏包括以下幾種情況：

(1) 無休眠(No-Sleep)漏洞：指應用獲取WakeLock對象使得CPU、屏幕保持在活動狀態(tài)，而在任務結束之后沒有及時釋放WakeLock對象占用的資源，導致CPU、LCD無法進入休眠狀態(tài)而持續(xù)消費能源。

(2) 資源泄漏：WiFi、多媒體等資源有可能在應用執(zhí)行過程中獲取，但是未能在應用結束時進行釋放，導致硬件資源處于開啟狀態(tài)，造成能耗泄漏。

(3) 自啟動漏洞：指應用進程被銷毀之后在后臺再次創(chuàng)建，使得手機無休止地為該進程消耗能源。該漏洞多數(shù)情況下由后臺的服務監(jiān)控，當收到進程銷毀的消息后，喚醒系統(tǒng)開啟新的進程實例[10]。

(4) 內存泄漏：所有應用程序都可能出現(xiàn)的一種能耗漏洞，指在程序運行時系統(tǒng)不斷為程序分配內存空間，或是由于疏忽和錯誤導致程序關閉時未能釋放相應的內存空間。內存泄漏的問題對于資源有限的嵌入式設備來說十分嚴重[11]。常見的內存泄漏問題，有位圖對象內存泄漏、監(jiān)聽器泄漏等。

3　Android應用能耗漏洞分析方法

為了能夠檢測應用中潛在的能耗漏洞，采用有效的程序分析、測試方法可以盡可能多地幫助應用發(fā)現(xiàn)這些錯誤，提高應用的可靠性和健壯性。

3.1靜態(tài)分析方法

3.1.1信息流分析

信息流分析分為控制流分析和數(shù)據流分析。控制流分析基于應用程序的代碼層，將程序劃分為一個個基本塊(連續(xù)的線性代碼的語句序列)，靜態(tài)分析基本塊之間的控制結構，以控制流圖的形式表示應用程序執(zhí)行路徑。Michael等人[12]構建了一般應用程序的控制流圖，根據Manifest文件定義每個組件的入口點(如MainActivity的onCreate方法)，并加入Android應用的回調機制等特性(如廣播的onReceive方法)，逐步完善控制流圖的構建。Guo[13]等人采用控制流圖的方法檢測能耗泄漏問題。該方法通過字節(jié)碼的分析構建函數(shù)調用關系圖以及每個函數(shù)的控制流圖，并對函數(shù)調用關系圖和控制流圖等結構進行深度遍歷，檢測應用中的喚醒鎖、傳感器等資源是否出現(xiàn)能耗泄漏。Abhinav等人[14]用數(shù)據流分析方法檢測無休眠漏洞。該方法以控制流圖為基礎，在控制流圖中基本塊的入口處以及出口處收集程序的語義信息，利用數(shù)據流方程對程序中數(shù)據的使用、定義及數(shù)據之間的依賴關系等方面的信息進行分析，從而對Wakelock對象以及Camera對象的申請與釋放狀態(tài)進行檢測。Panagiotis等人[15]使用控制流與數(shù)據流相結合的分析方法對328個Android應用進行No-sleep漏洞的檢測，發(fā)現(xiàn)其中145個應用存在該漏洞。

3.1.2中間語言轉換

由于Dalvik字節(jié)碼不同于Java字節(jié)碼，導致Soot[26]、WALA[28]等工具無法支持對Dalvik字節(jié)碼的分析。因此，一些研究方法通過將Dalvik字節(jié)碼進行轉換，轉換為Java字節(jié)碼或中間表示語言，從而可以采用更加通用的Java程序分析方法以及工具進行分析。Damien[29]等人提出Dare工具將Android應用程序作為輸入(輸入包括dex、apk以及class文件)，生成應用的Java字節(jié)碼。同樣地，Dexpler工具[30]可以將Dalvik字節(jié)轉換為Jimple語言表示。Jimple語言是Soot工具支持的中間表示語言，因此可以利用Soot工具對Jimple文件進行分析。

3.1.3模型檢測

在能耗泄漏問題中，研究方法可以將系統(tǒng)資源的使用情況作為應用的狀態(tài)，對應用的具體實現(xiàn)進行抽象，用狀態(tài)遷移系統(tǒng)建立應用資源狀態(tài)的轉換模型，并用相應的模態(tài)邏輯公式與時態(tài)邏輯公式驗證模型是否存在資源泄露問題。Song等人[35]使用模型檢測的方法識別用戶信息泄漏情況，文章雖然關注安全問題，但是模型檢測的方法同樣可以借鑒到能耗分析中。

3.1.4符號執(zhí)行

符號執(zhí)行的方法通常使用在路徑敏感的程序分析中。對于能耗問題的靜態(tài)分析，利用符號執(zhí)行的方法可以精確地模擬應用的執(zhí)行，并在每一條分支結構下，收集目標變量的可能取值。因此，研究方法可以將應用所使用的資源作為目標變量進行跟蹤，對每條執(zhí)行路徑中資源變量的取值狀態(tài)進行分析。現(xiàn)有工作中使用符號執(zhí)行方法的能耗研究相對較少，Nariman等人[34]通過改造Java Path Finder工具使應用可以運行于JVM虛擬機，并提出符號執(zhí)行的方法生成測試用例并對應用進行動態(tài)測試。

3.2動態(tài)分析方法

3.2.1事件流分析

為了能夠實時監(jiān)控應用執(zhí)行中出現(xiàn)的能耗漏洞，Abhijeet等人[4]提出了基于事件流圖的測試框架，動態(tài)分析應用程序的行為。該框架可以檢測能耗熱點以及能耗泄漏。事件流圖基于Android UI模型[16]，而流圖的構建需要通過其他工具完成，分別為Hierarchy Viewer[17]和Dynodroid[18]。前者提供應用布局中UI控件元素信息，而后者可以針對控件能夠觸發(fā)的事件自動化生成事件序列。序列中的每個節(jié)點代表一個具體的執(zhí)行動作(例如點擊應用中的播放按鈕執(zhí)行音頻文件的播放)，而節(jié)點之間的邊代表事件間的轉移。在應用程序運行過程中，框架在記錄事件序列的同時，還需要跟蹤并記錄交互過程中系統(tǒng)資源API的調用情況，并通過Yokogawa WT210[19]測量儀器給出精確的應用能耗信息?？蚣芨鶕芎男畔⒖梢杂嬎闾囟ńM件的能耗情況，該值越高則代表應用耗電越嚴重。因此，在應用執(zhí)行過程中出現(xiàn)能耗過高的情況則代表應用出現(xiàn)能耗熱點問題。應用退出時，能耗過高則代表能耗泄漏問題。框架對30個應用進行檢測，并準確發(fā)現(xiàn)潛在的能耗熱點與能耗泄漏。

3.2.2污點檢測

污點檢測[20]將來自于可疑渠道的數(shù)據標記為“被污染”，跟蹤污點數(shù)據在程序中的擴散過程，最后通過一定的檢測規(guī)則查找軟件中的漏洞。TaintDroid[21]是Android平臺的擴展工具，用于檢測敏感數(shù)據在不信任應用中泄漏的安全問題。它自動標記涉及到敏感數(shù)據的變量、文件、進程間的消息，當污點數(shù)據通過網絡傳播離開手機時報告給用戶以及安全服務商。而Zhang等人[22]基于TaintDroid的方法提出ADEL工具，用來檢測能耗熱點，例如下載無用網絡數(shù)據或數(shù)據頻繁更新。工具在網絡端口監(jiān)聽下載數(shù)據，將下載的網絡數(shù)據進行分類并將每類數(shù)據對象標記唯一的ID標簽作為污點數(shù)據，用堆棧結構存儲標簽信息以及該標簽的數(shù)據對象。Liu[23]提出的GreenDroid工具利用污點分析的方法分析傳感器數(shù)據的利用率。該工具構建基于Java Path Finder[24]，使Android應用程序可以運行在JVM虛擬機。該工具可以幫助應用定位能源使用效率低下的問題。Flowdroid[25]是一個Android應用靜態(tài)污點分析工具，工具在Soot[26]和Heros[27]的基礎上進行精確的數(shù)據流分析，整個分析過程與數(shù)據流執(zhí)行順序相關。該方法分為向前、向后兩種方向的分析，向前的污點分析用于找出污點變量、引用的傳播位置；而向后的污點分析用于查找污點數(shù)據生成之前所依賴的其他數(shù)據，這些數(shù)據存在于堆棧中。

3.2.3程序插樁分析

程序插樁技術是將代碼片段(如日志信息輸出語句)植入目標應用中，然后運行應用，收集應用在動態(tài)運行過程中的狀態(tài)變量變化信息以及執(zhí)行路徑信息(如函數(shù)執(zhí)行順序、調用關系等)。插樁分析不能直接檢測應用的能耗問題，但是該方法可以有效地理解應用的動態(tài)行為，從而驗證應用是否滿足某些性質或規(guī)則。Guo[13]等人利用插樁分析方法收集應用動態(tài)執(zhí)行的路徑覆蓋信息，從而驗證靜態(tài)分析中系統(tǒng)資源泄漏問題的正確性。

3.3現(xiàn)有工作總結

通過以上介紹，Android應用能耗漏洞的分析方法可分為靜態(tài)、動態(tài)分析兩類。從表1中可以看到每種方法的特點。

表1　能耗漏洞分析方法總結

3.4相關工具

探究應用性能及能耗的相關工具有很多，分別從應用的調試方面、測試方面和分析方面幫助開發(fā)者進行檢測。

在應用開發(fā)與調試方面，Google在Android2.3中增加的StrictMode接口[36]可以檢測代碼質量。Android提供的TraceView工具[37]可以圖形化顯示應用在每個線程中所調用函數(shù)的執(zhí)行時間與執(zhí)行次數(shù)。SDK中提供的Dmtracedump工具[38]可以分析應用執(zhí)行過程中方法之間的層級調用關系。Apktool[40]是一個應用的逆向工具，該工具可以對APK文件進行逆向工程，生成smali格式的字節(jié)碼文件。結合dex2jar工具[41]可以將smali字節(jié)碼轉為Java代碼，便于分析第三方應用。Androguard工具[39]同樣采用逆向工程的方法分析APK文件，可以獲取應用中的相關組件、權限等信息并生成相應的方法調用關系圖、控制流圖。Relda[13]是一個基于Androguard的Android應用的靜態(tài)分析工具，該工具可以檢測應用中存在的資源泄漏，并給出詳細的分析報告。 MAT工具[33]是Eclipse平臺提供的用于分析Java程序內存問題的工具，同時支持Android應用的內存分析。Hierarchy Viewer工具[17]適用于查看與分析應用布局中各個控件的層次結構，可以進一步分析布局中的性能瓶頸。

在應用測試方面，Android提供的Instrumentation框架[42]基于Junit框架[43]，增加Android應用特性。Robotium框架[32]是一個開源的Android自動化測試庫，該框架進一步封裝了Instrumentation框架，實現(xiàn)了應用的集成測試。Monkey[44]和MonkeyRunner[31]是黑盒測試工具，通常用于測試第三方應用的壓力、可靠性、運行錯誤與異常。

4　現(xiàn)有工作中的問題

4.1靜態(tài)分析中的問題

(1) 在靜態(tài)分析過程中，為了全局分析類之間或者函數(shù)之間的交互、依賴關系，經常采用構建函數(shù)摘要的方法。函數(shù)摘要是對函數(shù)信息的抽象，能耗分析中的函數(shù)摘要不僅要關注函數(shù)的輸入變量、輸出變量信息，還需要包含函數(shù)內部是否調用了資源相關的API。然而函數(shù)摘要的定義并沒有統(tǒng)一的標準，如果為了提高分析效率而將函數(shù)摘要定義得非常簡單，那么分析的準確度將會降低。例如某個函數(shù)摘要中定義了返回值的類型，在主調函數(shù)中該類型根據多態(tài)特性發(fā)生類型轉換，導致無法確定該返回值的實際類型。

(2) Android應用是基于事件驅動的，靜態(tài)分析需要將事件觸發(fā)時的回調機制考慮全面。然而Android版本升級頻率很高，每一次版本升級必然加入了新的API，分析方法需要定期將新的API回調規(guī)則以及錯誤模式進行升級。

(3) 目前的應用能耗靜態(tài)分析還存在較多誤報情況，這是由于分析的精確程度不同而導致的。例如分析方法未能將Android的回調特性考慮全面，或是無法識別多態(tài)類型的轉換導致變量的實際類型無法確認。另外，為了提高分析效率而簡化循環(huán)、遞歸結構的處理同樣會導致分析結果的不準確。

(4) 靜態(tài)分析往往能夠檢測出潛在的能耗問題，然而這些問題是否能夠給手機能耗帶來影響，還需要進行人工確認。一方面通過插樁的方式檢測問題是否能夠被觸發(fā)，另一方面需要監(jiān)控能耗的使用信息來判定問題的真實性。

4.2動態(tài)分析中的問題

(1) 動態(tài)分析不需要針對應用的代碼進行分析，而是在應用運行過程中檢測能耗漏洞。因此，動態(tài)分析需要生成有效的測試用例并保證測試用例能夠覆蓋應用運行過程中的所有狀態(tài)，這樣才足以觸發(fā)并檢測到應用的能耗問題，否則將會產生漏報情況。因此，如何保證測試用例的覆蓋率是動態(tài)分析需要解決并改進的問題。

(2) 應用的運行過程與用戶的行為密切相關，用戶會根據經驗改變應用的各種狀態(tài)，因此生成測試用例時如果能夠將用戶的行為習慣作為約束條件，那么動態(tài)分析的效率將會更高。

(3) 針對能耗問題進行動態(tài)分析需要運行真實應用并監(jiān)控手機的能耗情況。現(xiàn)有研究中通常利用外部儀器對手機能耗信息進行監(jiān)控，這就為動態(tài)分析的環(huán)境構建帶來不便因素。

5　Android應用能耗研究展望與趨勢

Android應用能耗相關研究自數(shù)年前開始得到廣泛關注，不論從能耗測量的角度或者能耗漏洞檢測的角度，大量的研究方法都證明了能耗研究在理論研究和實踐探索中都取得了較為突出的成果。然而隨著應用程序實現(xiàn)方法的不斷演變，能耗問題將會以不同形式展現(xiàn)，并且應用開發(fā)者在開發(fā)過程中會將主要精力放在功能實現(xiàn)而忽略能耗優(yōu)化，因此現(xiàn)階段研究并不能說明Android應用能耗研究已經達到完備。相反，現(xiàn)有研究并不充分，并且隨著系統(tǒng)的發(fā)展，仍有更多的研究領域值得廣泛關注。

(1) 改進靜態(tài)分析方法

目前應用的靜態(tài)分析需要提高分析的精確度。如圖3所示，很多研究工作的靜態(tài)分析都是通過Android應用源碼或反編譯后的Dalvik字節(jié)碼，并根據動態(tài)回調機制，生成應用的組件間關系調用圖、函數(shù)調用關系圖，以及每個函數(shù)的控制流圖；通過過程內與過程間的分析獲取應用組件的狀態(tài)，檢測組件的狀態(tài)是否在每條可執(zhí)行路徑結束時都處于釋放狀態(tài)，從而判斷應用是否存在能耗漏洞。因此從整個過程來看，分析方法需要在信息流構建、過程內以及過程間進行改進，例如細化函數(shù)摘要的定義；并且盡可能全面地考慮Android的動態(tài)回調機制，例如AsyncTask對象執(zhí)行execute()方法后要先后調用onPreExecute()、doInBackground()、onProgressUpdate()和onPostExecute()四個回調函數(shù)。因此可以將回調規(guī)則建立為相應的鍵值映射結構，當識別這些含有回調機制的指令時，根據鍵值映射結構以及對象所屬類型可以找到相應的回調函數(shù)塊進行分析。而靜態(tài)分析結果的不確定性可以通過動態(tài)分析確認，并將不確定的信息交由動態(tài)分析精化。如圖4所示，可以對應用代碼進行插樁或者添加某些日志消息輸出的指令，然后使用Monkey工具進行自動化壓力測試，收集應用測試過程中的路徑覆蓋信息。將這些信息和靜態(tài)分析結果的問題路徑信息進行比較，可以有效地驗證靜態(tài)分析的準確性。

圖3　Android應用靜態(tài)分析流程

圖4　通過動態(tài)分析確定靜態(tài)分析結果

當Android版本更新，分析方法需要收集新的組件API規(guī)則以及定義新的能耗錯誤模式?，F(xiàn)有工作通常是參照Android開發(fā)文檔進行人工整理，通常會花費大量時間。為了提高效率，研究工作可以利用網絡爬蟲技術，制定相應的過濾規(guī)則，對在線開發(fā)文檔進行API信息的抓取。如圖5所示，在開發(fā)文檔頁面的html頁面中，可以針對Android組件所屬的包名以及版本號進行分類過濾，然后通過包名所在的頁面獲取該包中的類型信息，以及每個類中所有方法的信息。例如通過抓取可以收集到WakeLock類在Android5.0中加入了帶參數(shù)的release方法，而Camera類在Android5.0中已經被Camera2替換。

圖5　通過網絡爬蟲對開發(fā)文檔API信息進行分類抓取

(2) 構建智能化的動態(tài)分析方法

現(xiàn)有能耗研究的方法以及技術已較為完善，然而Android應用的運行和用戶的使用行為密切相關，因此在系統(tǒng)和應用方面都需要智能化動態(tài)感知能耗漏洞，自適應使用環(huán)境的變化，甚至可以根據環(huán)境采取相應的措施來堵塞漏洞的發(fā)生。例如，當手機處于低電量狀態(tài)，用戶通常希望GPS、WiFi等高耗電組件處于關閉狀態(tài)。這時如果某個應用在后臺啟動這些組件，那么組件的啟動行為應該被檢測并記錄。研究方法可以一方面通過Android API獲取電量信息以及組件使用情況，如ConnectivityManager類可以判別當前網絡連接類型，LocationManager類可以判別GPS是否開啟等；另一方面獲取Android文件系統(tǒng)中的能耗信息，這些信息保存在/proc目錄下，例如/proc/stat文件記錄了系統(tǒng)CPU使用信息，/proc/meminfo記錄了系統(tǒng)內存使用信息等。根據電量以及組件使用信息，可以構建Android服務，在手機電量低的情況下對組件使用情況進行動態(tài)檢測，將組件的能耗信息進行統(tǒng)計并反饋給用戶，讓用戶了解手機中的應用是否潛在能耗問題。因此對于用戶來說，構建有效的、智能化的能耗分析、解決方案，將是Android應用能耗分析的前景。

(3) 應用本地庫代碼中的能耗分析

現(xiàn)有工作對應用的本地代碼研究相對較少。Android系統(tǒng)通過NDK可以得到C/C++代碼支持，目前大部分的開源庫是C/C++代碼開發(fā)，應用需要構建本地方法調用第三方開源庫。然而本地方法的錯誤使用同樣會導致能耗漏洞的出現(xiàn)。例如很多應用會使用OpenGL ES進行三維圖形的渲染，如果應用在本地方法中沒有有效控制渲染幀率，或者沒有及時釋放無用的幀緩存，那么手機將會加速耗電。現(xiàn)有工作中對NDK中能耗問題的探測相對較少，因此這是一個值得關注的領域。

(4) 應用布局的性能分析

布局在呈現(xiàn)的過程中需要系統(tǒng)讀取并解析布局文件。當布局文件相當復雜時，系統(tǒng)會消耗更多內存以及更長時間展開布局，造成布局的加載出現(xiàn)卡頓現(xiàn)象，大大降低了用戶體驗。圖6為Hierarchy View工具對布局的分析示例，左邊的FrameLayout控件中布局指示器和繪制指示器均顯示為黑色，表示該控件在視圖樹加載過程中執(zhí)行緩慢。究其緩慢的原因是該FrameLayout控件所包含的子控件數(shù)目很多，層次較為復雜。Android系統(tǒng)繪制應用布局需要經過測量過程和繪制過程，如果視圖樹中層次復雜，節(jié)點數(shù)目過多，那么布局加載的過程就會需要更多時間以及更大內存。因此在檢測布局性能問題時，研究方法可以關注布局中視圖樹的復雜程度，可以根據某些規(guī)則，減小視圖樹的層次。例如同一層次的ImageView控件和TextView控件可以合并為一個TextView控件，而利用TextView的drawable屬性就可以完成圖片的填充。目前應用布局性能分析的研究工作相對較少，因此如何減少布局帶來的系統(tǒng)開銷需要更廣泛的關注和研究。

圖6　Hierarchy Viewer工具分析布局加載的性能

(5) 新特性中潛在的能耗問題

目前Android5.0系統(tǒng)為改善能耗提出新的特性，包括系統(tǒng)以及API兩個方面。因此開發(fā)者應該遵循這些“新規(guī)則”構建出更為省電的應用，這就導致現(xiàn)有應用不得不經過舊版本移植的過程。并且伴隨新特性，新應用開發(fā)過程中出現(xiàn)的新問題也將會存在更多的研究空間。

(6) 應用能耗優(yōu)化分析

現(xiàn)有的研究工作多是針對能耗的分析與檢測。然而為了避免漏洞的出現(xiàn)，研究工作可以從優(yōu)化方法的角度出發(fā)，對存在能耗漏洞的應用給出合理的優(yōu)化建議和優(yōu)化方案，這樣可以更加有效地幫助開發(fā)者改善應用中的能耗問題。例如所有的資源釋放操作都可以提前到Activity的onPause方法中進行，也就是當應用處于暫停狀態(tài)下釋放相應的資源，關閉高耗電組件。

6　結　語

本文對Android應用能耗分析技術進行綜述。首先介紹Android應用中能耗問題的成因。然后對現(xiàn)有研究中發(fā)現(xiàn)的能耗漏洞進行分類，并對每種能耗漏洞的子問題進行描述。接著詳細描述了能耗漏洞的現(xiàn)有分析方法以及相關工具，并概括了現(xiàn)有工作中的不足。最后根據現(xiàn)有工作存在的問題以及Android應用能耗研究的發(fā)展對未來研究工作進行展望。

[1] Android Captures Record 85% share of Global Smartphone shipments in Q2 2014[OL].[2014-7-30].http://www.strategyanalytics.com/default.aspx?mod=reportabstractviewer&a0=9921.

[2] GooglePlay[OL].[2015-4-2]. http://en.wikipedia.org/wiki/Google_Play.

[3] Jack Z, Ayemi M, Wei L. A Comparison of Energy Bugs for Smartphone Platforms[C]//The International Workshop on Engineering of Mobile-Enabled Systems. San Francisco: IEEE, 2013:25-30.

[4] Abhijeet B, Lee K C, Sudipta C, et al. Detecting energy bugs and hotspots in mobile apps[C]//The 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering(FSE 2014). New York: ACM, 2014:588-598.

[5] Marion G, Mirco J, Jan J, et al. Removing Energy Code Smells with Reengineering Services[J].GI-Jahrestagung,LNI,2012, 208:441-455.

[6] Pathak A,Hu Y C, Zhang M. Bootstrapping Energy Debugging on Smartphones: A First Look at Energy Bugs in Mobile Devices[C]//The 10th ACM Workshop on Hot Topics in Networks Article(Hotnets’11).New York:ACM,2011:1-6.

[7] étienne P, Fausto S. Static analysis of Android programs[C]//The 23rd international conference on Automated deduction(CADE2011).Berlin:Springer,2011:439-445.

[8] Li D, Halfond W G J. An Investigation into Energy-Saving Programming Practices for Android Smartphone App Development[C]//The 3rd International Workshop on Green and Sustainable Software(GREENS’2014). New York: ACM, 2014:46-53.

[9] Hagen H, Christian B. Towards an energy-consumption based complexity classification for resource substitution strategies[C]//The CEUR Workshop Proceedings,CEUR-WS(GvD Workshop’10). Bad Helmstedt: 2010,581.

[10] Android Service[OL].[2015-3-19].http://developer.android.com/reference/android/app/Service.html.

[11] Jihyun P, Byoungju C. Automated Memory Leakage Detection in Android Based Systems[J].International Journal of Control and Automation, 2012,5(2):35-42.

[12] Grace M, Zhou Y J, Wang Z, et al. Systematic Detection of Capability Leaks in Stock Android Smartphones[C]//The 19th Network and Distributed System Security Symposium(NDSS 2012).San Diego: NDSS, 2012:1-15.

[13] Guo Chaorong,Zhang Jian,Yan Jun, et al. Characterizing and Detecting Resource Leaks in Android Applications[C]//The 28th International Conference on Automated Software Engineering(ASE 2013).Silicon Valley: IEEE, 2013:389-398.

[14] Abhinav P, Abhilash J, Hu Y C, et al. What is keeping my phone awake?: characterizing and detecting no-sleep energy bugs in smartphone apps[C]//The 10th international conference on Mobile systems, applications and services(MobiSys’12).New York: ACM, 2012:267-280.

[15] Panagiotis V, Ranjit J, Sorin L, et al. Towards verifying android apps for the absence of no-sleep energy bugs[C]//The 2012 USENIX conference on Power-Aware Computing and Systems(HotPower’12). Berkeley: USENIX Association, 2012:3.

[16] Atif M, Ishan B, Adithya N. GUI Ripping: Reverse Engineering of Graphical User Interface for Testing[C]//The 10th Working Conference on Reverse Engineering(WCRE’03).IEEE, 2003:260-269.

[17] Hierarchy Viewer[OL]. [2015-4-2].http://developer.android.com/tools/help/hierarchy-viewer.html.

[18] Aravind M, Rohan T, Mayur N. Dynodroid: An Input Generation System for Android Apps[C]//The 9th Joint Meeting on Foundations of Software Engineering(ESEC/FSE 2013).New York: ACM, 2013:224-234.

[19] Yokogawa WT210[OL].[2013-5-12].http://tmi.yokogawa.com/discontinued-products/digital-power-analyzers/digital-power-analyzers/wt210wt230-digital-power-meters/#tm-wt210_01.htm.

[20] Taint Checking[OL].[2014-1-7]. http://en.wikipedia.org/wiki/Taint_checking.

[21] William E, Peter G, Byung C, et al. TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones[C]//The 9th USENIX Symposium on Operating Systems Design and Implementation(OSDI’10),2010:1-15.

[22] Zhang L, Gordon M S,Dick R P, et al. ADEL: an automatic detector of energy leaks for smartphone applications[C]//The 8th ACM international conference on Hardware/software codesign and system synthesis(CODES+ISSS’12). New York: ACM, 2012:363-372.

[23] Liu Yepang, Xu Chang, Cheung S C. Where Has My Battery Gone? Finding Sensor Related Energy Black Holes in Smartphone Applications[C]//The 2013 IEEE International Conference on Pervasive Computing and Communications (PerCom).San Diego: IEEE, 2013:2-10.

[24] Java Path Finder[OL].[2007-10-30]. http://babelfish.arc.nasa.gov/trac/jpf/.

[25] Steven A, Siegfried R, Christian F, et al. FlowDroid: Precise Context, Flow, Field, Object-sensitive and Lifecycle-aware Taint Analysis for Android Apps[C]//The 35th ACM SIGPLAN Conference on Programming Language Design and Implementation(PLDI’14).New York: ACM, 2014:259-269.

[26] SOOT[OL].[2008-9-22]. http://www.bodden.de/2008/09/22/soot-intra.

[27] Heros[OL]. [2015-1-27]. https://github.com/Sable/heros.

[28] WALA[OL].[2013-7-17]. http://wala.sourceforge.net/wiki/index.php/Main_Page.

[29] Damien O, Somesh J, Patrick M. Retargeting Android Applications to Java Bytecode[C]//The ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering(FSE’12). New York: ACM, 2012:1-11.

[30] Alexandre B, Jacques K, Yves L T, et al. Dexpler: converting Android Dalvik bytecode to Jimple for static analysis with Soot[C]//The ACM SIGPLAN International Workshop on State of the Art in Java Program analysis(SOAP’12). New York: ACM, 2012:27-38.

[31] MonkeyRunner[OL].[2015-2-16].http://developer.android.com/tools/help/MonkeyRunner.html.

[32] Robotium[OL].[2015-3-10].https://code.google.com/p/robotium/wiki/RobotiumTutorials.

[33] MAT[OL]. [2014-6-25]. http://www.eclipse.org/mat/.

[34] Nariman M, Sam M, Corina S P, et al. Testing Android Apps Through Symbolic Execution[J].ACM SIGSOFT Software Engineering Notes,2012,37(6):1-5.[35] Song F, Touili T. Model-Checking for Android Malware Detection[J].Programming Languages and Systems, 2014:216-235.

[36] StrictMode[OL].[2015-4-2].http://developer.android.com/reference/android/os/StrictMode.html.

[37] Traceview[OL].[2015-4-2].http://developer.android.com/tools/help/traceview.html.

[38] dmtracedump[OL].[2015-4-2].http://developer.android.com/tools/help/dmtracedump.html.

[39] Androguard[OL].[2015-4-2]. https://code.google.com/p/androguard/.

[40] Apktool[OL].[2015-3-18]. http://ibotpeaches.github.io/Apktool/.

[41] dex2jar[OL]. [2012-10-25]. http://code.google.com/p/dex2jar.

[42] Instrumentation[OL].[2015-4-2].http://developer.android.com/reference/android/app/Instrumentation.html.

[43] Junit[OL]. [2014-12-4]. http://junit.org/.

[44] Monkey[OL].[2015-2-16].http://developer.android.com/tools/help/monkey.html.

SURVEY ON ENERGY BUG ANALYSIS TECHNOLOGY OF ANDROID APPLICATIONS

Yang Hongli1Jiang Hao1Qin Shengchao2Zhang Jian3Yan Jun3

1(College of Computer Science, Beijing University of Technology, Beijing 100124, China)2(CollegeofComputerScienceandSoftwareEngineering,ShenzhenUniversity,Shenzhen518060,Guangdong,China)3(InstituteofSoftware，ChineseAcademyofSciences,Beijing100190,China)

With the rapid development of mobile Internet technology, Android smart phone provides convenient services for people’s daily life with its powerful functions. However, the energy resource of Android applications is very limited. The energy consumption of Android applications will directly affect battery life. Therefore, the energy bugs of Android applications are greatly concerned by the researchers, and quite a few of technologies and correlated tools have been proposed and developed. This paper outlines the correlated research methods and tools for energy bugs analysis of Android applications and summarises the problems in recent studies, as well as discusses the research directions in the future.

Android applicationsEnergy bugProgram analysisMobile internet

2015-06-07。國家自然科學基金項目(61373033)。楊紅麗，副教授，主研領域：Android應用能耗分析，程序分析與驗證。姜皓，碩士。秦勝潮，教授。張健，研究員。嚴俊，副研究員。

TP3

A

10.3969/j.issn.1000-386x.2016.09.001