Troubleshoot Android app power consumption issues

1 Power consumption positioning tool and method 1-1 battery information provided by the system 1-1-1 used before Android 4.4 KitKat

adb shell dumpsys batteryinfo > d:/batterinfo.log
Get the Power log

1-1-2 used in Android 4.4 KitKat and later

• Get logs

adb shell dumpsys batterystats > d:/batterstats.log

Get a battery log you can use the command to clear records and re-record

adb shell dumpsys batterystats --enable full-wake-history
adb shell dumpsys batterystats –reset

• Analysis

Logs obtained from Android4.4 are somewhat different from the logs obtained above Android5.0, but do not affect the access to the main information; The following is an example of a log obtained above Android5.0:

Battery history
Time series of battery-related data:

0( the) Reset:time: .- ,- -- the- in- $                    0(2)099Status=discharging Health=good Plug=none temp= -volt=4218+running +wake_lock +wifi_scan +screen phone_state=off brightness=dim +wifi_running +wifi wifi_signal_strength=4wifi_suppl=completed proc=u0a501:"Com.tencent.mm:push"                    0(2)099Proc=u0a49:"Com.huawei.android.remotecontrol"                    0(2)099Proc= +:"Com.huawei.geofence"                    0(2)099Proc= +:"webviewloader-armeabi-v7a"                    0(2)099proc=u0a642:"Com.wukongtv.wukongtv:Global"                    0(2)099Proc= +:"Com.huawei.android.pushagent.PushService"                    0(2)099Proc= +:"webviewloader-arm64-v8a"                    0(2)099proc=u0a642:"Com.wukong.daemon"                    0(2)099Proc= +:"Com.huawei.powergenie"                    0(2)099Proc=u0a45:"COM.HUAWEI.ANDROID.HWOUC:HWBD"

Per-pid Stats
How long each process has been executed

  0 wake time: +21s516ms  3438 wake time: +10m38s598ms  4044 wake time: +2s286ms  4176 wake time: +2s682ms  4573 wake time: +3s825ms  8587 wake time: +3m49s32ms  4616 wake time: +12s392ms

Statistics since last charge
Data record since last charge

System starts:0, currently on battery:falseTime on Battery:6H AM theS718MS (98.8%) Realtime,2H theM WuS $MS (39.3%) uptime time on battery screen off:4H -M -S988MS (62.5%) Realtime, AM7S335MS (3.0%) uptime Total run time:6H $M AS139Ms Realtime,2H -M AS485Ms Uptime Start clock time: .- ,- -- the- in- $Screen on:2H -M $S730MS (36.8%)TenX, Interactive:2H -M $S309MS (36.8%)

Estimated power use (mAh)
At present, only a rough estimate, not as the actual consumption of data, other Google more accurate data

300014131110-1140    561    1000282    240    196    069.3    12.711.0

All partial wake locks
Wakelock in all Programs, focusing on duration and quantity

Wake Lock +Connectivityservice:3M -S310MS (4Times) Realtime Wake Lock +Dispatcher1M toS411MS ( +Times) Realtime Wake lock u0a501 Wakerlock:341975309: WuS332MS ( -Times) Realtime Wake Lock1013Audiomix: -S $MS ( -Times) Realtime Wake lock u0a623 Pushmanager: +S960MS ( -Times) Realtime Wake Lock +*alarm*:7S239MS ( theTimes) Realtime Wake Lock +Gpslocationprovider:7S2MS (4Times) Realtime Wake Lock +Audiomix:3S736MS (6Times) Realtime

Finally, the details of each application, including Wake Lock, Proc information, foreground time, CPU consumption time, service information, etc., analysis of the specific operation of an application, whether abnormal, the main can refer to this data;

1001: Wake lock Rilj: -Ms Partial (5Times) Realtime Foreground activities:1S566Ms Realtime (2Times) Foreground for:6H AM theS718Ms Proc Com.android.server.telecom:CPU: -Ms Usr + -Ms Krn;0Ms FG Proc Com.android.phone:CPU: +S960Ms Usr + -S -Ms Krn;430Ms FG APK Com.android.phone.recorder:Service com.android.phone.recorder.RecorderServer:Created for:0Ms Uptime starts:0, launches:1

