AWT Swing SWT区别

关于AWT和Swing的一点讨论

目前大多数的嵌入式Java虚拟机都提供了对AWT 的支持但是不提供对Swing 的支持。但是，在标准版的Java平台上Swing 才是推荐使用的图形界面系统，在Sun 公司所提供的Java Tutorial 中甚至把基于AWT 的图形用户界面设计这一部份从其网站中删除，需要利用到AWT 进行图形用户界面设计的用户只有将该部份下载到本地硬盘才能够使用这部份教程。在标准版Java中正值春风得意的Swing 为什么到了嵌入式应用中便不再吃香了呢？

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

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， 也就是通过牺牲速度来实现应用程序的功能。

抽象窗口工具集
       　　在开发applet和图形应用程序时，一般需要用到AWT，AWT是免费Java开发工具包(JDK)的一部分。
       AWT的作用是给用户提供基本的界面构件，例如按钮、列表、菜单、文本域等等。AMT
       构件主要是用来建立图形用户界面的独立平台。此外，AWT还提供事件处理结构、支持剪贴板、数据传输和图像操作。随着2D
       API的出现，AWT还包括提供高级字体操作、打印、地理数据获取和输入方法等功能的软件包。AWT的初始版本是基于在简单用户界面中开发小applet 程序而设计的，与之相比，当前的AWT做了很大的改进，它提供事件模型重新设计、剪贴板和数据传输支持以及打印和无鼠标操作等功能。从而与Parc
       Place的VisualWork或Borland公司的Object Windows Library(OWL)等企业级用户界面具有更多的可比性。
       　　
       　　同位体和平台独立
       　　随着Applet程序和图形应用程序接口的发展，AWT提供了一系列的通用类，这些通用类在引用时不需要考虑特定的窗口平台，同位体(Peer)就属 于这种AWT类集。同位体是一种本地图形用户接口(GUI)构件，由AWT类管理。同位体的工作方法和它们对程序开发的影响常

       　　常让人混淆。
       　　AWT构件中，包含有对其同位体的大量实用操作。例如，如果你使用AWT创建一个menu类的实例，那么当Java运行时系统将创建一个菜单同位体的实例，而由创建的同位体实际执行菜单的显示和管理。在创建菜单实例中，Solaris
       JDK将产生一个Motif菜单同位体;Windows 95将产生一个Windows 95菜单同位体;Macintosh
       JDK将产生一个Macintosh菜单同位体等等。
       　　
       　　一个Java程序创建并显示AWT构件，AWT构件创建并显示本地构件(同位体)。AWT开发组决定使用同位体方法，这一方法使得交叉平台窗口工具开发变得极为迅速。
       使用同位体可以避免重新实现本地窗口构件中已包含的实用工具，而且，使用同位体还能使applet和应用程序保留在本地系统中，这是因为同位体实质上是由本地构件组成的，而AWT类仅仅是同位体外围的包装与操作工具。

       　　虽然在使用AWT时，很少需要直接处理同位体，但它们的存在却影响其操作结果。例如，如果没有同位体，则某些java.awt.Component方 法不会象我们所预期的那样进行工作。使用同位体方法可以在记录时间内实现GUI工具构件。然而，使用同位体也有很多的缺点，同位体设计基础存在缺陷并且不 能缩放。

       　　
       　　轻量构件
       　　AWT构件全都是重量构件，即它们都具有同位体，并且在本地
       (不透明)窗口中进行显示。这样使用将花费昂贵的代价，而且在更改其默认行为时，不可以将其派生为子类。此外，它们必须是矩形的，而且不能有透明的背景。同位体可以快速产生一个GUI工具构件。因为本地同位体做了更多的实际工作，而AWT

       　　类所做的仅仅是表面工作，因此，它很容易开发。开发最初的AWT，只用了不到6个星期的时间。但这种效率带的利益在很大程度上被一些不利因素抵销了，比如基本的同位体结构、有限的事件模式以及同位体与AWT之间不匹配造成的大量缺陷。

       　　1.1版本的AWT引人了轻量构件的概念。轻量构件直接扩展了java.awt.Component或java.awt.Container。轻量构 件没有同位体，在其重量容器窗口中显示，而不是在其本身窗口中显示。轻量构件不会导致与它们自己关连的不透明窗口的性能损失，而且还可以有透明的背景。其 中有透明背景的性能意味着即使轻量构件的界限域实际上是矩形的，它也可以显示为非矩形。

       　　
       　　SWing的历史
       　　要了解Swing，首先必须了解AWT,AWT是Swing的基础。
       　　Java的发展速度超出了人们的想象，Java
       API中最可视的部分----AWT突然成为了人们关注的焦点。遗憾的是，原来的AWT不能满足发展的需要。
       　　原来的AWT不是为许多开发人员使用的、功能强大的用户界面
       (UI)工具包而设计的，其设计目的是支持开发小应用程序中的简单用户界面。例如，原来的AWT缺少许多面向对象UI工具包中所能见到的特性，例如，剪贴 板、打印支持和键盘导航等特性在AWT中都不存在。原来的AWT甚至不包括弹出式菜单或滚动窗格等基本特性，而弹出式菜单和滚动窗格是开发现代用户界面的 两个基本元素。

       　　此外，AWT的下层构件还有严重的缺陷。人们使AWT适应基于继承的、具有很大伸缩性的事件模型。甚至更糟，基于对等组件
       (peer)的体系结构也被用于AWT，该体系结构注定要成为AWT的致命弱点。
       　　为了尽快推向市场和保持本地的界面样式，于是产生了基于对等组件的体系结构，而该体系结构注定是要失败的。对等组件是完成薄弱的AWT对象所委托任务的本地用户界面组件。

       　　对等组件负责完成所有的具体工作，包括绘制自己、对事件做出反应等，这使得AWT组件除了在适当的时间与其对等组件交互外无事可做。由于AWT类只是 较复杂的本地对等组件的外壳，所以，AWT的早期开发人员能在最快的时间内创建组件。例如，java.awt.Panel类只包含十二行代码。

       　　另外，对等组件的设计也有严重的缺点。首先，在大多数平台上，对等组件都是在本地窗口中绘制的。每个组件一个本地窗口实在不能得到高性能，为此，含有大量AWT组件的小应用程序付出了很高的性能代价。

       　　把不同平台上的本地对等组件硬塞进Java框架中也是一个问题，使这些AWT组件跨平台的表现一致是完全不可能的。结果，不但没有实现急需的新组件，而且开发时间都浪费在修补对等组件的错误上和不兼容问题上了。

       　　更糟的是，AWT有很高的错误发生率。于是，第三方开始提供他们自己的工具包，这些工具包提供了更可靠的下层构件并提供了比AWT更多的功能。这些工具包之一是Netscape的Internet基础类
       (IFC)，IFC是一组建立在NEXTSTEP中的用户界面工具包概念基础上的一组轻量类。IFC组件不是对等的，在许多方面胜过了AWT组件。IFC还吸引了更多的开发人员加盟。

       　　由于认识到Java领域很可能在标准用户界面工具包问题上出现分裂局面，JavaSoft和Netscape达成了一个交易，共同实现Java基础类
       (Apple公司和IBM公司也参加了JFC的开发)。Netscape开发人员与Swing工程师一起合作，以便把大部分的IFC的功能嵌人到Swing组件中。

       　　起初打算让Swing类似于Netscape的IFC。然而，随着时间的推移，在增加了插入式界面样式等特性并修改了设计之后，Swing大大地偏离 了它原来的目标。随着Swing1.1版本的推出，虽然大量的IFC技术仍然嵌在Swing中，但是，Swing与IFC相似的部分已大部分消失了。今 天，在一个功能全面的用户界面工具包中，Swing提供了AWT和IFC中最优秀的成份。

       　　
       　　轻量组件与重量组件的比较
       　　轻量组件首次出现在AWT1.1版本中。AWT最初只包括与本地对等组件相关联的重量组件，这些组件在它们自己的本地不透明窗口中绘制。
       　　相反，轻量组件没有本地对等组件，而且在它们的重量容器的窗口中绘制。
       　　由于轻量组件不在本地不透明的窗口中绘制，因此，它们可以有透明的背景。透明的背景使显示的轻量组件可以是非矩形的，虽然所有组件
       (重量的或轻量的)都基于一个矩形边框。
       　　Swing组件几乎都是轻量组件，那些顶层容器:窗体、小应用程序、窗口和对话框除外。
       　　因为轻量组件是在其容器的窗口中绘制的，而不是在自己的窗口中绘制的，所以轻量组件最终必须包含在一个重量容器中。因此，Swing的窗体、小应用程序、窗口和对话框都必须是重量组件，以便提供一个可以在其中绘制Swing轻量组件的窗口。

       　　
       　　好了，这是对AWT和Swing的一个概述，更具体的应用需要在不断的实践中去体会。

SWT

SWT在性能和外观上、以及易用性上比起Swing来说确实要好得多。但是SWT的致命缺点在于：与平台绑定过紧，跨平台发布的时候比Swing要麻烦得多。 swt有个缺点：必需使用本地动态库.   SWING可以不考虑这点.