5

I have a web application to be run on mobile phones that when open continuously generates data (a few kilobytes every few seconds or every few minutes depending on settings) and needs to push it to a server in real time. No data is ever sent from the server to the browser.

My main concern is to make this submission battery efficient, a few seconds of delay is totally fine.

I envisaged two solutions:

  1. Periodically do a POST to the server with the data (to avoid having a permanent connection to maintain)
  2. Have an open websocket and periodically send messages (to avoid the weight of an http request)

Which one is the most efficient for the battery? Are there other strategies that I am missing?

Actually my app will be hosted on heroku, which does not supports websockets yet, resulting in long polling, thus for the moment I'll assume it is better to POST on demand, but I am wondering if it could be an option in the future (or maybe this assumption is wrong).

Mathieu
  • 61
  • 3

1 Answers1

2

Android

On Android devices, there are three different network radio states as the documentation says:

The state machine for a typical 3G network radio consists of three energy states:

  1. Full power: Used when a connection is active, allowing the device to transfer data at its highest possible rate.

  2. Low power: An intermediate state that uses around 50% of the battery power at the full state.

  3. Standby: The minimal energy state during which no network connection is active or required.

While the low and idle states drain significantly less battery, they also introduce significant latency to network requests. Returning to full power from the low state takes around 1.5 seconds, while moving from idle to full can take over 2 seconds.

The device changes from Full to Low after an idle time of 5sec, then from Low to Standby after another 12sec.

The above link also covers some best practices for battery friendly connections, although it doesn't say anything specific about Websockets.

iOS

I couldn't find such specific documentation on iOS devices, but the model seems to apply in a similar way:

Cellular and Wi-Fi radios are designed to power down when there is no activity. Depending on the radio, though, doing so can take several seconds. If your app transmits small bursts of data every few seconds, the radios may stay powered up and continue to consume power, even when they are not actually doing anything. Rather than transmit small amounts of data more often, it is better to transmit a larger amount of data once or at relatively large intervals.

So what?

In general, you should probably use short POST requests and send data as seldom as possible, so the radio can power down in between.

Community
  • 1
  • 1
pixelistik
  • 7,541
  • 3
  • 32
  • 42
  • Making periodical POST requests sounds more logical, and I'll also add a setting for buffering to limit frequency. Regarding Android it is unclear to me if an active websocket would prevent going in low power/standy, because it says "radio idle for XX seconds", but an unused socket would not actually send packets. I have to try with DDMS. – Mathieu Oct 31 '12 at 21:02
  • From my experience with websockets, a REST service (POST, GET,...) IS a socket. According to the documentation, Android devices handle and "tag" connections to have some sort of keep alive even if the radio becomes idle ("GCM is implemented using a persistent TCP/IP connection") – Goufalite May 27 '16 at 06:51