The ugly side of developing AIR HTML apps

i will take over the world.

I’ve been developing with AIR for over a year now. It’s all been HTML/JavaScript apps, but the complexity of most of them has been pretty low. Spaz, the Twitter client I created, definitely isn’t simple, though – mostly because I’m kind of a crappy coder, but also because it just does a lot of stuff.

Lately I’ve been getting a little bummed about AIR, because I’m starting to bump into limitations of the platform more and more. What’s particularly frustrating is that some of these limitations are specific to HTML AIR app dev. So what follows is a couple of issues that have been particularly troublesome when developing Spaz and other HTML/JS AIR apps.

AIR gets greedy under OS X

Julien Viet, who has contributed significantly to Spaz, made a post recently about the base resources used by the AIR runtime. In it he finds that the basic “Hello World” sample app provided by Adobe used about 20MB of RAM, and hovered at about 2% CPU usage even when idling. I replicated these tests on my Macbook (2.2Ghz, 4GB) under OS X 10.5.4 and WinXP SP2, and had similar results:

AIR HTML app - Base CPU and memory usage (WinXP SP2) AIR HTML app - Base CPU and memory usage

I also created a Flex-based “Hello World” application to compare base usage if the Webkit renderer isn’t being used. Memory usage was slightly lower, but otherwise it was comparable to the HTML app.

AIR Flex app - Base CPU and memory usage (WinXP) AIR Flex app - Base CPU and memory usage

The constant CPU usage seems to be specific to OS X: WinXP will jump back and forth between 0% and 2%. This is consistent with my observations of CPU usage in Spaz as well: in OS X, we get 10-15% CPU usage constantly, but under XP and Vista, CPU usage is 0% while idling. Initial memory usage is also about 30% higher with Spaz under OS X than it is under Windows. Something is goofy with AIR on OS X.

That aside, I don’t think the memory and CPU usage of AIR are surprising, considering the technology. AIR is a full Flash runtime, and HTML apps add a Webkit renderer on top of that. The memory and CPU usage is in line — or a bit lower — than most SSBs. Using traditional browser tech to build a desktop app is going to be a tradeoff in terms of memory and CPU usage, just like many other technologies that make development easier. But for one reason or another, the expectation seems to be that AIR is a lightweight technology, and it’s really not.

AIR HTML apps are leaky

What is particularly problematic is that there seem to be memory leaks within the Webkit engine as used in AIR – or at very least, it’s pretty easy to leak memory. Apps like Spaz run into this problem because it’s constantly pulling in large amounts of new data and images, and is often left running for hours or days on end.

Some of this is almost certainly because you can get away with that kind of thing on a web site, where users are unlikely to leave a single page open for days on end. Even if a web site does causes a big leakage, the browser almost always gets blamed. The libraries and tools available for HTML/JS devs, being browser-focused, typically don’t pay much attention to long-term performance issues.

Essential tools, like profilers and step debuggers, are non-existent

But memory leaks are a problem for most desktop app developers. That’s why memory profiling tools are common in desktop frameworks. And Adobe certainly understands this to be the case with Flex, as it’s FlexBuilder 3 IDE ships with memory and peformance profiling tools, as well as a full-featured debugger with breakpoints et al. That’s perfect if I was writing something in Flex, but it is completely useless for HTML/JavaScript AIR apps. I was able to get Spaz to run from within Flex Builder with a tiny bit of hackery, but the profiler gets no information about what’s going on within Webkit.

Other common choices for debugging web apps aren’t available either: Firebug is Mozilla-specifc, and the Drosera debugger and Web Inspector tools can’t hook into AIR’s Webkit instances. The information on Drosera does say:

In WebKit there is a WebScriptDebugServer which is started when WebKit starts and listens for a DCOM connection. Once a connection is made it will begin to interact with Drosera via Drosera’s ServerConnection class. WebScriptDebugServer informs Drosera about every line of JavaScript executed.

I would assume that WebScriptDebugServer exists inside AIR’s Webkit, but AFAIK this has not been utilized in any way. Adobe does have a nice AIR-specific tool called the AIR Introspector in the SDK, and it does offer some very useful functionality, but it too lacks step debugging and profiling capabilities.

That leaves us with good old console logging as our only option for debugging AIR HTML apps. That’s okay for simpler stuff, but tracking down execution bugs in more complex applications becomes extremely tedious. And console logging is basically useless for memory profiling, as there’s no insight into the underlying operations of Webkit.

I’m proud of the work I’ve done on Spaz, but as the application has grown in complexity, I’ve found the limitations of HTML app dev in AIR more and more problematic. Adobe has consistently stated that the HTML dev side of AIR is as important as the Flash/Flex side. To quote Mike Chambers:

Adobe AIR is as much about JavaScript, HTML, CSS, etc… as it is about Flash / Flex. #

If that truly is the case, Adobe needs to commit to providing a toolset for HTML/JS developers comparable to what Flex developers have. Until that’s changes, Mozilla’s XULRunner and Prism platforms are looking more and more appealing.

  • Ryan Stewart
    08/23/2008 02:18:51 PM

    This is really good feedback, so thanks for posting it. I’ll forward it on to the product teams because we definitely want to make HTML development as easy as Flex development is for AIR.


  • funkatron
    08/23/2008 02:55:52 PM

    Thanks Ryan. The guys on the Romanian team, especialy Dragos, have been very receptive to feedback and have been very helpful, so I don’t want this to seem unappreciative. They do very good work, and I would love to see them get more resources to improve the HTML side of AIR even more.

  • tom
    08/24/2008 10:47:21 AM

    Before you start with xulrunner: debugging it is very painful as well. We used it for a large-ish project with lots of forms (business logic) in 2007, but the following post from 2004 is still valid in many points:

    The first few week were bliss, xulrunner certainly allows you to prototype quickly.

    The following two month we hit so many walls that we re-did the gui in pygtk.

  • funkyboy
    08/25/2008 03:07:09 AM


    thanks for sharing. I can confirm many of the issues with Flex. Although there is a profiler, it is not easy to solve memory leaks, especially because you have no control over Garbage Collection. Let’s hope next releases of the framework will allow a lower level management of memory allocation/release.

  • funkatron
    08/26/2008 09:03:38 AM

    @tom: thanks for the feedback there. I think my approach might be a bit different in that I’d be placing most of the app inside an HTML renderer widget. That was I can still write in HTML and JS, and I should be able to use debugging tools like Firebug with a little muckery. I am interested in looking at pygtk, though.

    @funkyboy: I thought there was some (not a lot) of control over GC via the system.gc() call: Still, that’s not the same as easily discovering mem leaks. I think pushing Adobe for this kind of debugging is a good idea.

  • funkyboy
    08/26/2008 09:12:23 AM

    It is a very very very very vague suggestion to the GC. Let’s says you can tell it to act, but it takes much personal initiative in deciding when to intervene. :)

    More here (from one of the ebay desktop developers):

  • funkatron
    08/26/2008 10:14:37 AM

    funkyboy: That article made me want to shoot myself in the face.