APP耗電量測試白皮書
過去一年時間我在公司主要負責客戶端產品的質量保障工作，除了APP的自動化測試以外，還會重點關注APP的專項效能測試。現在大家對手機越來越依賴，而上面各APP的耗電量，直接影響了手機的待機時間，是使用者非常關心的一點。本文主要通過一些典型案例，介紹APP效能測試中的電量測試，並總結了我們由此引發的一些思考。
現象
APP耗電，導致電池續航能力不佳，如下圖，在小米MIX2和iPhone X機型上後臺靜默一小時各應用的耗電排行：
基本概念
相對於PC來說，移動裝置的電池電量是非常有限的，保持持久的續航能力尤為重要。另外，Android的很多特性都比較耗電（如螢幕、GPS、sensor感測器、喚醒機制、CPU、連網等的使用），我們必須要慎重檢查APP的電量使用，以免導致使用者手機耗電發熱，帶來不良體驗。
場景設計
主要的耗電場景有：
- cpu：複雜的運算邏輯、死迴圈等會直接導致CPU負載過高，會導致耗電；
- wakelock：只要有應用拿到wakelock這個鎖，系統就無法進入睡眠狀態。頻繁wakelock或者申請了wakelock沒有釋放，會導致耗電；
- wifiscan和wifilock：wifiscan和wifilock也會導致手機的wifi模組處於啟用狀態，頻繁的wifiscan或者wifilock不釋放，會導致耗電；
- sensor：感測器開啟後會導致系統持續監聽裝置外圍環境的資料變化，使用後不及時關閉，會導致耗電；
- network：大量的資料傳輸，或者長時間的行動網路資料傳輸導致radio長期處於活躍狀態，會導致耗電；
- gps：gps也是一種感測器，定位中沒有及時關閉，會導致耗電；
業務層面，使用者最核心基礎的模組：
- 新增的基礎邏輯，倘若入口明顯，潛在較大訪問，必須保證效能；
- 活動需要，因為活動上新的邏輯，存在較大的使用者訪問，需盡力提升使用者體驗；
- 反饋體驗不好的模組；
監控分析
耗電原理
1、各部件單位時耗電：各部件單位時耗電資訊儲存在power_profile.xml檔案中，如下圖（以魅族MX6為例）：
2、執行時長
電量（mAh）=各部件單位時耗電量（mA）*各部件執行時長（h）
資料獲取
測試環境
1、恢復出廠設定，排除其他APP對耗電的影響，減少干擾因素；
2、測試過程中，不出現充電情況；
3、Android 5.0 以上的裝置；
4、通過wifi連線電腦和手機；
<code>adb tcpip 5555 adb connect 192.168.1.101 （Android裝置IP地址）</code>
測試步驟
1、首先，電腦用資料線連線手機裝置，開啟裝置的開發者模式後，使用adb devices命令，能夠看到裝置線上
2、然後，預設情況下，android系統不會記錄特定應用的wakelock變化，為了依照時間順序，展示各個 wakelock的詳細資訊，需要先執行命令：
<code>adb shell dumpsys batterystats --enable full-wake-history</code>
3、接著需要重置batterystats資料：
<code>adb shell dumpsys batterystats --reset</code>
4、接下來可以拔掉資料線，在手機上對被測試app執行相應的用例進入測試場景
5、操作完成後，電腦再次連線裝置，執行命令：
<code>adb shell dumpsys batterystats > xxx.txt # 因為bugreport時間比較長，我們放到後面執行來減少與前面dumpsys的資料的偏差 Android 7.0及以上： adb bugreport bugreport.zip Android 6.0及以下： adb bugreport > bugreport.txt</code>
6、開啟Battery Historian平臺將bugreport.txt匯入, 並點選submit進行分析
案例分析
Case1：應用後臺靜默，wakelock長時間未釋放
如上圖，在一次版本的耗電量測試中發現耗電量顯著增加，通過進一步定位發現是應用中引入的某個SDK為了在後臺維持心跳使用了wakelock，而在使用者將應用切入後臺後一直持有沒有釋放，隨後經過跟對應的開發同學溝通進行了優化更改了實現方式去掉了wakelock，耗電量恢復正常。
Case2：應用後臺靜默，各種sensor持續工作
在做另外一個版本的專項測試中發現耗電量資料異常，如下圖，通過測試結果分析發現是應用在後臺駐留了51分鐘，各種感測器也同樣工作了51分鐘導致耗電量顯著增加，後經過排查確定是引入的推送SDK導致的，經過修改呼叫方式解決。
Case3：應用前臺靜默，各種sensor持續工作
通過前臺靜默（無任何操作）15分鐘，發現耗電量比上個版本高了一倍，如下圖： 應用前臺靜默期間加速度、重力、陀螺儀這三個感測器一直被使用。
跟開發溝通後確定是由於另外一個部門提供的SDK導致的，該SDK採集感測器資料的策略有問題導致會在應用啟動後一直採集造成耗電，解決方案是按照時間視窗來採集資料, 比如每次開啟APP採集5分鐘感測器資料, 然後關閉感測器資料採集。
通過標準
最佳實踐
附：iOS耗電量測試
上面主要是講的關於Android的耗電量測試方法及分析，當然思路是一樣的，關於iOS的耗電量測試由於還沒有具體的資料，這裡給出一些我調研嘗試過的一些方法：
1、系統介面
iOS 10系統內建的Setting裡可以檢視各個APP的電池消耗，系統介面能獲取到整體的電池利用率，以及充電狀態。
該方案不能檢測固定某一時間段內的電池精準消耗。
2、硬體檢測
通過硬體PowerMonitor可以精準地獲得應用的電量消耗。
步驟如下：
a. 拆開iOS裝置的外殼，找到電池後面的電源針腳
b. 連線電源監控器的裝置針腳
c. 執行應用
d. 測量電量消耗
該方案成本太高並不適合我們的測試工作。
3、軟體工具檢測
由於iOS系統的封閉性，獲取功耗資料只能通過Xcode自帶的Instruments工具實現，步驟如下：
1. 斷開iOS裝置與Mac的連線（充電時測試功耗會導致數值不準確）
2. iOS設定選項->開發者選項->Logging->Start Recording
3. 進入需要測試電量的場景操作
4. 操作完成後進入開發者選項點選Stop Recording
5. 將iOS裝置和Mac連線
6. 開啟Instruments，選擇Energy Log
7. 選擇File->Import Logged Data from Device
8. 儲存的資料以時間軸輸出到Instrument面板
該方案作為效能測試的補充方案具有較高的權威性，但輸出的資料不直觀，用於功耗測試的效果並不理想。
4、使用Battery Life進行功耗測試
該APP無需額外費用，輸出結果直觀（可得到毫安數及百分比）準確，可以嘗試使用。