step1-找kernel层的wakelock】
(1)先搜索从wake进入sleep的过程中打印出来的当前处于活动状态的wakelock
关键字“print_active_wakeup_sources”,类似于下面这样的log:
[print_active_wakeup_sources]: activity: PowerManagerService
[print_active_wakeup_sources]: activity: syspb_149
[print_active_wakeup_sources]: activity: EINT wakelock
如果没有这样的log,可以把所有申请wakelock的代码搜出来,关键字“ws activate->”
(2)然后往下搜索有没有这些wakelock释放的位置
关键字“ws deactivate->”类似如下log:
ws deactivate-> PowerManagerService
ws deactivate-> EINT wakelock
(3)那会出项两种情况
a. 根本没有找到释放某个wakelock的log
那就可以确实是这个wakelock导致(比如上面的syspb_149)
b. 有找到释放的log,但是中间间隔时间很长
这个就要看时间戳了,所以把申请释放的时间戳相减就是真实的wakelock锁住的时长
(4)找到wakelock后,要做的就是去检查wakelock的使用者
a. 如果发现出问题的不是PowerManagerService的wakelock,那么就直接找对应的驱动代码就行了
b. 如果是,就要继续看main log
【step2-找user层的wakelock】
(1)找到所有上层的wakelock申请的log
关键字“acquireWakeLockInternal”,会搜出来很多,类似下面的log:
acquireWakeLockInternal: lock=1131418552, flags=0x1, tag="GSM", ws=null, uid=1001, pid=696
acquireWakeLockInternal: lock=1131101696, flags=0x1, tag="RILJ", ws=null, uid=1001, pid=696
acquireWakeLockInternal: lock=1130767880, flags=0x20, tag="PhoneGlobals", ws=null, uid=1001, pid=696
但是不要担心,一般像 RILJ / ActivityManager / AlarmManager申请释放很频繁的就不用理会;flag的bit0不为1的也不用理会(bit0标识锁住底层不进sleep;但是有个例外,就是Psensor对应的wakelock,flags为0x20,在早期JB版本也会锁住底层)
(2)找到这些wakelock释放的log
关键字“releaseWakeLockInternal”,但是你可能只能看到下面这样的log:
releaseWakeLockInternal: lock=1131101696, flags=0x0
releaseWakeLockInternal: lock=1131418552, flags=0x0
releaseWakeLockInternal: lock=1130767880, flags=0x1(这个flag为1表示waitForNegativeProximity)
跟acquire的log的对应关系就是看lock=后面的整数值,就知道wakelock是在哪个时间点释放的了,两个时间戳相减就是锁住的时间,抓住wakelock时间不长的就可以忽略,找到那个长时间锁住的wakelock就是系统无法休眠的罪魁祸首
(3)找到wakelock后,就根据“tag”的字符串去找对应的代码