Monday, March 31, 2014

Let’s make our apps less battery consumptive

Major characteristics of a high battery consumptive app

1.) Apps that run without the user’s permission (Ex : Apps with administrator privileges).

2.) High usage of device functions which require high energy, such as GPS, accelerometer, camera and other sensors, or when the app fails to turn off those functions when the are not in use.

3.) Apps which do frequent wake-ups on smartphone or prevent the smartphone from going to sleep mode. (Handsets go into sleep mode when they are idle to enhance the battery life but it can be prevented programmatically by apps – Wakelocks)

4.) “no-sleep energy bug” – This is a situation where at least one component of the device is woken up by our app and failed to put back to sleep due to a programming error and it causes battery drain as well.

5.) Apps with high-end graphics such as games

Verizon rates apps considering battery consumption [1] and according to that, If the device consumes less than 30 minutes of battery time, it gets five stars.
  • 5 stars: current drain less than or equal to 5mA; up to 30 minutes battery life lost.
  • 4 stars: current drain 5-10mA; 30 minutes to 1 hour battery life lost.
  • 3 stars: current drain 10-15mA; 1-1.5 hours battery life lost.
  • 2 stars: current drain 15-20mA; 1.5-2 hours battery life lost.
  • 1 star: current drain over 20mA; over 2 hours battery life lost.
How do we optimize our app?

1.) Use resource optimizer tool by AT & T [2] to test and optimize the app (this tool is free and open source.)

2.) Use Wakelock Detector [3] to monitor our app's impact on waking the device up - This identifies all apps on the device that, with or without permission, override the sleep function.

3.) Performing updates while a device is charging causes minimal battery drain, so we can create our app to maximise its update rate when the device is charging. We can also reduce the update rate when the device is not connected to conserve battery life. Read android developer guide [4] for more information.

4.) We can use BatteryManager [5] to broadcast battery and charging details. BatteryManager broadcasts whenever your device is connected or disconnected from power. These events can determine how often you start your app in a background state. To monitor changes in the charging state, register a BroadcastReceiver in your manifest to listen for these events by defining ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED. Generally, you only need to monitor significant battery changes. To do this, you can use the intents ACTION_BATTERY_LOW and ACTION_BATTERY_OKAY, so you can determine when to disable all your background updates. For the full tutorial, see Monitoring the Battery Level and Charging State [6].

5.) The problem with using a BroadcastReceiver is that your app will wake up each time any of the receivers are triggered. However, you can disable or enable the broadcast receivers at runtime. This way the receivers you declared in the manifest are triggered by system events only when necessary. You can use the PackageManager to toggle the enabled state on any component defined in the manifest. - Blackberry developer blogs [7].

6.) If you determine that connectivity has been lost, you can disable all of your receivers except, which informs you when the internet connectivity status changes. Once you are connected, you can stop listening for connectivity changes. You can use this technique to delay larger downloads by enabling a broadcast receiver that initiates downloads only after you are connected to Wi-Fi.

7.) Stop view animations when they're not really necessary (Incl progressbar)

8.) Be very careful with location requests - Unless your app needs to know the device's precise geographic coordinates at all times (Ex: Map or navigation app), you should carefully decide on how often you send location requests.

9.) Push data to your apps (Using GCM) without making data calls always to check for updates.

To read in-depth on mobile application quality improvement, read the article [8] by “The App Quality Alliance”


No comments:

Post a Comment