構建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的內容以瞭解更多。