MacroViz

01

一月

大家 2009 新年快樂

美國東岸時間比台灣時間慢 13 小時，雖然台灣的大家在昨天已經跨年完畢了，不過野部還是要祝大家新年快樂。

正在一邊看著 CNN 在時代廣場上的 live 的轉播倒數，一邊寫這一篇文章，我要去倒數了 10, 9 , 8…

posted by 野部聖広 in 節慶 and have No Comments

Tags: 節慶

28

十二月

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

函式的宣告，並未宣告 public 或 private，就直接以 function 開頭。
函式的宣告，並未宣告類型，如 void、String、Number 等，就直接在 (…) 後接上 {…}。
變數的宣告，並未宣告 public 或 private，就直接以 var 開頭。
變數的宣告，並未宣告類型，如String、Number等，就直接以 ; 結束。
CSS 宣告的 Tag ，並未在 Application 的 MXML 中出現。
外部 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。
所以，野部提出幾個變通的方法。

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

Using external style sheets
Loading style sheets at run time

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

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

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

About the Application object
Passing data

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

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