The performance optimisation techniques discussed in this document will also improve battery life. There are, however, a few points that can help you understand the relationship between your algorithms and the battery power. It can be important, as your application may not be very popular if it drains the battery – the phone may be needed for more than running your application.
To minimise your battery consumption:
Ensure that
you do not have a code loop which does not call sleep() or wait(). Such a loop may be appropriate for a
limited amount of time, but if you have, for example, a game animation
loop that runs through the whole game, the CPU will never be allowed
to enter low power state and rest.
Design your
application primarily as short bursts of activity in response to user
input or other outside stimulus such as network activity. For example,
instead of polling in a loop, the application can be designed so that
when the user presses the key (keyboard event), touches the screen
(touch event), or the phone receives data from a server (network event)
or reads or writes a file (flash memory event), a short Java method
is called directly. This is called “event driven” code and it allows
the CPU to spend most of its time doing little or nothing. Such code
usually sits in a wait() statement until an outside
event starts it with notify() or notifyAll().
Make the polling interval as long as possible, if there are parts of your code which cannot be completely event driven. For example, if you interact with a non-push chat server, wake up and ask the server for new messages as infrequently as you can and with intelligent adaptations, such as making the poll interval longer when nothing has happened for some time.
Combine all periodic activities, like polling a web service and processing data, into a single burst event that runs infrequently. The radios in your Series 40 phone’s network interface can enter a low power state when not used. You can use this to save power by closing all unused network connections. When you need to connect, then connect to all the network services you need in one quick burst, if possible. The CPU and other chips on your Series 40 phone can enter a low power state when not actively in use. Doing all your background activity in a single burst maximises the amount of time the maximum number of phone subsystems can be in their low power sleep states.
Ensure that
the data sent from your network server is properly compressed. It
is very common for web services to be incorrectly configured, and
not compressing the outgoing data wastes time, bandwidth (= users’
money in many cases), and may increase your server scaling costs.
For example, verify the configuration of Apache web server’s mod_deflate or similar functions appropriate for your server.
GZIP compression is a web service standard, and your Series 40 phone’s HttpConnection component will automatically inflate the
data for you.
Be aware that reading from and especially writing to flash memory, such as the Record Management System (RMS) and the phone’s file system, is not only slow, but also consumes lot of battery power. Minimising the frequency and size of data written can save a significant amount of battery power.
If there are
infrequent activities, like updating an offline data cache, consider
doing this only when the phone is plugged in or has plenty of battery
power. You can use System.getProperty (“com.nokia.mid.batterylevel”)
to get the current charge level. You can also use the Sensors API
to check the “charger_state” sensor to find out if the phone is currently
plugged in and charging.