Swing

=====================================================

         總的來說Swing/AWT和SWT在事件處理機制上是類似的，窗口組件的樹狀結構也是類似的。圖形用戶界面系統在事件處理設計上有兩大類，一類是單線程模型，一類是多線程模型。在事件處理機制上，三者都是遵循單線程規則。

         單線成模型對于事件處理不保證線程安全性(Thread Safety)，所有的事件處理都在Event Dispatch Thread(EDT)上進行，此一類事件模型通常叫做單線程模型。這種模型規定所有對組件的訪問操作必須在EDT上完成。為什么對于組件的訪問需要在EDT上完成？這主要是為了保證對于組件狀態的改變是同步的，保證了界面組件的可確定性。這中模型是大部分圖形用戶界面工具采用的模型，包括Swing/AWT、SWT、GTK、WinForm等等。

         這種模型的好處是，結構設計和代碼實現都比較簡單，避免了為了實現線程同步的復雜處理。但是也帶來了一些問題，最常見的問題是，程序員容易將長時間復雜任務的處理放在事件處理函數完成，造成EDT線程被阻塞，給用戶造成界面失去響應的錯覺。其實人們對于Swing速度慢和反映遲鈍的感覺大部分來源于此，簡單的說，是程序員的問題，而不是Swing自身的問題，是因為程序員沒有理解這種事件處理機制造成的。其實在SWT、GTK、WinForm等任何以這種事件模型為基礎的工具都會出現。重現的方法就是你簡單的將長時間處理的任務放在事件處理函數中，你的用戶界面就會失去響應。

         如何解決這種問題？通用的辦法就是采用異步線程處理長時間任務。但是還要記住的是，在這種任務中對于界面的更新要采用SwingUtilities.invokeLater或者在SWT采用Synchronize方法，將訪問操作放到EDT上進行。關于如何寫一個有效處理長時間任務的Swing程序，將會在其他文章中描述。

         多線程模型中，所有的事件處理都是在異步線程中進行，界面組件同步訪問的操作需要程序員來保證。這種模型設計本身很復雜，而且對于程序員來說要求比較高，必須對線程同步編程很熟悉，而且花在同步上的操作影響了平臺的性能。一般現在的圖形界面工具都不再采用這種方式。

         下面比較一下Swing/AWT/SWT在API、GUI特征以及實現方法的不同。

         在API上，Swing和AWT是兼容的，SWT是單獨的一套接口。

1.Swing/AWT的組件在生成時可以脫離父組件獨立存在，SWT必須有父組件存在。這主要是由于SWT的資源是自己管理，SWT程序必須負責釋放不用的資源，為了避免這種釋放資源的重復性，SWT父組件被設計成在析構時自動遞歸調用子組件的析構函數。

2.Swing/AWT的資源回收由垃圾收集器負責，SWT必須由SWT程序顯式釋放。

3.Swing/AWT的事件線程循環不需要程序員顯式啟動，SWT必須要程序員來顯式啟動。

         Swing/AWT和SWT在布局管理器上是類似的，沒有太大區別。

         在GUI特征上，有兩個比較層面，一個是組件種類，一個是組件本身特征。在理解這些特征時，一定要牢牢記住這樣一個準則：Java是平臺無關的語言，因此它對應用程序所提供的API一定要各個平臺都相同，GUI特征其實也是API，所以GUI的特征必須在各個平臺都相同。

         組件類型上，AWT采用的是最大公約數方法，而Swing/SWT采用的是最小公倍數方法。簡單的說AWT是各個平臺所有組件集合的交集，而Swing和SWT則是各個平臺組件的并集。下圖所示，假設操作系統平臺OS1上提供組件{C1, C2, C3, C4, C7}，而OS2提供{C1, C2,C3, C4, C6}，OS3提供{C1, C2, C3, C4, C5}，那么其中的陰影部分就是AWT所實現的組件，由于C5、C6和C7是各個平臺所特有的，因此AWT中就不包含這些組件。比如Table和Tree在Java支持某些操作系統平臺中不包含，所以在AWT中就沒有Table和Tree。由于AWT的組件太貧乏，所以AWT在現在復雜應用程序幾乎沒有什么用。Swing和SWT提供的組件是各平臺所有組件的并集，這樣就解決AWT的組件貧乏的缺陷。也就是說，Swing和SWT提供的組件包括C1到C7的所有組件，而AWT只提供C1到C4的所有組件。

         從組件本身的特征來看，SWT和AWT采用了相同的策略，即最大公約數，而Swing采用的是最小公倍數。如下圖所示，假設對于同一個組件C，如果它在OS1上提供的特征包括{a,b,c,d,e}，而OS2上提供的特征包括{a,b,c}，而OS3包括的特征有{a,b,c,d}，那么SWT和AWT提供的組件特征只包括{a,b,c}，而Swing的包含的平臺特征包括{a, b, c, d, e}。比如由于Solaris平臺上的按鈕不提供對于圖標的支持，所以SWT和AWT的獨立按鈕就不提供對于按鈕圖標的支持，而Swing提供按鈕圖標的支持。

         在實現方法上，AWT采用Java+Native C Peer(一種JNI調用）方法，SWT根據各平臺的不同情況，一部分組件使用Java+Java Peer+JNI Wrapper，一部分采用Java模擬的方法，而Swing則采用所有組件都純粹Java模擬的方法。

                    AWT的接口和各操作系統組件之間的差別采用Native C Peer實現的方法來填平，下面是它的結構示意圖：

           其中AWT Native Peer Impl部分都是C語言寫的，在各種操作系統上是不同的，但是它們和AWT Component組件之間的AWT-Peer JNI調用接口是不變的，AWT Component的Java代碼實現在各個平臺上都是相同的，最后AWT Component向Application提供同一的API接口。

           SWT同AWT不同，它在Native Component上進行了一層薄薄的JNI封裝，所有操作系統的API調用都被映射到一個JNI調用上，然后SWT通過Java代碼組合這些JNI調用實現同一的API，下面是其結構示意圖：

         因此SWT的Java代碼實現部分在各個平臺是不同的，它的C代碼部分即JNI Wrapper部分只是一個各平臺GUI API的JNI簡單映射，SWT通過Java Peer在各平臺的不同實現填平了各平臺差異，從而給Application提供同一的API接口。當然SWT對于某種平臺上缺少的組件采用的方法和Swing基本類似。

         Swing和上兩中方式完全不同，它直接調用Java2D，拋棄了本地操作系統平臺組件的實現，完全自己畫出來了整個組件，當然Java2D底層也是調用平臺的圖形系統。下面是它的示意圖：

         當然Swing是建立在AWT基礎上的，對于一些頂層容器類如Frame / Dialog / Window以及Applet是直接采用AWT的，這兒為了方便并沒有畫出。由于Java2D API是個平臺無關的，因此Swing的Java實現代碼在個平臺都是一樣的，都是一套，當然除了與Swing的Look And Feel相關的東西以外。

         由于篇幅原因，今天就先談到這兒，至于這三種不同架構、實現會對它們的性能和外觀以及編程難度產生什么影響，我們以后的文章逐漸討論。