[Update: As if by magic, 36 hours after I publish this article, Microsoft releases an update to the Developer Preview, claiming battery life improvements! I'm testing the update - battery drain looks MUCH reduced! - and will also publish a new chart in due course. Sometimes, I really do think these companies hang on my every word.....!]
A new chart and article has now been published here - the rest of the article, below, is now outdated and can be ignored.
_____________
Getting through the day
Let's clear up one thing first - "It's just got to get me through the day" means that a smartphone, under potentially heavy use, has to stay powered on from a possible start at 7am until bedtime (say 10pm). So 15 hours of 'on' time, logged into a cellular network, on wi-fi periodically, pulling down email often, usually with at least one social network syncing to a client, with periodic web browsing sessions, a couple of hours of audio of some kind (e.g. while commuting), perhaps up to an hour of gaming in odd moments through the day, half a dozen shortish phone calls, the capturing of a dozen photos, and other miscellaneous use.
Hopefully the previous paragraph gets close to what you use a smartphone for - it's certainly pretty typical. And I'd venture that if any smartphone, whoever the manufacturer and whatever the OS, runs out of power before bedtime with the usage pattern above then there's a conceptual problem.
What's the battery used for?
Now, there are two components to battery life. Firstly, actual use. Applications in the foreground, screen lit up, touchscreen in use, GPS active, camera powered up, speaker blaring away - all of that. As mentioned below, there's only so much that can be modelled and tracked here because use patterns and devices vary so much. Plus, you expect to be draining power at a rate of knots when you're using a phone.
Secondly, and more interestingly (to me), is the power drawn when the phone is in standby mode, i.e. sitting in your pocket or on your desk apparently doing nothing. This then is the measure of how efficient a mobile OS (and its applications) is (are). Ideally, there should be minimal power drain when in standby, so that the maximum proportion of total battery capacity is available to power hands-on, foreground use.
What you absolutely don't want is to have standby power drain so high that, even left in a pocket for the aforementioned 15 hours, the battery will be almost dead by bedtime - clearly leaving no spare capacity at all for actually using the phone during the day!
So - I went testing...
Methodology
The idea in each case was to charge the phone/OS to capacity overnight and then to watch the reported percentage life left through a working day, with 3G/4G SIM in place (on the Three network in the UK), with Wi-fi connected and with a typical set of email and social accounts syncing regularly. Use of the phone was kept as light as possible, as what I was interested in most was the battery overhead for maintaining the running mobile OS - obviously, heavy use of any device would skew the results, since it would depend on what was being done, screen brightness and size, and so on.
A number of caveats are also worth mentioning:
- An OS's reporting of the state of a device's battery can be (notoriously) inaccurate. What's being attempted is a reading of the battery voltage, together with knowledge of how long it last was since the device was charged, added to a pretty huge 'fudge factor', ending up with a percentage which often amounts to little more than a guess. In other words, what gets reported as "50%" might actually be 60% or 40%. However, over a full charge/discharge cycle, at least the end points are consistent and we can still get a good idea of the relative, real world standby performance of each mobile OS here.
- Percentages are obviously relative to a 0-100 scale, with the actual battery capacity varying a lot between devices. Which is a large off-putting factor, though I'm testing phones as-is, and real world users will have the same configurations...
- Other variables include network conditions on each test day, plus Wi-fi strength variations as I moved from room to room in the house.
- I only did one rough usage pass with each device - ideally, multiple devices of each type would be observed over multiple days, and so on. But there's only so much one man can do, etc(!)
- In a couple of cases, where readings were missed or recorded out of time, I've interpolated slightly, in the interests of keeping the lines relatively smooth. This is, scientifically, a bit dubious, but then we're trying to guage the overall picture here and not look at minute details.
- Also not taken into account was battery age - as capacity is lost, over time (many months/years), the rate at which charge will drain will seem faster, of course. But again, short of buying all new devices, there's not much that can be done to allow for this!
Results
[Tested on Lumia 1020, Galaxy Note II, iPhones 4S and 5, Nokia 808 PureView]
Now, it's vital to note, before I go on, that the Windows Phone 8.1 being tested here was the 'Developer Preview' and, as such, is clearly a work in progress - it would be unkind of me to slam it too hard as-is, but I think it's fair enough to point out that improvement will be needed for final builds that go into shipping devices.
And it most certainly is. As you can see from the chart, with an average power drain of over 5% (of a Lumia 1020 battery, in this case) per hour, there's not a massive amount of charge left to power actual screen-on time. After all, even a rough calculation gives 4%x15 hours=60%. Now accept that you don't really want to be going lower than 15% (at which point you'll start getting battery warnings from the OS) and there's only really 25%, a quarter of the nominal capacity of the phone battery, to play with in terms of use. And, in the real world, as battery capacity reduces with time, this figure can only be lower still.
In contrast, my Android test phone managed to preserve well over half its battery capacity for 'on' time over the 15 hour period. Not ideal, but certainly workable in most people's situations. While my older Symbian-powered Nokia 808 PureView went one better, with 80% available for actual usage, and my test iPhone astonishing me* with very low power drain in standby and hardly measurable, even over a full day, almost within the bounds of error margins on a rough test like this.
[* It should be noted that some iOS 7 users have had wildly different experiences, possibly due to newer hardware and electronics, but I'm only reporting what I saw on a '4S' and a '5'.]
Conclusions - what has to be done still in 8.1
Now, all of this surprised me to an extent. Windows Phone, like iOS, was designed to severely restrict multitasking of third party applications and thus keep rogue battery drain well under control. This it does, but it seems like the core Windows Phone OS is actually the main culprit. In fairness, Windows Phone 8.0, tested here, was only marginally less battery efficient than Android, but the latter involves far more lenient multitasking and I'd have expected Windows Phone to be nearer the iPhone line.
In full real world, connected trim, with the Windows Phone 8.1 Developer Preview on board, battery drain in standby mode is clearly unacceptable - with almost no spare capacity users are forced to charge again mid afternoon or carry around emergency chargers (and recharge the latter overnight too).
All of this boils down to Windows Phone needing to become more efficient at how it uses the phone hardware when the screen isn't on. I'm positive that the Developer Preview still has debugging code within it, plus routines that hadn't yet been fully optimised, especially all the baseband stuff for handling 3G/cellular - see my curve above for 8.1 when no SIM card was present, for example.
Microsoft, I'm sure, knows what it has to do here - and I'll be here in a few months to chart the progress it makes in trying to really compete with Android and iOS.
__________________________
A new chart and article has now been published here - the article, above, is now outdated and can be ignored.