BlackBerry PlayBook browser performance
I am really excited about the BlackBerry PlayBook! I was able to play around with it at MAX a few weeks ago but sadly only for a little while. I loved the fact that it was incredibly light and yet seemed to be extremely powerful. RIM just posted a video of the BlackBerry PlayBook’s browser performance compared to Apple’s iPad. It’s amazing how fast it is… even when loading much richer content (it supports Flash!).
Oh… BTW… You can start developing applications for the PlayBook today! For more info, check out our Labs page about the BlackBerry Tablet OS and/or visit the BlackBerry developer website. The BlackBerry Tablet OS SDK just plugs right in to Flash Builder Burrito so you’ll be building PlayBook apps in no time!
Flash Player 10.1 & AIR 2.0: It’s not just about new features…
Recently I’ve been getting a lot of questions about the performance and stability of the Flash Player and AIR runtimes. I got another one just this morning and thought it would be a good idea to write a quick blog post about this.
Let’s talk about Flash Player first. In all honesty, I also encounter the occasional Flash Player crash in Safari on Mac OS X. Many times this seems to be caused by an uncaught exception. Some of these crashes could have been avoided if the developer had written the code to catch that exception. Flash Player 10.1 will make this a lot easier with a global exception handler.
Now don’t get me wrong, I’m not trying to push this back in to the developer’s shoes but it is something to think about. And just to be totally clear: Flash Player shouldn’t crash on an uncaught exception. That said, you should know that the Flash Player team is aware of some stability issues and is working on that. They are also constantly monitoring our public bug base so if you do encounter a crash, make sure you log it in the bug base! You can rest assured that stability and performance are always on top of the agenda of the Flash Player team.
I also keep hearing people say that the AIR runtime uses too much of the available system resources. Obviously this depends heavily on what the application is actually doing at that time. If your application is suffering from this symptom, make sure you read these blog posts. Soon after reading these three posts, your AIR application will use less than 1% of CPU while idle. In AIR 2.0 the target is to reduce the idle CPU usage to 0%. Early tests with AIR 2.0 show a 30% memory reduction and a 50% reduction in JavaScript CPU consumption. We’re also targeting a 40% reduction in runtime size.
We haven’t announced any specific dates for the release of Flash Player 10.1 and AIR 2.0 but make sure you keep an eye on Adobe Labs and our blogs.
Building CPU efficient Adobe AIR apps
One of the biggest complaints we hear a lot about AIR applications is that they use too much memory and/or too much CPU. Sure… Adobe needs to (and will) make investments in improving the performance of AIR and Flash Player but you as a developer can already make some improvements to your app as well. I know this has been discussed before but repetition never hurt anyone. ;-) If you’re having issues with the app that you are building, you should definitely check out Arno’s blog post about this very topic.
With just 4 simple tips, you can dramatically improve the memory/CPU usage footprint of your application.
- Use the lowest framerate possible
- Dynamically change the framerate to fit your application needs
- Only use Event.ENTER_FRAME handlers when necessary
- Have as few Event.ENTER_FRAME handlers and Timers as possible
Check out Arno’s blog for more info on how to implement these tips. The AIR team also has a blog post about this topic.
If you have any other tips that you are currently using, please feel free to leave a comment. Also, if you have any questions regarding this topic, please feel free to get in touch.
Feel free to follow me on: 
