騰訊視頻國際版（Android）電量測試方法研究與總結

本文由雲+社區發表

做者：騰訊移動品質中心TMQ

一、研究背景：

在2017年Google I/O大會上，Google發佈了Google Play管理中心的新功能：Android vitals。當app在大量設備上運行時，Android vitals會收集與應用性能相關的各類匿名數據，好比：與app穩定性相關的數據、app啓動時間、電量使用狀況、渲染時間以及權限遭拒等等，這些數據會被分析整理後展現在Google Play管理中心的Android vitals dashboard中。Android vitals 中須要開發者重點關注的核心指標有：crash率、ANR率、excessive wakeups（過渡喚醒）、stuck wake locks（喚醒鎖定卡住）。其餘指標，需根據應用類型選擇性關注（Android vitals中的指標總覽見圖1-1）。若app某些指標表現不好，會影響用戶體驗，而且會致使應用在Google Play商店中的等級很低、排名靠後（APP指標異常示例圖見圖1-2）。開發者能夠經過分析Android vitals中提供的一些參照指標，採起相應的措施來優化app。

圖1-1 Android vitals平臺檢測指標總覽

圖1-2 某APP指標異常示例圖

二、核心指標詳細信息：

要對APP的指標進行監控，首先要明確該指標在Android vitals中是如何進行統計的，這一節主要介紹電量相關核心指標的基本概念和計算方式。

2.1 Stuck partial wake locks（部分喚醒鎖定卡住）

A.WakeLock（喚醒鎖）基本概念：

Android系統自己爲了優化電量的使用，會在沒有操做時進入休眠狀態, 來節省電量。爲了便於開發(不少應用不可避免的但願在滅屏後還能運行一些事兒，或是要保持屏幕一直亮着--好比播放視頻)，Android提供了一個PowerManager.WakeLock的東西。咱們能夠用WakeLock來保持CPU運行，或是防止屏幕變暗/關閉，讓手機能夠在用戶不操做時依然能夠作一些事兒。然而，獲取WakeLock很容易，釋放很差就會成爲難題，消耗電量。

例如咱們獲取了一個WakeLock來保持CPU運轉，作一個複雜運算並將數據上傳到後臺服務器, 而後釋放該WakeLock。然而這個過程可能並不像咱們想象的那麼快，可能由於好比服務器掛掉，計算出了異常等等WakeLock沒有釋放。問題就來了，CPU會一直得不到休眠，而大大增長耗電。

喚醒鎖可劃分爲並識別四種用戶喚醒鎖：

自 API 等級 17 開始，FULL_WAKE_LOCK 將被棄用。應用應使用FLAG_KEEP_SCREEN_ON。

相關連接：developer.android.com/reference/a…

B.Partial wake locks（部分喚醒鎖）：

部分喚醒鎖可確保CPU正常運行，但屏幕和鍵盤背光能夠關閉。若是運行在後臺的APP長時間持有某個部分喚醒鎖，就致使部分喚醒鎖卡住。這種狀況十分消耗設備電量，由於它會阻止設備進入低電量狀態。Android vitals重點關注了stuck partial wake locks這項指標，當你的APP存在喚醒鎖定卡住的現象時，它會經過Play管理中心給出告警（APP出現部分喚醒鎖定卡住示例圖見圖2-1），並從各個維度給出相關的詳細統計圖（如圖2-2中給出每一個工做時段後臺wake lock最長持續時間分佈圖）。當出現如下狀況時，Android vitals會報告喚醒鎖定卡住：

1. 至少70%以上的battery sessions發生過至少一次、長達一小時以上的部分喚醒鎖定。
2. 當只在後臺運行時，至少10%以上的battery sessions發生過至少一次、長達一小時以上的部分喚醒鎖定。

（ps：battery session指兩次電池充滿電之間的時間間隔，Android vitals展現的battery sessions是全部app測試用戶的battery session合計。）

相關連接：developer.android.google.cn/topic/perfo…

圖2-1 某APP出現部分喚醒鎖定卡住（後臺）示例圖

圖2-2 每一個工做時段後臺wake lock最長持續時間的分佈圖

2.2 Excessive wakeups（過渡喚醒）

A.Wakeups 基本概念

