移動終端App電量測試與優化

袁宜霞

(廣東省外語藝術職業學院，廣東廣州 510000)

1 引言

隨著5G 網絡的普及帶來了移動互聯網的巨大發展，移動終端的App 應用越來越多，使用場景越來越豐富，使用頻率也越來越高，使得移動終端電量消耗過快的問題日益突出。移動終端的電池電量是非常有限的，保持持久的續航能力尤為重要。App研發團隊必須慎重檢查電量的使用，以免導致用戶手機耗電發熱，帶來不良體驗。

移動終端電池不耐用有兩方面原因：一方面是手機硬件和操作系統的問題，另一方面是移動應用App的問題，例如：隨意自啟動，頻繁在后臺多次喚醒，搶占桌面、通知欄和懸浮窗等。本文著重于關注Android 移動應用App 對電量帶來的影響，總結導致電量消耗過快的常見原因，介紹Android 電量相關測試與優化技術，并以案例的方式，針對典型問題提出相應優化措施，進一步有效地提升App電量方面的用戶體驗。

2 耗電本質

2.1 硬件系統架構

圖1是一個典型的智能手機硬件架構圖[1]。

圖1 智能手機的硬件架構[1]

當智能手機待機時，主板可以直接關閉應用處理器、無線網卡和顯示器等外設的供電電源，而基帶處理器、蜂窩話音和射頻設備等需持續供電，保證繼續等待來電、搜索網絡等功能[1]。

GPS、SD 卡、相機、傳感器、音頻、藍牙組件的耗電較少，而CPU、屏幕和射頻通信(蜂窩話音、蜂窩數據和Wi-Fi)的耗電量較大，需要特別關注[2]。

2.2 CPU

關于CPU，本文將從計算類型和頻率方面進行分析。

1)計算類型

縮短應用程序代碼產生指令運行的時間，從而減少應用程序對CPU時間片的占用總時間，進而降低單位時間內目標應用程序在整臺手機耗電的百分比。例如：在對算法性能要求高的應用程序中建議減少大整數除法的操作。

2)頻率

CPU 在不同頻率工作時，需要的電壓是不同的，提高電壓將直接提高CPU的耗電。電量=電流*時間，CPU工作的同時也會帶著顯示器等其他耗電組件一起運作，隨著時長的增加，單位運算量所耗費的電量也跟著增加。因此，App 運行時提高CPU利用率，減少sleep的使用將能減少耗電量。

2.3 顯示屏與耗電

手機顯示屏主要是LCD和OLED 兩個大類：LCD是背光源發光，在背光燈泡亮度一定的情況下，顯示不同顏色時耗電是一樣的；OLED 是主動發光，顯示不同顏色時，每個LED單元的功耗不同，所以整體功耗不同。全白顏色時OLED 耗電是LCD的3 倍，全黑顏色時LCD 耗電是OLED 的10 倍，30%白色時OLED和LCD耗電一樣[3]。

對于LCD屏幕，需要重點關注屏幕亮度(0-255)的取值，值越大耗電量越大。一樣的圖片，最亮亮度下LCD屏幕的耗電量是最暗亮度下的2～3倍[3]，所以選擇適當的亮度將能給應用程序帶來更優的省電效果；對于OLED 屏幕，不但要關注屏幕亮度，還要關注每個像素的RGB值，例如：Super AMOLED 最高亮度時全黑比全白節省電量60%[3]，所以應用程序UI界面應多采用深色調。

2.4 網絡

1)蜂窩數據

蜂窩數據組件在以下三種狀態中切換：①高功率狀態：在這個狀態下蜂窩數據需申請使用專享信道與基站進行通訊。當數據傳輸活動停止超過一個固定時間閾值時，狀態遷移至低功率狀態；②低功率狀態：在這個狀態下蜂窩組件釋放了專享信道資源，使用共享公用信道與基站進行信令通訊。這個狀態下耗電比高功率狀態低20%以上。當傳輸空閑時間超過特定閾值時，狀態遷移至空閑狀態；③空閑狀態：這個狀態下蜂窩組件只接收尋呼信息。這個狀態的功耗為高功率狀態的六十分之一。

經測試，傳輸3 秒的數據，蜂窩數據組件需要約16 秒時間才能回到耗電量最低的空閑狀態。因此，在蜂窩數據下，采用將大量碎片數據一起打包后，等待較大的時間間隔再進行依次整體傳輸的策略，將會更省電。

2)Wi-Fi

Wi-Fi 耗電需要關注2個因素：每秒發送和接收的包數(包率)和網速(通道率)。Wi-Fi組件在活動狀態下有四種模式：低功率、高功率、低傳輸、高傳輸。當Wi-Fi組件從低或高功率狀態開始傳輸數據時，短暫地進入相應的低或高傳輸狀態，發送完畢就回到之前相應的狀態。當進行高速傳輸時，Wi-Fi 組件在高傳輸狀態維持的時間非常短。

綜上，用Wi-Fi 傳輸數據時，在不超過最大傳輸單元的情況下，增大每個包的大小并降低發包的頻率能夠節省電量。

