AWT 、Swing、SWT的区别与比较（网摘）

      AWT

      AWT 是Abstract Window ToolKit (抽象窗口工具包)的缩写，这个工具包提供了一套与本地图形界面进行交互的接口。AWT 中的图形函数与操作系统所提供的图形函数之间有着一一对应的关系，我们把它称为peers。 也就是说，当我们利用 AWT 来构件图形用户界面的时候，我们实际上是在利用操作系统所提供的图形库。由于不同操作系统的图形库所提供的功能是不一样的，在一个平台上存在的功能在另外一个平台上则可能不存在。为了实现Java语言所宣称的"一次编译，到处运行"的概念，AWT 不得不通过牺牲功能来实现其平台无关性，也就是说，AWT 所提供的图形功能是各种通用型操作系统所提供的图形功能的交集。由于AWT 是依靠本地方法来实现其功能的，我们通常把AWT控件称为重量级控件。

    Swing

      Swing 是在AWT的基础上构建的一套新的图形界面系统，它提供了AWT 所能够提供的所有功能，并且用纯粹的Java代码对AWT 的功能进行了大幅度的扩充。例如说并不是所有的操作系统都提供了对树形控件的支持， Swing 利用了AWT 中所提供的基本作图方法对树形控件进行模拟。由于 Swing 控件是用100%的Java代码来实现的，因此在一个平台上设计的树形控件可以在其他平台上使用。由于在Swing 中没有使用本地方法来实现图形功能，我们通常把Swing控件称为轻量级控件。

      说到这里我想各位读者应该明白了AWT和Swing之间的基本区别：AWT 是基于本地方法的C/C++程序，其运行速度比较快；Swing是基于AWT 的Java程序，其运行速度比较慢。对于一个嵌入式应用来说，目标平台的硬件资源往往非常有限，而应用程序的运行速度又是项目中至关重要的因素。在这种矛盾的情况下，简单而高效的AWT 当然成了嵌入式Java的第一选择。而在普通的基于PC或者是工作站的标准Java应用中，硬件资源对应用程序所造成的限制往往不是项目中的关键因素，所以在标准版的Java中则提倡使用Swing， 也就是通过牺牲速度来实现应用程序的功能

     SWT

    SWT最初的目标之一是为了提供比AWT更为丰富的组件集。它遵循最小公倍数原则以提供一个各个平台上包含的组件的并集。思路是如果一个组件在某个平台上包含，那么SWT就会包装它并用java代码和JNI来调用它。如果一个组件在某一平台上不存在，它就会用继承并绘制Composite的方式来模拟组件。一个SWT Composite类似于AWT的Canvas。以这种方式，SWT提供了较AWT更为丰富的组件集。值得指出的是SWT的JNI封装不同于AWT，它的模拟也不同于Swing。

    在组件特征方面，SWT类似于AWT。它遵循最小公倍数原则。在早期的SWT版本中，SWT按钮因为和AWT同样的原因不支持附着图片。在之后的版本中，许多缺失的特征采用模拟的方式补全。但仍有许多特征无法采用纯粹的模拟实现。SWT将组件的控制交给本地操作系统。它难以扩展。只有例如图形装饰等特征可以借助模拟绘制来自定义实现。所以严格意义上将，SWT组件的组件集和特征因其难于扩展而不如Swing来得丰富。
AWT   SWT   Swing 比较

AWT

AWT是Sun不推荐使用的工具集。然而它在许多非桌面环境如移动或嵌入式设备中有着自己的优势。

更少的内存。它对运行在有限环境中的GUI程序的开发，是合适的。

1.更少的启动事件。由于AWT组件是本地由操作系统实现的。绝大多数的二进制代码已经在如系统启动的时候被预装载了，这降低了它的启动事件。

2.更好的响应。由于本地组件由操作系统渲染。

3.从java 1.x时代就为JRE支持的标准GUI工具集，你不用单独安装它，你不用担心平台差异的问题。

4.成熟稳定的。它能够正常工作并很少使你的程序崩溃。

然而，事物都有它们不好的一面。让我们来例数它吧。

1. 更少的组件类型。表和树这些重要的组件缺失了。它们是桌面应用程序中普遍使用的。

