Android功耗優化（7）---如何分析wakelock（wakeup source）持鎖問題

如何分析wakelock（wakeup source）持鎖問題

鎖通常分爲：APP透過PowerManager拿鎖，以及kernel wakelock.

分析上層持鎖的問題：

目前PowerManagerService的log 默認不會打開，能夠經過修改：

frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java

private static final boolean DEBUG = true;
    private static final boolean DEBUG_SPEW = DEBUG && false;
修改成:
    private static final boolean DEBUG = true;
    private static final boolean DEBUG_SPEW = true;
打開上層的log

經過syslog：搜索關鍵字：total_time=來肯定持鎖的時間.

PowerManagerService: releaseWakeLockInternal: lock=31602562 [*job*/DownloadManager:com.android.providers.downloads], flags=0x0, total_time=600051ms

或者經過正則表達式：total_time=[\d]{4,}ms 過濾出持鎖時間比較長的鎖.

PowerManagerService: releaseWakeLockInternal: lock=31602562 [*job*/DownloadManager:com.android.providers.downloads], flags=0x0, total_time=600051ms
PowerManagerService: releaseWakeLockInternal: lock=56317918 [*job*/DownloadManager:com.android.providers.downloads], flags=0x0, total_time=283062ms
PowerManagerService: releaseWakeLockInternal: lock=216012597 [AudioMix], flags=0x0, total_time=120003ms
PowerManagerService: releaseWakeLockInternal: lock=41036921 [AudioMix], flags=0x0, total_time=167984ms
PowerManagerService: releaseWakeLockInternal: lock=70859243 [GsmInboundSmsHandler], flags=0x0, total_time=3206ms
PowerManagerService: releaseWakeLockInternal: lock=242046348 [AudioMix], flags=0x0, total_time=122205ms

kernel的鎖默認不會打印出來，通常是待機結束後經過節點來獲取：

adb shell cat /sys/kernel/debug/wakeup_sources > wakeup_sources.log

• active_count:對應wakeup source被激活的次數.
• event_count:被信號喚醒的次數
• wakeup_count:停止suspend的次數.
• expire_count:對應wakeup source超時的次數.
• active_since:上一次還活躍的時間點.時間單位跟kernel log前綴時間是同樣(kernel單調遞增時間).
• total_time:對應wakeup source活躍的總時長.
• max_time:對應的wakeup source持續活躍最長的一次時間.
• last_change:上一次wakeup source變化的時間(從持鎖到釋放or釋放到持鎖)，時間單位跟kernel log前綴時間是同樣(kernel單調遞增時間).
• prevent_suspend_time:對應wakeup source阻止進入autosleep的總累加時間.

通常狀況下:

若是是復現機，前面沒有捉log，也沒有dump log，只有一份wakeup_sources.log

能夠看下prevent_suspend_time，通常時間越大越多是阻止系統進入suspend的wakeup sources.

若是測試先後，都有捉 wakeup_sources.log 請對兩份wakeup_sources.log的total time的差值.

差值時間跟滅屏的時間對得上，通常就是這個鎖引發的問題.

把捉出來的wakeup_sources.log複製到excel表格中，比較好對齊，一個是比較好計算.

其中dispsys_wakelock total_time的時間有697614mS 也就是總共有697s.

或者在待機測試結束後經過命令：

adb bugreport > bugreport.txt

搜索關鍵：

底層的鎖：

All kernel wake locks: 
Kernel Wake lock ttyC0 : 1h 33m 15s 668ms (3856 times) realtime 
Kernel Wake lock radio-interface: 1h 20m 56s 210ms (3995 times) realtime 
Kernel Wake lock ccci3_at : 1h 9m 43s 491ms (2932 times) realtime 
Kernel Wake lock ccci_fs : 1h 0m 52s 818ms (3432 times) realtime 
Kernel Wake lock ccci3_at2 : 41m 16s 938ms (2465 times) realtime

上層的鎖：

All partial wake locks: 
Wake lock 1001 RILJ: 5m 29s 768ms (13118 times) realtime 
Wake lock 1000 *alarm*: 4m 7s 823ms (2330 times) realtime 
Wake lock 1000 ConnectivityService: 59s 513ms (1 times) realtime 
Wake lock u0a111 *alarm*: 50s 334ms (751 times) realtime 
Wake lock u0a111 WakerLock:999603354: 28s 655ms (125 times) realtime 
Wake lock 1000 NetworkStats: 11s 434ms (569 times) realtime