It’s strange how sometimes people are very aware of the battery consumption of some applications but put all concerns aside when it comes to applications that use the internal accelerometer. Is it because they are all nice or because the application does not really give the impression of running in the background all the time? Ok, not all applications are the same but I’m not just talking about GUI differences here, I’m talking about how the application was implemented and how the battery and performance is affected by the application.
Of course there is one test which is very easy to make and will give you the best answer of the “quality” of the application implemented: “Check” your phone (e.g. measure how long the battery lasts) before installing the application and check it again after installing the application. In any case, I hope you’ll find the following considerations useful if you want to decide whether or not is worth installing a specific application permanently on your mobile.
Let’s look at a case scenario: an application that checks if you turned your mobile upside down (I’m not trying to refer to any existing application). From a technical point of view, the application has to take the x, y and z values and compare them with the previous values to detect a change in position. Now, there are three issues that will affect the battery life:
- how the solution is implemented
- how frequently the x, y and z value are checked
- when x, y and z are checked
First one is obvious, I know, and unless you have access to the source code you have to trust the developer. Anyway, let’s assume that the majority of the code in the application is there to build the GUI, capture user commands and take actions when the user finally turns the mobile upside down. With these assumptions, you should not notice major differences in battery performance between two applications trying to achieve the same goal because they will be executing the code for no longer than few minutes. You should also not notice any difference in battery performance (due to this issue) compared to when your mobile didn’t have the application.
Second issue depends on what you are trying to detect. For example, if the app has to detect a user turning the mobile upside down, checking the x,y ansd z values every second is more than sufficient. However, if the app has to detect a user shaking the phone, then the frequency of these checks needs to be increased to at least 10 every seconds (unless you are trying to shake the mobile that this guys on left holds in his hands
). Count how many times you can shake your mobile right and left in one second, then multiply by two and add 3 just as a margin. That’s the number of times in one second you might want the application to check the x, y and z values.
Last issue is also very important if you concerned about battery life. 3 scenarios here:
- Waiting for a specific event (e.g. an incoming call, an incoming text message, etc). That is the best scenario because the operating system has a way of telling the application when there are some events (e.g. incoming message). When that is the case, the developer can put the application in some sort of standby and wait for that event (and save your battery for something else!).
- If there is not event, you can still be lucky because the developer might need to check the x,y and z values only for few minutes. For example. imagine if you could set the time of a timer by shaking the device. The application would only need to monitor for user activity from the time the application is launched to the moment the timer is started, and that could be few minutes at most!
- Worst case scenario: running in background all the time. Let’s assume you want an application that tells you the time when you shake it. That applications is put in an “almost forever loop” and runs in the background all the time you are browsing, listening to music or doing something else. Let’s do some maths: let’s assume that the application will check the x,y and z values 20 times every second; that’s 1200 every minute which is also 72000 of wasted computing cycles in one hour. There is another factor that you should consider: how many application do you have that use the accelerometer and try to detect when you shake? If it’s more than one, then you should multiply 72000 by the number of applications.
If you are someone who tries a lot of applications I’m sure you might have come across an application that can drain you battery in less than 8 hours without doing you doing anything with the phone!
-Reda
Image source: gizmodo.com


