GUI開發之AWT、SWING、SWT和JFACE的比較

核心提示：AWT Abstract Windows Toolkit（AWT）是最原始的 Java GUI 工具包。在任何一個 Java 運行環境中均可以使用它。 AWT 是一個很是簡單的具備有限 GUI 組件、佈局管理器和事件的工具包.有些常用的組件，例如表、樹、進度條等，都不支持。 一般對於 AWT 來講

 

AWT

             Abstract Windows Toolkit（AWT）是最原始的 Java GUI 工具包。在任何一個 Java 運行環境中均可以使用它。

AWT 是一個很是簡單的具備有限 GUI 組件、佈局管理器和事件的工具包.有些常用的組件，例如表、樹、進度條等，都不支持。

 

一般對於 AWT 來講（也適用於 Swing 和 SWT），每一個事件類型都有一個相關的 XxxListener 接口（XxxAdapter 的實現可能爲空），其中 Xxx 是去掉 Event 後綴的事件名（例如，KeyEvent 事件的接口是 KeyListener），用來把事件傳遞給處理程序。應用程序會爲本身感興趣處理的事件的事件源（GUI 組件或部件）進行註冊。有時監聽接口要處理多個事件。

 

AWT 的一個很好的特性是它一般能夠對 GUI 組件自動進行銷燬。這意味着您幾乎不須要對組件進行銷燬。一個例外是高級組件，例如對話框和框架。若是您建立了耗費大量主機資源的資源，就須要手動對其進行銷燬。

 

AWT 組件是 「線程安全的（thread-safe）」，這意味着咱們不須要關心在應用程序中是哪個線程對 GUI 進行了更新。這個特性能夠減小不少 GUI 更新的問題，不過使 AWT GUI 運行的速度更慢了。

 

AWT 讓咱們能夠以自頂向下（top-down） 或自底向上（bottom-up） 或以任意組合順序來構建 GUI。自頂向下的意思是在建立子組件以前首先建立容器組件；自底向上的意思是在建立容器（或父）組件以前建立子組件。在後一種狀況中，組件的存在並不依賴於父容器，其父容器能夠隨時改變。

 

因爲 AWT 要依賴於主機 GUI 的對等體（peer）控件（其中每一個 AWT 組件都有一個並行的主機控件或者對等體）來實現這個 GUI，這個 GUI 的外觀和行爲（這一點更重要）在不一樣的主機上會有所不一樣。這會致使出現 「編寫一次隨處測試（write once, test everywhere，即 WOTE）」 的狀況，這樣就遠遠不能知足咱們的要求了。

 

AWT 提供了一個豐富的圖形環境，尤爲是在 Java V1.2 及其之後版本中更是如此。經過 Graphics2D 對象和 Java2D、Java3D 服務，咱們能夠建立不少功能強大的圖形應用程序，例如畫圖和製表包；結合使用 JavaSound，咱們還能夠建立很是有競爭力的交互式遊戲。

 

 

Swing

Java Swing 是 Java Foundation Classes（JFC）的一部分，它是試圖解決 AWT 缺點的一個嘗試。在 Swing 中，Sun 開發了一個通過仔細設計的、靈活而強大的 GUI 工具包。

Swing 是在 AWT 組件基礎上構建的。

 

爲了克服在不一樣主機上行爲也會不一樣的缺點，Swing 將對主機控件的依賴性降至了最低。實際上，Swing 只爲諸如窗口和框架之類的頂層 組件使用對等體。大部分組件（JComponent 及其子類）都是使用純 Java 代碼來模擬的。這意味着 Swing 天生就能夠在全部主機之間很好地進行移植。所以，Swing 一般看起來並不像是本地程序。實際上，它有不少外觀，有些模擬（儘管一般並不精確）不一樣主機的外觀，有些則提供了獨特的外觀。

 

Swing 對基於對等體的組件使用的術語是重量級（heavyweight），對於模擬的組件使用的術語是輕量級（lightweight）。實際上，Swing 能夠支持在一個 GUI 中混合使用重量級組件和輕量級組件，例如在一個 JContainer 中混合使用 AWT 和 Swing 控件，可是若是組件產生了重疊，就必須注意繪製這些控件的順序。

 

Swing 沒法充分利用硬件 GUI 加速器和專用主機 GUI 操做的優勢。結果是 Swing 應用程序可能比本地 GUI 的程序運行速度都慢。Sun 花費了大量的精力來改進最近版本的 Swing （Java V1.4 和 1.5）的性能，這種缺點正在變得日益微弱。因爲 Swing 的設計更加健壯，所以其代碼基礎也更堅實。這意味着它能夠在一臺健壯的機器上比 AWT 和 SWT 上運行得更好。

 

