建構Flex應用的10大誤區

Player）或者桌面上（使用Adobe

AIR）的富Internet應用。總之，Flex是一個強大易用的架構，但是今天讓我們瞧瞧建構Flex應用時經常犯的錯誤。

1. 使用RIA架構去建構Web1.0應用（新技術換湯不換藥）。

從Web

1.0到RIA的過渡中最大的挑戰之一來自思考方式的轉變。Flex給予開發者一個進階的元件庫，使其可以完成很多以前不可能完成的任務。但是很多時候，Flex的這種能力被忽略了，它僅僅被用來實作更加傳統的Web

1.0應用。

建構Web

2.0應用不僅僅意味着頁面的局部重新整理和旋轉的圓角圖示。例如，Flex開發者應使用矢量圖向使用者提供資料的可視化表示，以及對于富應用流的進階控制。最近Stephan

作為一個Java開發者，對于面向對象的ActionScript和UI标記語言的學習簡直就是小菜一碟。但是對于（Java）開發者來說真正的挑戰在于我們不是設計師，并且這兩個技術對于RIA來說是必不可少的。

2. 破壞标準的浏覽器體驗

盡管Flex确實提供了一個優秀的平台以改善使用者體驗，但是保持使用者習慣，如後退按鈕、書簽和自動完成也是相當重要的。

3. 使用過多的容器導緻應用變慢

Flash

Player使用了一個按層次顯示的對象圖，這一點與HTML的文檔對象模型（DOM）很相似。容器嵌套的層次越深，渲染所花費的時間就越長。Adobe的Flex開發者中心有一篇文章讨論了關于Flex性能的最佳實踐，包括了容器的使用細節：

Flex最大的性能風險來自于對容器的濫用。嵌套太多的容器會影響應用的性能。這是Flex開發者面臨的最嚴重的性能風險——不過還好，它完全能被避免。

4. 使用XML而不是其他更優化的協定導緻應用變慢

5. 試圖雇傭Flex開發者

現在很難找到有經驗的Flex開發者。Flex現在正處在上世紀90年代Java所處的位置。Flex開發者已經供不應求了。這就造成了難以尋覓

到有經驗的Flex開發者的後果。然而，這給Java開發者創造了一個很好的機會以擴充技能，并且從事一種新興且有趣的技術。很多尋找Flex開發者的公

司直接對Java或者其他web開發者進行幾周的Flex教育訓練，并且大獲成功。對于熟悉Web和GUI程式設計的開發者來說，學習Flex語言和APIs易如反掌。

6. 特效的過度使用

開發者可以很容易地通過Flash增加特效。但是要確定特效有意義并且與上下文是比對的。否則他們隻會讓使用者反感。特效的時間選擇也很重要。互動設計器可以幫助我們決定何時應使用特效，何時不應該使用。互動設計器還能為我們推薦最佳的特效類型、間隔和最簡化的功能。

大多數的特效簡直太長了。它們不但長，而且還慢，甚至讓人反感。關掉它。如果我遇到這種事情的話，我就會轉身離去，因為我實在讨厭這種等待。 千萬不要誤會我，我并不是反對特效。我隻是反對為了目的而做的太長或者太過分的特效。每個特效都可以依照其目的進行分解。找到你要特效的目的，然後再使用它。

7. 沒有搭建企業生态系統

就像其他的軟體項目一樣，為于你的Flex應用建立企業生态系統是非常重要的。

8. 沒有使用整個架構

你可以将共享資源內建到單獨的檔案中，這樣就可以在用戶端單獨下載下傳和緩存了，通過這種手段可以減少應用産生 的SWF檔案的大小。很多Flex應用可以在運作時加載這些共享資源，而每個用戶端隻需下載下傳一次即可。這些共享資源叫做運作時共享庫（Runtime Shared Libraries）。

9. 使用複雜的渲染器降低了DateGrid的速度

針對DataGrid開箱即用的itemRenderer已經有過很好的優化了。誤解#3讨論了嵌套過深的容器的性能問題。在Flex中有一個地

方很容易造成容器的深層次嵌套，那就是DataGrid的item渲染器。由DataGrid所渲染的item渲染器數量等于可見的行數乘以可見的列數。

定制的DataGrid和List

item渲染器應該經過非常好的優化才行。當需要在item渲染器中使用複雜的布局邏輯時，最好使用UIComponent（或者其他底層類）并且手工完成該單元格内容的定位。

10. 沒有準備離線應用。

樣的技術使得應用可以離線運作。如果使用者需要可以離線對應用時而你尚未準備好的話，那将你的應用改為支援離線特性将變得異常困難。典型地，在web應用

中，業務邏輯存在于伺服器端。在離線RIAs中，業務邏輯必須轉到用戶端。為了使應用既支援離線，也支援線上，那就很有必要提前決定某些業務邏輯的位置。