GUI 发展史

1,940
原文链接: www.jianshu.com

图形用户界面(Graphical User Interface,简称GUI,又称图形用户接口)是指采用图形方式显示的计算机操作用户界面。与早期计算机使用的命令行界面相比,图形界面对于用户来说在视觉上更易于接受。然而这界面若要通过在显示屏的特定位置,以”各种美观而不单调的视觉消息“提示用户”状态的改变“,势必得比简单的消息呈现花上更多的计算能力。有兴趣的可以研究下 计算机系统操作界面的发展史

N01.90年代的UI技术

MFC、WTL、WPF、wxWidgets、Qt、GTK各有什么特点?

WTL

WTL都算不上什么Framework,就是利用泛型特性对WinAPI做了层封装,设计思路也没摆脱MFC的影响,实际上用泛型做UIFramework也只能算是一次行为艺术,这个思路下继续发展就会变得没法用了,比如代码过于复杂,编译太慢,出错不好调试等问题难以解决。而且封装得也不完全,还是随处可见HWND HDC之类的东西。用途主要是写一些很小的程序,或者作为其他UI框架的后端实现部分,比如我写过一个小框架用来做安装卸载程序,非常小,其中创建管理窗口部分是用WTL的。

MFC

MFC是更高级点的Win API封装,比WTL封装彻底,很难见到HWND HDC了,也提供了不少实用工具类,比如高级控件,泛型容器,IO访问,网络协议等。除此之外,还提供了一些基本框架,比如 Document/View,这就是个MVC的简化版本,只有MV,但是对于数据的管理,消息的传递等又没有什么约束,导致Doc/View被用得乱七八糟。尤其是对事件处理的模型,消息映射是功能简陋,而且容易出错的方式,唯一优点是性能好。 从VC++ 1.X就有MFC了,那时整个UI界的设计思想都比较落后(除了Apple),MFC又背负了沉重的兼容性包袱,比如vc++ 1.52的MFC程序到了vc2003稍加修改都可以编译,导致MFC后期没有什么发展,就是沿着老的思路完善了些细节,添加了些组件,但是根本性的设计问题没有改进。

GTK

GTK,这个吃了语言的亏,用C写面向对象实在是痛苦,虽然在思想上比MFC要先进了些,但是写出来的代码比MFC要罗嗦很多了。相比MFC,多了Layout的概念,事件处理上有了Signal/slot,虽然用起来很麻烦。

wxWidgets

wxWidgets,这个基本就是个跨平台的MFC,对各个平台的差异做了抽象,实际上后端大多还是用平台原生的API实现,好多控件都是直接用系统原生的。有wxWidgets for GTK+的版本,后端就是GTK+,wxWidgets就是一层壳。这也是wxWidgets的优点,它编译出来的程序发行包比较小,性能也不错。

以上这些就是上世纪90年代的UI Framework技术水平了,至今它们也依然没有太多进步。

NO2. 21世纪的UI技术

Qt

Qt,虽然它也是上世纪90年代出现的,但是它在21世纪有了长足的进步。应该说它的起点就比较高,一开始就定位跨平台,而且不满足于简单封装系统API,而是要自己创造出一套完整的API和框架,甚至要代替系统API,所以不仅仅是做UI,而是涉及到了APP开发所用到的所有东西,包括网络,数据库,多媒体,脚本引擎等。signal/slot是Qt发明的,这是事件通知模型里C++语言的最佳实现了,甚至我都觉得这该写进C++标准,估计C++委员会的老顽固们是从不写GUI的。早期的QT也是没有DirectUI的概念的,每一个QWidget都对应一个原生窗口,从Qt4.4开始,只有顶层QWidget才是原生窗口,而Child Widget是Alien Widget,只是个抽象的图层不对应原生窗口,这就实现了DirectUI的概念,很多图形效果也就变得可能了,比如窗口层叠透明效果。在4.8后实现了QPA(Qt Platform Abstraction),这就使移植Qt变得很容易,目前Qt是支持平台最多的框架没有之一。由于早期授权的问题,Qt对于开源社区不是很友好,导致推广不太顺利,直到它改成了LGPL方式,如果Qt能早点想开了,恐怕就没有wxWidgets的生存空间了。

