RSL也需要谨慎使用
RSL也不是对于所有的应用都是有益的. 需要对应用RSL前后的下载时间和启动时间都测试过, 才能得到正确的结论.
RSL不能跨域共享. 如果客户在一个域中使用了RSL, 然后运行了另一个域的应用, 虽然这两个RSL是相同的, 但是需要下载两次.
RSL通常会增加应用的启动时间. 这是应用不管整个库实际如何使用, 只是简单地全部加载整个库. 就这一点来说, RSL越小越好. 这与静态链接库的使用是不同的. 当你编译一个Felx应用时, 编译器只解开需要的组件. 一般来说, 库的大小可以是任意的, 它只影响编译时间而不会影响下载的时间.
如果在好几个应用中使用相同的组件库, 那么可以考虑合并这些库, 形成一个RSL. 但是如果库合并后, 每个应用只会用到其中的一小部分, 那么还不如多加载几个小RSL更高效.
如果一些类重复打包在多个RSL中, 那么一定要注意同步更新的问题.
RSL不能应用在基类是Sprite或者MovieClip的纯ActionScript项目中. 因为RSL需要基类知道如何加载RSL, 比如: Application或者SimpleApplication.
关于 framework.swc文件
framework.swc是一个标准的SWC文件. 缺省地它不能用作RSL. 整个framwork.swc文件不被链接到任何一个应用中. Flex编译器只将那些应用用到的部分链接到生成最后的SWF文件. 比如: 如果一个应用只使用了Button, Panel和TextArea控件, 那么只有这几个控件和它们的依赖项被编译器链接.
几乎所有的应用都需要framework.swc文件的一部分, 但是它并不适合作为RSL. 原因如上据说, RSL是整个链接, 不管实际使用多少的. 如果RSL包含了很多类, 而应用只使用了其中的一小部分, 那么这样的加载方式并不是最合理的. 这样使用会造成应用的启动时间大大增加.
RSL的优点
下面的一个例子说明了将几个的共享组件做成RSL的优点. 在这个例子中, 组件库的大小是150K, 编译后的应用的大小是100K.
使用了RSL, RSL只被下载一次. 那么合计下载量是350K, 节约了30%. 如果再添加第3个, 第4个应用的话, 每次都能150K的下载量.
一般来说, 在一个域中使用同一个RSL的应用越多, 那么好处就越大.