AWT，SWT和Swing的區(qū)別
GUI 應用程序是軟件的一種主要類型，所以Java的GUI庫應該是標準化并被集成到JRE平臺中的。然而不同的操作系統(tǒng)有不同的GUi風格和組件集。有一些組件在所以平臺上有相似的觀感。這些共有組件如按鈕，標簽，文本域，單選框等被稱為標準組件。不同的GUI工具集提供了不同的組件集。GUI工具集總是遵循不同的原則來選擇組件類型和特征以實現(xiàn)?？疾煲粋€工具集，有兩個不同的要素：組件類型和組件特征。
Terms
首先讓我圖解兩個數(shù)學概念：最大公約數(shù)和最小公倍數(shù)。三個集合代表不同的操作系統(tǒng)。相交的部分是最大公約數(shù)，合并的部分是最小公倍數(shù)。
現(xiàn)在讓我們來考察Java GUI工具集AWT，SWT和Swing的區(qū)別
AWT
AWT 組件集遵循最大公約數(shù)原則，即AWT只擁有所有平臺上都存在的組件的公有集合。所以你在AWT中無法獲取如表或樹等高級組件，因為它們在某些平臺上不支持。AWT的組件特征同樣遵循這一原則。它只提高平臺上公有的特征。例如AWT按鈕不能附著圖片，因為在Motif平臺上，按鈕是不支持圖片的。
由于它低劣的組件集和特征，AWT無法吸引開發(fā)者。它是Sun不推薦使用的，只是為了確保向下兼容和支持Swing。
SWT
SWT 最初的目標之一是為了提供比AWT更為豐富的組件集。它遵循最小公倍數(shù)原則以提供一個各個平臺上包含的組件的并集。思路是如果一個組件在某個平臺上包含，那么SWT就會包裝它并用java代碼和JNI來調用它。如果一個組件在某一平臺上不存在，它就會用繼承并繪制Composite的方式來模擬組件。一個 SWT Composite類似于AWT的Canvas。以這種方式，SWT提供了較AWT更為豐富的組件集。值得指出的是SWT的JNI封裝不同于AWT，它的模擬也不同于Swing。
在組件特征方面，SWT類似于AWT。它遵循最小公倍數(shù)原則。在早期的SWT版本中，SWT按鈕因為和AWT同樣的原因不支持附著圖片。在之后的版本中，許多缺失的特征采用模擬的方式補全。但仍有許多特征無法采用純粹的模擬實現(xiàn)。SWT將組件的控制交給本地操作系統(tǒng)。它難以擴展。只有例如圖形裝飾等特征可以借助模擬繪制來自定義實現(xiàn)。所以嚴格意義上將，SWT組件的組件集和特征因其難于擴展而不如Swing來得豐富。
Swing
Swing 是三者中最強大和靈活的。在組件類型上，它遵循最大公約數(shù)原則。由于Swing可以控制自身GUI系統(tǒng)的全部并有很好的可擴展和靈活性，它幾乎可以創(chuàng)建所有你想象得到的組件。唯一的限制是它的AWT容器。在Swing中你還不能跨平臺地實現(xiàn)真正的透明化和不規(guī)則矩形窗口，因為Swing依賴于AWT頂層容器例如Applet, Window, Frame and Dialog等。除此之外，Swing幾乎實現(xiàn)了所有平臺上的標準組件。
在組件特征上，Swing遵循最小公倍數(shù)原則。它擁有所有平臺上可提供的組件特征。不僅如此，你還可以繼承已有的Swing組件并添加新的特性。
上面比較主要是在API級別上的。讓我們將比較的焦點轉移到實現(xiàn)細節(jié)上。AWT，SWT和Swing的區(qū)別是Swing是純Java實現(xiàn)，而SWT和AWT 是Java和JNI的混合。當然，它們的目標都是相同的，提供一個跨平臺的APIs。然而為了達到這一點，SWT和AWT不得不犧牲一些組件和特性以提供一個通用的APIs。
AWT
一個AWT組件通常是一個包含了對等體接口類型引用的組件類。這個引用指向本地對等體實現(xiàn)。舉java.awt.Label為例，它的對等體接口是 LabelPeer。LabelPeer是平臺無關的。在不同平臺上，AWT提供不同的對等體類來實現(xiàn)LabelPeer。在Windows上，對等體類是WlabelPeer，它調用JNI來實現(xiàn)label的功能。這些JNI方法用C或C++編寫。它們關聯(lián)一個本地的label，真正的行為都在這里發(fā)生。作為整體，AWT組件由AWT組件類和AWT對等體提供了一個全局公用的API給應用程序使用。一個組件類和它的對等體接口是平臺無關的。底層的對等體類和JNI代碼是平臺相關的。
SWT
SWT也使用JNI的方法論來實現(xiàn)。但細節(jié)不同于AWT。SWT的擁護者聽到人們拿SWT和AWT相提并論可是會很生氣的，Steve Northover，SWT之父，就曾為此抱怨過。
沒錯，它們是不同的。讓我們深究SWT的代碼。在SWT中，各個平臺上唯一相同的部分是組件的接口，是類和方法的定義簽名。所有的底層代碼都是平臺差異的。 SWT為每個平臺提供了OS類。這個類用JNI封裝了許多本地APIs。SWT組件類通過把這些JNI方法黏合在一起提供一個有意義的功能。
例如，在Windows上，文本域的選擇是由一個系統(tǒng)調用處理的。這個系統(tǒng)調用在Windows的OS類中作為一個本地方法實現(xiàn)。所以在Windows平臺的Text的setSelection方法中只用到了一個JNI調用。
然而，在motif上，文本域的選擇包含兩個本地調用。SWT就在motif的OS類中實現(xiàn)了兩個調用。所以在motif上組件類需要作兩次調用來實現(xiàn)文本的選擇。
現(xiàn)在你應該能看出SWT和AWT的最大不同了，它們使用了不同的對等體編程方式來消除平臺差異。SWT用java代碼或有JNI實現(xiàn)的java對等體來黏合系統(tǒng)調用。而AWT把代碼包含在對等體中，使情況復雜化了，我個人覺得SWT的方法更加明智。
SWING
到了Swing這里，一切就變得清晰和直接了。除了頂層容器，Swing的實現(xiàn)不依賴于具體平臺。它掌管了所有的控制和資源。Swing所需要的是事件輸入來驅動系統(tǒng)，以及承接自頂層AWT容器的圖形處理，字體和顏色。普通的Swing組件可以看作是AWT容器的一塊邏輯區(qū)域。它們并沒有注冊對等體。所有添加到同一頂層容器的Swing組件共享它的AWT對等體以獲取系統(tǒng)資源，如字體，圖形處理等。Swing將組件自己的數(shù)據(jù)結構存儲在JVM的空間中。它完全由自己管理畫圖處理，事件分發(fā)和組件布局。
由于AWT和SWT都持有對本地組件的引用，它們必須以正確的方式釋放這些引用以避免內存泄露和JVM崩潰。AWT將絕大多數(shù)資源管理任務交給系統(tǒng)，將開發(fā)者從單調乏味的資源管理中解救出來。然而這使得AWT的實現(xiàn)復雜化了。一旦它實現(xiàn)了，開發(fā)者很少有機會犯錯誤并使他們的程序崩潰。
SWT 用的是另一種方法。大體上，SWT讓開發(fā)者自己來管理資源。它的一條著名的規(guī)則是：誰創(chuàng)建，誰釋放。因此開發(fā)者必須謹慎地顯式調用dispose方法釋放每一個由他創(chuàng)建的組件和資源。這簡化了SWT的實現(xiàn)模型，但把開發(fā)者擺在了因錯誤編碼而易于造成程序崩潰這一風險之上。
模擬方式的區(qū)別
SWT和Swing在它們的實現(xiàn)上都使用了模擬。SWT只模擬平臺上缺失的組件。區(qū)別是SWT的模擬更像是AWT的Canvas實現(xiàn)的模擬。SWT的 Composite類有它自己在操作系統(tǒng)中相應的對等體。它從自己的對等體中獲得所有它所需要的資源如圖形處理的對象，字體和顏色等。它直接從操作系統(tǒng)獲取所有的事件并進行處理。然而，Swing組件在操作系統(tǒng)中沒有相應的對等體。它只是一塊頂層容器中的邏輯區(qū)域，實際上它從頂層容器的對等體中借用資源。 Swing的事件并不是底層系統(tǒng)產(chǎn)生的事件。它們實際是由頂層容器處理AWT事件所產(chǎn)生的偽事件。我們會在稍后的事件部分中詳細介紹它。
圖形層結構
另一個不同之處是Swing組件的z-order系統(tǒng)是來自于AWT組件的。如上所述，Swing組件與頂層AWT容器共享一個對等體。因此，Swing組件也和頂層容器有相同的z-order。SWT和AWT組件都有不同于頂層容器的z-order，通常是高于頂層容器。故而如果AWT組件和Swing組件混合在一起的話，Swing組件將可能被AWT組件遮住。當操作系統(tǒng)開始更新UI的時候，頂層容器和Swing組件總是先于AWT組件繪制。當它們完成繪制，AWT組件會覆蓋Swing可能繪制過的地方。因此不提倡Swing和AWT組件的混用。如果有一個浮動的Swing組件如菜單，AWT組件很可能遮蓋菜單。以上是AWT，SWT和Swing的區(qū)別的介紹
【編輯推薦】
