Battery life is one of the most important aspects of the mobile user experience. It goes without saying that an excessively power-hungry app leads to a poor user experience. Apps that drain battery life beyond expectations are likely to get less use‚ receive poor reviews‚ and ultimately end up being uninstalled. This is why‚ when we build Android apps‚ we must be as considerate as possible when it comes to conserving battery life.
When it comes to optimising battery performance‚ there are three major areas that developers need to concentrate on. These are networking‚ wakelocks‚ and sensors. Networking is by far the most power-hungry of these in the case of most apps. Common strategies for reducing an app’s battery consumption include having the app handle more power-hungry workloads when the device is put on charge and using the Google Play Services APIs‚ as well as many others.
Here’s a look at what we‚ as the #1 ranked mobile app development company by our customers‚ do to ensure our apps aren’t battery hogs:
Optimising background processing
In general‚ any tasks that take more than a few milliseconds should be deferred to background processing. These long-running tasks include things like data synchronisation and performing network requests. By processing data in the background‚ users can easily switch between their apps and enjoy a more responsive experience. There are several APIs for implementing background processing‚ and they fall into three categories:
-
Immediate – the app switches to background processing as soon as the user finishes an interaction or leaves a certain scope‚ such as switching to another app.
-
Scheduled – using the AlarmManager API‚ a task can be executed at a specific point in time or schedule to happen repeatedly at specified intervals.
-
Deferred – the WorkManager API can be used for deferring tasks that aren’t directly connected to a specific user interaction and can run at any point in the future.
Doze mode and App Standby
When a device is unused for long periods of time‚ the last thing users want is to pick it up after a few hours or days only to find that its remaining battery life has greatly decreased. To prevent this from happening‚ developers should use the Doze mode to defer background processing and network activity. This way‚ any pending processing is carried out only when the device is in use again. It is possible to set restrictions to jobs‚ alarms‚ and network access during Doze mode.
Doze mode ends when a specific action takes place‚ such as the device being moved or the screen being activated. Developers can specify how Doze mode works by selecting triggers‚ timing‚ restrictions‚ behaviour‚ and exit requirements. For example‚ Doze mode might trigger when the device is on battery power‚ after which the app won’t have network or GPS access‚ and only high-priority push notifications will be received until the user interacts with the device again. Newer versions of Android also support a lightweight Doze mode that works from when the screen turns off until the device is fully idle.
The App Standby feature works in a similar way to Doze mode. The feature allows the system determine which apps are idle when the user is not interacting with it. For example‚ when a device is idle for extended periods‚ the system will allow apps network access only once per day. Determinations can be made when apps are explicitly launched by the user‚ there are foreground processes currently running‚ a notification is generated‚ or the app is an active device admin tool. When the device is plugged in‚ Android will release all apps currently in standby.
Developers should refer to App Standby Buckets to help the system prioritise an app’s request for resources whilst on battery power. There are five priority buckets in total‚ with higher ones making more resources available to the app:
-
Active – these are apps currently in use
-
Working set – these are foreground apps that are not currently in active
-
Frequent – these are apps that are used regularly‚ such as every day
-
Rare – these are apps that are rarely used and thus have stronger restrictions
-
Never – these are apps that have been installed but never run
To optimise Android battery consumption‚ developers should be mindful when marking high-priority push notifications‚ lest there be a risk of a genuinely urgent message being treated as normal.
Battery optimisation tools and monitoring
Battery monitoring and optimisation are vital to the quality control process‚ not only during the initial development of an app‚ but for releasing future updates. Android app developers have a wide range of tools at their disposal. For example‚ the Battery Historian displays battery information and events over a period of time. This lets us visualise system- and application-level events across a timeline‚ complete with a panning and zooming function. This is useful for conducting A/B tests between different versions of the same app‚ thereby allowing us to quantify the effect of a new iteration of an app on battery life.
For apps that rely on GPU rendering‚ we can also use the GPU rendering tool‚ which gives us insights into how hard the GPU needs to work to perform specific tasks. Since GPU-intensive apps are among the biggest battery hogs of all‚ this is especially important. Developers can also use the Debug Visualise Overdraw tool to identify situations where an app is doing more rendering work than necessary. For example‚ if an app is drawing the same pixel more than once in the same frame‚ then it will consume additional battery power unnecessarily.
Find out more
Do you have a legacy Android app that’s in need of a performance boost? We are a UK-based mobile app development company and one of the leaders in Android app development. Get in touch today to find out how we can help with your digital product development.
If you would like to find out more about our stance on Android security practices then read this blog post or if you would like to keep up to date with the latest industry news then sign up to our newsletter here.