2.缺乏丰富的组件特征。按钮不支持图片附着。这很明显是它遵循的设计原则造成的。

3.不支持Look And Feel。AWT被设计为使用本地组件。因此，它依赖系统来提供Look And Feel支持。如果目标系统并不支持这一特性，那么AWT将无法改变它的Look And Feel。

4.无扩展性。AWT的组件是本地组件。JVM中的AWT类实例实际只是包含本地组件的引用。唯一的扩展点是AWT的Canvas组件，你可以从零开始创建自定义组件。然而无法继承和重用一个已有的AWT组件。

SWT
   SWT有如下优势：

1.丰富的组件类型。SWT提供了种类繁多的组件，从基础组件如按钮和标签到高级的表格和树。

2.相对的丰富组件特性。尽管SWT也遵循最大公倍数原则，它采用模拟的方式重新设计了对更多组件特性的支持。所以同AWT相比，它有着相对丰富的组件特性。

3.更快的响应时间。基于和AWT同样的原因，SWT组件包装了本地组件，由操作系统实现渲染。操作系统通常对渲染处理做了优化，保存GUI二进制代码为标准库，减少了内存的使用，提高了响应性能。

4.更少的内存消耗。既然操作系统为本地组件提供了优化，这一点就容易理解了。

不足之处：

    1.不在JRE的标准库中。因此你必须将它和你的程序捆绑在一起，并为你所要支持的每个操作系统创建单独的安装程序。

2.不够成熟和稳定。SWT因其设计上的一些缺陷，如资源管理，Windows友好等，被认为是不稳定的。它可以在Windows上表现得很好，但在其他操作系统上，它经常是不稳定且容易崩溃的。这很大程度上是因为它把资源管理交给开发者来处理，而并不是所有的开发人员能够正确地处理这些。

3.在非Windows平台下的性能不高。如同第2点提到的，SWT被设计为与Windows API相协调的，这导致了在非Windows平台上的性能问题，糟糕的UI感官，不稳定甚至内存泄露。

4.无Look And Feel 支持。和AWT同样的原因。

5.不可扩展，和AWT同样的原因。在SWT中你可以通过有限的方式扩展一个组件，例如，监听PAINT事件并添加自定义绘图到组件上，但鉴于你只能控制绘制处理的一部分，这是十分有限的。你也只能在操作系统绘制完组件后补充，这并不能很好支持自定义。许多应用程序在自定义行为上有很高的要求。

SWING
    Swing是三者中最强大的GUI工具集。它和另外两者相比同样有自己的优劣势。

1、丰富的组件类型。Swing提供了非常广泛的标准组件。这些组件和SWT一样丰富。基于它良好的可扩展性，除了标准组件，Swing还提供了大量的第三方组件。许多商业或开源的Swing组件库在开发多年后都已经可以方便地获取了。

2、丰富的组件特性。Swing不仅包含了所有平台上的特性，它还支持根据程序所运行的平台来添加额外特性。Swing组件特性遵循特定原则，易于扩展，因此能够提供较SWT和AWT更多的功能。

3、好的组件API模型支持。Swing遵循MVC模式，这是一种非常成功的设计模式。它的API成熟并设计良好。经过多年的演化，Swing组件APIs变得越来越强大，灵活和可扩展。它的API设计被认为是最成功的GUI API之一。较之SWT和AWT更面向对象，也更灵活而可扩展。

4、出色的Look And Feel支持。MVC设计模型允许Swing分离组件视图和它的数据模型。它有高级的UI委托来将UI渲染委托给UI类。这些类被注册到一个展现特定的Look And Feel的对象上。已经有上百个Look And Feel 可以提高各种各样的GUI风格。你甚至可以基于其他人的成果编写组件的Look And Feel 。

5、标准的GUI库。Swing和AWT一样是JRE中的标准库。因此，你不用单独地将它们随你的应用程序一起分发。它们是平台无关的，所以你不用担心平台兼容性。

6、成熟稳定。Swing已经开发出来7年之久了。在Java5之后它变得越来越成熟稳定。由于它是纯Java实现的，不会有SWT的兼容性问题。Swing在每个平台上都有相同的性能，不会有明显的性能差异。

