Swing


天行健 君子以自强不息

posts - 69, comments - 215, trackbacks - 0, articles - 16
   :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

Swing模型与渲染器

Posted on 2007-10-12 10:35 zht 阅读(1691) 评论(0)  编辑  收藏
        本文承接Swing/AWT/SWT比较一文,概要叙述Swing的体系结构,解释了Swing架构关键概念:模型与渲染器,解释如何使用渲染对象扩展该体系架构来支持大数据量的组件。后面的文章还会简要概述SWT的体系结构,为Swing/AWT和SWT的比较做一铺垫。

=====================================

         Java基础类(JFC)Swing工具提供了使用Java平台创建高度可交互性图形用户界面的类。Swing是高度灵活的,但是也因此相当复杂,虽然新手能够使用Swing创建基本的图形用户界面(GUI),但是真要创建一个复杂、专业的GUI界面,你必须理解Swing的体系架构的基础,尤其是使用 Swing创建复杂、像JTable、JTree、JComboBox以及JList这样基于渲染器的组件,Swing提供的基于模型和渲染器的组件是构建高性能、可扩展GUI的关键。

Swing体系结构

         最初Smalltalk系统的UI工具使用所谓的模型-视图-控制(MVC)模式,MVC引入这样一个概念:数据源应该同屏幕展现分开。这是一个优秀的体系设计结构,能促进代码重用和程序框架。Swing使用的是一个变体的MVC架构,如图所示:

http://s2.album.sina.com.cn/pic/4b6047bc02000kk1

         典型的Swing GUI组件包括至少三个对象:一个Component,一个Model和一个UI Delegate,在这个框架中,Model负责存储数据,UI Delegate负责从Model获取数据并渲染到屏幕上去,Component通常协调Model和Delegate之间的操作,并同时负责将 Swing嵌入到AWT窗口系统中。

         注意,UI Delegate对象可以在运行的时候动态替换,这就使Swing具备了可插拔的外观(Pluggable Look-And-Feel, PLAF)。

         虽然Swing的MVC结构显然具备灵活性的好处,但是这个结构通常被指责为一些程序慢的根源。虽然基于MVC结构需要更多的方法调用来支持额外的重定向,其实花费在这儿的消耗很小。对基于Swing的应用程序profile的结果显示,model-view分隔的开销可以忽略不计,不到CPU总开销的 1%,复杂的Swing用户界面的多数处理事件其实都花费在了底层的图形操作上了。Swing的model-view结构并不是低性能的根源,它是构建可扩展程序的关键。

矢量组件

         Swing提供了一些处理大数据量数据集的组件,包括JTable、JTree、JList以及JComboBox。这些矢量组件被设计成能够处理成千上万甚至数百万的数据,为了避免占用大量内存,这些组件在Swing的体系架构增加了渲染器(renderer)概念。下图是增加了渲染器结构的Swing 体系架构。

http://s3.album.sina.com.cn/pic/4b6047bc02000kk2

渲染器(Renderer)

         在这些更为复杂的Swing组件中,渲染器是提供可扩展性的关键。我们以JTable作为渲染器的示例。缺省表格中的每一格可能都有一个JLabel,这对于比较小的数据集来说可行,但是对于大数据集就行不通。比如,如果使用这种表格显示1000x1000的数据集,需要的内存可能要1G,即使每个格子都是空的。

         如果解决这种扩展性问题?Swing的JTable使用一个组件来画出所有相同类型的格子。比如所有的String对象的格子都使用相同的组件画。这种类型的组件被称作渲染器(renderer),使用渲染器显示多个表格极大的减小了大型数据表存储空间。

         当渲染器用来显示表格时,JTable从model中获取格子中的数据,然后使用这些数据对渲染器进行配置,然后使用该渲染器画出该格子。接下来,渲染器继续移动到下一个格子,然后重复这个过程。

         注意你可以通过操作渲染器和模型来控制这个过程,所有的矢量组件,包括JTree、JList以及JComboBox都使用渲染器方法,并不仅限于JTable。

模型(Model)

         直接操作Swing的模型(Model)对于编写可扩展的用户界面至关重要,下面代码是往JComboBox添加数据项的通常做法:

JComboBox box = new JComboBox();
for (int i = 0; i < numItems; i++) {
    box.addItem(new Integer(i));
}

         这些代码只是简单的往JComboBox中添加数据项,代码同往AWT的Choice中添加选项类似,这种方法对于小数据量来说可以,但是当要添加大量数据时就会明显变得非常慢。

         尽管上面的代码没有明确引用任何模型,JComboBox的模型对象实际上参与这个过程,每次调用addItem时,JComboBox内部发生了许多操作:组件将请求传递给JComboBox的模型,模型发送一个事件表明一个新项被添加。很明显,如果你直接操作模型的将会更高效,如下例所示:

Vector v = new Vector(numItems);
for (int i = 0; i < numItems; i++) {
   v.add(new Integer(i));
}
ComboBoxModel model = new DefaultComboBoxModel(v);
JComboBox box = new JComboBox(model);

         这样为什么会更快呢?原因有两个。第一,因为所有项是一次添加到模型去,而不是一个一个的,只有一个事件发出,这意味着更少的事件触发,更少的方法调用。第二是因为需要通知变化的对象更少,总的工作量等于触发次数乘以侦听器数目。因为模型是新创建的,侦听在上面的侦听器为零,这意味着没有触发事件发生。

         从上面的例子可以学到两点:

  • 尽可能使用批操作,尽量减少触发事件的数量。

  • 当初始化或者需要完全替换模型的内容时,考虑重新生成模型,不要使用已经存在的模型,已存在模型上已经保持了很多的侦听器,新生成的模型没有侦听器,这样避免了不必要的处理函数的调用。

             触发事件数量严重影响你的程序启动时间,也会影响打开对话框和相似操作的时间。

=====================================

          本想详细举几个例子进一步说明模型和渲染器的用法和好处,但网络速度还是太慢,写一篇文章太痛苦了...加上篇幅原因,准备以后再写一文,弥补这方面的知识。

          以后几篇文章包括(非文章标题):

  • 使用Swing模型和渲染器优化Swing程序。

  • Swing/AWT事件处理模型以及线程安全。

  • 如何编写响应快速的Swing程序。

  • SWT设计和实现介绍。

  • JNI与Java性能的关系。

  • 垃圾收集与虚拟机与Java性能。

  • Swing与SWT性能比较(前面所有的文章都和这篇有关,是基础)。