如何分析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
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/48243.html
標籤：嵌入式