SWT_AWT_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相关的东西以外。

         由于篇幅原因，今天就先谈到这儿，至于这三种不同架构、实现会对它们的性能和外观以及编程难度产生什么影响，我们以后的文章逐渐讨论。