MacroViz

當 Flex 專案變龐大，Building workspace (編譯專案) 的速度會變得極慢。不過野部也發現一些方法，可以大幅提升 Building workspace 的速度。
每次 Building workspace 之後，我們可以看到 0 errors, 0 warnings, 0 infos。提升速度的竅門，在於讓這三個數字都保持 0。 errors 並不可怕，因為修正之後，errors 並不會再次出現，拖慢 Building workspace 的速度。
真正可怕的是 warnings。warnings 的產生，野部歸納為下列幾種原因：

1. 函式的宣告，並未宣告 public 或 private，就直接以 function 開頭。
2. 函式的宣告，並未宣告類型，如 void、String、Number 等，就直接在 (…) 後接上 {…}。
3. 變數的宣告，並未宣告 public 或 private，就直接以 var 開頭。
4. 變數的宣告，並未宣告類型，如String、Number等，就直接以 ; 結束。
5. CSS 宣告的 Tag ，並未在 Application 的 MXML 中出現。
6. 外部 CSS 套用到 Custom component 上。

第 1 ~ 4 項，留心改善便可。第5、6項，其實是吃掉 Building workspace 的元兇。在Adobe / Macromedia 網頁設計工具中，例如 Flex、Dreamweaver、或是 Flash，針對 CSS 的運用時機，可分為 Design mode/time (設計時期之外觀) 和 Run time (執行時期之外觀)。
當我們在 Flex 使用 <mx:Style 標籤時，不論是外部或者內部 CSS，就是使用了 Design mode CSS。而每次存檔，Design mode CSS 都必須重新套用到整個專案，並輸出成 swf 檔，速度一定會很慢。
有時候，我們不得不將外部 CSS 套用到 Custom component (自訂元件，類似 Java Beans 的觀念，BCB or VB 也具有相同或類似的運作觀念)上。雖然外部 CSS 對 Custom component 的 Control (設計控件) 仍具有影響力，但是會出現一大串 warnings。
所以，野部提出幾個變通的方法。

1. 盡量減少 Custom component，改用 Application 搭配 SWFLoader，並根據不同的 Application 設計不同的外部 CSS。 每次 Custom component 的存檔，會影響所有引用這個 Custom component 的 MXML 重新編譯，這也是拖慢 Building workspace 的速度的另一個主因。
2. 用 Actionscript 產生 Control，不過這樣做，就走回 JAVA 在人機介面設計上，被人家詬病的老路了。不過野部知道，有些從 JAVA 領域來到 Flex 領域的設計師，極端偏好此道。優點是執行效率真的極端的高，缺點是這個專案無法讓太多不同背景的人共同 teamwork。如：視覺設計師、或專案經理。專案的邏輯只有程式設計師自己看得懂而已。萬一這位程式設計師離開專案，這專案就掛定了。
3. 將 Desing mode CSS Complie 成 Run time CSS。Run time CSS 的哲學是，程式開始執行才導入外部 CSS 去改變外觀。不但可以避開 Design mode CSS 重新套用的低效能，也不會產生任何 warnings。詳細做法，可參考 Flex Help 內的幾個主題：

1. Using external style sheets
2. Loading style sheets at run time

個人認為，上列三種方式，可靈活變通運用，不必極端。用得好，就是有效，用得不好，那就不如不用。

另外，針對除錯效率方面。雖然 Flex Builder 在 Eclipse 開發環境下，已經整合了自動提示 errors 的功能。可是過度依賴這個功能，是不好的觀念。而且，每次都讓開發環境去提示，可是得浪費掉很多效能和時間的。野部的 Flex 專案開發環境，最高消耗掉 700 多 mb 的記憶體。
正確的開發觀念是，一次就把程式寫對了，別讓開發環境來提醒。然而，弔詭的是，開發環境沒 errors，不見得寫下的程式就是對的。下面兩種情形，就是這樣的：

1. 某些 Default control 被 implement 時所呼叫的 Manager 有 bug，而我們並不知道這樣的 bug 存在。目前已知的情形是 ComboBox 所呼叫的 IPopUpManager 有這個情形。解決方法是要自行先 import 這個 Manager。聽說 DragManager也有。由於許多 Control 被 implement 都會使用到 IPopUpManger 和 DragManager，例如 ComboBox 或者 List，當發現下拉清單拉不下來時，就是了。所以，還是養成好習慣，調用 Manager 時，用和 JAVA 一樣嚴謹的態度完全 import，甚至開發環境沒有提醒到的，還是要強制 import。
2. 濫用的 parentApplication。在 Custom component 內的 parentApplication 語法會去參照引用這個 Application/Custom component 的最上層的 Application，不論中間引用的 n 層的 Application/Custom component。所以，可能是基於運算效能上的考量，開發環境並不會去偵測和除錯 parentApplication 語法，成了隱形的炸彈。parentApplication 絕對不是唯一的解決方案，還有很多寫法可以取代。parentApplication 用法可參考 Flex Help：

1. About the Application object
2. Passing data

還有一個小技巧，對設計師在 layout 上影響不大的一些 Control 就可以善加使用迴圈 + this[字串] 讓 Actionscript 自動產生或者批次處理大量的 Control，或者使用 repeater 達到同樣的目的。不但可以大幅減少 MXML 和 as 的檔案長度、增加程式的可讀性，並且不用重複撰寫多次類似的函式。

這些經驗的歸納，來自於野部不斷犯的錯，以及工作夥伴們，用血淚堆砌的開發經驗，希望對大家在開發 Flex 專案上，有所幫助。

當在專案中，運用的自訂元件越來越多層時，為了頁面的切換和導覽，有時候會需要存取上層，或同層之間的變數或物件，這個時候，Flex 的 Actionscript 3.0 提供了parentApplication作為一個解決方案。野部用一個通俗的概念來描述，parentApplication 可以視同為 flash 開發環境下的 _root，但是限制比較多，可以有下面幾種運用方式：

1. parentApplication.componentID.objectID.property
2. parentApplication.objectID. property
3. parentApplication.varableName

但是當遇到兩層元件以上的時候，用下列語法會造成執行錯誤：

componentID.componetID.objectID.property

此外，parentApplication還有幾個需要注意的事項：

1. 一定是從最上層也就是 <mx:Application> 那一層開始算起
2. 引入自訂元件一定要下 ID，如 <local:myComp id="myComp">，這點有時候會被忽略。
3. 如上所述，元件只能一層。
4. parentApplication 之後的語法，Flex Builder 不會即時除錯，必須等到在瀏覽器中執行時才知道錯誤與否，因為超過運算範圍。

可是有時候為了導覽，不得不跨層存取，限制那麼多，又不能即時除錯，那該怎麼辦呢？

其實解決方法很簡單，就是在最上層，也就是<mx:Application>層，宣告一個 public 變數。之後任何一層，需要存取或者判斷時，直接用parentApplication.varableName 的方式來達成就行了。

P.S. 上述的componentID, objected, property, varableName 請代換成您自己的語法就行了。

野部

花了一些時間，終於完成了 0.0.5 版了。後來才體驗到，如果瞬間透過 E4X 存取 XML 六千多次，那執行效能真的非常差。所以後來字典書的切換，用別的方式寫。效能就改善很多了。

這一次有下列幾項重大更新：

其實，到了這個版本，才完成了我當初想要開發 Verbal Plus 的大部分的功能。例如自訂字典，加入紅寶，字母分組，搜尋 Time 雜誌等等。歡迎有興趣的朋友，前往下列網址下載最新版本：

http://blog.macroviz.com/verbal_plus