性能優化6--電量優化
1、 電量測試
Android4.1版本之后在系統增加了battery info模塊,記錄一定時間周期內整機及單個App的電量消耗。
2.1 注冊廣播
ACTION_BATTERY_CHANGED
IntentFilter filter = new IntentFilter(); filter.addAction(Intent.ACTION_BATTERY_CHANGED); registerReceiver(filter,receiver);
然后就可以獲取電池電量、充電狀態、電池狀態等信息。具體參考BatteryManager。
缺點:
①獲取到的是手機整體的耗電量,而不是特定App的耗電量;
②實時性差,精度較低,只能接受被動通知電量余量以及跳變。
2.2 Battery Historian
最強大、最推薦的工具:Battery Historian是Android5.0之后Google開源的一款用于檢測與電池有關的信息和事件的工具,從設備中收集電池數據,然后使用Battery Historian可以可視化分析相關指標如耗電比例、Wifi、蜂窩數據量、WakeLock喚醒次數。隨著Android6.0更新了Battery Historian 2.0加入引起手機狀態變化的應用。
通過Battery Historian可以方便的看到各耗電模塊隨著時間的耗電情況:包含操作類型、執行時間、對應App等;還可以進行篩選特定的App,給出一個總結性的說明,包括:Network Information、 Syncs、WakeLock、Services、Process info、Scheduled Job、Sensor Use等,查看每一個模塊的總結,可以看出來每一項的耗時以及執行次數。當發現異常的時候可以針對性的進行排查。總之:Battery Historian真的很強大。
adb命令導出電量信息:
adb shell dumpsys batterystats --reset(Android4.1到4.3 adb shell dumpsys batteryinfo) adb bugreport > bugreport.txt(Android7.0以上 adb bugreport bugreport.zip)
安裝Battery Historian后打開:http: //localhost:9999/, 上傳bugreport.txt文件開始分析,下圖分析360手機助手為例;


