I love Adobe AIR! I think it’s an amazing platform with a huge amount of potential. However, AIR has one problem that could earn it a bad reputation before it has a chance to truly realize that potential – idle CPU usage.
Try this on a Mac: open FlashCS4. Create a new, completely empty FLA and publish it as an AIR file. Install it, run it, and examine it in Activity Monitor. On my brand new MacBook Pro, that completely empty AIR application uses nearly 4% of my CPU. Doing nothing. In the background.
Now look at the types of applications that are popular on AIR: Twitter apps, news apps, notification apps, mashups. Applications that are designed to be left open all the time. Open a few of these up at once, and you’re committing a decent chunk of your CPU to them. And that’s when they’re doing nothing. I typically have 10-20 applications open at all times. If these were all AIR applications, half of my CPU would be used just from having them open.
Expected CPU use for an idle application doing nothing is ~0%. An acceptable level is <1%. AIR must fit into this range cross-platform to be a serious contender on the desktop.
This issue does not affect Windows. I haven't tested on Linux yet.
It's also worth noting that this problem isn't limited to AIR, it appears to be an issue with the player itself. Try the same test with an empty SWF running in the standalone player or the browser, and you'll notice the same kind of CPU usage. I believe this may be part of the reason that FlashCS4 on the Mac eats so much idle CPU - it has at least 2 instances of the Flash player running in it, one for stage core, and one for panels.
I've been in contact with the team at Adobe, and they have acknowledged that they are aware of the issue, and are actively working to address it. Despite that, I felt it would still be good to write this post for three reasons:
The first reason is to create awareness of this issue, and hopefully through that awareness help to generate some external pressure on Adobe to fix the problem in a timely manner. If you feel this issue is important to you, spread the word about it, and please vote up bug #FP-2009 in the Flash Player bug system. To do so, register on Adobe’s JIRA bug system, do a quick search for “FP-2009”, and vote for the issue using the link in the left column.
The second reason is that I’ve had to explain this issue to our clients a few times recently, and I thought it would be useful for other developers to have a post explaining and validating the issue so they could refer their own clients to it.
Finally, I thought it would be good to provide a location where developers can share tips on working around this issue until Adobe addresses it. As a start to that, I have created a simple class that will automatically reduce your application’s frame rate when it is in the background, and restore it when it regains focus. You can also temporarily restore the framerate while in the background (for example, if you loaded some new data and wanted to transition it in smoothly). Reducing the framerate is the best method I’ve found so far for improving idle performance. Using the class is simple:
// this should be called as soon as your application starts up and has an open window.
// the first parameter is optional, and specifies the background fps to use (default is 1)
FramerateThrottler.initialize(2);
// set enabled to false to temporarily restore the framerate while in the background, or prevent it from reducing the framerate
// when your application moves to the background:
FramerateThrottler.enabled = false;
// you can also specify whether to only use this feature when running on a Mac:
FramerateThrottler.onlyThrottleOnMac = true; |
// this should be called as soon as your application starts up and has an open window.
// the first parameter is optional, and specifies the background fps to use (default is 1)
FramerateThrottler.initialize(2);
// set enabled to false to temporarily restore the framerate while in the background, or prevent it from reducing the framerate
// when your application moves to the background:
FramerateThrottler.enabled = false;
// you can also specify whether to only use this feature when running on a Mac:
FramerateThrottler.onlyThrottleOnMac = true;
You can download the FramerateThrottler class here.
Update:
Robert Christensen, Sr. Product Manager for Adobe AIR has posted an entry on the AIR Team Blog addressing my concerns titled “Performance Tips for Adobe AIR. I think its awesome how responsive Adobe is to issues like these! Thanks Rob!
Arno Gourdol, Sr. Engineering Manager on the Adobe AIR team just posted a blog entry on “Writing well-behaved, efficient, AIR applications“. The suggestions break down to reducing your framerate (see above), and minimizing the use of Timers and enterFrame listeners. Worth a read.
Update 2:
As a real world example, we added FramerateThrottler to an AIR application we are currently working on. It was originally using 5-10% CPU idling in the background, with FramerateThrottler it’s now using 0.5%. We also tried setting mouseEnabled and mouseChildren to false on the stage of all open windows while in the background, but that had minimal effect, dropping it to ~0.4%.
