技術角度論Flex與Silverlight優劣
這樣的比較有意義嗎？個人意見，只要別把自己當成宗教教徒，將語言看作工具而不是信仰，那么比較就是有意義的。
|
語言（Silverlight以C#為準） | |||
|
特性 |
比較 |
勝出 | |
|
Flex |
Silverlight | ||
|
語法 |
Flex的編程語言ActionScript在變量與屬性聲明的方面語法有一點羅嗦（有些類似VB）： public var varName : int; 相比之下C#就要簡潔一些： public int varName; 不過，ActionScript支持以字面量的方式聲明字典，這方面又比C#的Dictionary來得簡明： public var dict = { x: 1, y: 2 }; |
|
√ |
|
語言特性 |
ActionScript支持動態類屬性，這是C#目前所不支持的，因此在動態編程方面，Flex要簡潔得多，也減少了很多代碼生成的工作。 |
√ |
|
|
OO特性 |
ActionScript不支持抽象類和抽象方法。雖然對一般性的編程來說沒有太大問題，但是對框架設計來說這是一個嚴重的缺點。 |
|
√ |
|
反射 |
反射對于元編程是相當重要的。Flex的反射機制比較原始，只支持有限的反射方法，并且代碼中沒有明確引用的類在編譯階段會被排除，這使得動態創建類更為麻煩。 不過得益于語言的動態特性，Flex反射代碼比同等的C#代碼要更加簡明。 Silverlight也排除了一些高級反射特性（比如TypeDescriptor相關的一些方法），不過總體來說反射機制還是比較完整的，但同時反射的語法比較羅嗦。 |
|
√ |
|
基本類庫 |
Flex的基本類庫相當精簡，精簡的代價就是有些基本功能（如字符串的trim、日期的格式化）都欠奉，不得不求助于工具類庫。Flex的集合類庫功能也有一些薄弱。 Silverlight類庫也比完整的.Net類庫精簡了許多，有些時候如操作Xml的時候不大順手。不過大體上來說還是夠用的。 |
|
√ |
|
擴充特性 |
E4X是Flex的獨有特性，在Flex中使用XML簡單到了讓Linq to XML也相形見絀的地步。 Silverlight勝于Flex之處包括：Linq to object、lambda表達式和顯式多線程，這些都是Flex所不支持的。 |
|
√ |
|
語言支持 |
Flex只支持ActionScript，Silverlight則支持C#、VB、IronPython、IronRuby、JScript等多種語言。但不論Visual Studio還是Expression Blend都沒有為腳本語言創建項目提供任何支持，這使得Silverlight的多語言優勢打了一個很大的折扣 |
|
√ |
總的來說，語言方面是Silverlight大勝Flex。
|
框架 | |||
|
特性 |
比較 |
勝出 | |
|
Flex |
Silverlight | ||
|
界面組件 |
經過幾年發展，Flex的界面組件已經比較完整。基本框架中包括超過50個界面組件，遠遠超過Silverlight的組件數量。但是Flex里也缺少如AutoComplete等少數重要組件。 Silverlight本身就組件數量和功能方面遠遜于Flex，不過添加Silverlight Toolkit以后可以在一定程度上彌補其不足。 |
√ |
|
|
布局 |
Flex的布局機制簡單且靈活。Canvas支持多種對齊和擺放方式，靈活性遠遠超過Silverlight Canvas，是布局中最常使用的組件。Canvas、HBox和VBox三個組件基本上可以包攬90%上界面布局的工作。 此外，Flex中還有一些布局組件如Panel、Form和ViewStack是Silverlight所缺乏的。Flex還支持基于輔助線的布局，Silverlight里面沒有這樣的功能。 Silverlight的布局組件不僅數量少，基于附加屬性的語法也比較冗長拖沓。 |
√ |
|
|
樣式 |
Flex的樣式語法基于CSS，非常簡潔，且對于熟悉HTML的用戶來說馬上可以上手。 Silverlight的樣式聲明語法相當繁瑣。比較一下Flex/Silverlight的樣式設置：
Button { margin: 10; } <mx:Button /> Silverlight: <Style x:Key=”component” TargetType=”Button”> <Setter Property=”Margin” Value=” </Style> <Button Style=”{StaticResource component}” /> 可以看到，相比Flex所用的CSS語法來說，Silverlight中超過一半以上的代碼是純粹的語法噪音，只是為了方便解析器而設計的，對設計者來說完全是不必要的額外負擔。此外，Silverlight并不直接支持類似Flex的全局樣式。雖然StyleManager可以達到類似的效果，但語法更加羅嗦，會使得XAML更加冗長。 |
√ |
|
|
動畫 |
Flex有多達10多種動畫。Silverlight基于依賴屬性的動畫只相當于Flex的AnimationProperty，數量和功能都比較受限，并且只對于Dependency Property有效。 |
√ |
|
|
數據綁定 |
Flex的數據綁定語法直觀且簡潔，可以使用幾乎任意的表達式。聲明綁定屬性的語法也相當簡單，任何屬性只要加上一個[Bindable]標簽即可。 Silverlight的數據綁定語法相當累贅，至少造成了兩個嚴重后果：1、大量數據綁定屬性是造成XAML冗長難讀的罪魁禍首；2、依賴屬性編寫很麻煩，需要大量樣本代碼，而許多框架特性又嚴重依賴于依賴屬性，使得編寫Silverlight組件成為相當累人的工作。 |
√ |
|
|
通信機制 |
Flex和Silverlight都支持大量標準化的通信機制，包括XML、Web Service和二進制數據等，支持程度也大致在同一水平上。 Flex略微勝過Silverlight的地方在于Flex有一個標準化的二進制通訊標準：AMF，基于AMF的服務框架不論開源或商業的目前都有廣泛的應用。Silverlight在這方面還是一片空白。 |
√ |
|
|
異常處理 |
Flex的一個問題是不支持全局異常處理，對框架設計而言這是明顯的缺憾。 Silverlight支持應用程序級別的全局異常處理。不過這個異常處理似乎也不是非常完整，有個別異常還是會漏網，造成Silverlight插件出錯。 |
|
√ |
|
國際化 |
Flex對國際化的支持比較完整，使用上也很方便。唯一的小問題是支持額外的語言需要要執行一次copylocale命令行。 Silverlight對國際化的支持是有問題的，雖然可以使用，但要做很多手工工作，并且需要一些work around才能成功執行。 |
|
|
|
其他特性 |
Flex包括一個非常方便的界面特性：State，在界面有少量變化的時候使用非常方便，可以避免很多不必要的編碼。這是Silverlight所欠缺的。 Silverlight的DeepZoom是Flex所沒有的功能。 |
√ |
|
|
外觀 |
外觀是否好看應該說是個見仁見智的問題。不過Flex似乎在細節方面做得更好，請看Flex/Silverlight默認按鈕外觀的比較：
Flex組件默認情況下就有一個相當合適的邊距，看起來很舒服，基本上不用再作什么調整。Silverlight就差多了，密密麻麻的擠在一起，顯得非常局促，必須在樣式上作很多調整才會比較好看。在這些細節上Silverlight明顯不如Flex。 |
|
|
框架方面Flex可以說是大優勢戰勝Silverlight。
|
IDE | |||
|
特性 |
比較 |
勝出 | |
|
Flex |
Silverlight | ||
|
可視化設計器 |
具有諷刺意味的是，號稱Visual的微軟開發環境在WPF時代就再也難以自稱Visual了。Visual Studio中的Silverlight可視化設計器目前只能說是一個廢品，拖拉不能用，屬性設置不能用，預覽也不能用，并且常常假死，微軟自己都似乎不好意思把它顯示出來了。Expression Blend說實話也并不好用，不過它編輯XAML時的性能倒是比Visual Studio好多了，至少不會出現經常假死的情況。 Flex Builder編輯器經過幾年發展，在可視化設計上已經達到不錯的水準，使用也相當方便。不足之處在于不能同時打開太多頁面，不然內存的耗用會相當驚人。 |
√ |
|
|
代碼編輯 |
在代碼編輯的方面則是Visual Studio要比Flex Builder表現更好。對于代碼輔助和編輯提示方面，Visual Studio比Flex Builder表現更加成熟。 不過Flex Builder也有Visual Studio所不及之處：1、類導航的功能更加豐富，使用快捷鍵比Visual Studio中更迅捷；2、無論設計還是代碼視圖都支持文檔大綱，瀏覽和跳轉更加方便；3、指定文件編碼也要比Visual Studio要容易。 |
|
√ |
|
代碼隱藏 |
由于Flex Builder并不直接支持Code Behind模型，因此在界面和對應代碼的管理上要比Visual Studio麻煩一些。 |
|
√ |
|
編輯器性能 |
對于可視化編輯器而言，Flex Builder的性能要比Visual Studio好得多。對代碼編輯器而言Visual Studio和Flex Builder表現差不多，但Flex Builder占用內存比較厲害。 |
√ |
|
|
編譯器性能 |
Flex編譯性能一直都是一個飽受詬病的重大問題。在項目大到一定程度，編譯效率就開始急劇下降，編譯一次需要三四十秒是常有的事。（據說有人編譯一次甚至需要20分鐘以上，不過我還沒有遇到） Flex編譯慢是有原因的，因為編譯器替程序員完成了相當多的工作。如果你打開-keep=true編譯開關，檢查一下生成的代碼，就知道編譯器的工作有多繁重了。如果愿意放棄一些可視化特性，手工編寫ActionScript組件而避免使用MXML組件，就可以在很大程度上提高編譯效率。 從長遠角度來說，我認同Flex這種設計思路，用機器效率來換取程序員效率是值得的（Unix格言：寧用計算機一分，不花程序員一秒。）但對于眼下的機器性能來說，Flex編譯性能還是一個無法忽略的問題，編譯速度太慢會拖慢迭代開發的節奏，對程序員的心理也不能不說是一種折磨。 Silverlight編譯效率還是不錯的，代價就是冗長的程序代碼需要程序員自求多福了，編譯器的工作實際上是很輕松的。 |
|
√ |
|
調試 |
在開發環境的支持下，Flex和Silverlight的調試都比較方便。Flex的一個小問題是開發人員需要單獨安裝一個Debug版本的Flash Player，Silverlight則不用，所以Silverlight更加方便一些。 Silverlight缺少Flex Builder內置的Profiler，沒有簡單的方法進行性能測試。傳統的.Net性能測試工具基本上都不支持Silverlight |
√ |
|
|
開放性 |
基于Eclipse的Flex Builder開放性明顯要優于封閉的Visual Studio，有大量免費的Eclipse插件可以直接拿來使用。不過有少量插件會與Flex Builder產生沖突。如果沒有大量的Java開發工作，那么安裝Flex Builder完整版要比插件版更加穩妥并且簡單。 Visual Studio的插件數量不多，配合Silverlight Tools使用的目前基本上還沒有看到。 |
√ |
|
IDE方面Flex和Silverlight各擅勝場。
|
環境 | |||
|
特性 |
比較 |
勝出 | |
|
Flex |
Silverlight | ||
|
插件大小 |
目前Flash插件安裝包大小為 Silverlight插件安裝包大小為 |
√ |
|
|
安裝 |
Flash的插件基本上可以做到全自動安裝升級，不必用戶手工參與。這也很容易理解為什么Flash Player能夠成為占據全球95%以上電腦的裝機量最大的軟件。 Silverlight插件要麻煩一些，必須用戶手工執行安裝步驟，這勢必影響Silverlight插件的普及。當然微軟也可以使用諸如捆綁安裝之類的市場手段，這就不再屬于技術討論的范疇了。 |
√ |
|
|
運行性能 |
我沒有作過這方面的測試，就使用感覺來說還沒有發現明顯差別。不過我看到外國已經有這方面的測試，結果認為Flex在畫面渲染效率上優于Silverlight，而Silverlight則在數學計算上效率高過Flex。考慮到Adobe/Macromedia就是以圖形起家的，而微軟在編譯器上已經深耕多年，這個結果應該不會讓人感到驚訝。由于瀏覽器插件的主要功能還是提供顯示，用于大量數學計算的場景并不多見，看起來Flex還是占有一定優勢。 |
√ |
|
環境方面Flex仍然占有優勢。
最后再說一些比較瑣碎的話題，因為不太好分類，并且主觀意味比較濃厚，就不再詳細比較，當作姑妄言之好了。
Flex與Silverlight目前來看都是存在一些問題的。有些屬于語言設計的范疇，比如ActionScript的聲明語法比較羅嗦，而Silverlight則是綁定屬性的語法特別累贅，但這些問題受系統設計限制，基本上已經沒有修改的余地了（除非整個框架推倒重來）。另外一些問題是比較嚴重但是有望解決的，Flex方面是大項目中的編譯速度讓人抓狂，不過在Flex Builder 4 beta中似乎已經看到了改善的跡象。Silverlight則是框架還不夠完整，界面組件有限。Silverlight 3已經比Silverlight 2有所提高，加上Silverlight Toolkit一類擴展可以得到很大改進。Silverlight的另一嚴重問題是IDE工具完全沒有達到應有的水平，Visual Stuido插件可用性非常差，此問題從Silveright 2到3以后反而有惡化的趨勢，VS2010似乎又是個極其吃機器的怪獸，這個問題短期內能否解決，實在讓人無法樂觀。
如果從程序員的觀點來看，Silverlight的語言特性要比Flex更佳：.Net框架結構上更加完備、多種開發語言支持、Linq和客戶端多線程，這些都是Flex所欠缺的特性，應該為Silverlight額外加分。可惜受到開發工具和應用范圍的限制，這些優勢目前并沒有充分發揮出來。此外，從從業人員的現狀來看，Flex語法更加簡單、容易上手，對非程序員頗具吸引力，而C#對這些人來說門檻實在有點過高。所以這些特性是好是壞，眼下也不太好作出結論。
從社區來說，Flex目前已經擁有相當數量的用戶和開發社群，其獨有的特點是來自設計者和程序員兩個背景完全不同的群體，因此意見和風格常常參差不齊，好處是能夠看到不同觀點的碰撞，比較有活力。Silverlight社區規模還比較小，基本上全部來自微軟開發者陣營，背景相當一致，對程序設計通常能夠有很好的觀點，缺點是對UI設計師的團體和理念缺乏了解，解決思路大多是以程序員為本位的。另外一個似乎不利于Silverlight的現狀是：Java/開源陣營基本上不會考慮使用Silverlight，反或來說，以微軟技術為平臺的開發者倒是還有相當一部分會采用Flex（從博客園的話題分類也可以看得出來）。
Flex與Silverlight未來的趨勢如何？看一看這兩個技術近幾年的發展趨勢，Flex仍然具有領先優勢，但該優勢目前已經有所縮小：
- <!--[if !supportLists]--> <!--[endif]-->Flex 2和Silverlight 1沒有什么好比較的，Sliverlight 1功能實在太過貧弱，這時Flex遙遙領先；
- <!--[if !supportLists]--> <!--[endif]-->Flex3和Silveright 2相比，Silverlight在框架結構上比版本1已經有改天換地的提高，拉近了和Flex的距離，但可用組件仍然嚴重不足；
- <!--[if !supportLists]--> <!--[endif]-->Silveright 3在結構上沒有什么重大改變，主要在于功能的完善。如果說Flex 2比Silverlight 1領先整整一步的話，那么到Siliverght 3，這個差距已經縮小到半步，Silverlight在部分特性上甚至超越了Flex。
目前，Silveright 3剛剛出現，各方面的支持仍然有待跟進，Silverlight 4眼下還看不到什么消息。而Adobe已經開始準備Flex 4，目前釋出了第一個beta版本，從已經知道的情況分析，這個版本在框架上將會有相當重大的修改，明顯意圖再度拉大與Silverlight的差距，在許多方面都設計得更加靈活。但兼容性究竟如何、能否允許從前的用戶平穩過渡，將會是Flex 4面臨的主要問題。
我以前曾經說過，現在仍然這樣認為：鑒于微軟自身的市場定位，它絕不希望基于Web的技術強大到足以讓用戶忽略瀏覽器和操作系統的地步。因此Silverlight將來究竟能發展到什么程度，長遠來看還是不得不打上一個很大的問號，即使目前來看微軟仍然在力推這門技術。不過已經使用了Silverlight的同學也無須太過顧慮，只要是微軟推出的技術，不論好或不好，就算是被放棄以后也還能夠生存相當一段時間（看看眼下的IE6）。
眼下，Flash在諸如在線視頻等市場的領導地位是不爭的事實，Silverlight暫時還沒有直接與其對抗的力量，并且它們還都面臨著一個共同的對手——Ajax，未來還會有HTML5來攪局。所以今后一段時間，我們大概只能看到它們之間發生一些小規模的局部戰爭。Flash Player在瀏覽器中的覆蓋率現在超過95%，地位已經極其穩固，有如今日之Windows，但同時也意味著基本上再沒有上升的空間，只能依勢固守。而Silverlight則有望以后起之秀的姿態從Flash中搶走一部分市場份額，然而考慮到其他廠商對微軟的警惕心理和Web標準領導話語權的力量，Silverlight恐怕也難以取得非常理想的戰績。作為用戶的我們，其實也沒有多大必要去在意誰會是最后的贏家（歷史為鑒，最終的贏家最初通常都在人們的視野之外。Google勃興而引導網絡時代，當初沒有任何人預見到），只要領會時代和技術交鋒進步的精彩之處就好了。
本文來自Shuhari的博客園文章《Flex/Silverlight的技術比較》
【編輯推薦】