7、可扩展和灵活性。Swing完全在Java空间中实现。它可以控制它所需要的一起。Swing基于MVC的结构使得它可以发挥Java作为一门面向对象语言的优势。它提供了许多扩展组件的方法。让我们来列举一下：

A.继承已有组件；
B.靠复合组件的方式扩展。
C.从零开始使用JComponent编写自定义组件；
D.使用渲染器和编辑器机制扩展复制的Swing组件，如JList，JComboBox，JTable，JTree等；
E.基于已有Look And Feel 或从零开始创建新的Look And Feel；
F.使用LayeredPane，GlassPane或拖放机制开发高级的组件，例如浮动的固定组件，自定义弹出窗口，自定义菜单等。

8、总体上良好的性能。Swing的速度是其为人诟病的一点。然而随着JRE的开发，Swing的性能如今已经有了很大的提高。特别是Java5之后，Swing的总体速度能够接近本地小控件系统。

一个GUI的速度总是从两个方面被衡量：响应时间和数据反馈时间。

    响应事件指从事件任务出现到组件更新UI的这段时间。例如按下一个按钮，拖动一个组件，改变一个多标签面板等。在这个方面本地组件总能比模拟组件有更好的响应。AWT和SWT通常比Swing表现出更好的响应时间。然而事实并非总是如此。这取决于操作系统。如果本地组件没有被良好的实现，那结果就是相反的。例如Windows开发了不错的GUI库，而Linux平台通常差得较远。SWT可能在Windows上表现得比Swing好，而在Linux上表现得比Swing差。也就是说，AWT/SWT的性能决定于底层平台。随着JRE的开发，Swing的响应性能能够随着JVM的优化，更好的实现方式，以及图形硬件加速而得到长足的改进。在Windows上，Java6的Swing可以媲美SWT的性能。在非Windows环境中，Swing可以表现出更好的响应时间。

     数据输送时间是指用于将应用程序数据传递给UI组件所需要的时间。例如，一个学生管理系统要求从数据库中装载学生信息并在一个表格中显示出来。花费在从内存到表格组件的数据传递时间被称为数据输送时间.在这个方面，Swing通常比其他二者的性能更好。或许当数据量不大的情况下并不明显。但当海量的数据被输送给表格的时候，这一点就显而易见了。为了理解这一点，提醒你注意JVM和本地操作系统是两个分离的运行时环境。由于JNI的调用在两个环境中跨越式地发生，通常比一个普通的Java调用花费更长的时间。通常这包含两个处理。一个是Java数据结构转换为本地数据结构，另一个是方法返回时的本地数据结构转换为Java对象。其他的性能开销暂时忽略不计。当一个大范围数组的数据从本地组件中输送过来，大量反复的JNI调用将极大地拖垮性能。

     Swing的另一个优势是它有许多的组件模型以提高输送的性能。例如TableModel被映射为两个维度上的数组。这样，在Swing组件中甚至不需要进行数据方式的转换。Swing直接将应用程序数据显示在屏幕上，节省了在数据转换上所花费的事件。

Swing也有不足之处：

     比AWT和SWT更多的内存消耗。Swing自己实现了所有组件。因此，它在运行时装载了大量的类。一些其他的问题来源于小的可变对象的创建，如Rectangle，Point，这些对象基于同步的考虑通常不可重用。Java在堆上创建所以对象。小的对象通常导致了额外的堆空间消耗。许多小的对象较之大对象更难以有效地被垃圾回收。因此，Swing应用程序通常无法及时回收大而小的对象。这种情况的普遍就会导致性能下降。

    更多的启动时间。现在JVM已经快得多了。许多人甚至扬言它可以媲美C++的实现。但多数的Java应用程序还是看上去很慢。实际上，Java性能的很多问题来源于类装载机制。这是一个I/O操作，故而能够明显地降低Java应用程序的速度。也许这是每个动态链接系统中都要面对的问题吧。Swing通常包含了上千个Swing类的使用，在Swing应用程序可以显示它的主窗口之前，它比AWT或SWT装载了多得多的类。这严重降低了Swing的启动时间。这种问题也许会相对好一点如果Swing的类是以共享系统库的方式预加载的。

AWT   SWT Swing比较的更详细信息可参考：

http://www.java3z.com/cwbwebhome/article/article2/21005.html?id=1709