Qt的缺点也是有的,就是太大,不过可以自己剪裁,我可以把QT库剪裁到发行包压缩后2.5MB。

WPF

WPF,微软在Win Form的思路上走到死胡同后,终于痛下决心用正确的方法开发UI库了。21世纪的UI一定是定义出来的,绝对不能是代码写出来的,所以有了XAML这个强大的定义工具,不但可以定义UI布局,还包括图形动画效果,消息响应方式等。配合C#这种优秀的语言,更是如虎添翼。但是问题也很明显,就是过于庞大,不仅开发时要用到庞大的IDE和设计工具,发行的安装包也十分巨大,所以目前还是很少有人拿他写通用软件客户端的,大多是做企业项目时写专用客户端。大概4-5年前吧疼讯曾经用WPF写了个QQ,但是只实现了基本功能就已经比C++客户端大好多了,而且运行缓慢,主要是太吃内存,而且那时WPF的优化还不充分。

cocoa

最后我想补充下真正的UI库之王,cocoa。Apple的成功有很多原因,其中之一就是cocoa,cocoa理念十分先进,而且出来得早,我都怀疑Qt和WPF有不少思想都是借鉴cocoa的。定义式的UI,用xib就可以定义UI的绝大部分细节,而且提供所见即所得的可视化设计工具。严格的MVC,而且定义非常清晰,分工明确。signal/slot,虽然不叫这个名字,但思想就是,而且真的是拖动鼠标就能connect。提供了ARC,闭包和反射,给UI开发带来巨大的便利性,当然这得益于Objective-C这个语言。

OWL和VCL

再补充下Borland的OWL和VCL。

我是从Borland C++3.0和Delphi 1.0开始用的,那时的Borland看来很有前途的,可惜后来一系列决策失误导致现在这个公司几乎消失了,同学们不要再往这个坑里跳了。OWL曾经和MFC是竞争对手,设计思想也差不多,个人感觉OWL的API设计更优雅一点,但是在市场上OWL被MFC彻底击败。Delphi是神作,它在RAD(快速应用开发)领域长时间没有对手,直到BS架构取代CS架构。Delphi的特点就是简单、开发快,单纯就写个基本可用的应用来说,可能至今都没有比他更快的,但是缺点就是丑,基本大多数Delphi应用都是一大堆控件堆积在一起,很不美观,另外由于Pascal语言的限制无法和现有大量的C/C++代码融合。虽然后来有C++ Builder,但是Builder里简单和快的优点也消失了。Borland的C++编译器越做越差,导致后来开源项目都不太愿意兼容这个编译器了。VCL准确地说不是UI库,而是一套组件接口规范,类似COM ActiveX。delphi和C++builder都是基于这个规范构建了基础库。

UI库是个很大的话题,够写好几本书来探讨的,我这里就是随便写点自己的感受。单纯讨论每个库的优劣是没有意义的,而是要放到具体的应用场景里来看,每个库都有自己擅长的场景。如果仅在Windows下,追求程序小巧,用WTL,不足的地方自己实现去吧,但是视觉效果就呵呵了。如果可以大一点,还要好看点,那就Qt。如果完全不在乎大小,只要视觉效果华丽,就用WPF,如果把开发工具价格也考虑进来,那么土豪才会选WPF呢。MFC就是个鸡肋了,除非你现有的工程师不会用别的,或者有历史遗留代码要保持兼容。如果要求跨平台,那么就用Qt,wxWidgets和GTK+跟现在的Qt比起来没有什么优势了。如果是iOS Android,那么最好用原生UI库,除非你写游戏。

No3.Web解决UI方案

