[转载]SWT,又如何? - JAVA论坛

Eastsun

等　级：贵宾
威　望：32
帖　子：802
专家分：0
注　册：2006-12-14

楼主

问题点数：0 回复次数：4

[转载]SWT,又如何?

本文为翻译一篇经典的博文，原文详见SWT - So What?

引言

如果你正打算采用SWT来做一个重要项目，我建议你要三思而行。相对比其竞争对手Swing来说，SWT在功能、支持以及社区开发经验上都严重缺乏。不难理解你很难从怒气冲冲使用SWT来创建应用软件的人们那儿获得不到多少信息。网上有许多刚学SWT、狂热的人写下的“时尚男孩”的文章(Fan-boy stuff)，认为所有SWT都是如此酷毙，如此令人震惊，却很少能发现那些长年累月使用SWT，实现过真正SWT软件的人的评论。最贴切的是能在eclipse.org.swt新闻组上的“老手”那些人。从SWT开发社区反馈出意见来看，我发现人们对于SWT的热情同他们使用SWT经验成反比。

首先让我从高层次上简要描述一下SWT和Swing的区别：

Swing是Sun在1997年发布的。被认为是Java界面开发“标准”同Java绑定在一起的。Swing仅靠模拟来实现界面，也就是Java使用原子画图操作将按钮、菜单以及其他组件画在空白屏幕上。Swing完全忽略所在操作系统能够提供什么组件，但是通过它的“Look and Feel”机制能够模仿这些组件的外观和行为。
SWT是IBM为了支持Eclipse集成开发环境于2001作为开源发布的。起初IBM使用Swing开发Eclipse，但发现Swing速度太慢，于是决定自己实现一套组件系统，这就是SWT。总的来说SWT封装了底层操作系统的本地化组件，目的是为了获得比Swing更好的性能，并使用SWT开发的界面同本地操作系统相同。

关于Swing和SWT比较争论已经成了宗教式的辩论。SWT阵营的人标榜其同本地应用程序的平台一致性(Fidelity)、性能以及效率。他们嘲笑Swing的响应、内存消耗以及复杂度。Swing阵营的人标榜Swing的成熟、强大的功能以及支持。他们嘲笑SWT的功能简单、质量差以及开发使用者小。双发都认为对方出身可疑（血统不好）。

使用SWT存在的问题

对于SWT初学者来说，SWT有数不清的问题需要解决。总的来说你会发现它们是沮丧之源。

Bugs

