【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，那么就直接找对应的mtk2503驱动代码就行了
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”的字符串去找对应的代码