08年的时候,我刚听说微软出了WPF,非常兴奋。那时候的我写的最多的是WinForms的应用程序,但我对WinForms 程序有诸多不满,主要原因是WinForms的设计仅仅是对系统的Win32 API做了一层薄薄的封装,UI设计方面束缚依然比较大——老老实实套用内置控件倒还好,一旦要做些许“创新”,开发复杂度就陡然增大。于是当年我就赶紧买下了Charles Petzold老爷子写的《Windows Presentation Foundation 程序设计指南》,如获至宝的学起来。这期间逐渐感受到WPF的强大、灵活,并憧憬着用它开发出更加酷炫的应用程序。

然而现实是残酷的,一个棘手的问题是WPF性能比预期差很多。当你为一个控件添加下拉阴影特效(DropShadowEffect)后,再让其参与到动画事件中,性能会急剧下降。起先我以为是我使用方法不正确,但最终发现这是一个普遍问题。归根结底,DropShadowEffect在当时是用CPU 完成计算的,当存在动画时,为了保证渲染正确,需要逐帧重新计算,导致CPU占用率暴涨,性能自然受到拖累。

尽管我们可以尝试一些“优化”手段,例如预先计算出一次DropShadowEffect后将其缓存,后续仅以位图方式重绘,这一方案自然能快很多,却也存在这样或那样的弊端,例如需要考虑缓存结果是否能与背景正确匹配的问题。另一种办法,我们还可以在纯色背景上预先计算出DropShadowEffect后,再将半透明化,这样既能保证性能,又能保证与背景正确匹配。但还是略有瑕疵。总之方法虽多,但需要具体情况具体设计,非常不方便。说到底这个问题还是应当由微软解决,而不是推给框架的使用者。

作为UI框架新贵,WPF存在些许缺陷不足为奇。但有趣的是,下拉阴影导致性能下降的问题在同期的浏览器(如 Firefox)中却并不存在,你可以为任何元素添加下拉阴影,然后让它们动起来,浏览器依然顺畅如初。这一个细节让当年轻视Web开发的我逐渐的意识到,浏览器作为一个渲染引擎,其性能经过了精心的优化,是一个优秀的UI容器。受此启发,在近两三年里,我便很少再用WPF开发了。后续的项目都采用基于内嵌浏览器内核(例如XULRunner、CEF)的方式。这样一来UI都用 Web来做,就拥有极大的灵活性,例如可以使用ExtJS、Bootstrap、Semantic UI框架等等,而应用程序的能力则依然是Native的,可以完成任何之前的程序所能做到的事(调用 Win32 API?很容易)。

我们交付的许多项目都是这样实现的。开发成本大大下降,而且跨平台也不再是问题。关键是可以享受到Web 开发后续发展的所有红利,例如模板引擎,响应式界面,React UI等等。

近来,Node.js的出现也再一次降低了这方面的开发成本,特别是node-webkit(近来改名为 nw.js)之类的程序,更是将这方面的开发门槛急剧降低——之前你如果不熟悉底层开发,你可能就不知道应当如何将CEF之类的控件嵌入到你的程序界面里,另外还需要解决Web界面与底层库的通信问题。但是使用node-webkit根本无需考虑这方面的问题。对于需要调用底层 API的时候,直接给node.js增加C++ Addon,在界面里就可以通过JavaScript 调用,非常方便快捷,而且还有大量的package可用,不能更强了。

但是底层开发人员在向Web技术拓展的时候,常常遇到的最大的问题是在于固有思维定势带来的偏见。其中最常见的问题就是,觉得Web很糟糕,没有Control的概念,缺乏封装。因此用起来总觉得不好用。起初我也是这样认为的,但后来我发现并非如此。这其实是一个设计理念的差异,慢慢会发现各有利弊。Web基于Document的设计也有颇多精彩之处。

总而言之,我总希望大家在传统Native框架的基础上,多试试基于Web的方案,你一定会因此变得更加强大,并找到更多乐趣的。

