Sun在JDK 1.0最初发布了图形API包,代号AWT (abstract windowing toolkit)，里面除对GUI基本支持（如结合各OS的事件分发机制等）外，自有一套重量级开发GUI的思路，并提供了一组常规使用的重量级组件。所谓重量级组件就是每个组件都引用一个本地对等体peer成员对象，这个对等体对象利用本地系统GUI API绘制组件。后来在JDK1.1，AWT包中引进了一套轻量级开发GUI的新思路，并提供了一组轻量级组件。所谓轻量级组件就是自身没有本地对等体，而借助重量级组件作为容器来绘制组件。JDK 1.1之后，sun在开发GUI思路上，在效率，扩展性等方面给出了很多创新，并基于这种新思路推出一套丰富的新组件（轻量级组件），sun为此打出一个新的响亮的代号---Swing，并推荐以后的GUI开发都应该基于Swing的GUI开发思路开展，应该使用或扩展这套Swing的组件。
不论是AWT模式还是Swing模式，Sun的GUI开发思路都是纯OO的。开发人员总是构建多个组件对象实例来组合建立GUI，这些对象是因不同的输入输出表现被封装为多种组件类的实例，而这些组件类是有合理的继承关系因而容易扩展的“套件”。而且两种模式最基本的统一的程序运行思路都是：
1．通过建立各种组件的实例来负责GUI的工作。
2． 约定出GUI变化时机—java应用程序随需发出请求调用或对操作系统级某种操作的监听（如暴露被遮挡的窗口内容）。
3. 在时机到来时由“框架程序”来判断并调用应该调用的目标组件实例所提供的各种形式的paint方法（各组件在此方法里通过java 2d API包来实现自己的具体绘制逻辑）来完成各组件绘制。
4. 在GUI的整个生命周期里，通过以上的123模式来完成整个应用界面的随需而变。
下文将主要分析Swing模式。
Swing式 开发GUI的基本约定包括：Swing提供4个顶层容器JFrame,JDialog,JApplet,JWindow，如果是桌面应用，则GUI必须要有一个JFrame，如果是浏览器应用，则GUI必须要有一个JApplet。其他Swing组件，或自定义开发的Swing组件都扩展自JComponent，并且其实例要存在于顶层容器的层次树中。下面是一个符合约定的GUI的运行分析。
这里的repaint将首先确定RepaintManager.HANDLE_TOP_LEVEL_PAINT-如果不支持将委托给 Component.repaint，形成PaintEvent并进行提交走AWT模式。支持的话将促使RepaintManager加入重画区后通过调度走Swing模式。Swing模式就是走RepaintManager的方式。自身的repaint不会去考虑每窗口双缓存直接拷贝区域，因为这时的需求就是要求重新绘画。轻量级Swing组件在自己的repaint方法去主动创造绘画时机。
JComponent.Repaint{RepaintManager.currentManager(this).addDirtyRegion}走Swing模式处理。
Swing模式都是借由RepaintManager来安排绘画，它维护了一个几何区域并负责重画的框架。外界总是要求先加入RepaintManager重绘区，在加入的同时激发起一个调度重画的
- SunToolkit.getSystemEventQueueImplPP(context).
- postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
- processingRunnable))
注意，通过上文分析，对于顶层容器处理底层消息的触发时，走Swing处理模式而通过SwingpaintEventdispatcher 去创建painitevent时除向repaintmanager登记脏区（如果不使用每窗口双缓存策略）外，还要额外post一个 IgnorePaintEvent。该paintevent在随后的EDT里按awt模式走peer处理时并没有加入awt的重画脏区，实际上忽略掉了绘制意义，这样做避免了在Swing和awt两种模式的重复绘制，但同时形成依然将paint事件通知到组件的效果。
- public void coalescePaintEvent(PaintEvent e) {
- Rectangle r = e.getUpdateRect();
- if (!(e instanceof IgnorePaintEvent)) {
- paintArea.add(r, e.getID());
- }
【编辑推荐】