1-1-3 used after Android 5.0

• Get logs

We need to start by using the following command to turn on battery data acquisition and reset:
adb shell dumpsys batterystats --enable full-wake-history
shell dumpsys batterystats –reset

Get log files by command, get a long time, wait a moment
adb bugreport > d:/bugreport.txt

• Analysis

A. Analyze with Google tools Battery-historian

After getting the Batterstats.log log, this time use our Battery-historian to generate a visual HTML report, the specific generation method reference [http://blog.csdn.net/itfootball/article/ DETAILS/44084159]

The Battery-historian tool can also analyze dumpsys batterystats logs obtained by means of

B. Battery Historian 2.0

The new version brings a lot of improvements: clearer reporting, a summary of each application, faster execution, and more.
Installation reference: [http://www.07net01.com/linux/2016/01/1207924.html]
Tip: You can download it directly on GitHub when you are unable to download it from GitHub using the GO command at the time of installation, and you will need to flip the wall to analyze the report.

Through the visualization of the report can be more intuitive to see the overall use of the phone, the use of the front-end application of various time periods, mobile phone indicators and each application independent report, from the report can be observed in the operation of the application, consumption, abnormal behavior, etc.

1-2 showing CPU usage CPU usage data

In the developer options, turn on the show CPU usage switch
Such as:

• On the right, a list of currently running processes is displayed, sorted in descending order of CPU usage, and upward indicates more CPU consumption
• Green indicates userspace consumes CPU percentage, red means kernel consumes CPU percentage, blue indicates IO interrupt consumes CPU percentage.
• The first line represents the percentage of CPU occupied by all process overlays, and the number of left to right represents Userspace,kernel,io interrupt

By observing the CPU usage of the application process, it is possible to determine whether the application is running reasonably, whether there will be an abnormal power consumption, and the application should not consume or consume very little CPU under the condition of static state.

1-3 Monitor specific processes using Android monitor

For the debug version of the application, use Android Studio's own Android Monitor tool to observe a process for that app.

By detecting the CPU, network and GPU of a process, it can be seen that the behavior of the process is abnormal in a static state, and if it is abnormal, it can be returned to the code to find out the anomaly.

1-4 using the TraceView in DDMS to locate

The TraceView tool is a parser that records the execution time of each function in the application;
Open Ddms, then select a process, then click on the "Start Method Profiling" button above (the red dot turns black to start running).
Open the page we suspect needs to be tested, sit for a moment, then click on the Start button, after a period of time (time according to your needs), click the button again to stop recording, wait a moment to appear, as follows:

The entire interface consists of the upper and lower sections, which are the timelines that each thread runs in the process you are testing, and the following are the values of each of the metrics executed by each method (including parent and child). Through the time panel can be intuitively discovered, which methods CPU consumption of more. When we select a thread above we can find the following performance panel is very complex, in fact, this is the core diagram of TraceView, it mainly shows the thread of the various methods of the call information (CPU usage time, number of calls, etc.), which is the core focus of our analysis, So let's look at a few important attribute descriptions, as follows:

Property name	meaning
Name	Method name for dispatching in thread
Incl CPU time	The CPU time occupied by the current method (which contains the sub-methods of internal dispatching);
EXCL CPU Time	The CPU time occupied by the current method (which does not include a sub-method of internal dispatching);
Incl Real time	The actual time, in MS Units, of the current method (which contains the sub-methods of internal dispatching);
EXCL Real Time	The actual time, in MS Units, of the current method (which does not contain the sub-methods of internal dispatching);
Calls+recur Calls/total	The number of times the current method was dispatched and the percentage of the total number of allocation of the recursive allocation;
CPU Time/call	The current method of allocating CPU time and allocation of the ratio, that is, the current method of averaging CPU time;
Real Time/call	The current method of dispatching the real time and the allocation of the ratio, that is, the current method average execution time-consuming;

By analyzing which methods consume a lot of CPU, whether these methods are normal consumption, we can find out the method of abnormal consumption, these methods of abnormal call is also the source of power consumption;

General TraceView can locate two types of problems:
It takes a long time to transport the method.
It takes a long time to transport a method, but the frequent dispatching results in the accumulated time.

When locating power consumption anomalies, you can open TraceView and then follow the CPU Time/call or real time/call in descending order, then open the suspicious method and its child to analyze the view, and then go back to the code positioning Check Logic optimization;

The new version of Ps:android Studio has integrated the TraceView (start Method tracing) feature in addition to the DDMS on the left side of the CPU view

The. trace file is as follows:

1-5 code-based Troubleshooting loop method

Search the code inside the timing loop execution method, consider the method of power consumption;
Includes: Timer, handler. Postdelayed, Scheduledfuturetask, Jobservice, Animation, animationdrawable, etc.

Write Log records

A Log in key places and suspicious places;
B The log is stored in a local file by process and by an hourly classification;
Like Processa-20161026090520.log, Processa-20161026100520.log.

This makes it possible to clearly observe which processes are showing signs of activity at what time periods; see if there is a looping log, or a time-consuming method, and go back to the code to see

Sub-module shielding

Block blocks, use exclusions to narrow down the scope, and eventually locate the problem

2 analysis and positioning in the process of actual troubleshooting

This is limited to the analysis of power consumption in the case of an application being used, and the performance optimization when the application is being operated. Refer to the blog http://blog.csdn.net/yanbober/article/details/48394201
For a more complex application, there will be many processes, background programs, pull live, push, and so on, need to analyze from these dimensions: (The state of the screen, the state of the screen), (mobile phone static, operation), (measured in the foreground, the background), (long time, short time)

2-1 off-screen status-applied in the background-mobile phone static

Environment: In the mobile phone screen is off, the application is tested in the background run (using the test application after the normal exit, you can apply white to prevent the system to kill the test, the phone is in the desktop state), the phone static state test, you can test short time can also put the phone for a long time to take data

Use battery Historian 2.0 + logging method to locate

If you view the application details from the report results, you can see the basic information of the application, power consumption, Wake Lock, Service, process, etc., the main analysis of Wake Lock is reasonable, the number of Service starts, the length of the operation is reasonable, There is no timely closure of the situation, the length of the process of the operation, there is no timely closure, etc.;
Combined with the logging, the specific running logic is identified, whether the logic is not stopped in time when the screen is destroyed, the complexity of the evaluation logic and the power consumption are determined.

2-2 splash screen Status-applied in the background

Environment: When the phone screen is on, the app is running in the background (after using the app under test), you can try to play other apps with your phone or stay in an app

Use the display CPU condition + Traceview to locate

Turn on the display CPU switch, in the process of using the mobile phone, observe the application of all the process is CPU consumption, CPU consumption will be in front, if a process is frequently in front of the process is suspicious, you can use TraceView to trace the suspicious process, Find out which methods consume the CPU and optimize it;

2-3 splash screen Status-applied at foreground-static

Environment: In the mobile phone screen is turned on, using the test application, stay on a page after the static (try to avoid banner, ensure the page static), observe the page (mainly used to test the application of the page is reasonable, static state should not have CPU consumption)

Use Android Monitor + Traceview to locate

Turn on Android Monitor to see the CPU, network, memory, GPU curves of each process, find the crest rule from the curve (there is no loop operation), Judge the curve rationality (is not reasonable logical operation), Unreasonable place use TraceView to trace suspicious process, find out which method consumes CPU to optimize;

The power consumption of the foreground static interface of the tested application is mainly considered two parts:

• Loop execution logic associated with the current interface
• Loop execution logic unrelated to the current interface (other interfaces have no logic or background logic to turn off)

May consider:

• You can test the desktop state of the static power consumption (background process power), the background process optimization again and optimize the foreground process;
• Ensure that the loop logic enabled in the interface is turned off after an interface exits;
• Timer, Handler. Postdelayed, Scheduledfuturetask, Jobservice, Animation, animationdrawable and so on start to pay attention to the synchronization problem, to ensure that the cycle can stop;
• There is no way, the ultimate kill Recruit: Sub-module shielding function, page, the use of exclusion method to locate the problem;

PS: welcome you to discuss, there are other good ways please @ I

Troubleshoot Android app power consumption issues