富Internet应用程序(RIA)

“传统网络程序的开发是基于页面的、服务器端数据传递的模式,把网络程序的表示层建立于HTML页面之上,而HTML是适合于文本的,传统的基于页面的系统已经渐渐不能满足网络浏览者的更高的、全方位的体验要求了,这就是被Macromedia公司称之为的“体验问题”(”Experience Matters”),而丰富因特网应用程序(Rich Internet Applications,缩写为RIA)的出现也就是为了解决这个问题。RIA 是集桌面应用程序的最佳用户界面功能与Web应用程序的普遍采用和快速、低成本部署以及互动多媒体通信的实时快捷于一体的新一代网络应用程序。目前WEB领域和桌面软件领域正逐步向RIA靠拢,预计3、5年后RIA的时代将会完全到来”。

优势

RIA最突出的特点为“Rich”,同时RIA最核心的部分也体现在“Rich”中。“Rich”包含了两层含义。

丰富的数据模型:

RIA技术提供了多种数据模型来处理客户端复杂的数据操作。使用RIA可以将部分原本需要在后台程序处理的问题转移到客户端,使数据能够被缓存在客户端,从而可以实现一个比基于HTML的响应速度更快,且数据往返于服务器的次数更少的用户界面。

丰富的界面元素:

RIA技术提供了比HTML更为丰富的界面表现元素,密集、响应速度快和图形丰富的页面元素与数据模型结合在一起,为用户提供好的使用体验。

RIA具有的桌面应用程序的特点包括:

在消息确认和格式编排方面提供互动用户界面;在无刷新页面之下提供快捷的界面响应时间;提供通用的用户界面特性如拖放式(drag and drop)以及在线和离线操作能力。

RIA具有的Web应用程序的特点包括如:立即部署、跨平台、采用逐步下载来检索内容和数据以及可以充分利用被广泛采纳的互联网标准。RIA具有通信的特点则包括实时互动的声音和图像。

客户机在RIA中的作用不仅是展示页面,它可以在幕后与用户请求异步地进行计算、传送和检索数据、显示集成的用户界面和综合使用声音和图像,这一切都可以在不依靠客户机连接的服务器或后端的情况下进行。

部署好处:

对于企业来说,部署RIA的好处在于:

1)RIA可以继续使用现有的应用程序模型(包括J2EE和.NET),因而无需大规模替换现有的Web应用程序。通过Rich Client技术,可以轻松构建更为直观、易于使用、反应更迅速并且可以脱机使用的应用程序。

2)RIA可以帮助企业提供多元化的重要业务效益,包括提高销量、提高品牌忠诚度、延长网站逗留时间、较频繁的重复访问、减少带宽成本、减少支持求助以及增强客户关系等。

发展态势

在过去的两到三年中,Web开发人员一直是想构建一种比传统HTML更丰富的客户端:这是一个用户接口,它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA技术的出现允许我们在因特网上以一种像使用Web一样简单的方式来部署富客户端程序。无论将来RIA是否能够如人们所猜测的那样完全代替HTML应用系统,对于那些采用C/S架构的胖客户端技术运行复杂应用系统的机构和采用基于B/S架构的瘦客户端技术部署Web应用系统的机构来说,RIA确实提供了一种廉价的选择。下面介绍一下目前出现的几种比较有实力或者有特点的RIA客户端开发技术:

1)Adobe Flash/Flex

Flash 从6.0开始Flash就逐步具备建立窗体风格的应用程序的功能。据Adobe称已经有98%以上的桌面系统的浏览器都安装了 Adobe Flash Player。这使得以Adobe Flash Player为客户端的RIA可以支持种类广泛的平台和设备。