2.5 軟件系統架構

為了適應嵌入式設備省電的需要，Linux 操作系統實現了一套休眠和喚醒的機制，Android 沿用了這套機制并有新的改進。Early suspend：一種新的系統狀態。顯示器被關閉，重力感應器、觸摸屏進入掛起狀態，但是其他設備繼續工作，系統依然進行任務處理，比如掃描SD卡文件。Late resume：一種新的系統操作。喚醒進入Early suspend狀態的設備。

當系統進入休眠時，CPU 掛起，所有用戶態應用程序和內核態的進程全部被凍結，按照各個設備注冊的順序調用外圍設備的suspend 回調函數，執行每個外圍設備的suspend，使核心設備和CPU進行休眠，直到系統被某種原因喚醒才會解除。此時系統只有系統時鐘RTC(Real-Time Clock)在進行工作。

為了喚醒CPU，終端軟件需要設置鬧鐘alarm。底層系統提供了兩種類型的時鐘，軟時鐘Timer 與硬時鐘RTC。Android系統提供AlarmManager 這個API，其對應AlarmManagerServie服務程序，該服務程序在系統啟動時被啟動并初始化鬧鈴設備，一共有四種Alarm 類型：RTC_WAKEUP、RTC、ELAPSED_REALTIME_WAKEUP、ELAPSED_REALTIME[4]。

在特定使用場景下(例如：資源下載)，應用程序需要喚醒系統并且讓系統在一段時間內保持喚醒。因此，Android 系統提供了一種鎖機制，只要進程持有wake lock，系統就無法進入休眠狀態，這將會帶來較大的耗電量。所以，關注應用程序中alarm和wake lock的使用是否合理對于節省電量十分重要。

2.6 耗電的本質

目前，各種應用程序耗電量評估系統主要都是通過CPU利用率來估算每個應用程序所消耗的電量，部分系統也會根據其他硬件設備(屏幕、蜂窩數據、Wi-Fi等)使用時長來修正應用程序的耗電量。

3 移動終端App省電優化措施與案例詳析

移動終端App 電量測試是為了找出被測試的應用程序中不合理消耗電量的場景，從而進行代碼優化，達到省電的目的。省電優化需要盡可能減少對各類資源占用的時間，例如：CPU、網絡、屏幕、GPS、相機、SD 卡等。而不合理耗電的場景往往并不是在應用程序前臺操作的過程中，而是在后臺使用場景。

典型的后臺使用場景：當用戶按返回鍵或者HOME 鍵時，終端應用程序退出UI 界面，UI 主線程會停止運行。如果應用程序進程中不含service，等待3秒后，該進程會進入“緩存進程”列表，點選“顯示緩存進程”或者執行PS 命令才能看見這個進程?！熬彺孢M程”與正在運行的進程相比，僅僅是UI主線程是否運行的區別，創建出來的子線程仍然可以繼續執行，從而為后臺執行邏輯代碼進行不合理耗電帶來了可能性。以下是需要重點關注的會在后臺執行的耗電API 和對象：java.lang.Thread.new()、ThreadPool.addTask()、run()、Handler.sendMessageDelayed()、java.util.Timer、Thread.sleep、AlarmManager。

手機滅屏后進入的休眠狀態是移動終端大部分時間所處的狀態。timer 和sleep 底層都是通過線程信號量來控制調度的，用的是軟時鐘的計數器，只統計CPU 運行過的相對時間間隔，所以在手機休眠后，java.util.Timer 和Thread.sleep 會停止。但是，alarm在系統休眠后使用的是RTC的硬時鐘鬧鐘，即可以通過RTC 芯片引腳信號喚醒系統執行邏輯，所以，即使手機休眠了，AlarmManager 還是會持續工作。綜上，如果AlarmManager使用不當將會帶來終端的極大耗電。

本文將分別通過CPU、屏幕顯示和網絡三個方面的案例，對典型問題提出電量測試方法和相應優化措施，從而有效地提升App的電量方面的用戶體驗。

3.1 CPU耗電優化案例

如下為CPU 相關概念，CPU 頻率：執行相同周期個數時，CPU主頻越快，那么耗時就越短；CPU時間片：每隔N個高電頻脈沖，時鐘計數器加1，把自然時間分成固定的小塊，每一塊為一個時間片，手機一般是10ms，單位是jiffies。于是，機器時間都轉化為用時間片的個數來衡量；CPU 利用率：指CPU 執行非系統空閑進程的時間除以CPU總的執行時間。

通過CPU 利用率來估算應用程序占移動終端系統耗電的百分比是可行的，但操作應用程序時，CPU 利用率是一段比值波動的曲線，表示進程占用CPU 的百分比，不能定量地評估CPU 的具體消耗，精準度不高。電量=電流*時間，CPU 利用率高手機電流就高，但是不一定電量大，還需要看占用CPU 運行的時間長短。為了精準量化應用程序對CPU的消耗，測試人員需要固定CPU 頻率后獲取執行操作進程所占用的CPU 時間片總數。具體操作為：

