I think that every Android user sooner or later there is a need to understand which application ate the entire battery overnight, while the phone was lying with the screen off. The fate of the culprit is not enviable: most often it is simply deleted. So, what can we do to make our applications use the battery minimally? In the article I will try to answer this question and talk about the approaches to reducing battery consumption that I have ever used.

Quantification

First of all, let's agree on how we will measure battery consumption, in order to monitor progress after certain corrections in the code. All that is available to us is the percentage of battery charge. And we will be guided by it. This value varies depending on many factors.
')
To reduce measurement error, it is advisable:

• use the same device;
• use the same part of the scale (the fact is that a change by one percent charge on different parts of the scale means a change by a different charge, for example, from 100% to 99% usually discharges faster than from 90% to 89%);
• Before starting a series of tests on the battery on the device, it is desirable to make a factory reset;
• restart the device before each test;
• during one test, discharge the device by more than 10% so that the measurement error is not very large;
• Do not install or run any new applications during a series of tests, they may consume battery in the background;
• Do not change the device settings: screen brightness, network settings, etc .;
• do not move the device to significant distances (more than a few meters) during the test or with each test move it along the same trajectory.

What does the battery go for?

The main consumers of the battery are:

• CPU operation;
• screen backlight;
• GPU operation;
• work with the network;
• frequent obtaining of GPS coordinates.

I think this list is familiar to many Android developers. The most interesting is the contribution of each of these points. Of course, it can be different. And here are my observations.

• CPU is often the main consumer;
• the screen backlight often goes no less than the CPU;
  It is very important not to change the brightness of the backlight during the comparative tests. Otherwise it may distort the result. For example, when I measured how the change in brightness affects battery consumption on Nexus 5, which lasted more than a year, I got the following result: changing the screen brightness from 20% to 80% increased battery consumption by 15% per hour.
• network consumption may increase significantly if the phone moves and if the cellular signal is bad;
  This is due to the cost of searching for cellular points. As in the case of the brightness of the screen, we must bear in mind that this may affect the test results.
• The effect of consumption on obtaining GPS coordinates is often enhanced by the fact that when a coordinate is updated, a callback is called in which a certain amount of code is executed.

What can we influence to reduce battery consumption by the application? In fact, not much.

• First of all, this reduction in CPU load. This is the main way to reduce battery consumption. It makes sense to profile an application for CPU usage. If possible, transfer part of the load to the GPU. This can make a significant contribution.
• Then network. It makes sense to buffer the data in order to less frequently access the network. It describes in detail how to reduce battery consumption when transferring data over the network.
• Next GPS. If an exact, frequently updated coordinate is not required, do not request it. It is worth considering the possibility of determining the coordinates of WiFi. It is well written about it.

Battery consumption profiling

We will need:

• Android device with OS 5.x and fairly new battery. If possible, it is better for him to make a factory reset.
• Profiler: github.com/google/battery-historian . It needs to be installed on the desktop and tested before the tests.

Each experiment consists of the following steps:

1. Fully charge the battery. It is important that later it was possible to compare the results of experiments with each other on the same part of the battery scale.
2. Install the application under test on the device.
3. Reboot the device. This is necessary because Otherwise, other applications running in the background may affect the result.
4. We reset battery statistics: adb shell dumpsys batterystats --reset
5. You can also enable wakelock statistics. It is disabled by default: adb shell dumpsys batterystats --enable full-wake-history
6. Do not forget to disconnect the device from the computer so that it does not charge.
7. Then, we start the tested application.
8. And we postpone the device for several hours, so that it is discharged by at least 10-15%. During the test, it is advisable not to touch the device or turn on the screen, as this may affect the result.
9. We study the data during the test.

At the last step I will stop in detail. There are two ways to study the test data. You can use the profiler, developed by Google. And you can use the UI in the Android settings.

1. battery-historian profiler
First of all, the profiler shows different UI for Android 5.x and for earlier OS versions. Moreover, the number, completeness of data and the ease of display are markedly different in favor of Android 5. On the other hand, the results of profiling an application on a battery can differ significantly if run on different versions of Android. I recommend starting profiling with Android 5, and then be sure to repeat the process on earlier versions of the OS.

2. UI in Android settings
It's simple. On the phone go to Settings -> Battery. Percentages mean how many percent of the battery is spent on each application. 100% takes everything that was spent during the test.



For example, the screen above shows that statistics are collected from approximately 10 pm to 7:30 am. During this time, the device was discharged by 72% (100% - 28%). 14% of what was discharged (ie, from 72%) went to the screen. 12% at MAPS.ME. If you click on an item in this list, you can get detailed information about the expense for the selected application. This screen also shows that consumption has increased dramatically from 6 to 7 hours. It often happens that the application actively uses Google Apps, and the charge is charged to them. This is also seen in the screenshot above. This dialog allows you to quickly understand what is happening with the application against the background of other applications and services launched by the system. And in the case of Android 4.x and earlier, it provides data that can not be obtained using the profiler.

Work with the battery-historian profiler

To begin, the profiler needs to be installed. The installation process is described in detail here . It includes:

• go installation: golang.org/doc/install
  If you set go, as suggested by default, to the $ HOME / go directory, then it is enough to set the following environment variables after installation:
  export GOPATH = $ HOME / go
  export GOBIN = $ GOPATH / bin
• protobuf installation;
• install the battery-historian profiler.

Next, we connect the device and collect information about the battery consumption since the last charge data reset (it happens if the battery is fully charged or if the command was called: adb shell dumpsys batterystats --reset):

adb bugreport > bugreport.txt 

Run the profiler:

 cd $GOPATH/src/github.com/google/battery-historian go run cmd/battery-historian/battery-historian.go 

Go to the browser at:
http: // localhost: 9999

In the window that opens, select the previously saved file bugreport.txt.

The results that you see in the browser will depend on the Android version from which bugreport.txt was downloaded. For Android 5.x, a page with a number of tabs and a wide variety of information is displayed, including statistics for each system application. General statistics of battery consumption on the device:





Application statistics:



For Android 4.x, we get this dialog. It is significantly less informative, but one can understand from it what is going on with consumption as a whole.

Application Profiling Modes

It makes sense to check in at least two modes:

• foreground app;
• application in the background.

It is desirable that the application in the background does not consume resources at all, unless there are very good reasons. In addition, it is often worthwhile to separately check how the application consumes the battery while driving. Especially if it uses GPS or is otherwise connected with the location.

Battery degradation

It is important to consider that over time, the battery charge weakens. I had a case where in six months the application began to discharge the battery one and a half times faster. The reason is battery aging. This is worth considering when testing. If the application consumed the entire battery of the device in 4 hours of work six months ago, then, most likely, now it will eat up the battery in less time. And the reason is not that something is wrong in the application.

Comparison with competitors

I want to note that the above techniques do not require access to the source code of the application. This means that you can compare how your application consumes battery compared to competitors.

Conclusion

In this article, I described the approaches to reducing battery consumption, which we use when working on MAPS.ME in Mail.Ru Group. It would be interesting to hear if someone uses some other means and technologies to solve the same problem. Write in the comments.