20180828 手机助手后台唤醒和Doze模式下WiFi密集唤醒

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/su749520/article/details/82147863

1.手机助手后台唤醒现象

com.qihoo.appstore 和 com.tencent.android 主要是通过JobScheduler 和 SyncManager 事件进行后台唤醒,因为之前网络静态广播、应用安装静态广播等大部分广播事件都被 google取消了,所以三方应用保活就依赖现有不受现在的机制进行定期唤醒和保活

SyncManager
Aug 21 2018
21:51:47 - 21:51:48
+6h28m12s484ms to +6h28m12s624ms
active duration: 140ms
2 occurences

SyncManager                                                                                                                 | Number of times | Total duration | Actual event times   
com.tencent.android.qqdownloader.YYBLiveAccountProvider/com.tencent.android.qqdownloader.YYBLiveAccountProvider.account/应用宝 | 1               | 140ms          | [21:51:47 - 21:51:48]
com.qihoo.appstore.account.syncprovider/com.qihoo.appstore.account/360手机助手                                                  | 1               | 16ms           | [21:51:48 - 21:51:48]

手机助手

上述中的应用唤醒问题属于正常,但是耗电曲线趋势下降快

2. 查看耗电排行榜

2.1 设备耗电

 Device's Power Estimates:
Show  entriesSearch:
Ranking Name    Uid Battery Percentage Consumed
0   UNACCOUNTED 0   30.60%
1   CELL    0   11.52%
2   SCREEN  0   5.72%
3   ROOT    0   4.08%
4   IDLE    0   4.00%
5   ANDROID_SYSTEM  1000    3.46%

2.2 应用耗电

 Sorted by Device estimated power use:
Show  entriesSearch:
Name    Uid Device estimated power use
ROOT    0   4.08%
ANDROID_SYSTEM  1000    3.46%
com.android.webview|com.ss.android.caijing.stock    10096   1.18%
com.mediatek.camera 10038   0.68%
com.tencent.android.qqdownloader    10076   0.26%
CAMERASERVER    1047    0.23%
RADIO   1001    0.16%
com.qihoo.appstore  10078   0.16%
SYSTEM_UI

上述中的设备耗电真的是大头,且应用待机中总体来说是正常的

3. 耗电唤醒源

从BugReport中看到,系统的唤醒很是密集

Kernel Overhead Time    9h52m2.384s
Kernel Wakelocks    5h20m0.952s (1.30751e+06 times)
Wakeup Reasons  9h4m13.695s (40196 times)

3.1 唤醒源

 Kernel Wakesources:
Show  entriesSearch:
Ranking Name    Duration / Hr   Count / Hr  Total Duration  Total Count
0   WLAN AHB ISR    12m5s566ms  4614.13 3h48m50.957s    87320
1   ttyC0   2m24s108ms  281.91  45m27.177s  5335
2   NETLINK 1m9s438ms   10294.30    21m54.089s  194814
3   MT6356 AuxADC wakelock  18s690ms    9667.75 5m53.71s    182957
4   WLAN TX THREAD  18s4ms  30243.88    5m40.73s    572349

3.2 唤醒原因

 Kernel Wakeup Reasons:
Show  entriesSearch:
Ranking Name    Duration / Hr   Count / Hr  Total Duration  Total Count Show Count vs Time
0   unknown 7m39s818ms  1021.06 2h25m1.811s 19323   
1   Abort:Pending Wakeup Sources: WLAN AHB ISR  15m8s690ms  902.43  4h46m36.48s 17078   
2   Abort:Last active Wakeup Source: WLAN AHB ISR   1m19s647ms  86.29   25m7.292s   1633    
3   Abort:Pending Wakeup Sources: WLAN TX THREAD WLAN AHB ISR   27s763ms    17.75   8m45.412s   336 
4   Abort:Pending Wakeup Sources: ttyC0 21s326ms    17.23   6m43.589s   326 Showing 1 to 5 of 36 entries

单纯看上述,其实只要将WiFi开关关闭,唤醒源就大幅度改善。这里的WiFi唤醒次数太严重了,在Doze模式下也是唤醒异常

4. 优化思路

有时候涉及Modem的真的很无助,明明应用层没有多大作为,底层的基础功耗就这么大,我们可以根据情况因地制宜,doze 模式下进行间断性停止WiFi的扫描,例如下面的细节现象Doze模式下WiFi密集唤醒

Doze模式下WiFi密集唤醒

猜你喜欢

转载自blog.csdn.net/su749520/article/details/82147863
今日推荐