UI框架和应用

我其实应该早就开始写这篇文章了，因为写它的初衷是回复wenzhezujie的留言。可是写文章既需要时间也需要心态，结果就拖了些日子。现在还是酝酿的不够，但是至少应该开始了。

 

先把那段留言抄下来，方便参考 :-) -- "基于Gtk做widgets与scheme/skin应该属于应用级别，还算不上去研究UI框架的层次吧。比如Qt里面，元对象系统，信号槽实现机制，才属于UI框架最核心的东西。我不认为内核，系统设计的层次比设计UI的层次高。比如对Linux来说，内核有进程调度的机制，UI最底层有XWindow协议。 只不过可以看作这是一整套知识体系结构。内核 视窗系统 网络等独立的模块"

 

先谈谈软件框架。在计算机科学的远古时代，人们还是用纸带卡片和计算机打交道的时候，并没有什么框架的概念，程序都是一次性的，计算机也只是用于重复的完成某个任务。之后人们自然而然的开始试图提高劳动生产率，也就是希望写过的东西能重复使用，于是诸如例程，函数的概念就加入进来，但是这些没有从根本上解决这个问题。科学家们开始尝试从理论上解决它，而建筑作为一个成熟的，工业化程度很高的技术就被广泛用于计算机软件的研究，简单的说，就是怎么样让写软件和盖房子一样，堆几个模块就差不多了，而不用总是从一块一块砖烧起，这也是为什么系统构架师其实就是建筑师（Architect）的意思。所以最初框架（Framework）就是和房子的基础构架意思差不多，指的是软件的基本结构 （详细历史请参考许许多多的软件工程和面向对象的“巨著”，最好看英文版的）。姑且不论这么做是不是非常合理，这也差不多是约定俗成的习惯了。

 

我认为软件框架的另一个目的是解决或改进代码复用的问题。在这一点上，软件有自己独特的地方，以分层结构为例，就是可以非常细的定义层次和接口，下面的一层都可以称为上层的框架，因为理论上，上层的模块是不需要解决下层框架已经解决的问题，也就是说相应的代码只应该出现在下层框架中，可以被不同的上层模块通过相同接口复用，这要求框架的实现应该有相应问题的抽象。因此抽象和接口是框架的核心。

 

在软件发展的历史上，出现的框架层出不穷，这是因为人的思想还是非常富有创造性的，但是能发展下去的就不多了，毕竟被许多技术以外的因素左右着。广义上说，任何一种软件的结构都可以被称之为某某框架，而着力解决用户界面问题自然就可以称为UI框架了。但是事情并不是那么简单。

 

UI，顾名思义，是指用户，也就是人，和计算机的界面，所以早先的时候也被称为MMI（Man Machine Inerface）。因此UI的设计就是解决人和计算机交互的问题，可以归结为输入和输出的问题，即计算机如何准确有效接受人的指令，然后按照人需要的方式输出处理结果的问题。再看计算机历史，从纸片输入输出到今天的3D的现实和触摸屏，计算机的确变得人性化了很多，UI所面临的问题也由如何使用最初的非常底层和原始的硬件到了如何让人们和计算机接触时更像和人打交道（毕竟人与人的交流习惯是最自然地），甚至可以有更虚幻的身处未来的感觉。这些变化也影响了不同时期UI框架的重心。例如，在图形界面出现的初期，要做的就是串行化用户输入和串行化的显示（不能多进程、线程同时写屏），消息队列之类的机制或者说框架就被设计出来了，而这些之所以成为框架而不是应用，更重要是它们抽象了一个特定的功能，被其它的不同模块所复用。到了今天，没有人继续花很多时间研究这些东西，因为技术已经成熟，而且UI的重心已经转向用户体验上。当然由于新硬件诸如触摸屏的普及会带来已有框架的更新，但这个时代的UI框架更多的是如何围绕OpenGL提供前所未有的用户体验，而不是如何解决字体显示或者有效、灵活的实现scheme/skin这些早已被解决的问题。

 

在面向对象UI设计已经成为主流的今天，不同的框架基本都是从单一的基类实现了应用相关的类和对象的基础抽象，如JAVA的Object和Qt的QObject，同时在这个基类所实现的抽象也不是UI的特性了。至于消息响应机制，例如MFC的消息映射宏，Swing和SWT的listener，以及Qt的signal/slot，本质上都是基于消息队列和分发机制，对于应用而言，更多的是接口的区别（顺便说一下，我是坚决站在signal/slot这一边，不过其中的细节不是这篇文章的重点）。更重要的是，这些框架并不是只适用于UI，所以严格的说，它们是属于应用程序框架的一部分。

 

再来谈谈什么是UI的应用。我的理解这是指通常意义上的UI应用程序，物理上，它们通常以单一执行文件的形式存在，而且依赖其它的软件库或后台的服务/守护进程（Daemon）所提供的通用框架。所以，它们往往只针对一个特定的问题，例如EMail客户端就是解决使用EMail的问题，因此通常它们的代码是不会被其它应用或框架使用的，设计也相对简单一点（我的另一篇文章也有所提及）。

 

同一种应用在不同的环境中所包含的内容也不相同。举例而言，JAVA的应用设计就要比OSGi的应用设计考虑的东西多一些，因为OSGi*框架*替它的应用设计好了生命周期的管理框架，同样的道理，KDE的应用比Qt的应用就可以少考虑一些和桌面系统的集成问题。这直接反映到桌面系统的UI框架和手机，汽车系统的UI框架的内涵是不同的。

 

总而言之，我认为UI框架并没有严格的定义，只要它能解决任何基础UI的问题，也设计为能够被其它模块，特别是上层模块复用，就可以是UI框架的一部分。其实实际工作中，很多曾经是UI框架的设计核心，现在已经不再是UI框架设计的重点了，因此过去看上去似乎是UI应用的事，也变成了UI框架的一部分，因为现在的UI应用已经不需要实现这些功能了，同样在不同的设备环境下，UI框架所包含的东西是不同的。