除非你开发的是一个非常小的程序界面，否则你必须非常熟悉eclipse.org的bugzilla(Eclipse的bug报告系统）的使用方法。进一步举例，在Bugzilla上查询一下Azureus和BitTorrent(两个使用SWT开发的大型应用）主要开发者提交的bug，你会发现每人在开发产品过程中都提交了至少50多个SWT的问题。如果你是在开发一个开源应用，由于没有时间期限和资源限制，这是可以接受的，但如果这是一个商业环境，在发现和提交bug、以及等待bug解决上花费大量时间就会是一个严重问题。

你肯定不想你的产品有严重问题，而这些问题你又无法控制在规定时间之内。以前开源中所说的“Just fix it yourself”是不可能的。在商业环境下，客户付钱给你是让你提升业务价值的，不是让你用来克服组件工具的缺点的。而且，又有多少人能同时具有五种甚至更多操作系统底层窗口系统的知识呢？

当涉及bug修改和功能提升时，每个bug修改都要在不同本地操作系统组件上使其运行，这会是一个很大工作量，也是工期延期的主要根源。在最近的eclipse.org.swt新闻组上，当一个程序员抱怨Table组件的bug已经好几年没有得到修改，SWT系统构架师Steve Northover这样回答：

“如果你（抱怨Table组件的bug的程序员）这样想一想，我们要支持五个不同的操作系统，使用不同的代码，要把它们结合在一起，而都要实现可移植的API，并且我们是免费做的...”

这个问题是SWT系统架构不可避免的副作用，使用本地操作系统组件就不得不维护数不清不同得代码。这负担很大而且就像James Gosling说的是“一个出力不讨好的地方”。

功能局限

从Swing背景转过来的SWT程序员可能会对SWT缺少如此众多的功能而感到吃惊，这些功能是他们在Swing早已熟悉的而认为是理所当然的东西。比如，Swing开发人员会觉得在按钮上同时放置文字和图片没有什么困难的，但是惊奇的发现这在SWT中无法实现，除非这些按钮是在工具栏或者CoolBar中出现。他们会习惯于在组件上添加一些合适的边框，但是却发现为什么边框只在某些SWT组件比如Text和Label中支持。他们会习惯于在文本输入框中设置Input Masks，却发现在SWT中他们只好自己写Listener来处理Text组件的按键事件。

Eclispe驱动的开发模式

我们都知道SWT最初是为了开发Eclipse而产生的。现在Eclipse已经开源了，SWT被某些人吹捧为可以替代Swing的通用界面开发工具。但是这种继承（Eclipse血统）现在看来却是累赘。好像有一个同Eclipse相关的双向沟通部门，如果发现某个bug影响到了Eclipse，那么在一定时间内就会被注意到，但是如果这个bug不影响Eclipse，那么情况就很不同了。这样的bug往往优先级很低。而且由于Eclipse界面开发组的资源限制，想要提高某些功能就比较困难。当你的开发领域同Eclipse不一样时，这种以Eclipse为核心的维护和扩展策略就很是问题。比如构建数据仓库和厂家跟踪系统应用的界面就和构建一个IDE的界面需求就不同，前者所需的不是后者所要的，但是维护和提高的优先级却是要根据同Eclipse相关大小而定的。因此，如果你发现SWT越和所需不一样，越说明你的应用领域和IDE不一样。

谎言

有许多围绕SWT和Swing不实的谎言和说法。当评价这两种技术时，你首先要区分什么是观点看法，什么是事实。下面我就举出常见的几种错误观点。

SWT速度快，Swing速度慢

显然最初对于Swing速度的担心才促成了IBM开始开发SWT。令人感兴趣的是，如果是现在他们是否还会做出相同的结论，特别是当Swing的速度在JDK1.5之后得到了巨大提高。实际上，如果编程不好，将耗时任务放在界面事件线程中，Swing和SWT应用都有可能失去响应。比较SWT和Swing速度最好、最科学的办法是通过benchmarks，然而当底层实现技术差别如此之大时，很难做出客观公正的比较。

（在另一篇文章,有一个关于Swing和SWT的速度的Benchmarks：
http://www.javalobby.org/java/forums/t78884.html）

一致性提升易用性

SWT支持者们所以不断强调一致性的原因是认为其提升易用性。SWT目的是提供比Swing更好的平台一致性，并因此使得SWT应用更好使用。我认为这个论据是华而不实站不住脚的，原因如下。

首先，支持此观点的人都是开发者，而并非最终用户。这一点非常重要，因为程序员认为重要的，普通用户未必这样认为。有可能程序员的技术信仰影响了他们对于易用性理解，请注意，Eclipse是一个IDE，它的最终用户是程序员，因此SWT的产生是基于程序员的观点而产生的。在SWT产生之前，Eric Gamma(SWT主要设计者之一)曾这样说：

“我是小组成员之一，我们的目标是为嵌入式应用开发基于的集成开发环境，以替代IBM的VisualAge/MicroEdition...我们对已经取得的成果很满意！然而，我们早期用户（开发者）并不像我们一样满意...他们抱怨速度，而且最重要的是IDE(Eclipse)看起来感觉起来不像一个本地程序。有些速度问题是我们的错误，有些是因为Swing造成的。我们并不太关心速度问题，随着时间通过修改可以改进（速度）。我们关心的是非本地化感觉的批评。我们可以用Swing实现一个非常漂亮运行在Windows上的应用程序，但是我们无法创建一个真正的Windows程序。弥补这个缺陷需要更激进的措施。”

于是SWT的产生源于IDE开发的努力，并且是基于IDE早期使用者的反馈，而这些人本身都是程序员。我怀疑非程序员是否关心平台一致性。从我自己来说，我没有发现Swing模拟的界面和本地Windows程序界面的些小差异会造成易用性上的巨大差异。许多最终用户甚至没有注意到这些差异，他们只是模糊的感觉到这些程序有些不同，但具体是什么并不确定。

其次，由于上文描述的LCD（最小公约数）效应，SWT常常并不能准确的表现本地组件系统的行为和外观。另外，并没有确切证据说明SWT组件和Swing模拟组件的差异造成了易用性的差异。事实上，许多情况恰恰相反，想想在Windows上成功的一些软件：iTunes, QuickTime, Winamp以及Firefox浏览器，它们都拥有与本地平台非常不同的界面，使用他们的恰恰是那些Windows用户的新手。当用户从一版Windows升级到另外一版，比如从2000到XP，界面上往往有数不清不同花哨的东西，难道他们就突然发现自己无法使用这些程序了？当然不，原因就是些许审美差别不是易用性的决定因素。整体界面结构、基于任务的设计模式是关键因素。按钮阴影效果是3个像素还是2个像素无关紧要，只要用户能够识别出他们面前大的构件是什么，这个构件有预期的行为，易用性就不会被影响。

最后，即使易用性和平台一致性是不可分的，又如何看待SWT中的Flat Look部分呢？它们能创建类似Web页面一样界面，但是否带来更多功能呢？它们与SWT支持的本地平台完全不同，如果你见到过Eclipse的PDE，你就见过Flat Look。如果平台一致性和易用性是联系在一起的说法是正确的，Flat Look界面岂不是噩梦？这种前后不一致的说法让人觉得很糊涂。

SWT比Swing容易学

SWT狂热分子声称SWT比Swing容易上手。当我两个都学完了之后，我发现并不是这样。任何技术是否容易学习都包含两个方面：学习技术知识本身的难度，以及教这些技术知识的难度。理论上说，SWT和Swing有很大的重叠部分。组件层次结构，布局管理器，事件处理线程以及数据展现分离是两者中都存在的概念。内置的组件和布局管理器基本相同，真正的不同是相关材料的数量与质量。SWT的javadoc很少，剩余的知识需要从各种SWT文章、代码以及在SWT新闻组中拼凑。SWT方面的书也许只有六七本。除此之外，你只好自己研究SWT代码，籍此反向理解怎么会事。Swing的情况正好相反，javadoc非常丰富，各种各样的在线教程，大量相关的书籍，因为有相对较多的材料，学Swing相对SWT来说要容易的多。

相对较少的第三方组件是件好事

任何SWT和Swing的比较总要面对这个事实：SWT几乎没有第三方组件库，但是Swing却丰富的多。这会对程序员的效率产生很深的影响，本来可以直接引入的第三方组件，现在却要手工编写，这增大了开发费用。

我听到的也许是最疯狂的支持SWT的理由是：有限可供选择的第三方组件是件好事，因为这减少了程序员犯错的机会，如果有许多可供选择的组件，程序员就会将他们的界面堆满了他能得到的任何漂亮组件。使用SWT不会有这样问题，因为这样的第一手组件在SWT中很少。

这个理由是如此荒唐，只有乞丐才会相信，但这就是我听到的SWT狂热分子所说的，近乎疯狂的证明他们的理念是正确的。其错误之处在于混淆了组件的丰富性和组件的滥用性。界面的易用性不是它能包含多少组件的功能，而是这些组件被使用和组织的方式。好的界面设计者知道新奇的组件会让不熟悉他们的用户感到困惑，因此一般不会使用他们，除非需要提供巨大改进功能而牺牲直观性。差的界面设计者即使手头的组件再怎么少，构建出的界面可用性也不会好。为了更好理解，可想想下面的类比。

假设一个优秀艺术家和一个低劣艺术家，每人给他们一个上千种颜色的调色板让他们作一副画。好的艺术家会能创作出艺术作品，差的艺术家只会糟蹋颜料。现在，为了让差的更不容易犯错，你让他们俩都使用只有十种颜色的调色板，结果会怎么样呢？优秀的艺术家仍然能创作出艺术，虽然可能不像第一个那样细腻，差的艺术家仍然是一塌糊涂，只是比第一次少了一些颜色变化。通过限制可选择的颜色，你并不能保证差的更难画出脏乱作品，反而你却限制了优秀艺术家的创作才能得到全部发挥。用户界面是同样道理，界面的易用性很大程度上和设计者的才能和经验有关，而和可以使用的组件多少没有关系。

结论

最近人们对于富客户界面应用的兴趣重新复苏，看起来近几年业界所经历的Web应用困惑开始消退，人们终于认识到将所有交互都塞到浏览器里并不合适。尽管目前程序员仍然喜欢基于Web的开发，他们的热情却并不能被最终用户所认同，他们不得不挣扎在IT部门由于技术和意识狂热而产生的产品上。

对于那些对公司实际利益关心的人，除了看起来“酷”，SWT没法和Swing进行竞争。SWT仍然不适合于通用界面开发，而且相对于Swing不成熟（比Swing晚7年），你要考虑其使用和持续开发怎么样才是理智的。

如果你正在使用Java开发一个富客户界面的程序，考虑SWT和Swing时，我建议你考虑清楚以下几点：

如果你认为SWT的平台一致性会带来更好的可用性，你所依据的实际理由是什么？你把他们都放在最终用户面前测试过吗？
找一个好的界面开发人员很难，找一个好的具有SWT技术的开发人员更难。你去哪儿找使用SWT开发用户界面的员工呢？如果你想让Swing开发人员再学习SWT，考虑一下员工运营费用问题。让Swing开发人员去转而使用SWT，就像让习惯骑Harley Davidson的人去骑Vespa摩托车一样，他们不可能会高兴的。
你的终极界面和Eclipse界面有多少相似点呢？注意你的功能只要偏移Eclipse的功能需求，你就得依赖自己了，很有可能你不得不自己写自定义组件来实现你希望的行为。你公司愿意你在这些组件上花费时间和金钱吗？而这些组件在Swing中很容就找到。
由于SWT的bug和缺点，你的开发人员工作效率就会不高，因此你得预料到工期会延期，必要时还要增加资源。你公司能为你花费这些额外支出吗？
在认为Swing应用程序又慢又丑陋之前，你看过NetBeans和JIDE这些产品吗？我就遇到过这种自从AWT时代就没有再回头看过Swing的人。
你关于SWT的信息是不是来自界面设计新手的博客网站，或者那些仅仅简单使用过SWT的人的文章？我建议你订阅SWT新闻组和邮件列表，在那儿你就会发现许多长时间使用SWT人的在痛苦挣扎，他们已经过了狂热的初始阶段。