Read-only archive of the All About Symbian forum (2001–2013) · About this archive

Why battery life sucks

23 replies · 10,397 views · Started 06 September 2010

There is a great rant over on Mobile Fanatics, about battery life in mobile devices. The author makes the case that poor battery life is down to lack of optimisation by developers, citing Android as the worst offender. Furthermore, he blames mobile platforms being based on the Unix/POSIX/Linux family of operating systems, stating that these systems were never planned to have been run on mobile platforms where energy is at a premium. Read on for commentary.

Read on in the full article.

It's getting time to include a bicycle in the Smartphone packages . Of course with a (nokia) bicycle charger .
It might cause an explosive hype , reduce rants and make geeks happier .

😊 Regards jApi NL

It's not pretty, but you CAN kill apps on Android without a third party app:
Settings | Applications | Manage Applications | Running Apps | choose the one you want to kill, and choose force close.

Julie

I do not agree with all of what was written. It seemed to be based more on rant than complete facts. One big problem is that battery technology has not kept pace with the newer devices. I have to give a hats off to Apple for pursuing better technology. The fact that they can squeeze almost 10 hours out of a 17 inch MacBook Pro battery as well as over 10 - 12 hours on an iPad are testaments that some companies are serious about battery life.

From a technical perspective....

Symbian C++ is explictly designed such that apps do not have to execute if they have nothing to do - they are properly event driven. Like them or loathe them, active objects are designed all around only needing to respond to events if there is some work to be done. No polling should ever be occuring.

In contrast Android (or more accurately Java) fails quite miserably on this front. To perform animation on say Android, you have to have a thread of execution that goes round a loop as fast as it can, permenantly, all the time, regardless of processor speed. You poll the timer every loop to determine enough time has passed you then do some work. As bad as you can get for battery life. Want to partion anything, launch another thread + let it burn as many cycles as it can.... etc.

Obviously the above also applies to Java apps running on Symbian so its not immune.

Apple OS fundamentally has the same problem, as does Windows, old PalmOS, any brand of unix/linux etc etc as they are all based on polling for events in their 'getNextEvent()' loop. Sure, some of the burn as many cycles Java approach to life is mitigated by the OS event loops but its still fundamentally the wrong thing to be doing to maximize battery life.

Quite frankly its laughable that '10-12' hours is seen as acceptable. 20 years ago we built real world mobile devices (on early versions of what became Symbian OS) that lasted several MONTHS on 2 std AA batteries. Sure they were not mobile phones with associated signalling but even so...

Unregistered wrote:I do not agree with all of what was written. It seemed to be based more on rant than complete facts. One big problem is that battery technology has not kept pace with the newer devices. I have to give a hats off to Apple for pursuing better technology. The fact that they can squeeze almost 10 hours out of a 17 inch MacBook Pro battery as well as over 10 - 12 hours on an iPad are testaments that some companies are serious about battery life.

It would be nice if thoses devices actually offered that kind of life in reality, in normal use. I can tell you from experience that they get nowhere near it.

Sequences shortened, some steps removed.

bbj wrote:

In contrast Android (or more accurately Java) fails quite miserably on this front.

Dalvik in Android is not Java, no JRE, no J2ME. It's not even a stack machine. It uses some of the language to create classes for compilation to Dalvik, but has its own library.

"Dalvik in Android is not Java, no JRE, no J2ME"

Correct its a virtual machine.

However Java is the input language. Its pretty irrelevant that its converted to something else e.g. for a dalvik vm or any other format for any other vm. The key point as far as developers are concerned is the restrictions are defined at the input level - i.e. Java.

Sure the Android App model is somewhat different to say a J2ME app model, but both encourage a polling model, as such if you are choosing to differentiate, neither is particularly well designed for battery conservation.

bbj wrote:"Dalvik in Android is not Java, no JRE, no J2ME"

Correct its a virtual machine.

However Java is the input language. Its pretty irrelevant that its converted to something else e.g. for a dalvik vm or any other format for any other vm. The key point as far as developers are concerned is the restrictions are defined at the input level - i.e. Java.
.

Seriously?

So the code syntax affects how the SGL, the Surface Manager and 3D libraries work?

LOL! These are C++ libraries with exposed APIs, the "java" style code just calls these APIs and glues things together.

It's true that Android devices are dire for battery life (pound for pound they are even worse than Windows Mobile) but the use of java style code is not the reason.

Unregistered wrote:It would be nice if thoses devices actually offered that kind of life in reality, in normal use. I can tell you from experience that they get nowhere near it.

Sequences shortened, some steps removed.

Sorry but I agree with the poster. I have gotten over 12 hours out a wifi only iPad following Apple's testing procedures and similar times with a MBP. Not saying that you are wrong, but you are not correct.

Unregistered wrote:Sorry

You are wise to apologise.

Unregistered wrote:
but I agree with the poster. I have gotten over 12 hours out a wifi only iPad following Apple's testing procedures and similar times with a MBP. Not saying that you are wrong, but you are not correct.

