AWT，SWT和Swing的布局管理器與Look And Feel機制
布局管理器
并不是三者中的所有部分都是不同的。布局管理器是一個例外。開發(fā)GUI應(yīng)用程序，當(dāng)容器改變大小的時候，組件需要重定位或改變大小。在傳統(tǒng)的編程語言中，這依靠監(jiān)聽大小改變的事件來實現(xiàn)。相應(yīng)的片段散落在源代碼的各個角落降低了程序的可讀性。Java引入了將布局代碼封裝的思路，稱之為布局管理器。當(dāng)布局管理器對象被設(shè)置到一個容器中，它自動處理大小改變的事件。當(dāng)大小改變時，管理器的布局方法被調(diào)用以重定位子組件或調(diào)整它們的形狀。
AWT，SWT和Swing都以這樣的方式來組織，而都有它們各種獨特的布局管理器。由于AWT和Swing擁有一個共同的超類java.awt.Component，它們的布局管理器可以交替地使用。
Look And Feel機制
包括SWT和AWT在內(nèi)的本地工具集并不支持Look And Feel機制。它們將組件捆綁在操作系統(tǒng)上，有其優(yōu)勢和劣勢。其中的一個劣勢是它們不支持可插拔的Look And Feel。將繪制處理交由操作系統(tǒng)完成剝奪了它們實現(xiàn)自定義組件Look And Feel的能力，也就使得它們無法提供這種機制。Look And Feel機制越來越成為GUI工具集中不可缺少的一部分。
Swing擁有很好的Look And Feel支持。你甚至可以動態(tài)地改變Swing應(yīng)用程序的Look And Feel，鑒于AWT和SWT將組件控制完全交給操作系統(tǒng)處理，這是它們所無法超越的任務(wù)。我曾經(jīng)聽很多人抱怨過Sun在Swing上的設(shè)計。他們覺得 Swing為什么不像SWT那樣沿用AWT的思路呢？事實上，Look And Feel機制正是Swing走到這個方向上的原因之一。如果Swing遵循的是包裝已有的組件并模擬不存在的組件的路線，那它就無法提供Look And Feel機制。因為提供Look And Feel機制是本地策略所無法完成的任務(wù)。
Graphics and Fonts圖形和字體
Swing作為一個仿生系統(tǒng)，它的圖形工具集較之AWT和SWT強大許多。Swing基于其自身系統(tǒng)中的兩個基礎(chǔ)組件群：Java 2D和AWT。Java 2D在Java中是強大的類庫，它為高級圖像處理，顏色管理，圖形繪制和填充，坐標(biāo)系變換和字體生成提供豐富的特性。相較之下，AWT和AWT僅對這些特性提供有限訪問，它們是相對原始和低級的。
JavaBeans Specification Conformity JavaBeans規(guī)范一致性
Swing 和AWT在設(shè)計之初就秉承了JavaBeans規(guī)范，它們的組件類與JavaBeans規(guī)范一致。然而SWT并沒有很好的遵循這一規(guī)范。例如，在SWT的組件類中沒有無參的構(gòu)造器。每個組件都必須至少擁有一個單參數(shù)的構(gòu)造器。這個參數(shù)就是父組件的引用。這意味著無論何時組件被創(chuàng)建，它都直接被添加到一棵組件樹中。一個組件無法脫離于已注冊的本地對等體而存在。這樣，SWT就能讓由編程者創(chuàng)建的組件在display的dispose方法被調(diào)用的時候自動被釋放。
More on Resource Management更多在資源管理方面的內(nèi)容
SWT 的組件構(gòu)造器策略可以排除某些內(nèi)存泄露的可能性。AWT在資源管理方面也有類似的問題。但它采用了不同的方式解決。當(dāng)AWT組件被創(chuàng)建的時候，相應(yīng)的對等體并不會立即被創(chuàng)建。即便它被添加到一棵組件樹，而如果這棵樹還不可見，那么對等體仍不會被創(chuàng)建。只有當(dāng)頂層容器被設(shè)為可見，這些對等體才會被創(chuàng)建。創(chuàng)建對等體的方法通常在addNotify中，它們通常遞歸地調(diào)用父組件的addNotify直到整棵組件樹上的對等體都被創(chuàng)建了。當(dāng)頂層容器由 dispose方法銷毀的時候，一個對應(yīng)的方法removeNotify將會被遞歸地調(diào)用以釋放這些對等體。這樣，AWT在不由開發(fā)者介入的情況下管理了它的資源。
Event System事件系統(tǒng)
一個事件要求特定的動作被執(zhí)行，它被作為消息由外界或系統(tǒng)自身發(fā)送給GUI系統(tǒng)。這些事件包括來自計算機設(shè)備如鼠標(biāo)鍵盤和網(wǎng)絡(luò)端口的I/O中斷，以及GUI系統(tǒng)的邏輯事件觸發(fā)，比如一個按鈕的ActionEvent事件。
Single-Threaded vs Multiple-Threaded 單線程 vs 多線程
事件分發(fā)遵循兩種不同的模型。單線程分發(fā)模型和多線程分發(fā)模型。
在單線程分發(fā)模型中，一個事件從隊列中抽出并在同一個線程中被立即處理。事件處理后，緊跟著的下一個事件再被抽出并繼續(xù)下一輪的循環(huán)。在多線程分發(fā)模型中，從隊列中獲取事件的線程啟動另一個被稱作任務(wù)線程的線程，并把事件交給它處理。而獲取事件的線程并不等待處理線程的結(jié)束。它簡單的獲取下一個線程并分發(fā)它。
事件處理通常涉及應(yīng)用程序的數(shù)據(jù)變化。而且這些數(shù)據(jù)經(jīng)常是組件需要顯示的。多線程分發(fā)很容易產(chǎn)生同步問題，它產(chǎn)生多個可能互相干擾的事件處理線程。在一個穩(wěn)定的GUI系統(tǒng)中，組件應(yīng)該能夠保持視圖與模型間的同步。由于同步問題的出現(xiàn)，多線程模型要求開發(fā)者擁有更多并發(fā)編程的經(jīng)驗。而對于普通編程人員，造成同步錯誤是很容易的。因此許多GUI系統(tǒng)并不使用這一模型。
單線程模型通過強制事件序列化地被處理提供了實際上的同步。AWT，SWT和Swing 都采用了這一模型來分發(fā)事件。但單線程模型也會有它自己的問題。其中之一就是線程專注。既然所有的事件都在一個線程中被分發(fā)，如果其中的一個事件的處理費時過久，將會拖延下一個事件的抽取和執(zhí)行。如果有一個PAINT事件被延后，那么在屏幕上就會呈現(xiàn)為無法響應(yīng)。這經(jīng)常使用戶感覺到軟件很慢。許多這樣的低效程序是由于開發(fā)者的經(jīng)驗不足造成的。他們的做法是將耗時任務(wù)填充到監(jiān)聽器方法中。由于這種錯誤的編程方式在Swing中大量被使用而尤為突出，這也是它慢而丑陋的壞名聲的由來之一。實際上，如果你懂得使用線程，Swing應(yīng)用程序可以表現(xiàn)出很高的響應(yīng)度。以上就是介紹AWT，SWT和Swing的布局管理器與Look And Feel機制
【編輯推薦】
