Impact of HTTP requests on battery life

I have a project in which a client application, probably on an Android device, will request some files from the server. One of the implementations is to have batch transfers from the server to the device, where X files are sent along with a link / pointer to the next block. Another implementation is to send a list of file identifiers, and then make one HTTP request for each of the identifiers and receive the files separately. I heard that it will really damage the battery life. It's true?

Another problem is bandwidth, the client may not want / need all the files sent in one packet, so the server seems to make the client accept them all together. In an individual presentation, the client can receive files whenever he wants, whether he wants them.

Is the effect of battery life so great that it would be the right option to go beyond the bandwidth? Or are there alternatives?

+6
source share
2 answers

I heard that it really hurts battery life. It's true?

Not necessary. On most Android devices, both HttpClient and HttpUrlConnection can support Keep-Alive , so if your HTTP server is configured correctly and you make requests in a fairly quick sequence, I would not expect a significant difference.

In an individual presentation, the client can receive files whenever he wants, whether he wants them.

If you mean that they may require them for a considerable period of time, this will not be able to use Keep-Alive . However, you may request fewer files in general and consume significantly less bandwidth. It is impossible to tell you, in an abstract form, what will be better for battery consumption.

Is the effect of battery life so great that it would be the right option to go beyond the bandwidth?

It will depend on how much you load, how often, etc.

However, IMHO, you are focusing on the wrong issue.

If you consume so much bandwidth that battery life bothers you, your users will attack you with forks and picks in order to cost them so much money on their measured data plan.

Therefore, I would use TrafficStats and try out various scenarios to see how many bandwidths you really use, and therefore, whether you need to look for ways to reduce bandwidth in general (for example, polling less often), so users are not bankrupt with your application. I suspect your batteries will take care of themselves as a side effect.

However, if in your testing you find that your application appears on the "Battery Charging" screen in the settings, then start worrying about battery consumption, whether from bandwidth or from other sources (for example, excessive use of WakeLocks ).

+4
source

See these slides from a Google IO session on battery life:

http://dl.google.com/io/2009/pres/W_0300_CodingforLife-BatteryLifeThatIs.pdf

In particular, AlarmManager , which has a setInexactRepeating(...) method. The system can combine your update with others that are more energy-efficient and avoid waking the device from sleep more than necessary.

+3
source

Source: https://habr.com/ru/post/905412/


All Articles