既生AWT，何生Swing？
|
在Java 技术刚出现的初期，大家最感兴趣的Java API 无疑地就是AWT。一方面因为JDK 1.0 时只有AWT 称得上是一组完整的application framework，其它Java API 都比较偏向个别的class，二方面是因为当时大家受尽了MFC 的苦，希望能有一个比较好的替代品。MFC 的兴盛期已过，目前余孽尚存，我很乐见这种不良的API 逐渐凋零。Bruce Eckel 说得好：「MFC 是我经验过最糟糕的东西（MFC is the worst thing that I've experienced）」。少说重话的Bruce Eckel 批评MFC 其来有自，因为Bruce Eckel 是物件导向程式设计的倡导者，而MFC 正是物件导向设计失败的绝佳范例。相较于MFC 的不良设计，AWT 在物件导向方面就好很多了，但是因为两者都采用ripple 形式的event model，所以两者在这方面很类似。在JDK 1.1 版以后，整个Java（包括AWT）的event model 改用较好的delegation event model。JDK 1.2 之后，Java 有了另一组GUI 的API，叫做Swing。因为Swing 是lightweight 的API，所以无所不能，不但有各式各样先进的元件，而且连元件风格都可抽换。Swing 出现之后，大家很快地就不太使用AWT 了。我发现lightweight 元件近年来大行其道，跨Windows/unix/Linux 平台的Qt 也是lightweight 元件的套件。
虽然Swing 的元件有诸多优点，但是它有一项致命的缺点...「慢」。许多人开发出来的Swing 程式执行速度很慢，但是问题不见得全都出在Swing 上面，有可能在于程式员的程式经验不足，思虑欠周所致。遇到像这样的情况，我会建议他们把程式的某些地方改写，通常效能会有明显地改进。如果这样还是不够快，那么最后一招就是把GUI 由Swing 改成AWT。最近AWT 又变得稍微重要起来了。IA（资讯家电）产品热潮逐渐兴起，许多IA 产品上会有JRE，能够执行Java 程式，例如WinCE、PalmOS、Symbian EPOC 这三大PDA 的OS 都有JRE。比起桌上型电脑，掌上型的IA 不但记忆体有限、CPU 不够快、萤幕小且色彩少。这类IA 上面的Java 程式一定要用AWT 来设计GUI，因为这类装置的JRE 根本不支援Swing 这样耗费资源的庞然大物。总而言之，如果你：
那么，你应该多花一点时间把AWT 学好。否则，你应该直接去学Swing，会比较实际些。 |
1、 三者的概述：
AWT(Abstract Window Toolkit) 是 API为Java 程序提供的建立图形用户界面GUI (Graphics User Interface)工具集，基于一个对等体实现的。AWT可用于Java的applet和applications中。它支持图形用户界面编程的功能包括： 用户界面组件；事件处理模型；图形和图像工具，包括形状、颜色和字体类；布局管理器，可以进行灵活的窗口布局而与特定窗口的尺寸和屏幕分辨率无关；数据传送类，可以通过本地平台的剪贴板来进行剪切和粘贴。
SWT（"Standard Widget Toolkit"，是一个最初由IBM开发的工具包，现在由Eclipse基金会维护。）是一个独立于平台的，也是基于一个对等体实现的，可以脱离 Eclipse 框架单独使用的图形组件，用JNI技术提供与本机系统同样的用户界面组件的观感，较好的运行效率，稳定的平台表现。一个SWT应用程序的基本组成部分为显示界面（Display）、命令界面（Shell，使命令进入并使运行初始化）和窗口部件（Widgets）。Display负责管理事件循环和控制UI线程和其他线程之间的通讯。Shell是应用程序中被操作系统窗口管理器管理的窗口。每个SWT应用程序至少需要一个Display和大于等于1个的Shell实例。
Swing是基于AWT的架构之上的，在不改变大量的程序代码前提下允许程序中每个组件观感的变化。支持可更换观感技术的引入允许Swing组件在模拟原生组件外观的同时又保持了平台独立的优点。
2、 三者的区别
AWT、SWTt都依赖底层平台，都基于对等体实现的，在不同的操作系统上开发出来的程序显示效果不一样，SWT提供比AWT更为丰富的组件集；而Swing对底层平台的依赖很少，所以给不同用户一致的感觉，还拥有一个丰富、便捷的用户界面元素集合。由于AWT和SWT都持有对本地组件的引用，它们必须以正确的方式释放这些引用以避免内存泄露和JVM崩溃。AWT将绝大多数资源管理任务交给系统，不过这使得AWT的实现复杂化了。一旦它实现了，开发者很少有机会犯错误并使他们的程序崩溃。而SWT是采用另外的方法，它有一条法则就是：谁创建，谁释放。因此开发者必须谨慎地显式调用dispose方法释放每一个由他创建的组件和资源。这虽然简化了SWT的实现模型，但把开发者摆在了因错误编码而易于造成程序崩溃这一风险之上。
awt只提供所以操作系统都有的控件，即全部调用的是本地操作系统的控件；Swing只是窗口和框架等的顶层的组件调用操作系统控件，大部分都是使用java代码来模拟的；swt大部分是用的本地操作系统的控件，有些在别的操作系统的控件要经过自己的绘制。Swing和SWT都在实现上都使用模拟。SWT是模拟平台上缺失的组件。区别是SWT的模拟更像是AWT的Canvas实现的模拟。SWT的Composite类有它自己在操作系统中相应的对等体。它从自己的对等体中获得所有它所需要的资源如图形处理的对象，字体和颜色等。它直接从操作系统获取所有的事件并进行处理。然而，Swing组件在操作系统中没有相应的对等体。它只是一块顶层容器中的逻辑区域，实际上它从顶层容器的对等体中借用资源。Swing的事件并不是底层系统产生的事件。它们实际是由顶层容器处理AWT事件所产生的伪事件。另一个不同之处是Swing组件的z-order系统是来自于AWT组件的。Swing是基于awt的架构之上的，故Swing组件与顶层AWT容器共享一个对等体。
因此，Swing组件也和顶层容器有相同的z-order。SWT和AWT组件都有不同于顶层容器的z-order，通常是高于顶层容器。故而如果AWT组件和Swing组件混合在一起的话，Swing组件将可能被AWT组件遮住。当操作系统开始更新UI的时候，顶层容器和Swing组件总是先于AWT组件绘制。当它们完成绘制，AWT组件会覆盖Swing可能绘制过的地方。因此不提倡Swing和AWT组件的混用。如果有一个浮动的Swing组件如菜单，AWT组件很可能遮盖菜单。
https://sites.google.com/a/mis.nsysu.edu.tw/cheng-shi-zi-xun-wang/java-jin-jie-pian/gui-pian/1-java-degui-gai-nian
https://blog.51cto.com/caochun/1751064