|
Dealing with Build Times in AIR How to Reduce Build Times in Large AIR Applications Published Thu, Nov 08, 2007 at 2:47 AM Dealing with Build Times in AIR How to Reduce Build Times in Large AIR Applications Waiting....waiting...wait. Why is my AIR application taking so long to compile? We've built up a great framework around one of our AIR platforms but the shear number of files can really be rough on the compiler. I'm not the only person experiencing the problem either, Daniel is and Marc plus a bunch of posts on the Adobe forums. Since this issue will only increase in frequency as people push the boundaries of Flex, I thought I'd pull together some of our collective wisdom to try and save some up-and-comers from the same problem. First off, styling and specifically images are a huge source for compiling frustration. The compiler converts each image you Embed in your application to a Class file, which can be a relatively lengthy process. If you have to Embed all your images, rather than just specifying a URL, make sure you do so in the CSS. You can always comment out your CSS while you're working on core functionality and add it back in before production or design-related builds. When tasked with pixel-perfect design, Marc's suggestion about loading the styling at runtime seems to be the best approach. Compile all you images and associated styles into a separate Flex module and then load that at run-time. You'll only have to recompile the styling module if you make a change and that won't affect core application build time. Check out his article for specifics. Second, break up your application classes into functional libraries. This is just a good idea in general to support code reuse but it will also allow you to generate SWC's for those libraries. Also, make sure you point Flex Builder to the SWC file not the project otherwise it'll treat the library like additional source files rather than a compiled binary. One caveat to this approach is that you shouldn't be actively developing in these modules otherwise you'll drive yourself mad having to recompile both the library and then the main project to see the change. Try solidifying/testing the classes in the main application and then moving them into their own project workspace. Third, and this may just be a Vista issue, don't use networked drives to host your project workspaces. I'm not sure if its Java or the compiler but one of them really hates the latency associated with reading files into memory from a remote computer. I cut my build times in half just by moving everything to my local box. FYI, the original motivation for using the networked computer was because we had the Flex compiler shell hooked up for IIS, a sweet little piece of software if you're building Flex apps not so much for AIR. Lastly, invoking the command line utilities directly also appears to speed up the process a bit. I guess it should be too surprising that the developer OS that is Eclipse adds a little bit of overhead (and I'm pretty sure its the source of a memory leak or two). If you're not a command-line type of guy, you can find a great tutorial on setting up Ant build scripts for AIR up on Livedocs. If you're unfamiliar with Ant, it provides an XML format for command line utilities, so rather than: mxmlc -debug=true +flexlib=C:/AIRSDK/frameworks +configname=air -file-specs=.ExampleApplication.mxml you can pass ant a build file like this: <?xml version="1.0" ?> <project> <property name="SDK_HOME" value="C:/AIRSDK"/> <property name="MXMLC.JAR" value="${SDK_HOME}/lib/mxmlc.jar"/> <property name="ADL" value="${SDK_HOME}/bin/adl.exe"/> <property name="ADT.JAR" value="${SDK_HOME}/lib/adt.jar"/> <property name="APP_NAME" value="ExampleApplication"/> <property name="APP_ROOT" value="."/> <property name="MAIN_SOURCE_FILE" value="${APP_ROOT}/${APP_NAME}.mxml"/> <property name="APP_DESCRIPTOR" value="${APP_ROOT}/${APP_NAME}-app.xml"/> <property name="AIR_NAME" value="${APP_NAME}.air"/> <property name="DEBUG" value="true"/> <target name="compile"> <java jar="${MXMLC.JAR}" fork="true" failonerror="true"> <arg value="-debug=${DEBUG}"/> <arg value="+flexlib=${SDK_HOME}/frameworks"/> <arg value="+configname=air"/> <arg value="-file-specs=${MAIN_SOURCE_FILE}"/> </java> </target> </project> Ok, so maybe Ant looks a little verbose....but at least it can be reused and auto-generated, which is what we're working on internally. It might be too late for me on my current application but hopefully I've saved you a little frustration. Cheers, |