Following an AT&T Labs Research and corresponding paper entitled “Profiling Resource Usage for Mobile Applications: A Cross-layer Approach“, AT&T found that a few simple design approaches could significantly improve mobile application responsiveness and reduce battery drain by lowering your application power consumption.
They analyzed PANDORA internet radio and discovered that the streaming music was delivered efficiently, but periodic audience measurements were draining battery life. Here is an excerpt of the PANDORA Case Study:
While the music itself was sent simply and efficiently as a single file, the periodic audience measurements—each constituting only 2KBs or so—were being transmitted at regular 62.5-second intervals. The constant cycle of ramping up to full power (2 seconds to ramp up, 1 second to download 2KB) and back to idle (17 seconds for the two tail times, the first down from full-power mode and the second down from half-power mode) was extremely wasteful. Of the total amount of device battery energy consumed, 46% was expended on these periodic measurements, less than .2% of the data transmitted.
Once the initial problem was diagnosed—a scatter-burst transmission of small packets—the solution was obvious: bundle the packets into a single transmission. Doing so would result in an easy 40% energy savings.
The result of their research is a series of 11 best practices recommendations in order to reduce power consumption and improve application responsiveness namely:
- Understand Mobile Networks: Higher latency than Wi-fi and Broadband. Limit the number of connections to save battery life and decrease your app latency.
- Handle Multiple Simultaneous TCP Connections: Group multiple simultaneous connections from the same server. Efficiently managing multiple persistent connections saves energy, plus it can sometimes improve response time and reduce bandwidth.
- Reduce Inefficient Connections with Periodic Transfers: The shortest TCP timeout amongst the four major US carriers is four minutes and AT&T’s timeout is actually 30 minutes. Keep that in mind to reduce the number of periodic messages (e.g. keep-alive) as much as possible and save battery life.
- Deal with Connection Opening Problems: Try to download all the content your app will need as quickly as possible. By grouping all data together, your user’s content will download faster, making your application appear faster as well as reducing the amount of energy consumed by the device radio.
- Close Connections As Soon As Possible: Closing all connections as soon as possible once data is transmitted. However, there are situations where a persistent connection needs to be kept open so it can be reused. The issue is pinpointing connections that don’t truly need to be kept open—and closing them.
- Offload to Wi-Fi: Wi-Fi connections are much more efficient than 2G or 3G connections from a battery and network perspective, make use of this as much as possible.
- Handle Duplicate Content and Caching: Make sure the server properly set the caching information and that it returns HTTP 304 instead of transferring the whole object. On the client side, use a cache, make sure you’re properly handling HTTP caching and that you don’t download objects that are already cached.
- Utilize Pre-fetching: Pre-fetching means grabbing chunks of data in anticipation of what your user will want to see in order to reduces the number of connections. This can however be overdone (downloading too much data), so you’d have to find the right balance.
- Manage Peripherals: Turn off unused hardware such as Bluetooth, GPS and other features to save battery life in your apps. cnxsoft: I’m not sure how they’d do in a multitask environment like Android.Your application may not use a particular hardware features but what about other apps?
- Upgrade from HTTP 1.0: Make sure your application uses HTTP 1.1 as it can support persistent TCP connections and HTTP pipelining.
- Handle Screen Rotations: Do not contact the server each time the screen rotates, but instead track the orientation change in the app and send the information at scheduled intervals with other data.
For further information, you can read the full AT&T Labs Research article.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
