返回首页

AWT/SWT/Swing大比较之一:模型设计与实现

时间:2009-02-03 22:02来源:sina 作者:WilliamChen 点击:
总的来说Swing/AWT和SWT在事件处理机制上是类似的,窗口组件的树状结构也是类似的。图形用户界面系统在事件处理设计上有两大类,一类是单线程模型,一类是多线程模型。在事件处理机制上,三者都是遵循单线程规则。
   总的来说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提供按钮图标的 支持。

http://static11.photo.sina.com.cn/orignal/4b6047bc110f3bdf23c9a

         在实现方法上,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,下面是其结构示意图:

http://static1.photo.sina.com.cn/orignal/4b6047bc914c1ab21d970

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

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

顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
发布者资料
小朱 查看详细资料 发送留言 加为好友 用户等级:超级会员 注册时间:2008-11-18 17:11 最后登录:2012-02-06 13:02
推荐内容
热点内容