Flex是为满足希望开发 RIA的企业级程序员的需求而推出的表示服务器和应用程序框架,它可以运行于J2EE和.NET平台。Flex表示服务器提供基于标准的、声明性的编程方法和流程,并提供运行时服务,用于开发和部署丰富客户端应用程序的表示层。Flex开发者使用直观的基于XML的MXML来定义丰富的用户界面。该语言由 Flex服务器翻译成SWF格式的客户端应用程序,在Flash Player中运行。

2)Laszlo

Laszlo 是一个开源的RIA开发环境。使用Laszlo平台时,开发者只需编写名为LZX的描述语言(其中整合了XML和Javascript),运行在J2EE 应用服务器上的Laszlo平台会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说,Laszlo的本质和Flex是一样的。Flash是任何浏览器都支持的展示形式,从而一举解决了浏览器之间的移植问题。而且,在未来的计划中,Laszlo还可以将LZX编译成Java或.NET本地代码,从而大大提高运行效率。

3) Java SWT

Java 已经出现几年了,并且完全支持创建基于窗体的用户界面。除了Java基础类(JFC/Swing)中的用户界面组件之外,开发人员还可以使用来自于 Eclipse Project的SWT工具箱和许多第三方工具箱进行开发。对于图形来说,可以采用Java 2D API:一个非常完整且非常复杂的图形API。你可以通过一个Web浏览器使用Java插件软件,或使用Java运行时环境中较新的Java Web Start技术来部署应用程序。使用Java建立Rich Client的主要缺陷是它的复杂性(即使对简单的窗体和图形也要求编写非常烦琐的代码)和Java浏览器插件的低市场占有率。

4) XUL

XUL (念作”zool”)是一种基于XML的用户界面语言,它来自于Mozilla的开放源码项目。它可用于建立窗体应用程序,这些应用程序不但可以在 Mozilla浏览器上运行,而且也可以运行在其他描述引擎上,如Zulu(一个FlashMX组件)和Thinleys(一个Java实现)。XUL描述引擎都非常小(100K以下),它可以使用XML数据也可以生成XML数据。XUL的一个主要缺点在于它目前还没有获得一个主要商业实体的支持。XUL最大的优点在于它与Gecko引擎的集成(打开了通向大量Web标准的大门),以及与大多数其它XML用户界面描述语言相比它是一种非常具有表达力和简洁的语言。

5) Bindows

Bindow 是用Javascript和DHTML开发的Web窗体框架。Javascript用于客户端界面的显示和处理,XMLHTTP用于客户端与服务器的信息传输。Javascript在客户端的表现力不容置疑,利用Javascript几乎可以实现Windows应用程序所能干的大部分事情,XMLHTTP 一直以来常被用于实现”无刷新”的Web页面,它和Javascript配合,可以完成数据从服务器和客户端的传输。Bindows的一个主要的缺点是它采用一次全部载入的方式来实现脚本库,在窗口的加载期,需要一个漫长的等待过程,甚至浏览器的进程会产生无响应的情况。这点Bindows根本没有遵循”用多少去多少”的准则。另外,内部大量利用了IE6 的技术,没有考虑到非IE的浏览器,限制了Bindows的流行。

6)JavaFX

2008年12月05日 Sun微系统公司今天正式发布了基于Java语言的平台JavaFX 1.0,这个平台建立在其广泛应用的Java编程语言的基础上,旨在建立大量可在电脑和手机上运行的网络程序。 Java一直以来就是编程语言,但是随着JavaFX的发布,Sun公司开始允许将编程内容创新这一任务转移到以设计艺术为重点而非编程科学为重点的设计人员身上。

“我们的目标群体是叫做创造者的人群”,Sun公司Java平台组的高级副主任 OctavianTanase对 说,“随着1.0版的发布,我们将目标锁定在网页开发人员,这群可能拓展Java界面体验的人。到2011年,主要的目标是大量使用诸如Adobe系统等设计工具的设计人员”。

当然,通向这个以设计为导向的工具还需要一些时间。Sun公司最后打算提供自己的程序给设计人员来建立RIAS,但是直到如今,这些设计人员还得使用程序员所使用的Netbeans或Eclipse集成开发环境(IDE)。新工具将在来年夏天面市。