Wakeups 是AlarmManager API中的一種機制，開發者能夠設置一個alarm在特定的時間來喚醒設備。當某個喚醒alarm觸發，設備會走出低電量模式，在執行alarm的onRecieve（）或onAlarm（）方法的時候，Alarm Manager會持有一個部分喚醒鎖。若是wake alarms頻繁觸發，會耗盡設備電量。Android vitals中展現了app的過渡喚醒次數。

Alarm有如下四種類型：

1)RTC_WAKEUP

在指定的時刻（設置Alarm的時候），喚醒設備來觸發Intent。

2)RTC

在一個顯式的時間觸發Intent，但不喚醒設備。

3)ELAPSED_REALTIME

從設備啓動後，若是流逝的時間達到總時間，那麼觸發Intent，但不喚醒設備。流逝的時間包括設備睡眠的任什麼時候間。注意一點的是，時間流逝的計算點是自從它最後一次啓動算起。

4)ELAPSED_REALTIME_WAKEUP

從設備啓動後，達到流逝的總時間後，若是須要將喚醒設備並觸發Intent。

在Android vitals中只列出了RTC_WAKEUP和ELAPSED_REALTIME_WAKEUP兩種類型的喚醒數據，Google會統計每小時發生10次以上wakeup的電池工做時段百分比（APP發生過渡喚醒示例見圖2-3）。分別從應用版本、wakeup標記、設備、Android版本等幾個維度統計每小時的Alarm Manager wakeup次數（每一個工做時段中每小時的wackup分佈圖見圖2-4）。

圖2-3 某APP發生過渡喚醒示例圖

圖2-4 每一個工做時段每小時wakeup次數分佈圖

三、測試方法研究

3.1 傳統電量測試方法回顧

咱們以前也對騰訊視頻主線版本進行過電量測試，以前關注的重點在於APP在各場景中耗電量是否正常，是從比較宏觀的角度去進行測試的，採起的測試方法主要是物理儀器測試法和GT測試法。

A.物理儀器測試法（電流表等）

在保持電壓恆定的狀況下，獲取各場景平均電流值來統計系統耗電狀況，經過此方法能夠從大致上看出APP電量消耗是否正常，若儀器精度大，此方法測出的電量值是最準確的。

缺陷：此方法只能測試整個手機的電流，不能區分APP，受影響的因素多，如屏幕亮度大小、音量大小等等，要保證每次測試的環境徹底一致是不可能的。

圖3-1 物理儀器測電量

B.GT測試法

GT（隨身調）是由MIG專項測試組自主研發的APP隨身調測平臺，它是直接運行在手機上的「集成調測環境」(IDTE, Integrated Debug Environment)。利用GT，僅憑一部手機，無需鏈接電腦，您便可對APP進行快速的性能測試(CPU、內存、流量、電量、幀率/流暢度等等)、開發日誌的查看、Crash日誌查看、網絡數據包的抓取、APP內部參數的調試、真機代碼耗時統計等。

經過GT，能夠採集手機耗電量相關數據：電流、電壓、電量、溫度等，經過分析這些數據，能夠對整個手機的電量使用狀況進行分析。

缺點：和物理儀器測試方法同樣，採用GT測試也只能獲取到整個手機的電量數據，沒法只關注單獨APP，且受各類因素影響較大。

3.2 國際版電量測試方法預研

因爲國際版APP在Google Play上發佈，咱們作電量測試不只僅須要關注整個APP的電量使用狀況是否正常，還須要關注APP持有 wack lock和使用alarm的狀況。所以，傳統的電量測試方法已經沒法知足咱們的需求，咱們須要在此基礎上增長額外的測試方法。

A.Batterystats/ bugreport

Android5.0後，電量數據可經過dumpsys batterystats獲取。Android系通通計耗電量的基本公式是W=UIt。在手機中，U通常恆定不變，所以能夠單獨經過Q（電容量）=I*t來表示電量。核心類BatterStatsImpl提供App各部件運行時間、PowerProfile提供部件電流數值。Android部件電流信息存於：power_profile.xml文件中，每一個OEM廠商都有私有的power_profile.xml文件，PowerProfile經過讀取該文件獲取訪問部件電流數值（圖3-3是samsung某型號的power_profile.xml）。Android系統以uid爲單位，依次統計每一個apk的使用cpu使用耗電量、wake lock耗電量、移動數據耗電量、wifi數據耗電量、wifi維持耗電量、wifi掃描耗電量、各傳感器耗電量。其中wake lock消耗的電量只統計了持有Partial wake lock的耗電量，正好是咱們須要關注的喚醒類型，所以咱們能夠經過分析batterystats得到的電量數據來測試app持有Partial wake lock狀況。

