构建 Flex 应用的 10 大误区

在这篇新闻中， Adobe 的 James Ward 与 InfoQ.com 一起为你带来了 Flex 的另一种 10 大（ Flex 最新的 10 大）。Flex 是一个开源的应用开发框架，用来构建运行在 web（使用 Flash Player）或者桌面上（使用 Adobe AIR）的富 Internet 应用。总之，Flex 是一个强大易用的框架，但是今天让我们瞧瞧构建 Flex 应用时经常犯的错误。

对于 Flex 新手，请阅读 InfoQ 最近的 _ Adobe Flex Basics _ 以对该框架有一个快速的了解。下面是易犯的错误列表：

1. 使用 RIA 框架去构建 Web1.0 应用（新技术换汤不换药）。

从 Web 1.0 到 RIA 的过渡中最大的挑战之一来自思考方式的转变。Flex 给予开发者一个高级的组件库，使其可以完成很多以前不可能完成的任务。但是很多时候，Flex 的这种能力被忽略了，它仅仅被用来实现更加传统的 Web 1.0 应用。

构建 Web 2.0 应用不仅仅意味着页面的局部刷新和旋转的圆角图标。例如，Flex 开发者应使用矢量图向用户提供数据的可视化表示，以及对于富应用流的高级控制。最近 Stephan Janssen与 InfoQ.com 一起讨论了该议题：

作为一个 Java 开发者，对于面向对象的 ActionScript 和 UI 标记语言的学习简直就是小菜一碟。但是对于（Java）开发者来说真正的挑战在于我们不是设计师，并且这两个技术对于 RIA 来说是必不可少的。

2. 破坏标准的浏览器体验

尽管 Flex 确实提供了一个优秀的平台以改善用户体验，但是保持用户习惯，如后退按钮、书签和自动完成也是相当重要的。

Flex 3 包含了新的深层链接特性以支持后退按钮和书签。你可以访问 labs.adobe.com 来了解更多。那有很多组件能够实现自动完成。你可以使用来自于 Adobe Exchange 的 AutoComplete Input 组件。

3. 使用过多的容器导致应用变慢

Flash Player 使用了一个按层次显示的对象图，这一点与 HTML 的文档对象模型（DOM）很相似。容器嵌套的层次越深，渲染所花费的时间就越长。Adobe 的 Flex 开发者中心有一篇文章讨论了关于 Flex 性能的最佳实践，包括了容器的使用细节：

Flex 最大的性能风险来自于对容器的滥用。嵌套太多的容器会影响应用的性能。这是 Flex 开发者面临的最严重的性能风险——不过还好，它完全能被避免。

4. 使用 XML 而不是其他更优化的协议导致应用变慢

Flex 向开发者提供了多种选择以在 Flex 客户端和服务器之间进行数据传输，包括 AMF3、XML、SOAP 及直接的 HTTP 请求。Ward 在他的人口普查应用中阐述了这些技术的使用及性能。

对于后端使用Java 的新项目来说，应该考虑一下BlazeDS。BlazeDS 是 Adobe 最近的一个开源数据服务产品，它使用了 AMF3 协议。AMF 是一个二进制传输协议，很容易与 Java 集成，其性能要优于 XML。对于所有主要的后端技术都有相应的 AMF 开源实现。

如果你不选择 BlazeDS，那么你还可以选择 Hessian。 Hessian 对二进制的 web services 协议提供了 ActionScript/Flex 支持。

5. 试图雇佣 Flex 开发者

现在很难找到有经验的 Flex 开发者。Flex 现在正处在上世纪 90 年代 Java 所处的位置。Flex 开发者已经供不应求了。这就造成了难以寻觅 到有经验的 Flex 开发者的后果。然而，这给 Java 开发者创造了一个很好的机会以扩充技能，并且从事一种新兴且有趣的技术。很多寻找 Flex 开发者的公 司直接对 Java 或者其他 web 开发者进行几周的 Flex 培训，并且大获成功。对于熟悉 Web 和 GUI 编程的开发者来说，学习 Flex 语言和 APIs 易如反掌。

6. 特效的过度使用

开发者可以很容易地通过 Flash 增加特效。但是要确保特效有意义并且与上下文是匹配的。否则他们只会让用户反感。特效的时间选择也很重要。交互设计器可以帮助我们决定何时应使用特效，何时不应该使用。交互设计器还能为我们推荐最佳的特效类型、间隔和最简化的功能。

关于特效的使用在 laair.org 上有一篇好文：

大多数的特效简直太长了。它们不但长，而且还慢，甚至让人反感。关掉它。如果我遇到这种事情的话，我就会转身离去，因为我实在讨厌这种等待。 千万不要误会我，我并不是反对特效。我只是反对为了目的而做的太长或者太过分的特效。每个特效都可以依照其目的进行分解。找到你要特效的目的，然后再使用它。

7. 没有搭建企业生态系统

就像其他的软件项目一样，为于你的 Flex 应用建立企业生态系统是非常重要的。

测试驱动开发（TDD）在当前是大多数企业项目的首选方案。对于 Flex 来说， FlexUnit 框架可用来编写单元测试。在 Adobe 的开发者网络上， Neil Webb 讨论了面向 Flex 开发者的 TDD 及 FlexUnit 的使用。此外， Flexcover 可用来度量代码覆盖率。

当多个开发者协同工作时，持续集成（ Continuous Integration ）被证明是良好的实践。与 Java 应用类似，也有相应的 Ant 和 Maven 插件对你的 Flex 应用进行持续集成。

8. 没有使用整个框架

在 Adobe Flex 中有大量可选的特性，你应该考虑在你的应用中使用它们。例如，运行时共享库（ Runtime Shared Libraries ，即 RSL）可用来减少应用的大小。

你可以将共享资源集成到单独的文件中，这样就可以在客户端单独下载和缓存了，通过这种手段可以减少应用产生 的 SWF 文件的大小。很多 Flex 应用可以在运行时加载这些共享资源，而每个客户端只需下载一次即可。这些共享资源叫做运行时共享库（Runtime Shared Libraries）。

框架的另一个特性是内建的辅助功能。你可以通过 Adobe 在线文档了解更多的关于 Flex 的辅助功能的信息。除了内建的辅助功能外，框架还提供了对于本地化的内在支持。请访问 Adobe 新手上路来了解最新的 Flex3 框架特性。

9. 使用复杂的渲染器降低了 DateGrid 的速度

针对 DataGrid 开箱即用的 itemRenderer 已经有过很好的优化了。误解#3 讨论了嵌套过深的容器的性能问题。在 Flex 中有一个地 方很容易造成容器的深层次嵌套，那就是 DataGrid 的 item 渲染器。由 DataGrid 所渲染的 item 渲染器数量等于可见的行数乘以可见的列数。 定制的 DataGrid 和 List item 渲染器应该经过非常好的优化才行。当需要在 item 渲染器中使用复杂的布局逻辑时，最好使用 UIComponent（或者其他底层类）并且手工完成该单元格内容的定位。

10. 没有准备离线应用。

RIAs 的传统模型在于浏览器。然而像 Adobe AIR 和 Google Gears 这 样的技术使得应用可以离线运行。如果用户需要可以离线对应用时而你尚未准备好的话，那将你的应用改为支持离线特性将变得异常困难。典型地，在 web 应用 中，业务逻辑存在于服务器端。在离线 RIAs 中，业务逻辑必须转到客户端。为了使应用既支持离线，也支持在线，那就很有必要提前决定某些业务逻辑的位置。

查看 InfoQ.com 上有关 Flex 的内容以了解更多。

查看英文原文： Top 10 Mistakes when building Flex Application