7)Curl

Curl诞生于1995年的美国,Curl是由美国国防部高级研究项目代理资助,马萨诸塞州科技学院的David A. Kranz开发的Web开发语言, HTML语言的创建者Tim Berners-Lee也参与其中,并扮演了重要的角色。

该语言的目标是用一种统一的面向对象的语言代替HTML、Cascading Style Sheets、JavaScript等;仅使用Curl便可开发出Web应用的各种软件;Curl程序在浏览器中运行,并且因为它以类似JRE的形式提供了客户端运行环境Surge RTE,能够轻松开发出日益流行的Rich Client应用程序。

Curl是为了实现富客户端(rich client)应运而生的Web开发语言, 仅仅从其外观的丰富性上就能体现其富客户端理念。

为了实现真正有益的富客户端,它能有效地实现各种复杂处理,具备提供高信赖、高扩展性、高维护性的应用程序所应拥有的各种编码能力。其拥有在Web环境上便利的分配、管理以及低廉的维护费以及在C/S环境上的用户便利性、迅速的应答,华丽的图像显示等众多优点于一身。

Curl语言于2002年在美国正式开始商业化,在美国和日本拥有重多的客户和合作伙伴,现已进军北美及韩国市场,发展势头迅猛。

8)SilverLight

微软在Mix07上发布一些重大通告,其中最值得关注的就是SilverLight的发布,SilverLight的前身就是WPF/E技术,SilverLight就是微软新Windows图形子系统“Windows Presentation Foundation”(代号Avalon)的一个子集。

这是一种新的Web 呈现技术的名称,创建该技术的目的是使其能够在各种平台上运行。该技术支持创建丰富的、具有绚丽视觉效果的交互式体验,并且可以随处实现:无论是在浏览器内、在多个设备上还是在桌面操作系统(如 Apple Macintosh)中。可扩展应用程序标记语言(XAML) 遵循 Windows 演示基础 (WPF),前者是”WPF/E”呈现功能的基础。XAML 是Microsoft .NET Framework3.0(Windows 编程基础结构)中的呈现技术。

9)ActiveX 插件

ActiveX 插件同样是微软推出的 RIA 解决方案,它是一个开放的解决方案,可以兼容多种语言,不过它的缺点也是显而易见的,用户需要调整浏览器的安全等级并下载插件才能运行 RIA 应用,极大地降低了安全性。

10)HTML5

为推动 web 标准化运动的发展,W3C 推出了下一代 HTML 的标准 - HTML5,为众多的公司所支持,因此具有良好的前景。它有以下特点:首先,为增强用户体验,强化了 web 网页的表现性能;其次,为适应 RIA 应用的发展,追加了本地数据库等 web 应用的功能;再次,由于高度标准化以及诸多浏览器厂商的大力支持,它的兼容性和安全性非常高;最后它是一种简洁的语言,容易为广大开发者掌握。更为难得的是,由于节能和功耗低,在移动设备上 HTML5 将具有更大的优势。因此更适合如 Web 操作系统一类的 RIA 应用的前端开发。

11) MUILIB

MUILIB是国内推出的第一款RIA技术解决方案,它通过传统的Win32 C++开发技术搭配XML构建的界面,达到客户端界面强大的用户视觉体验和人机交互性,由于采用的是C++技术,所以不管是功能上还是性能上对比其他语言的解决方案都有绝对的领先优势。

N04.云计算

与RIA相反的是日益强大的云计算,RIA是富客户端,把主要的计算都放在本地完成,仅用网络来传递少量的关键数据。而云计算把各种数据处理都放在服务器端,从而减轻客户端的压力。

No5.大数据

从技术上看,大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理,必须采用分布式计算架构。它的特色在于对海量数据的挖掘,但它必须依托云计算的分布式处理、分布式数据库、云存储和虚拟化技术。