log 分析wakelock

【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 ”的字符串去找对应的代码