阻碍Flex应用的一个很大因素就是采用Flex框架的程序体积非常大。300-400K是很正常的大小了，对于当前的“宽”带环境，客户 不得不忍受非常长的loading时间，极大的影响了用户经验。更让人忍受不了的是，这几百k的大小中，往往我们自己的程序代码还占不到50K，其余都是 Flex的类库代码。从宏观上看，每个flex应用都加载相同的类库而不能互相共享是非常浪费的做法。
还好，Adobe在最新的Flex3中加入了Framework RSL机制来解决这个问题，这也是Flex3的最大亮点之一。RSL全称是Runtime Shared Library，即运行时共享库。当前RSL主要有3个级别的，一个是Standard RSL（即一个网站内共享），一个是Cross-domain RSL（跨域共享），最后一个也是最关键的是Framework RSL（Flex框架共享）。这里只介绍Famework RSL，其余的可以在帮助文档中或者这里查看。
Framework RSL是指Adobe官方为每一个版本的Flex制作一组RSL（当前版本包括3个RSL：framework RSL，data services RSL，data visualization RSL），同时为它们签名。Flex开发者需要做的是使用Framework RSL选项编译程序，你会发现你的程序体积会显著减少，同时你还需要指定这些RSL的地址以及如果加载RSL出错以后要加载的类库地址。这样，当一个用户 加载了任何一个使用此版本RSL的应用程序后，此版本RSL会被其缓存在flash player的cache中，并且这个cache不随着浏览器缓存清空而清空，以后如果此用户再次加载使用此版本RSL的程序的时候便不再需要加载此 RSL，加载速度将大大提高。这里需要注意的是，只有9.0.115 以上版本的flash player 才支持Framework RSL， 所以填写加载RSL出错后要加载的类库地址尤其重要，低版本的player会自动加载此类库以让程序正常执行。
在查看了这些RSL文件（swz后缀名）后，发现一个问题，就是Framework RSL的体积相当客观-_-!!!!。datavisualization 278K，framwork 526K， rpc 120K。最重要的framework RSL 居然有526K！对于player高版本的用户而言还好，因为只要加载一次。但是对于低版本的用户而言则意味着每次都要加载后备类库（类库大小与RSL文 件大小相当，和RSL文件在一个目录下，以swf为后缀名），这样的话，用户每次加载的时间反而增加了（当然，浏览器缓存能稍微帮些忙)。所以，现阶段 flash player 9.0.115普及率还很低的情况下是否使用Framework RSL还有待考量。
以上是对Flex3 framework RSL机制的整体介绍，具体细节还是看帮助文档或者在线文档的这一章吧。