Android爲了方便開發人員分析整個系統平臺和某個app在運行一段時間以內的全部信息，專門開發了bugreport工具。bugreport文件中記錄了系統容許過程當中的各類log信息，其中也包括了耗電量信息。經過分析bugreport中的電量相關數據也能獲取APP持有Partial wake lock的信息。

ps：Uid與App關係：2個App簽名和sharedUserId相同，則在運行時，他們擁有相同Uid。就是說processAppUsage統計的多是多個App的耗電量數據，對於普通App，出現這種狀況的概率較少，而對於Android系統應用則較爲常見。

圖3-2 wack lock耗電量計算源代碼

圖3-3 sumsung某型號power_profile.xml

數據準備：

• 先斷開adb服務，而後開啓adb服務。

(1)adb kill-server

(2)adb start-server

因爲開發時作電量記錄時會打開不少可能形成衝突的東西，爲了保險起見，重啓adb命令。

• 重置電池數據、收集數據

(3) adb shell dumpsys batterystats --enable full-wake-history

(4) adb shell dumpsys batterystats --reset

(5) adb shell logcat -c

經過以上命令來打開電池數據的獲取以及重置，清除干擾的數據，清除歷史日誌。

• 獲取電量報告

把數據線拔掉，防止數據線形成充放電數據干擾。而後作一些測試的case，通過一段時間後，從新鏈接手機確認adb連上了，運行如下命令來將bugreport的信息保存到txt文件中。

(6) adb bugreport >D:/bugreport.txt

或者用下面的命令也能夠，官網上記述的內容，經實踐，沒法被讀取…

(7) adb shell dumpsys batterystats > batterystats.txt

(8) adb shell dumpsys batterystats > com.example.app(包名) >batterystats.txt

ps：在此注意必定要等到該條命令執行完(稍微會有些慢)後，再打開bugreport.txt文件，以前遇到過沒有導出完，就點開，信息缺失的狀況，致使沒法成功生成圖表。

B.battery historian

生成的bugreport文件有的時候異常龐大，可以達到15M+，想想對於一個txt文本格式的文件內容長度達到了15M+是一個什麼概念，若是使用文本工具打開查看將是一個噩夢。所以google針對android 5.0（api 21）以上的系統開發了一個叫作battery historian的分析工具，這個工具就是用來解析這個txt文本文件，而後使用web圖形的形式展示出來，這樣出來的效果更加人性化，更加可讀。咱們可使用該工具對bugreport文件進行解析，更輕鬆的獲取電量相關數據。

battery historian的安裝能夠參考如下連接：

github.com/google/batt…

developer.android.com/studio/prof…

也能夠直接使用在線版本：

bathist.ef.lc/

數據分析：

（1）選擇騰訊視頻app

（2）Wacklocks表格中展現app持有的wacklock，持有時間及數量，經過這個表格咱們能夠看到咱們APP是否有持有一小時以上的wack_lock。

（3）Wakeup alarm info表格中展現了APP運行過程當中觸發的wakeup alarm名字和個數，經過該分析工具也能夠統計app的鬧鐘喚醒次數。

C.QAPM

QAPM是SNG開發的致力於解放專項測試人員的工具平臺，該平臺帶有電量監控功能，在電量個例菜單中會統計前臺30分鐘、後臺5分鐘兩個場景下的wacklock持有信息。該平臺上的數據能夠做爲咱們電量測試的參考對象，具體的統計方法還需後續深刻了解。

D.dumpsys命令

Android提供的dumpsys工具可以用於查看感興趣的系統服務信息與狀態，手機鏈接電腦後可以直接命令行運行adb shell dumpsys 查看電池、電量相關信息。

• adb shell dumpsys power

經過該條命令能夠看到手機中全部的wack_lock持有信息

• adb shell dumpsys alarm

此命令會提供設備上的alarm系統服務相關信息。其中Alarm Stats列出了應用設置alarm的狀況，其中有系統被該應用全部alarm消耗的時間以及被鬧鐘喚醒的次數。能夠經過獲取一小時內的電量數據來分析用戶在每小時的喚醒次數。