與 AWT 同樣，Swing 能夠支持 GUI 組件的自動銷燬。Swing 還能夠支持 AWT 的自底向上和自頂向下的構建方法。

 

與 AWT 不一樣，Swing 組件不是線程安全的，這意味着您須要關心在應用程序中是哪一個線程在更新 GUI。若是在使用線程時出現了錯誤，就可能會出現不可預測的行爲，包括用戶界面故障。有一些工具能夠幫助管理線程的問題。

 

與 AWT 相似，Swing 的一個優勢是，它也是 Java 技術的一種標準配置。這意味着您不須要本身來安裝它了。不幸的是，Swing 已經有了很大的變化，所以它很容易變得依賴於最新版本的 Java 語言所提供的特性，這可能會強制用戶更新本身的 Java 運行時環境。

 

 

SWT

與 AWT 的概念相比，SWT 是一個低級的 GUI 工具包。JFace 是一組用來簡化使用 SWT 構建 GUI 的加強組件和工具服務。SWT 的構建者從 AWT 和 Swing 實現中學習了不少經驗，他們試圖構建一個集兩者優勢於一體而沒有兩者的缺點的系統。從不少方面來講，他們已經成功了。

 

SWT 也是基於一個對等體實現的，在這一點上它與 AWT 很是相似。它克服了 AWT 所面臨的 LCD 的問題，方法以下：定義了一組控件，它們能夠用來構建大部分辦公應用程序或開發者工具，而後能夠按照逐個主機的原則，爲特定主機所沒有提供的控件建立模擬控件（這與 Swing 相似）。對於大部分現代主機來講，幾乎全部的控件都是基於本地對等體的。這意味着基於 SWT 的 GUI 既具備主機外觀，又具備主機的性能。這樣就避免了使用 AWT 和 Swing 而引發的大部分問題。特定的主機具備一些低級功能控件，所以 SWT 提供了擴充（一般是模擬的）版本（一般使用 「C」 做爲名字中的第一個字母），從而能夠產生更一致的行爲。

 

在對等體工做方式上，SWT 與 AWT 不一樣。在 SWT 中，對等體只是主機控件上的一些封裝程序而已。在 AWT 中，對等體能夠提供服務來最小化主機之間的差別（就是在這裏，AWT 碰到了不少行爲不一致的問題）。這意味着 SWT 應用程序實際上就是一個主機應用程序，它必然會所有繼承主機的優勢和缺點。這還意味着 SWT 不能徹底實現 WORE 的目標；它更像是一種 WOTE 解決方案。這就是說，SWT 儘管不如 Swing 那麼優秀，可是它在建立可移植解決方案方面是很傑出的。

 

SWT 不支持 GUI 控件的自動銷燬。這意味着咱們必須顯式地銷燬所建立的任何控件和資源，例如顏色和字體，而不能利用 API 調用來實現這種功能。這種工做從某種程度上來講獲得了簡化，由於容器控制了其子控件的自動銷燬功能。

 

使用 SWT 只能自頂向下地構建 GUI。所以，若是沒有父容器，子控件也就不存在了；一般父容器都不能在之後任意改變。這種方法不如 AWT/Swing 靈活。控件是在建立時被添加到父容器中的，在銷燬時被從父容器中刪除的。並且 SWT 對於 style 位的使用只會在構建時進行，這限制了有些 GUI 控件的靈活性。有些風格只是一些提示性的，它們在全部平臺上的行爲可能並不徹底相同。

 

與 Swing 相似，SWT 組件也不是線程安全的，這意味着您必需要關心在應用程序中是哪一個線程對 GUI 進行了更新。若是在使用線程時發生了錯誤，就會拋出異常。我認爲這比不肯定的 Swing 方法要好。有一些工具能夠幫助管理線程的問題。

 

若是所支持的操做系統提供了可訪問性服務，那麼 SWT GUI 一般也就具備很好的可訪問性。當默認信息不夠時，SWT 爲程序員提供了一個基本的 API 來指定可訪問性信息。

 

SWT 提供了一個有限的圖形環境。到目前爲止，它對於 Java2D 和 Java3D 的支持還不怎麼好。Eclipse 使用一個名爲 Draw2D 的組件提供了另一種單獨的圖形編輯框架（Graphical Editing Framework，GEF），它能夠用來建立一些繪圖應用程序，例如 UML 建模工具。不幸的是，GEF 難以單獨（即在整個 Eclipse 環境以外）使用。

 

