What kind of bugs have you fixed due to energy inefficiency issues when you develop mobile apps

Question

For those who write applications for mobile phones, what kind of bugs/problems have you fixed in order to improve energy efficiency, and how much the fix improves?

A follow-up question: is energy efficiency considered as important as features and avoiding functionality bugs when you write mobile apps?

Answer 1

To answer the follow-up question first, very few customers notice any difference in energy efficiency or battery life from using a particular app. This is almost never mentioned in the App store reviews. I write power efficient code mostly because I don't want to run down my own device's batteries while testing and using my apps.

Some suggestions for iPhone apps:

1. Write your app so that it runs well on the slowest device (iPhone 2G or 3G) with the slowest OS (4.x on a 3G). Then it can mostly be idle on the much faster current devices.

2. In graphics routines, try not to redraw anything already drawn. Use a small CALayer or sub view for localized graphics updates/changes.

3. Use async methods as much as possible so that your app isn't even running on the CPU most of the time.

4. Use plain C data structures (instead of Foundation objects) and pack them so that your app's working set can stay completely resident in the very limited ARM CPU data cache, if possible.

5. Don't do networking any more than necessary. Do the largest data transfers possible at one time so that the radios can turn off longer between your app's network use, instead of lots of continuous small transfers.

Answer 2

In my opengl based live wallpapers battery life is a significant issue.

Keep sensor use to a minimum, there is lots of different profiles, use the delay that you require.

To maximize battery in a LWP I usually force a frame delay of 5ms by default. This appears to be enough time to let the CPU relax between frames and keep the usage reasonably low. You can also manage the timeout based on the current FPS and pin it to a FPS profile. E.g. the device could render 60fps, but you are just rendering at 30fps and sleeping half the time.

For games you could do the same, just put a fps limit in your engine and don't let it go above that.

If you want to be hardcore, realize that OLED's used in many android devices use more power to display light colors as opposed to dark ones. On a LCD there is a equal backlight, but on OLED a black pixel is effectively off and not using power. So the darker your screen, the longer your battery life should last. Something to consider in certain situations if you want to be really hardcore on the battery side of things.

Don't use the GPS, don't use 3G, and if you do cache everything locally.

Answer 3

Energy efficiency in mobile dev is tantamount to memory constraints in embedded systems.

Specifically, I like GPS apps and so make sure that the GPS is only on for the bare minimum of time. Of course, when there are bugs that are introduced that keep the GPS turned on too long they go to the top of the list to get fixed.

So, the short answer is: Yes, energy efficiency is definitely as important as features.

Answer 4

EE is important especially if the application is running constantly in the background.

We had to replace polling methods with event based methods whenever possible. If it was not possible we reduced the polling frequency.

Also reducing file read/writes to minimum reduces battery consumption considerably.

Answer 5

1. Process images + calculations on the server for low cpu phones rather than using the phones cpu (not as applicable on iPhone + Android handsets)
2. Draw to the screen only when necessary rather than endlessly
3. Save state at all times so the user can enter the application where they left off if an interrupt causes your application to be placed into the background
4. Avoid running in the background where ever possible? do you really need to or can wait until the application has focus
5. Avoid using fine grain location where a coarse location would do (GPS vs cellular location)
6. Use push over pull where ever it is possible to save polling the network