相關連接：blog.csdn.net/memoryjs/ar…

該方法與經過burgreport文件統計電量信息相似，都是經過Android系統中提供的工具來輸出電量的消耗狀況，且該種方式輸出的報告也比較複雜，可讀性查，可在測試過程當中做爲參考。

四、國際版電量測試方法總結與實踐

4.1 測試方法總結

1. 根據上一節的測試方法研究，咱們打算首先用GT測試各個場景中APP電量消耗是否有異常。
2. 接下來採用battery historian分析工具對手機裏獲取的bugreport文件進行分析，統計app中持有超過一小時的wack_lock和一小時內發生的wackup數。
3. QAPM中採集到的數據做爲咱們的輔助分析數據，咱們能夠比較兩份數據，看咱們經過battery historian統計的wack_lock數據是否準確。
4. 咱們也能夠經過使用dumpsys命令，查看app電量相關信息做爲測試輔助方法。

4.2 測試方法實踐

騰訊視頻國際版1.0.0已經發布，咱們已經使用該方法對其進行了一次電量測試，具體測試過程以下：

A.GT測試：

測試場景：啓動-播放-前臺靜置

測試機器：nexus

測試結果分析：

1. 從如下電流趨勢變化圖中能夠看出，播放過程和前臺靜置過程，電流曲線平穩，無較大波動，無明顯異常。
2. 從播放到退出播放前臺靜置，使用電流明顯變小，符合預期。

B.Battery Historian測試：

測試場景：

1. app前臺靜置2小時
2. app後臺靜置2小時
3. 全屏播放2小時

測試型號：

• Y7 Pro 2018 （LDN-LX2）
• OPPO F7 （CPH1819）

測試結果分析：

1. 三個場景中，僅播放場景下會持有WindowManager這個wakelock超過1小時以上。而Android Vitals中關注的是app運行在後臺時，長時間持有部分喚醒鎖的狀況，播放這個場景能夠排除在外，所以得出結論，國際版APP持有喚醒鎖狀況正常。

場景	機型	持有1小時以上的wack lock
app前臺	華爲Y7 Pro 2018 （LDN-LX2）	無
OPPO F7 （CPH1819）	無
app後臺	華爲Y7 Pro 2018 （LDN-LX2）	無
OPPO F7 （CPH1819）	無
全屏播放	華爲Y7 Pro 2018 （LDN-LX2）	WindowManager
OPPO F7 （CPH1819）	WindowManager

\2. 測試過程當中沒有統計到alarm數據，說明國際版APP暫時沒有使用到AlarmManager定時任務。

C.測試結論：

1. GT電流測試顯示國際版APP各應用場景電量使用狀況正常。

場景	啓動APP	播放	退出播放，前臺靜置
結論	啓動過程需加載圖片等資源，電流較大，正常	播放過程電流平穩無異常	退出播放電流變小，靜置過程平穩無異常

\2. Battery Historian分析電量數據得出，前臺靜置、後臺靜置、播放三個場景中僅播放場景會持有wack lock1小時以上，不屬於Android Vitals統計範疇，不會影響到國際版APP在Google Play商店的排名。

場景	機型	stuck wake locks	excessive wakeups	結論
前臺靜置	華爲Y7 Pro	無喚醒鎖定卡住	無過渡喚醒	正常
OPPO F7	無喚醒鎖定卡住	無過渡喚醒	正常
後臺靜置	華爲Y7 Pro	無喚醒鎖定卡住	無過渡喚醒	正常
OPPO F7	無喚醒鎖定卡住	無過渡喚醒	正常
播放	華爲Y7 Pro	持有喚醒鎖1小時以上	無過渡喚醒	正常
OPPO F7	持有喚醒鎖1小時以上	無過渡喚醒	正常

五、總結與展望

因爲騰訊視頻國際版目前功能比較少，用到wack_lock和alarm的狀況比較少，咱們只測試了前臺靜置、後臺靜置、播放三個場景，電量測試的結果也顯示APP電量使用狀況正常，無部分喚醒鎖定卡住和過渡喚醒的狀況出現，後續國際版功能會日漸豐富，可能須要補充push、下載等測試場景，持有wack_lock和alarm的狀況也會更加複雜，所以咱們會根據實際狀況不斷改進和完善咱們的電量測試方法。

此文已由騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨，能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號