與 AWT 和 Swing 不一樣，SWT 和 JFace 並非 Java 技術的標準配置。它們必須單獨進行安裝，這能夠看成是 Eclipse 安裝的一部分，也能夠看成是單獨的庫進行安裝。Eclipse 小組已經使它的安裝變得很是簡單，而且 SWT 能夠與 Eclipse 分開單獨運行。所須要的 Java 檔案文件（JAR）和動態連接庫（DLL）以及 UNIX® 和 Macintosh 上使用的相似庫能夠從 Eclipse Web 站點上單獨下載。JFace 庫須要您下載全部的 Eclipse 文件，並拷貝所須要的 JAR 文件。在下載所須要的文件以後，咱們還須要將這些 JAR 文件放到 Java CLASSPATH 中，並將 DLL 文件放到系統 PATH 中。

 

SWT自己僅僅是Eclipse組織爲了開發Eclipse IDE環境所編寫的一組底層圖形界面 API。或許是無意插柳，或是有意爲之，至今爲止，SWT不管是在性能和外觀上，都超越了SUN公司提供的AWT和SWING。目前Eclipse IDE已經開發到了2.1版本，SWT已經十分穩定。這裏指的穩定應該包含兩層意思：

 

一是指性能上的穩定，其中的關鍵是源於SWT的設計理念。SWT最大化了操做系統的圖形構件API，就是說只要操做系統提供了相應圖形的構件，那麼SWT只是簡單應用JNI技術調用它們，只有那些操做系統中不提供的構件，SWT才本身去作一個模擬的實現。能夠看出SWT的性能上的穩定大多時候取決於相應操做系統圖形構件的穩定性。

 

另外一個穩定是指SWT API包中的類、方法的名稱和結構已經少有改變，程序員不用擔憂因爲Eclipse組織開發進度很快（Eclipse IDE天天都會有一個Nightly版本的發佈），而致使本身的程序代碼變化過大。從一個版本的SWT更新至另外一版本，一般只須要簡單將SWT包換掉就能夠了。

 

SWT採用了一種簡單而直接的方式去適應本地GUI系統對線程的要求：在SWT中，一般存在一個被稱爲"用戶線程"的惟一線程，只有在這個線程中才能調用對構件或某些圖形API的訪問操做。若是在非用戶線程中程序直接調用這些訪問操做，那麼SWTExcepiton異常會被拋出。可是SWT也在*.widget.Display類中提供了兩個方法能夠間接的在非用戶線程的進行圖形構件的訪問操做，這是經過的syncExec(Runnable)和asyncExec(Runnable)這兩個方法去實現的。

 

 

JFace

JFace與SWT的關係比如Microsoft的MFC與SDK的關係，JFace是基於SWT開發，其API比SWT更加易於使用，但功能卻沒SWT來的直接。好比下面的代碼應用JFace中的MessageDialog打開一個警告對話框：

 

MessageDialog.openWarning(parent," Warning"," Warning message");

 

若是隻用SWT完成以上功能，語句不會少於30行!

 

JFace本來是爲更加方便的使用SWT而編寫的一組API，其主要目的是爲了開發Eclipse IDE環境，而不是爲了應用到其它的獨立應用程序。所以在Eclipse 2.1版本以前，很難將JFace API完整的從Eclipse的內核API中剝離出來，老是要多多少少導入一些非JFace之外的Eclipse核心代碼類或接口才能獲得一個沒有任何編譯錯誤的JFace開發包。但目前Eclipse組織彷佛已經逐漸意識到了JFace在開發獨立應用程序起到的重要做用，在正在開發的2.1版本中，JFace也開始變成了和SWT同樣的完整獨立的開發包，只是這個開發包還在變更中(筆者寫本文時，應用的Eclipse2.1M3版本)。JFace開發包的包前綴是以org.eclipse.jface開頭。JAR包和源代碼也和SWT同樣，也在$｛你的eclipse安裝路徑｝\plugins路徑下去找。

 

對開發人員來講，在開發一個圖形構件的時候，比較好的方式是先到JFace包去找一找，看是否是有更簡潔的實現方法，若是沒有再用SWT包去本身實現。好比JFace爲對話框提供了很好的支持，除了各類類型的對話框(好比上面用的MessageDialog，或是帶有Title欄的對話框)，如要實現一個自定義的對話框也最好從JFace中的Dialog類繼承，而不是從SWT中的*.widget.Dialog繼承。

 

應用JFace中的Preference包中的類很容易爲本身的軟件作出一個很專業的配置對話框。對於Tree、Table等圖形構件，它們在顯示的同時也要和數據關聯，例如Table中顯示的數據，在JFace中的View包中爲此類構件提供了Model-View方式的編程方法，這種方法使顯示與數據分開，更加利於開發與維護。JFace中提供最多的功能就是對文本內容的處理。能夠在org.eclipse.jface.text.*包中找到數十個與文本處理相關類。