首先，修改/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq的設置來固定CPU頻率；然后，電量測試開始前和結束后，通過如下命令獲得被測試的應用程序的進程在用戶態和系統態消耗的CPU時間片總數：cat/proc/1/stat。此命令會顯示進程處于用戶態的時間utime 和進程處于內核態的時間stime，單位是jiffies。最后，電量測試開始前和結束后得到的utime+stime總數相減的差值就是被測試應用程序所消耗的CPU時間片。

1)典型案例——CPU頻繁輪詢耗電的問題分析：①應用程序的線程頻繁監聽桌面事件：無論移動終端是否關閉屏幕以及應用程序是否正在被使用，線程一直在輪詢檢測棧頂task(耗時0.2秒)，每秒發出2次廣播，5個監聽者輪流去判斷棧頂task 是否為桌面(耗時1 秒)；②應用程序的線程頻繁檢測前臺服務是否活著：每5秒進行1次檢查。

2)典型案例——CPU頻繁輪詢耗電的解決辦法：①移動終端開啟屏幕且不再使用應用程序，應用程序的線程0.5s輪詢一次，棧頂發生變化再對外廣播；②移動終端開啟屏幕且正在使用應用程序，應用程序的線程30s輪詢一次，棧頂發生變化再對外廣播；③移動終端滅屏的時候停止應用程序的輪詢線程。

測試結論：在用戶退出應用程序以及移動終端滅屏的時候，停止頻繁的輪詢能大大減少電量的消耗。

3.2 屏幕顯示優化案例

Android系統的動畫性能不高，在進行Android應用程序開發時，遵循以下措施將能減少不必要的電量消耗：減少動畫的長時間展示；合理控制動畫繪制幀率，測試數據表明：動畫繪制幀率為每秒40 幀時CPU 占比50%，繪制幀率為每秒10 幀時CPU占比10%，兩者的耗電量相差1倍；僅在顯示動畫的時候才執行渲染邏輯，當移動終端滅屏或動畫消失的時候立刻停止渲染邏輯避免不必要的電量消耗；提高動畫繪制效率，減少繪制次數和單次耗時；合理選擇動畫的亮度，因為最亮亮度下LCD屏幕的耗電量是最暗亮度下的2～3 倍；合理使用暗配色動畫，因為OLED屏幕為全黑顏色比全白顏色要節電60%。

1)典型案例——播放動畫顯示耗電的問題分析：①應用程序使用了呼吸動畫效果，CPU 占用高達50%；②應用程序動畫的繪制幀率高達每秒40 幀；③應用程序只有一套較為耗電的白色系背景。

2)典型案例——播放動畫顯示耗電的解決辦法：①應用程序不使用呼吸動畫效果，采用其他樣式的動畫；②調整應用程序動畫的繪制頻率為每秒10 幀的時候，足以滿足用戶的視覺效果需求；③為應用程序增加一套暗色系背景，讓用戶可以自由選擇背景，也能進一步降低應用程序的電量消耗。

通過如上的幾種優化方法，應用程序的電量消耗大幅減少。

3.3 網絡耗電優化案例

對于Android 終端要獲取服務器上不定時更新的信息，例如：微信用戶需要及時獲得其他用戶發來的信息，通常有兩種方法：第一種是客戶端使用PULL(拉)的方式，隔一段時間就去服務器上獲取信息，看看是否有新的信息；第二種就是服務器使用PUSH(推送)的方式，當服務器端有新信息了，服務器主動把最新的信息Push 到客戶端上。相對于PUSH 方式，頻繁的PULL 方式會帶來客戶端的網絡流量和電量的過度消耗。所以，絕大部分應用程序都是采用PUSH機制。國內Android App需要實現一套PUSH 服務，一般會使用小于5 分鐘的周期發送心跳數據包與后臺云服務保持通訊鏈路[5]。這種方案意味著Android手機每天將從待機省電狀態被喚醒近300次，手機每天有15%～20%的電量被消耗在發送過度頻繁的心跳上，所以，在待機PUSH機制方面的電量優化考慮是很有必要的。

1)典型案例——待機PUSH 機制耗電的問題分析：①應用程序與后臺維持長連接等待接收push 消息；②應用程序使用sleep 方式每隔5分鐘發送1個心跳包到后臺云服務；③應用程序開啟另一個線程每5分鐘用alarm保持2分鐘wake lock。

2)典型案例——待機PUSH 機制耗電的解決辦法：①應用程序與后臺維持長連接等待接收push消息；②應用程序每隔5分鐘用alarm和wake lock給后臺云服務發送心跳包后立即釋放wake lock。

PUSH 機制優化前的耗電量明顯高于優化后，主要原因在于優化前的方案持有喚醒鎖的時間過長。綜上，結合項目實際情況，應用程序采用合理的PUSH機制能節省大量電能消耗。

4 結束語

在全民積極擁抱移動互聯網的時代，越來越多的用戶關注應用程序對電量的消耗。研發團隊不斷累積優秀開發技術的同時，測試人員也可以從移動終端的硬件和軟件系統架構分析出耗電本質，進行可靠的電量測試，并總結出電量優化措施，協助研發團隊打造精品應用程序。