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