This is an article about application power consumption, focusing on Android power collection mechanism and the second generationBattery HistorianAnalysis tools. From the perspective of data collection, export, environment construction and interpretation of the report, this paper explains the whole process in detail. Different from the articles on concepts, the actual operation and analysis will be carried out here.
Overview of power statistics module
Android counts the power consumption from two levels:Software rankingandHardware ranking。 They each have their own power consumption list. The software list is the power consumption list of each app in the machine, and the hardware list is the power consumption list of each hardware. The statistics of the two rankings are independent of each other and do not interfere with each other.
**The statistics at the software level are mainly described here**
Specifically, the power consumption information can be seen intuitively in settings – > power. be careful,All power consumption statistics of Android are estimated through code, and there is no integrated circuit to report。 The accuracy depends on the power provided by the manufacturer’s ROM_ profile. XML file. Due to different manufacturers_ profile. XML accuracy and source code are different, so the data of different mobile phones and different versions may be quite different.
power_ profile. XML directly affects the accuracy of statistics, and this file cannot be modified by application. Again, Android power consumption estimation does not involve hardware, but all depends on code estimation.
power_ profile. The XML file is located in / framework / base / core / RES / RES / XML / power under the source code_ profile. XML, part of which is shown as follows:
<itemname=”radio.scanning”>0.1</item><!– cellular radio scanning for signal, ~10mA –><itemname=”gps.on”>0.1</item><!– ~50mA –><!– Current consumed by the radio at different signal strengths, when paging –><arrayname=”radio.on”><!– Strength 0 to BINS-1 –><value>0.2</value><!– ~2mA –><value>0.1</value><!– ~1mA –></array></array><!– Different CPU speeds as reported in
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state –><arrayname=”cpu.speeds”><value>400000</value><!– 400 MHz CPU speed –></array><!– Current when CPU is idle –><itemname=”cpu.idle”>0.1</item><!– Current at each CPU speed, as per ‘cpu.speeds’ –><arrayname=”cpu.active”><value>0.1</value><!– ~100mA –></array><arrayname=”wifi.batchedscan”><!– mA –><value>.0002</value><!– 1-8/hr –><value>.002</value><!– 9-64/hr –><value>.02</value><!– 65-512/hr –><value>.2</value><!– 513-4,096/hr –><value>2</value><!– 4097-/hr –></array>
This is the parameter directly involved in the calculation when making statistics at the hardware level. Both software power consumption statistics and hardware power consumption statistics are summarized through batterystatshelper. Batterystatshelper is located at / framework / base / core / Java / COM / andorid / internal / OS / batterystatshelper Java.
Software power consumption statistics
In batterystatshelper In Java, there is such a method:
In the processappusage() method, the total power consumption of an application is reflected here:
Wakelock (hold wake lock)
Radio (2G / 3G / 4G)
These data will determine the position of your application in the power consumption ranking and whether to warn users of high power consumption.These warnings may be fatal to the application, and the user may uninstall the application.
The total power consumption of the application is the sum of the above eight statistics. These eight statisticians inherit from powercalculator java
Specifically, the algorithms of the eight power consumption calculators are as follows:
The summary of power consumption statistics is described above. Generally speaking, it is not complicated. The total power consumption is obtained by aggregating the consumption in eight different ways and displayed to users.
Acquisition of power consumption data
Data collection is a unilateral act of the machine and does not need to rely on the assistance of a third party, because this is an Android system level function. But before that, we need to make some preparations. Please open developer mode in advance. USB access to the computer. Execute in the terminal:
adb shell dumpsys batterystats –enable full-wake-history
By default, wake data will not be collected, so we need to enable it. If the full amount of wake up data is not collected, the observation data cannot be well observed in the analysis stage.
Then the terminal executes:
adb shell dumpsys batterystats –reset
This command clears the information collected in history.
Finally, unplug the USB.
Finally, unplug the USB.
Finally, unplug the USB.
Say something important three times!
Now, the power consumption statistics have begun. Yes, power consumption statistics are always on and cannot be turned off: This is a system level function.
Why unplug the USB? Because if you keep plugging in USB, your data will be cleared if it is fully charged. Batterystats will only record the record after the last full charge. Therefore, it is strongly recommended to fully charge the battery first and unplug the USB power supply after completing the above operations.
Next, just like using your mobile phone every day, operate the application you want to count. The power consumption recorder will count all the power consumption of the whole machine in the background. Yes, there is no need to specify the target app in advance, and all apps will be counted. This also shows that anyone can count any installed applications. Therefore, in addition to counting their own apps, they can also be used to count competitive products.
When you think the operation is almost done, connect to USB and the terminal executes:
adb bugreport bugreport.zip
For Android 6.0 and below:
adb bugreport > bugreport.txt
bugreport. Txt is the source data that records the power consumption information of the whole mobile phone.
Finally, the terminal executes:
adb shell dumpsys batterystats –disable full-wake-history
Don’t forget to turn off full recording wake-up.Keeping it on will cause performance problems. It is recommended to keep it off unless it is in the power collection stage.
Next, set up the analysis environment: Battery historian.
Build battery historian & upload bug report
Battery historian is a power consumption analyzer produced by Google. Through the battery historian, you can visualize the exported bugreport file. In the first generation of battery historian, Google used Python as a data analysis tool. After getting the bugreport file, the visual HTML file is generated by executing Python on the terminal. This method is cumbersome to use and cannot be deployed to the server. Therefore, in the second generation of battery historian, Google chose to use the docker container. The first generation battery historian is not recommended at all. It has not been maintained for a long time, and the function is too simple.
I’m here to demonstrate the construction of MAC environment. Other operating systems are similar. Please refer to the official tutorial of battery historian.
First download docker and install it.
Start docker. Click the docker icon in the upper status bar, as shown in the figure, “docker is running” indicates successful startup.
Next, start the terminal and execute:
docker run -p 9998:9999 gcr.io/android-battery-historian:2.1 –port 9999
If you have not run this docker image before, it will be automatically downloaded and installed. 9998 port refers to the port mapped to your local port, which means that after the image is executed, the image can be accessed through 127.0.0.1:9998. You can change this port yourself. Wait for the image download to complete, and execute the previous command again. If successful, the following information will be output:
➜~docker run-p9998:9999gcr.io/android-battery-historian:2.1–port99992017/06/0410:24:13Listeningon port:9999
The 9999 port of the image has been monitored and mapped to the 9998 port of the physical machine. After the deployment of the analysis platform is completed, start uploading the bugreport file for analysis.
Now, visit 127.0.0.1:9998 and successfully open the battery historian analysis platform:
In addition to uploading a single bugreport file, it also supports uploading more analysis files. In addition, you can compare two bugreport files. This contrast function is an artifact. I won’t start here. Just upload the bugreport txt。
The effect after uploading is as follows:
Now let’s see how to use battery historian to analyze the bugreport file.
Aerial view of battery historian
Again, the bugreport file contains the health status of the whole mobile phone, not a single app, soWhen viewing the chart, pay special attention to whether the data shows the currently selected app data or the superposition of all apps。
I use wechat as my goal now. Check com tencent. mm。
Now, the first place in this chart appears. The icon data will be different before and after selecting the target package name. Before selection:
Notice the bold top app, activity manager proc, jobscheduler? After these data are selected, the chart data will become only the data of the currently selected app, while other data will still be the full data of the whole machine. If you are not careful, you can pit you many times. This is where you need to pay special attention when using battery historian for the first time. You can roughly observe the changes of data by pointing to the icon with the mouse.
Data analysis is divided into three tables, which areSystem Stats,History Stats,App Stats。 System stats and app stats are key observation and analysis objects.
System stats contains the overall overview of the machine, including how much power the whole machine consumed during this period, and all situations of all apps using wakelocks, jobscheduler, CPU, WiFi, sensors and so on.
Next is app stats. All optimizations are for the data here.
Read app stats
App stats displays the data generated by the selected package name and will not be affected by external factors.
The Misc summary section summarizes the activities of the selected app during the collection phase:
As mentioned above,
Electricity consumption accounts for 3.94% of the total consumption;
The front desk ran for 3 hours and 34 minutes;
It vibrated 8 times for 225 milliseconds;
CPU user status time: 22 minutes and 33 seconds;
Alarm wakes up 40 times.
Take a look at a specific data: check the wakelocks data area under app Stats:
Note that the display as wakerlock: XXXXXXXX is caused by confusion. This will not happen with your own development kit.
Do you remember how the app’s power consumption ranking is calculated? The above data will affect the energy consumption calculation formula mentioned at the beginning of the article.
For example, if you keep a wakepowerlock, but you don’t do anything – there’s no real power consumption, right. But because you have a lock, that’s the formula: wakelocktime * wakelockpower. Even if you don’t do anything, the Android system thinks you’re consuming power, and you’re at a loss.
Let’s take another look at alarm wake up (wakeup alarm info under app stats):
Check your own app and you may be surprised to find so many unnecessary wakeups.Wakeup alarm and scheduled job may be used by some manufacturers to detect frequent background wakeups and display this information to users.
Finally, let’s take a look at the sensor use section:
See if your own application has too many sensor calls? If not necessary, can the last GPS data be reused? All these resource consumption will be included in the energy consumption. When your app has won the power consumption list for many times, it is not far from unloading.
In most cases, the effect of optimization will be amazing. There may be some obstacles, including the conflict of product demand. Try to negotiate and communicate the cost of energy consumption.
This article is a reprint of the article:
Author: Abel_ Jia Jun