1. Wake up phenomenon of mobile assistant in the background
com.qihoo.appstore and com.tencent.android mainly wake up in the background through JobScheduler and SyncManager events. Because most of the previous broadcast events, such as network static broadcast and application installation static broadcast, have been canceled by google, so the three-party application maintenance relies on the existing mechanism that is not affected by the present to regularly wake up and maintain the life
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/Application treasure | 1 | 140ms | [21:51:47 - 21:51:48]
com.qihoo.appstore.account.syncprovider/com.qihoo.appstore.account/360Mobile assistant | 1 | 16ms | [21:51:48 - 21:51:48]
The above application wake-up problem is normal, but the power consumption curve is declining rapidly
2. View the power consumption ranking
2.1 power consumption of equipment
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 application power consumption
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_UIThe power consumption of the above equipment is really large, and the application standby is generally normal
3. Power consumption wake-up source
From BugReport, we can see that the wake-up of the system is very intensive
Kernel Overhead Time 9h52m2.384s
Kernel Wakelocks 5h20m0.952s (1.30751e+06 times)
Wakeup Reasons 9h4m13.695s (40196 times)3.1 wake up source
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 5723493.2 wake up reason
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 entriesSimply look at the above, in fact, as long as the WiFi switch is turned off, the wake-up source will be greatly improved. The number of WiFi wakes here is too serious. It is also wakeup abnormal in Doze mode
4. Optimization ideas
Sometimes when it comes to Modem, it's really helpless. Obviously, the application layer doesn't do much, and the underlying basic power consumption is so large. We can stop WiFi scanning intermittently according to the situation and local conditions. For example, the following detail phenomenon, WiFi intensive wake-up in the Doze mode
