构建 Flex 应用的 10 大误区

  • Jon Rose
  • 张龙

2008 年 4 月 25 日

话题:JavaWeb框架语言 & 开发架构

在这篇新闻中,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 AIRGoogle Gears这 样的技术使得应用可以离线运行。如果用户需要可以离线对应用时而你尚未准备好的话,那将你的应用改为支持离线特性将变得异常困难。典型地,在 web 应用 中,业务逻辑存在于服务器端。在离线 RIAs 中,业务逻辑必须转到客户端。为了使应用既支持离线,也支持在线,那就很有必要提前决定某些业务逻辑的位置。

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

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

JavaWeb框架语言 & 开发架构