It appears that there has been some confusion from the community at large surrounding battery performance. This was caused by my colleague Michael Chaize publishing an amazing video of Flash Player 10.1 demos on Vimeo.
Bloggers from Daring Fireball and Macgasm have spent a little more time than expected studying the battery indicators, as opposed to the incredible advancements in web browsing for mobile phones, netbooks and tablets. To be clear, the battery indicator changes being discussed are a function of video editing and Android design.
Typically these indicators are 4 step graphics, so the indicator will drop by one step for every 25% battery used. If Michael shows his phone with 50% full then this could be 51% in reality, using ~2% would then appear like a 25% loss. It’s just a graphic, and below Michael has provided more concrete results from the phone management UI.
That said, let’s look at some mobile facts for fun.
Mobile phones are complicated mini-computers with extremely complex chip designs all working to produce a rich experience with maximum efficiency. It should be no surprise that using 3G, WIFI, Bluetooth, GPS or leaving a browser window open and showing even basic HTML can drain your battery. Additionally, distance from a cell tower is also a potential pitfall and some the travellers among you will note differing battery life in various cities, countries and networks.
For many years we have been working within these constraints, probably without many of you realizing it. Remember that our mobile optimized runtime Flash Lite (shipped on over a Billion phones) and has been used extensively for User Interfaces on mobile phones from Samsung, Sony Ericsson and LG, so this is something that we know quite a bit about.
During our testing of Flash Player 10.1 we have baseline tests against the following use cases (among others), and using a multi-meter to ensure that your content runs with acceptable battery consumption. We’re also testing against the web on sites like youtube, blip.tv and others with great performance reaching to hours of playback on the Nexus One.
Here are the actual combinations of test scenarios carried out at our offices, of course the real world result for you will be different:
- Idle – No 3G, Wifi, Bluetooth, IR
- Idle – No 3G, Wifi, Bluetooth, IR + backlight ON
- 3G enabled – Wifi, Bluetooth, IR off
- WIFI + vanilla HTML. ‘simple.html’
- 3G + vanilla HTML. ‘simple.html’
- 3G + vanilla HTML file + swf: ‘simple-swf.html’
To demonstrate battery performance on the Nexus One here is a recording of a large movie playing on Youtube. It lasts for some 17 minutes with little effect on the battery indicator, and just to ensure fairness I have included the battery usage chart data from the Android OS. Our own tests show that video can be played for well over 3Hours over WIFI from youtube in H.264 (Baseline 1.2).
Note – This data is for a single website, below you can see that tv.adobe.com achieves better performance in the real world.
The resulting battery usage is a mere 6% for the Browser which totalled 199Mb of data received:
Update:
My colleague Michael Chaize has also completed his own tests shown below. In addition to my own basic test he demonstrates the ability to play videos and gaming for over 4 hours and five hours respectively.
Content Optimization
Without optimizing your applications, Flash or otherwise, they can perform badly on any platform this is 101 for any software developer. Our investments with Flash Player 10.1 and AIR are designed to provide the best possible results for the majority of existing content for web enablement on devices.
However, all of us will have to consider the user experience for our new mobile users and test effectively. Those of you that have created native or Flash Lite applications will know some of the tricks of the trade already, but nothing beats practice and real-world testing.
Thibaut (from the video above) has in fact written a fantastic document to lead you through the first steps in optimizing your content. Most of this is applicable to any of the Flash Platform runtimes, and certainly the desktop/AIR/netbooks/tablets etc.
Mike Chambers has also completed a great study on the Touch and Mouse events, and in particular how you can begin to optimize your content for this huge array of new platforms; and ultimately customers.
#1 by Michael CHAIZE on February 24, 2010 - 6:06 pm
Thanks Mark for the post.
I’ve also tested some similar experiences. My tests are showing that I can also run more than 4 hours of Adobe TV videos without interruption. I don’t even know if my PC can make it
#2 by dan mcweeney on February 24, 2010 - 6:45 pm
I’d love to see a test with a movie ( whatever the “ideal” format is for the OS ) loaded onto the phone on the SD card and played in full screen by their media player till the battery dies.
Same test with an FLV optimized for the player ( same “quality” ) played in full screen till the battery dies.
This makes the simplest comparison of the battery usage of each “player”.
-d
#3 by jdk on February 24, 2010 - 10:45 pm
Good idea, assuming the .flv is stored locally as well. Another side-by-side that may be helpful in isolating and identifying the power hungry applications would be to test the radio usage and video playback independently.
#4 by Mark Doherty on February 24, 2010 - 11:21 pm
Actually this is precisely what we do, the baseline is formed by testing the browser and various radios without Flash. Then we can determine the additional impact of the player on top of that, although it’s not 100% perfect because of the dependencies between both applications, though this is true on the desktop too.
#5 by Mark Doherty on February 24, 2010 - 7:05 pm
Hi Dan,
The goal of this was not to objectively compare Flash against the native player but to basically prove the battery performance concerns.
Well that and I don’t have so many hours to spare
Mark
#6 by James C on February 24, 2010 - 9:20 pm
For any device, Flash is going to add CPU cycles.
Native video: App -> video APIs provided by the OS
Flash video: App -> Flash translation layer -> video APIs provided by the OS
Flash is an unnecessary middleman, and using it cannot do anything other than negatively affect battery life.
#7 by Mark Doherty on February 24, 2010 - 9:33 pm
Hi James, As I wrote in my post, having your device powered up also uses CPU cycles. Please add to the discussion?
#8 by wygit on February 24, 2010 - 11:33 pm
You mean, as opposed to having separate native apps for every OS?
#9 by Rupert on March 5, 2010 - 3:27 am
Man you are going nowhere with that reasoning. It’s like if you say Java VM is unnecesary. So if we follow your advice we would have one version of the same app for each mobile SO instead of the benefit gained from the usage of a VM. Of course it consumes more memory and cpu cycles but the cross plataform independence is a much higher benefit don’t you think?
#10 by Gwydion on February 24, 2010 - 10:23 pm
I can’t see your site from my Nexus One, nor from the stock browser nor Dolphin.
Pretty ironic.
#11 by Mark Doherty on February 24, 2010 - 11:31 pm
Sorry about that, I was testing mobile optimizations and broke a few things. It should be fixed now.
#12 by Gwydion on February 25, 2010 - 6:01 am
Thanks
Waiting for the final release
#13 by justin on February 24, 2010 - 10:25 pm
Why is the video choppy? Is it Flash or the framerate of the video? Also, why wasn’t the test done using full screen?
#14 by Mark Doherty on February 24, 2010 - 11:33 pm
It’s just a matter of compression, I used my 3GS to record the video playing back on the Nexus and then compressed it about 4 times. Also, I could have done it in fullscreen, but then you wouldn’t have seen the battery indicator or clock..
#15 by Sam on February 24, 2010 - 10:25 pm
“Our own tests show that video can be played for well over 3Hours over WIFI from youtube in H.264 (Baseline 1.2).”
H.264, as in not flash? Whats the results for continuous playing of flash video, or am I missing something?
#16 by Mark Doherty on February 24, 2010 - 11:38 pm
Hi Sam, The test was for an FLV containing an H.264 encoded video playing in Flash Player
#17 by Paul on February 24, 2010 - 10:43 pm
I think the point James is making is that Flash is always going to be worse than a native app, from a battery life point of view, from a performance point of view, and quite possible from a security point of view. You should be trying to convince us exactly why Flash is a better solution for running apps on mobile devices.
#18 by Mark Doherty on February 24, 2010 - 11:35 pm
Hi Paul, I’m not sure what James’ point was other than discussing CPU cycles. The goal of this particular post is to provide a response to concerns over battery depletion, one step at a time huh?
#19 by Rajdeep Rath on February 24, 2010 - 10:55 pm
@James – When you work with Microsoft visual studio or Corel draw on your computer, ever tried gauging the power consumption? Nothing comes free, i might say.Each drag-drop interaction simply consumes more and more power. So basically every software will do the same. If you really have a problem with applications consuming battery on mobile devices i suggest you wait till smartphones let you run on electricity optionally.
#20 by John on February 24, 2010 - 11:00 pm
3 hours is pretty impressive, but can you please do a test running video from YouTube in the YouTube app?
Then do a test with video playing from the phone with 3G and Wifi turned off.
Need to compare the times of all 3 categories.
#21 by David Doukidis on February 24, 2010 - 11:14 pm
So, the Nexus One goes from 7 hours video playback using HTML5 to 3 hours H.264 playback using Flash.
Therefore flash chews through battery MORE than twice as fast to do the same thing!
Be careful with these kind of claims. If you put these in print in the UK, these would be illegal.
#22 by Dylan Bennett on February 24, 2010 - 11:22 pm
I bet you just came over here from Daring Fireball, right? Well, keep in mind that the video playback rating of 7 hours that Gruber linked to was almost undoubtedly done with Wi-Fi OFF.
#23 by Mangesh on February 24, 2010 - 11:24 pm
Are you simply repeating the claims from daringfireball.net? Where did you get the information that Nexus One can do 7 hours of video playback using HTML5 (i.e. internet video over either Wi-Fi or 3G)?
#24 by Mark Doherty on February 24, 2010 - 11:40 pm
Hi David,
As Dylan and Mangesh point out these playback results are only comparable to our test scenario. If the device can play back 7Hrs of video over WIFI then great, and I’d love to see that demonstrated.
Mark
#25 by John on February 24, 2010 - 11:19 pm
“Here are the actual combinations of test scenarios carried out at our offices, of course the real world result for you will be different”
Did I miss it, or did you post data for these scenarios?
#26 by Mark Doherty on February 24, 2010 - 11:28 pm
Hi John, The test scenarios are in bullets.
#27 by Jesper on February 25, 2010 - 11:13 am
Yeah, but where’s the _data_??
#28 by Mark Doherty on February 25, 2010 - 11:33 am
What data are you looking for?
#29 by Mangesh on February 25, 2010 - 6:12 pm
Mark, your statement “… of course the real world result for you will be different” implies that you’ve shared test results for the “scenarios carried out at our offices”
#30 by James on February 24, 2010 - 11:39 pm
I don’t have a horse in this race, but the claims that the apparent battery life issues seen in Thibault & Chaize’s demo video are the result of “video editing” (a claim made here and by the creators in the comments to their post) seem to be directly contradicted by the video evidence of the phone’s own clock.
In short: the clock on the phone is clearly visible at the beginning and the end of the video demo, and it shows that only 7 or 8 minutes have elapsed — about the same amount of time that the video lasts. This directly contradicts the claim here that the demo video was edited extensively and that’s why the battery level seems to drop rapidly.
I haven’t seen an explanation from anyone that explains why, if the video was edited extensively, the phone’s clock shows 8 minutes elapsed.
I also suspect the demo here showing H.264 video is deceptive, in that this may be one of the least CPU-intensive things done in Flash (or put another way, one of the most efficiently coded).
#31 by Mark Doherty on February 25, 2010 - 12:03 am
Hi James, as i wrote in my post the battery is obviously being used. The claim made was that the battery depleted by 25%, which is inaccurate, the battery was already at the threshold. You can test this on any phone and achieve the same result.
#32 by Alex on February 25, 2010 - 9:01 am
Actually, the claim being made is that the video is heavily edited and actually shows much more than 8 minutes of use which is 100% contradicted by the clock visible right next to the battery meter in question. I still haven’t seen anyone actually explain this discrepancy.
#33 by Wilhelm Reuch on February 25, 2010 - 2:04 am
Is the H.264 decoder in Flash really coded in Actionscript 3.0 running on top of the interpreter in Flash?
My guess it is coded completely in C and compiled to optimized native binary-code as part of the Flash runtime. Maybe even some central small routines are in hand-coded machinecode.
So this test is really misleading and has nothing to do with the code that Flash-developers deliver. Or the code that runs in the Michael Chaize demo.
#34 by Mark Doherty on February 25, 2010 - 10:08 am
Hi Wilhelm, The codecs in the Flash Player on all platforms are written in C just like they are in any media engine. My test showed the youtube player playing youtube video, which is of course delivered by a automated system created by Flash and other developers.
#35 by PeterG on February 25, 2010 - 3:54 am
This test goes to show that playing a Flash based video (FLV) is probably not any harder on your battery than playing an H.264 video.
But I don’t think that’s as important as what the Flash player will do to your battery life during web browsing.Think about all the animated SWF ads you see on web pages… those things will increase battery drain because they are procedural animations. Procedural animations cannot simply be handed off to the video hardware. They require the Flash ActionScript interpreter to run on the CPU for the duration of the ad. And having done some work on a Flash player clone, I can tell you that the added CPU load to process the ActionScript is not minor.
So imagine what those continuously updating banner and sidebar ads are going to do to your battery while you’re reading a web page. I guarantee you that the effect on your browsing time will not be trivial.
Peter.
#36 by Mark Doherty on February 25, 2010 - 10:02 am
Hi Peter, Flash itself is also GPU accelerated and not just video/audio etc. If some applications are demanding 60fps and running over our respectable 50mb limits then they will be shut down.
#37 by PeterG on February 25, 2010 - 9:15 pm
Understood that the pixel pushing is accelerated. But that was not my point.
My point is that the ActionScript in procedural animations (i.e., animated ads) runs on the CPU *IN ADDITION TO* the pixel pushing done by the GPU. This prevents the CPU from lowering its clock-rate or powering down logic units, which will cause the battery to drain faster than playing a video stream that doesn’t require any ActionScript to execute.
Peter.
#38 by James c on February 25, 2010 - 4:00 am
The point is that any additional cycles spent running the Flash runtime are unnecessary, given that Flash is nothing more than a pass-through to APIs that are already provided by the OS.
The same is true of Silverlight or Java. For mobile devices, virtual machines take up unnecessary cycles and add potential points of failure.
#39 by Inas Luthfi on February 25, 2010 - 5:48 am
Unfortunately, there is a time investment in learning a new technology (especially native OS API), and what Adobe will deliver to us is how we can use our past knowledge on Flash Platform on many different devices and OS.
Silverlight allow .NET developers to leverage their past knowledge of WPF on web. Same story with JavaFX for Java Developer.
If you ever build multimedia application from scratch with C/C++ in win32 (not using any framework like QT) and then you must port it into mac or linux in a short time, you will realize that there’s a lot of effort to do that. When you look at Flash, you will be amazed on how Flash can help you handling graphic, input, sound, movie, etc; while ensuring work across-platform, web and desktop without too much effort. There are pros and cons on Virtual Machine; Native is clearly high-performing, but it is a nightmare if you want to port your app in different device/OS platform.
#40 by Mark Doherty on February 25, 2010 - 10:12 am
Hi James, Flash is a lot more than what you describe, there are over 1m Flash developers creating rich content and driving the web forward.
#41 by z7 on February 25, 2010 - 4:51 am
Adobe’s Large problem is we all have problems with Flash. This is not a Publicity issue. This is not Image, this is not the Blog mob going off half cocked.
These stories affirm our experience, so we believe them.
You have maybe 1 year. Browsers are hot to trot for HTML 5. Google is is shifting youtube that way.
Me? I have had it. ESPN’s lovely new Net Radio GUI locks up my machine, playing audio.
Audio.
Just kill it, or fix it. I don’t care why it is broken, or who is breaking it, it is broken.
Your time is running out. I would say you have about a year, before you are in the Real Player
Club.
#42 by Mark Doherty on February 25, 2010 - 10:16 am
Strange that it actually fails to load on my machine too, so I’d suggest they have a bug. If you find applications that do not work well and you think it’s a Flash bug then please report them here:
http://bugs.adobe.com/jira/browse/FP
Also – download our latest player here for much improved performance and memory usage: http://labs.adobe.com/downloads/flashplayer10.html
#43 by Nick on February 25, 2010 - 5:00 am
I don’t understand what everyone keeps saying about “CPU cycles” being eaten up like they’re potato chips or something. The processor runs at a certain speed, using a certain number of cycles a second– battery life will be the same whether these are NOP instructions, additions, shifts, whatever…
#44 by Mark Doherty on February 25, 2010 - 10:20 am
Hi Nick, this is certainly true for most chipsets. I’m not sure if the other know this or not but power management on mobile devices will lower the clock speed and power usage of the requisite CPU/GPUs. So they are correct to some extent, just like living further away from you cell tower will increase battery usage because your phone will need to use more power even at idle.
#45 by joey on February 25, 2010 - 5:55 am
lol. that’s a real, real bad excuse.
test it fullscreen with a good screen light and let’s see the indicator at the end. we don’t care to see it all along the video, but we want to see a real world use case.
#46 by iFrodo on February 25, 2010 - 6:50 am
Are you kidding? 3H? Only? That’s pretty bad actually!
The Nexus One can play fullscreen (native) video for 6 to 7H straight, and you tell me that the small post stamp sized video you are showing us here can be played for about 3H with Flash Mobile?
Seriously, you should not be proud of that, not at all… You made me start to believe that Steve Jobs is not exaggerating with his claim of 1H30 on the iPad (which have a bigger screen and the video would also be bigger in that case)…
This is clearly unacceptable result! Particularly considering that FLash Mobile is supposed to be highly optimized and use the GPU, it should then have similar battery life than native video playblack. And you are far from it! So go back to work Flash Mobile team.
#47 by Mark Doherty on February 25, 2010 - 10:44 am
The test shows an example use case for Flash running in a browser on youtube, a real world test. Our other examples show playback well over 4 hours on WIFI when using the hardware decoders.
Remember – real world tests are meaningful, not chipset performance tests created in lab conditions.
#48 by RichardL on February 25, 2010 - 5:16 pm
Think for yourself.
If you had bothered to look at the Nexus One technical spec page that Gruber linked to for your now infamous 7 hours of video playback stat you will see right above the general battery stat for “Internet Use” which is claimed as up to 6.5 hours over Wi-Fi. Clearly the Nexus One claim for 7 hours of video playback is not claiming 7 hours of video streaming over Wi-Fi. The video presentation on this page demonstrates only video streaming over the Internet via WiFi.
I’m sure such an obvious fact must have been clear to Gruber when he linked to the Nexus One specs, he must have assumed his readers had the sense not to presume that somehow video playback battery life would go up when streaming over an Internet connection rather than playing a local video file as would be the case for a simple video playback battery life statistic.
#49 by William on February 25, 2010 - 7:47 am
It’s awesome!
Awesome this non-discussion…
Since Steve Jobs said “Flash kills battery”, everyone is looking after any point which could serve that…
I can’t believe it….
He guys! if you launch a browser, it will consume CPU cycle. if you launch a badly written game, it will consume CPU cycle.
Come one! just use your phone as a phone (stop browsing, playing, etc..) and you won’t consume CPU nor battery!
I just can’t believe it….
#50 by Kirk Davis on February 25, 2010 - 7:56 am
I think it’s great that Flash 10.x is being made available for Android – certainly, for some websites, it’s much more convenient being able to see an embedded YouTube video, or other Flash-hosted video, than going to a dedicated YouTube app to find and play it.
As long as it’s a *choice* for the user, as in, I hope that there’s a simple menu toggle-option for enabling/disabling flash. That way, we can leave Flash disabled when browsing around most websites (and avoid having flash-based banner ads eating up bandwidth, limited screen real-estate, etc), but enable it when we’re on a site that has the place-holder showing, if it’s a video we want to watch.
People who are religiously opposed to ever having flash on their mobiles could simply leave it disabled, and the rest of us could toggle it at will
Oh – and to try to be relevant to the discussion – it does look, from your tests, that some of the concern about the impact on battery consumption has been overblown, or borderline disingenuous. Thanks for taking the time to do a more detailed test of flash-based video’s impact on power usage.
#51 by Jesper on February 25, 2010 - 11:36 am
“Update:
My colleague Michael Chaize has also completed his own tests shown below. In addition to my own basic test he demonstrates the ability to play videos in full screen, windowed mode, gaming and”
Link?
#52 by Michael CHAIZE on February 25, 2010 - 4:17 pm
Here is the link: http://www.vimeo.com/9724682
#53 by Steve Volk on February 25, 2010 - 3:38 pm
I see the video going about 16 minutes from start and it showed the battery at full when started and about 3/4 when done so that is a significant use of the battery power in my eyes.
#54 by stephane on February 25, 2010 - 4:15 pm
cpu cycles account for a negligible fraction of power drain. What kills smartphones is the display. A brilliant 480×800 is demanding. Usually 50% , often above 70%.
Unless Flash means more energy for the display, I don’t see how it could make a significant difference.
#55 by Shawn on February 25, 2010 - 4:39 pm
Mark,
Some of this confusion could be cleared up if you had stats on the performance comparison between viewing the same YouTube video as an HTML5 video vs. the Flash player. This would tell you how much additional overhead Flash is incurring since the only difference between the two scenario’s would be Flash running in between.
Also, what’s the performance profile of Flash mobile decoding VP6 vs. H.264? There’s still a lot of flash video out there using older codecs.
#56 by Mark Doherty on February 25, 2010 - 7:03 pm
Hi Shawn, Thanks for your comment, in fact the purpose of this post was to demonstrate Flash battery performance and not to compare against other technologies. The video tag planned for HTML5 is merely the native video player rendering in the browser, and Flash is not a video player.
#57 by Mike Cardwell on February 25, 2010 - 7:40 pm
In case you’re interested, I wrote an app a while ago for uploading battery data from Android to a server and then automatically graphing it using RRD:
https://secure.grepular.com/Google_Phone_Battery_Usage_Graphing
You’ll find the full source code on there.
#58 by Mark Doherty on February 26, 2010 - 10:33 am
Great stuff Mike!
#59 by Jeff on February 26, 2010 - 11:01 am
@40 you gotta be kidding me. HTML 5 is not going to be universally supported for a number of years. I have no wish to return to the bad old days of multiple implementations for different browsers/OS.
#60 by leef on March 2, 2010 - 11:27 am
Holy lamesauce batman, these antiFlash kids need to get a life. Flash is a great plugin widely used, and runs great on Nexus One. If you dont want Flash request for a plugin disable setting as most OS’s allow for. Then stfu and get back to writing your HTML sites.
#61 by VenkatnarayanB on March 8, 2010 - 3:21 pm
I am totally impressed. Great job by Flash Team.