If you are running multiple Flex applications on a server you should seriously consider using Flex Framework RSLs (runtime shared libraries) to reduce redundancy by eliminating the loading of the same core framework libraries used by all applications. The result could be a reduction in the size of your application SWF file to 1/10th of the original size! I recently implemented this approach for Tour de Flex since each of our hosted samples is its own application and would ultimately contain a large amount of code shared by all the other samples. I saw the size of the swf’s for the samples go from 572k to 57k just by making one small change, removing the core Flex Framework RSL’s from the resulting swf.
The good news is, in Flex 4 previously optimized core framework RSL’s are enabled by default and dynamically linked at runtime (versus compiled into the code via the ‘merged into code’ option). This option is specified in the project properties under Flex Build Path. Under the Library Path tab there you will see a Framework linkage selection that should look like the screenshot below and use runtime shared libraries by default. If it does not show that as the default, you can also select Runtime Shared Libraries from the drop-down list to ensure they are used.
It’s important to understand what is happening here whether you are using Flex Builder or Flash Builder. Obviously with Flex Builder you will need to modify that option if you want to take advantage of the performance gain of having those libraries externalized. However even with Flash Builder and using Flex 4 it’s important to note what is happening, because though the RSL’s are enabled by default, the default configuration settings currently create a copy of the RSL locally for each of the different SWZ files (the extension of the core framework RSL). This means that when you export your release build for your application (File -> Export -> Release Build) you will have a copy of the each of those 6 .swz files created ranging from 60kb to 620kb. The 6 .swz files (release build number will vary) are:
This may not be a big deal, but in the case of Tour de Flex samples there was no reason to have a copy of these files for every single sample on our server. I thought it would be useful to share this in case others were faced with this same issue or wondering what the heck all those .swz files were in their release directory. If you want to make a change to how this works, you can change your Flex configuration file to point to a different location for the runtime shared libraries other than creating them locally. There are two XML tags that specify an RSL location in the configuration file for each of the shared libraries. The first one points to the official Adobe path where they are located and you should leave that one as is. The 2nd one specifies the failover URL that you would want to change to point to a single location on a server somewhere for instance. For Tour de Flex I modified each of the failover URL paths in the configuration file to point to our Tour de Flex server that had all of those SWZ files (RSL’s) in one location. Then when I compiled each sample (or any application for that matter once these settings are changed, so be careful) it would no longer generate those local .swz files.
Here’s an example of one of the six default RSL path settings from the flex-config.xml file that comes with the Flex 4 SDK. The flex-config.xml file is the Flex configuration file and located on Mac for instance at /Applications/Adobe Flash Builder 4/sdks/4.0.0/frameworks/flex-config.xml:
<!-- Spark SWC--> <runtime-shared-library-path> <path-element>libs/spark.swc</path-element> <rsl-url>http://fpdownload.adobe.com/pub/swz/flex/184.108.40.20659/spark_220.127.116.1159.swz</rsl-url> <policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url> <rsl-url>spark_18.104.22.16859.swz</rsl-url> <policy-file-url></policy-file-url> </runtime-shared-library-path>
with these settings you will see the RSL files generated in the local bin-release directory when the application is built for release.
In the case of Tour de Flex, I changed that 2nd tag to point to our TDF Server location. For example:
<!-- Spark SWC--> <runtime-shared-library-path> <path-element>libs/spark.swc</path-element> <rsl-url>http://fpdownload.adobe.com/pub/swz/flex/22.214.171.12459/spark_126.96.36.19959.swz</rsl-url> <policy-file-url>http://fpdownload.adobe.com/pub/swz/crossdomain.xml</policy-file-url> <rsl-url>http://tdfserver/RSL/spark_188.8.131.5259.swz</rsl-url> <policy-file-url></policy-file-url> </runtime-shared-library-path>
When Flash Builder was then restarted with these settings and a sample recompiled, the local SWZ files were no longer output in the local release directory. IMPORTANT NOTE: if you keep Flash Builder open while you modify your flex-config.xml file you must restart it to pick up the changes. You also may need to delete the bin-release folder of your project first before seeing the change from recompiling.
There is also an option in Flash Builder that will create local copies of the runtime shared libraries in your bin-debug folder by default. If you look at the same Build Path -> Library Path settings in the Flash Builder screenshot above (1st screenshot), notice the checkbox for ‘Use local runtime shared libraries when debugging’, you will see that same set of files (but .swf) generated in your bin-debug output. When you uncheck this box they will not be generated. I thought it would be useful to point this out as well.
The last thing I want to note is that you can also use command line compile to change the option of where to load the RSL file from. Loads of information on how to do that, as well as more information on Framework RSL’s in general can be found here.