Well I can only go by what happens when I make real world use (not testing procedures - that would be as pointless as 'urban cycle' figures). I can get far more than 12 hours out of an iPad is I don't touch it.

7 hours max.

I was not apologizing to you directly. I guess you're having a narcissistic flare up. Anyway, I guess you are supposed to be the standard by which all Apple devices are measured? Maybe the devices, as simple to operate as they are, are just to difficult for you.

Unregistered wrote:I was not apologizing to you directly. I guess you're having a narcissistic flare up. Anyway, I guess you are supposed to be the standard by which all Apple devices are measured? Maybe the devices, as simple to operate as they are, are just to difficult for you.

Obviously. Because when iPad owner use their devices, they always follow the Apple test process precisely.

Duh.

Great response that: "duh". Must have taken hours to get that just the way you wanted it.

Anyway, I've done the same tests that Apple does on their products and for the most part they are usually on the conservative side. The new iPhone 4 is miles ahead of the 3GS and 3G in terms of battery life. Another thing that is worth mentioning is that Android phones as well as iPhones sort of entice the user into doing something with it. Nokia phones are great for making calls, or sending an SMS, but they are boring utilitarian phones that beg to be left laying on the table until a call or SMS is needed. iPhone and Android users actually use/play with their phones more because they are more exciting.

If you want excellent battery life (weekly charges), then just don't bother with smartphones. However, if you want powerful, flexible and fun devices then you'll be looking at charging it every one or two days minimum.

I agree 100% that Android currently makes for a very poor low-end experience, but all devices in the high-end category have issues with battery life, regardless of OS or manufacturer.

Also, Android (and now iOS) applications suspend when you leave them, and only occupy memory (which would be powered up anyway). The only reason any application would still be burning CPU cycles in this state is if it was programmed that way. It should be generally unnecessary to manually manage background tasks on Android and iOS. If you don't like applications that do work in the background, then don't install / use them, or turn them off.

bbj wrote:
In contrast Android (or more accurately Java) fails quite miserably on this front. To perform animation on say Android, you have to have a thread of execution that goes round a loop as fast as it can, permenantly, all the time, regardless of processor speed. You poll the timer every loop to determine enough time has passed you then do some work. As bad as you can get for battery life. Want to partion anything, launch another thread + let it burn as many cycles as it can.... etc.

Utter crap.

Most(All?) J2ME midlets can listen for a suspend/backgrounding event. It's up to the programmer to honor these events, otherwise (yes) the code will continue to execute. It's called multitasking.

we always get the blame.there are many (debatably) good reasons why we don't optimize as much as possible for battery life, many are the result of compromise.

How about blaming battery developers who have promised new advances and delivered next to nothing? Longer lasting batteries would solve the problem once and for all. All we get is small incremental improvements that are eaily eaten up. Where are the fuel cells/etc? An innovation in battery tech is needed...

Unregistered wrote:I do not agree with all of what was written. It seemed to be based more on rant than complete facts. One big problem is that battery technology has not kept pace with the newer devices. I have to give a hats off to Apple for pursuing better technology. The fact that they can squeeze almost 10 hours out of a 17 inch MacBook Pro battery as well as over 10 - 12 hours on an iPad are testaments that some companies are serious about battery life.

wow, I barely get one hour from my Acer laptop but I have a problem with my laptop battery and windows 7. 😞

I don't get it. How hard can it be. I'm currently running around with a N6220 Classic
Ok, it only has a 2,2" screen, and no Wifi, but I'm using 2 to 3Gb of 3G data each month (a lot of tethering).
The battery isn't large (900 mAh) and I still get around by only charging it every 2-3 days. How is this possible.
Are thos big (touch-)screens really that hungry?

This is all very well but irrespective of the power requirements of various apps and OS's, doesn't a higher capacity battery mean a longer life?

I mean, why does my N97 Mini have a 1200mAh battery when the slimmer E51 and E71 have 1500mAh? Why couldn't the newer touch screen phones have these batteries in?

I know that they can hammer the battery harder and might still need charging every night but it's surely better to have the larger capacity??

I just don't get why Nokia or any other manufacturer makes a positive decision to put a smaller battery in. I mean, it's not like they haven't got the 1500 mAh on their parts list is it?

The problem with battery technology, is because the inherent danger of explosion.
Newer tech battery must pass through test in order to ensure the safety of it's user.

And because Nokia make slimmer phone, this means the battery power will be reduce in order to make the battery smaller but with the same battery technology.

For those that need a phone that will last "in the field" so to speak, just got back from a holiday in rural France where the signal was constantly being lost on my 3G-always-on phone (won't name names as negativity on forums is boring) which despite little use still required a daily charge.

On the other hand, my wife's E72 lasted 8 days without charging!

Truly remarkable, and clearly the result of (1) a good battery and (2) small screen without touch input.

Even my old 6230 could only do a week!

I completely agree to the fact that these devices does not offer better battery life. This is what I detest about the use of devices.