安裝過程可以參考Github:battery-historian。備注:我使用Docker的方式并沒有執行成功,通過Go的方式完成的。
2、 電量優化
Android系統上App的電量消耗主要由cpu、wakelock、數據傳輸(流量和wifi)、wifi運行、gps、other senior組成,而耗電異常也是由于這幾個模塊的使用不當。
2.1 CPU時間片優化
當檢測到CPU時間片消耗異常時,需要使用TraceView,獲取進程執行信息,定位CPU占用率異常的問題,關于CPU的使用可以參照《Android性能優化(一)之啟動加速35%
》一文。
2.2 網絡傳輸
通常情況下,使用3G移動網絡傳輸數據,電量的消耗有三種狀態:
Full power: 能量最高的狀態,移動網絡連接被激活,允許設備以最大的傳輸速率進行操作。
Low power: 一種中間狀態,對電量的消耗差不多是Full power狀態下的50%。
Standby: 最低的狀態,沒有數據連接需要傳輸,電量消耗最少。
2.2.1 數據壓縮
通過數據壓縮等方式縮減傳輸時間,降低電量消耗,此章節可以參考《Android 性能優化(八)之網絡優化》。
2.2.2 選擇更快的傳輸方式
雖然3G芯片比Wifi芯片耗電低,但Wifi的速率可以讓數據在較短時間內完成傳輸,從而降低電量消耗。
2.2.3 請求集中發送
分析和統計之類的非重要操作,可以在合適狀態(電量充足或Wifi狀態)下發送。參見3.6節JobScheduler。
2.2.4 無網狀態避免網絡請求
之前在網絡優化的文章里寫過,網絡請求失敗之后的重試機制,但是要注意這個重試是在有網狀態下的重試。否則無網狀態下重試不會請求成功,只會消耗電量。尤其是與AlarmManager或者WakeLock連用的場景下,耗電量會更多。
2.3 GPS
定位是App中常用的功能,但是定位不能千篇一律,不同的場景以及不同類型的App對定位更加需要個性化的區分。
2.3.1 選擇合適的Location Provider
Android系統支持多個Location Provider:
GPS定位,利用GPS芯片通過衛星獲得自己的位置信息。定位精準度高,一般在10米左右,耗電量大;但是在室內,GPS定位基本沒用。
II. NETWORK_PROVIDER:
網絡定位,利用手機基站和WIFI節點的地址來大致定位位置,這種定位方式取決于服務器,即取決于將基站或WIF節點信息翻譯成位置信息的服務器的能力。
III. PASSIVE_PROVIDER:
被動定位,就是用現成的,當其他應用使用定位更新了定位信息,系統會保存下來,該應用接收到消息后直接讀取就可以了。比如如果系統中已經安裝了百度地圖,高德地圖(室內可以實現精確定位),你只要使用它們定位過后,再使用這種方法在你的程序肯定是可以拿到比較精確的定位信息。
例如你的App只是需要一個粗略的定位那么就不需要使用GPS進行定位,既耗費電量,定位的耗時也久。
在獲取到定位之后或者程序處于后臺時,注銷定位監聽,此時監聽GPS傳感器相當于執行no-op(無操作指令),用戶不會有感知但是卻耗電。
2.3.3 多模塊使用定位盡量復用
多個模塊使用定位,盡量復用上一次的結果,而不是都重新走定位的過程,節省電量損耗;例如:在應用啟動的時候獲取一次定位,保存結果,之后再用到定位的地方都直接去取。
2.4 謹慎使用WakeLock
Android為了節省電量,會在用戶無操作一段時間之后進入休眠狀態。Wake Lock是一種鎖的機制,只要有人拿著這個鎖,系統就無法進入休眠。一些App為了能在后臺持續做事情,就會持有一個WakeLock,那么手機就不會進入休眠狀態,App要做的事情能做了,但是也更加耗電。
v1:App在前臺不要申請WakeLock,此時無需申請,申請的話會計算到應用電量消耗;
v2:App在后臺由于業務需要必須要申請WakeLock時使用帶有超時參數的方法,防止由于忘記或者異常情況下沒有釋放;
v3:App申請使用WakeLock,任務結束之后及時釋放,讓系統再次進入休眠狀態。
PowerManager pm = (PowerManager)mContext.getSystemService(Context.POWER_SERVICE); PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK| PowerManager.ON_AFTER_RELEASE,TAG); wl.acquire(TIMEOUT);// 使用帶有超時參數的acquire方法 // ... do work... wl.release();
備注:如果只是需要屏幕常亮的話,可以使用FLAG_KEEP_SCREEN_ON,無需考慮釋放WakeLock的問題。
2.5 傳感器使用
①使用傳感器,選擇合適的采樣率,越高的采樣率類型則越費電;
SENSOR_DELAY_NOMAL (200000微秒)
SENSOR_DELAY_UI (60000微秒)
SENSOR_DELAY_GAME (20000微秒)
SENSOR_DELAY_FASTEST (0微秒)
②在后臺時注意及時注銷傳感器監聽;
2.6 JobScheduler
使用JobScheduler,一些任務通過JobScheduler來觸發,例如可推遲的網絡請求、下載、GPS等,可以在特定場景:連接Wifi、連接電源等場景觸發。既完成了任務,也無需考慮由于一些任務導致的電量消耗。
3、 后記
4.1 電量優化的一般套路
在設置-電量里查看App的耗電情況;
使用Battery Historian進行分析,這是分析里最重要的一步;
針對分析結果,參照第三章節的優化方式進行優化。
4.2 Android系統費電嗎?
一直有一種傳言:Android系統比較費電,然而真相不是這樣,請不要把鍋甩給Android系統:
①原生的Android手機其實并不耗電,不安裝App的Android手機放置一周仍然是電量充足,而且對功耗的控制在Android每次版本更新都會有所補強。
②耗電的原因在于手機ROM以及安裝的軟件,手機ROM會針對原生的Android做各種各樣的定制(免費贈送各種“親情軟件”,各種系統級應用)。安裝軟件的開發者不考慮電量損耗,以及都希望千方百計占用系統資源(例如保活、互拉)等。
電量優化可以說是開發者和QA最不關注的一個方面了,但是如果任而由之,變成“電量殺手”不僅僅是傷害用戶的體驗,也是對自己的放縱。性能問題不僅僅在于發現之后的優化更改,更在平時的防微杜漸。
浙公網安備 33010602011771號