flex编程感受

cimmicola能否讲讲flex开发经验(轉貼)应该清楚Flex是完全编译成swf文件后交由客户端浏览器中的Flash player来执行的。而不像传统web语言，经由服务端进行解释后转化为纯html元素和脚本。

这样来说，一个纯Flex应用（主要是指企业级开发，有很多功能和业务流程的那种）编译之后的体积，基本上是不能在互联网上访问的，不采取任何优化手段，应用程序就会达到900K~几兆，对于现在普遍的1M带宽来说，下载速度已经是不能接受的了，而且浏览器的下载也不会是断点续传，一旦下载受到干扰，那么下载就中断了。因此Flex的企业应用最适合的是在局域网内使用，如果有外网访问的需求则会比较棘手，对于RIA来说，缺少了互联网，不是致命缺陷吗？而且我认为这绝对不是提高带宽可以做到的，因为现在早有5M~10M的带宽了，可是装的人还是很少，而且我公司是100M独立光纤，都没能解决这个问题，你不能让所有的用户都是100M独立光纤吧？

这点JavaFx也存在同样的致命问题，也是JavaFx没有被RIA甚至是Java自己阵营的人接受的原因。这点silverlight很好的在其运行环境中解决了，它能直接执行axml文件和其中的脚本，而无需事先编译成二进制的文件。这是我觉得他最大的优势。我们现在能做的只是尽量减少体积带来的影响，而不可能完全解决，问题的本还是Flash player，Adobe还要加油啊。

而Flex很年轻，很多人都没有项目开发经验，因此都是从官方或者从国外一些人的教程那里学习和借鉴的，包括我在内。但事实是，Flex官方的教程甚至是样例程序都是很糟糕的。因为大家访问时都是在自己本机上，而那些应用都是很小很小的，感觉不出这样带来的不良影响。因为很多学习Flex的人可能不是搞程序出身，而是搞Flash的，这样他们对程序的理解，对设计，都缺少认识，绝对会依葫芦画瓢的

举个例子在一个MXML文件中的方法，经常是没有参数，而是在函数内部调用该页面内其他元素的，这有个非常大的不好就是，这些代码不能被抽象出来，使得每个页面都有些相同的冗余代码。越到后期会使得程序体积越大，代码越来越难管理，经常会在方法中发现一些既不是方法内声明的变量，也不是传进来的参数，就满文件的找，这个变量是哪里来的局面，使得改造和维护代码变得很艰难。

除了以上说的一点还有一些经验和大家分享一下。
1. 尽量抽象出方法，写进as类或者as文件中，以降低耦合度（避免方法的依赖性）。而关于业务的一些操作方法那是没办法避免的。

2. 尽量将会公共使用的组件抽离出来，比如说一些通用性的组件，单独的作为component会比直接写进程序好的多。除了降低程序体积外（模块中会讲原因），还会提高重用，便于维护。

3. 采用模块化设计会分散主程序的体积（总体上会增加体积，但是拆散了），Flex在编译文件时，会将共用部分编译进主应用，而模块中将不包含这些资源，因此，这些模块只能被你的主程序调用，而其他程序调用时，会因为缺少某些组件或者类而报错。但是请不要过高的期望与模块带来的惊喜，根据项目不同，他可能并不能太大的减少你的应用的体积。

4. 搜一下关于模块体积优化的策略，你会找到RSL，和report.xml的一些做法。他的做法类似与将Flex的核心文件拆散成若干小的swf程序，分批的下载，因为有些库你可能在项目中完全没用到，那你完全可以不用把那个库引用进项目。

5. 主应用的下载我们是避开不了的，但是那些模块就不同了，我们有很多下载策略，比如加载主应用时把所有模块都加载进来，这样避免排队式的等待。企业级应用多数和权限挂钩，结合模块式设计，我们能很轻松的将权限控制起来，如果你没这个模块的权限，那就不要加载了。

6. 尽量不要将资源Embed进程序，比如图片，音乐之类的，Embed的嵌入进你的项目，使得体积增大。

7. 暂时不要使用Flex3提供的runtime localization的做法，他会把语言资源嵌入进程序，这样不仅加大体积，还会使得本地化时依赖源代码。需要的话，最好读取出来，从xml或者数据库都行。

8. 样式最好都写进css，然后编译时选择将css编译成swf，不然它又把css编译进应用里去了。

9. 一定要有个框架，因为我们现在对Flex的架构、功能都不熟悉，自己包装一次，在以后加深了对Flex的理解后会更容易扩展，如果全部是用的Flex默认的东西，就很难扩展了，搞不好就要大改。举个简单的例子，popupmanager是用来弹出窗口的，有人会觉得弹出来没特效，如果你直接在代码中用到Flex的popupmanager，那么你想加入特效就得一个一个的去加，如果你事先设计时封装了一次这个popupmanager，那么简单多了，直接改你的popupmanager，再弹出的时候加入特效多好。这点建议看看design pattern（遗憾的是，我后来才知道有这么个好东西，否则就能更快的进行设计了）。

10. 不推荐使用其他的什么框架，但是一定要把Flex的一些核心了解透彻，比如事件机制，异步，组件设计，组件生命周期，绑定等，这些是非常重要的设计依据，好在Flex部分核心是开源的，可以学习一下他们的写法。而那些框架，第一，那本来就不是你写的，对那个框架的了解，不如你去自己包装一下。第二，现在的框架谈不上成熟，本身也过于复杂，而我没看出那些框架有多大的好处。既然目的是为了方便扩展和修改，那么自己的框架会更适应这样的需求。

11. 不要import xxx.*，这样你不用的也导进来了。
同理在设计时，如果不是一定需要那个组件，比如你只需要一个容器，你new Container会比 new Canvas更好，基类在编译时体积小于继承类，因为他的import和方法都少一些，除非你依赖Canvas某些属性或功能。但是后者要求有些苛刻，因为在一个模块中有一处引用了canvas，那么你这个做法也是徒劳的了，总体原则是，如果不是必须，不要引用你不需要的东西。

12. 还有个变态的东西，如果纯as project会比flex project体积小10倍以上，对于相同效果，我用flex做就是200K+，用as 项目做就是19K……，但是要想实现Flex强大的组件，那有点麻烦，我们可以考虑，对于程序框架采用Flex做，而一些不是基于Flex组件的，比如：你需要绘图面板，那么这个功能纯粹是as的功能，那么你就在as 项目中开发，然后编译成swf后再在flex中应用，这样体积会比你用flex的组件构建要小。



……还有什么想不起来了，有就补充吧，各位也可以。呵呵，个人认为以上内容绝对是书本里找不到的~
但是我们看到，为了缓解本该不是我们解决的问题，采用了一些极端的抠门的方法，使得设计和开发时也颇为伤脑筋，本来客户端我们需要考虑的时如何提高用户体验，关注的是业务流程，但是，现在为了优化程序不得不考虑减少程序体积，而在程序功能、开发和设计的心情（太抠门会让自己很不爽）与程序的体积之间徘徊了。这样是我为什么说Flex作为企业级应用开发尚不成熟的根本原因。

当然服务端针对这种纯RIA应用也有些设计上的注意点，不过这不在Flex讨论范围内，就不赘述了。

评论

1 楼 luofeng113 2008-12-26  

分析得不错，