应用于界面设计的视界模型研究

开篇：润墨网以专业的文秘视角，为您筛选了一篇应用于界面设计的视界模型研究范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：传统的界面设计往往通过窗体上放置各种控件来完成。该方式会造成系统资源较多的消耗，而且灵活性欠佳。根据Windows操作系统消息驱动机制，建立了一种名为视界的模型，可以解决上述问题，并用较小的代价表现出无限多种用户界面，实现复杂的软件与用户的交流，并能产生任意的视觉特效。

关键词：视界模型；用户界面；消息传递；窗体；控件

中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)01-0213-03

Study on Vision Model Applied to User Interface Design

LIU Ji-wei, GUO Tian-jie

(Naval Aeronautical and Astronautical University, Yantai 264001, China)

Abstract: Traditional user interface design is usually accomplished through placing kinds of control on forms. This way requires more system resource and possesses less functional agility than the model called Vision constructed in this paper according to message-driven mechanism of Windows Operation System. The Vision Model can solve the problem above, create unlimited kinds of UI, support complex communication between software and user, and produce vision impression discretionally at less cost.

Key words: vision model; user interface;message transmission; form; control

近年来许多程序员热衷于“堆积”控件（Control）来编写软件的用户界面（UI）。诸如Microsoft Visual Studio系列、Borland Delphi系列等常用开发软件的界面制作功能日益“傻瓜”化，使得软件设计者可以通过拖放操作快速添加控件，不用较多注意技术细节，而把更多的精力投入业务流程中去。软件的界面制作过程变得看似十分简单。然而，在Windows操作系统平台下，在窗体上堆积控件会使软件运行时耗费较多的系统资源，而且如果需要制作非传统的界面（比如游戏界面），控件又会因为欠缺灵活性而给设计者带来许多不必要的麻烦。

本文建立了视界模型，专用于编写用户界面，可以有效解决上述问题，并具有高度的灵活性和实用性。

1 传统的界面制作

在Windows系统平台上开发应用程序的用户界面（窗体）所包含的控件，实际上都是它的子窗体。每一个子窗体都具有独立的消息队列（Message Queue）。作为消息驱动的Windows应用程序，其控件与父窗体（容器，Container），控件与控件之间的交互实际上都是由消息的传递实现的。所谓控件的事件及其触发，实际都是消息的传递及其处理。虽然消息传递的接口都是统一的，但是系统要维护多个（通常超过15个）控件（窗体）的消息队列，会耗费许多系统资源。

对程序员而言，虽然编译软件和第三方组件提供了大量的UI接口供调用，但是众所周知，一个软件模块规模越大，它的不稳定性也就越强。这些UI接口所封装的大量技术细节可能包含了不安全的组分。当程序出现异常时，人们往往最后才想到业务流程之外的代码错误。当发现业务流程实际上并没有逻辑上和语法上的问题时，已经耗费了大量的时间和成本；而且即使发现了控件的异常反应也无法快速纠正。

如果需要制作多样化的，非“传统”的窗体界面，则很可能需要编写额外的代码来控制窗体和控件的行为，甚至重新制作相应的UI接口。例如通过传统的控件来实现按钮被用户单击后爆裂这样的视觉特效，显得粗糙而又笨拙。

2 视界模型的提出

笔者经过研究发现，可以完全抛开窗体与子窗体的繁复设定，采用一种新的模型来支持用户界面的开发。笔者称之为“视界（Vision）” 。视界模型只需要一个窗体，就可以表现出理论上无限多种用户界面，实现复杂的软件与用户的交流，并能产生任意的视觉特效。

视界是这样一种用户界面模型，它以一个窗体为依托，集中业务所需的所有界面，并根据业务流程和用户输入予以显示。每个界面上都放置有类似于控件的控制对象，可供用户操作；而且，每个界面都可绑定任意的绘制代码，可表现丰富多彩的视觉特效。不同的界面都绑定有不同的消息处理方法，以满足不同的业务处理需要。

3 视界模型的组成

视界模型的组成结构如下图1所示。

如图1，视界包括若干页面，页面又包含若干控制对象，控制对象可视为使能区的有机组合。下文逐一描述这些概念。

3.1 使能区

使能区（Enable Field）是控制对象的组成部分，用以确定和响应用户的输入（鼠标点击等）。使能区一般是窗体上的矩形区域（Region），与若干操作（Operation）绑定。当用户激活使能区时，相应的操作就会自动执行。在这一点上，使能区与操作的关系十分类似于控件与事件（Event）之间的关系。

3.2 控制对象

控制对象（Control Object）在功能上与控件类似，是用户界面上可操作的对象。控制对象可以模拟按钮（Button）、静态文本（Static Text）、图片框（Picture Box）、列表框（List Box）等理论上无数种控件的属性和操作，并生成相应的派生类（子类）。

控制对象包含单个或多个使能区，并封装它们的操作。当其中的某个使能区被激活，控制对象就会表现出一定的行为，此时称触发了控制对象的事件（Event）。值得注意的是，有的控制对象并没有使能区，它是籍由页面的调用而表现出行为的，例如内置的音频播放器。

控制对象和使能区与控件之间存在本质上的区别。

控件是子窗体，有独立的消息队列，父窗体与它之间通过传递消息来交换数据。使能区不是窗体，只是窗体上的一个区域，在静态特性上，使能区与窗体之间只有坐标上的相对关系；在动态特性上，窗体可以调用使能区的操作，而使能区的操作也可以包含向窗体投递消息的代码。控制对象也不是窗体，没有独立的消息队列，没有信息传递。

控件的绘制“制式”几乎完全决定于系统的设定，设计者能够直接干预的只有诸如显示文本等小部分属性。而控制对象则可以任意绘制，其仅取决于控制对象的背景图片。

使能区的激活方式可以由设计者自行定义，亦即控制对象的事件触发方式可以自行定义，而控件的事件触发方式诸如鼠标单击、双击、拖动等则是系统预先定义好的，无法改动。

3.3 页面

视界模型的基本元素称为“页面（Page）” ，它是指当前显示的用户界面，包括可视的画面和当前界面的控制代码。如图2，从面向对象的角度来看，页面的属性主要包括背景图片（Background Picture），用以显示界面背景；控制对象列表和控制对象数目，用以指定用户操作的对象列表；消息处理方法，用以处理窗体的各种消息。而控制对象的主要属性包括背景图片，用以显示自身；标题，用以显示控制对象的文字标题；使能区列表和使能区数目，用以确定控制对象的组成，从而指明控制对象的行为。

图3是笔者开发的一个游戏软件的界面截图。该界面是软件实现的视界模型中诸多页面之一。图中包括4个按钮，1个静态文字和1个列表框。页面和控制对象的背景都是事先制作的图片，页面的绘制实现只需要一个简单的贴图操作即可完成。可见其简易性和灵活性。如果需要表现某种视觉特效，只需要在页面显示方法中添加相应代码，依据动画原理，修改窗体的重绘机制，使其不断调用页面的绘制程序，从而产生视觉特效。

视界是由若干页面组成的。一个视界只有一个窗体，这意味着只有一个消息队列。但每个页面都有各自不同的消息处理方法，以承担不同的与用户交互的任务。

页面与页面之间“共享”窗体的消息队列，但各自的消息处理方法是相互独立的。实际上，在任一时刻，有且只有一个页面显示于窗体之上，并处理系统和用户的消息。其余页面均处于“休眠”状态，它们可以相互传递数据，也可以与当前显示的页面交换数据。在这个意义上，页面与页面之间在数据上是相互独立的，不存在主从或依赖关系。

当前显示的页面与其它页面之间可通过跳转（Redirect）来相互切换，改变窗体的消息处理方法，亦即传递消息处理权。页面的独立性保证这样的传递不会产生数据交换的异常。

4 视界模型的实现

在软件中应用本模型必须先将其实现。

首先，将视界本身视为对象的做法无助于模型的实现。一个应用程序很可能会包含许多不同的页面，页面的许多共同属性和方法使得它们从同一个父类（称页面类）继承这些会更加符合面向对象设计（OOD）的原则。然而，这些页面根据业务需要，也会具有许多不同的属性和处理方法。实际上，它们之间是如此的不同，以至于将它们并为一个集合，使用统一的接口去调用它们显得十分愚蠢。因此，虽然视界可视为诸多页面的集合，但是却没有必要作为对象去实现。

其次，不同控件之间存在许多相同的属性和方法，因此在MFC的类库中所有控件类都从一个超类派生而来，以此实现代码重用。类比之，笔者设计了一个控制对象的超类，所有类比诸如按钮、静态文本、图片框、列表框等的控制对象都是这个超类的派生类。

再次，控制对象事件通常是由用户触发的。如4.2节所述，其触发机制可以由设计者自行定义。假设用户输入为鼠标单击，不妨设定机制如下图。图中用户单击输入后，系统将对应消息传递给窗体亦即当前页面的消息处理方法，页面根据消息附加信息查找到用户操作的控制对象，并得到事件参数后，将事件参数传递给控制对象，后者根据事件参数获知用户激活的使能区，并得出操作参数，而后调用使能区对应的操作。如此完成控制对象事件的触发和处理。

在Windows操作系统平台下，笔者利用Win32 API设计了一系列类，使用Visual Studio2003编译通过，籍以实现视界模型。以页面类为例。

class Page//页面类

{public:

Page(VOID);//初始化页面数据（如控制对象），不绑定窗体，必须重写

virtual ~Page(VOID);//释放相关对象，必须重写

protected:

SIZE Size;//窗体大小

LPTSTR Pic;//背景图片资源号，如果是NULL，则不显示

SHORT ControlObjectCount;//控制对象数目

ControlObject **ControlObjects;//控制对象指针

protected:

virtual BOOL Load(HWND);//绑定窗体，切入时特效及其它操作，必须重写，默认无操作

virtual BOOL Unload(HWND);//释放窗体，切出时特效及其它操作，必须重写，默认无操作

public:

virtual LRESULT CALLBACK PageReactor(HWND,UINT,WPARAM, LPARAM)=0;//页面消息处理函数，必须重写

virtual BOOL Show(HWND);//显示页面，必须重写

……

BOOL Redirect(Page *NextVision,HWND hWnd);};//页面跳转并显示，如果NextVision为NULL，则仅卸载(Dispatch)当前页面，不可重写

上述代码只是一个粗略的框架，其中略去了一部分方法的定义。具体应用模型时还要遵从以上原则，根据业务需要进行实现。

5 视界模型与传统界面的对比

笔者分别使用视界模型和MFC开发了两个HelloWorld程序（KstHelloWorld_Vision和KstHelloWorld_MFC），界面如图5，左为KstHelloWorld_Vision，窗口中只有一个控制对象（按钮）；右为KstHelloWorld_MFC，窗口中只有一个按钮。两个对象的功能都是单击后显示一个HelloWorld的消息框（Message Box）。

启动Microsoft Spy++追踪工具，可以查到如图6内容。图6(a)表明窗口KstHelloWorld_MFC包含一个名为Hello World的按钮（子窗体），而KstHelloWorld_Vision则只有一个独立的窗口。图6(b)上部表明KstHelloWorld_MFC的两个窗体都在接受消息，而下部表明KstHelloWorld_Vision只有一个消息队列。

根据追踪结果，在功能完全相同的情况下，采用视界模型制作的应用程序比MFC框架下的应用程序所消耗的消息传递与处理等系统资源要少。可以推论，如果KstHelloWorld_MFC使用更多的控件，那么它的消耗也会明显增多。

6 结束语

在传统的软件设计中，用户界面总是包含一个或多个主窗体、若干子窗体和对话框，以及它们各自包含的一堆控件。它们消耗较多的系统资源，根据对比结果，实现同样的业务功能，笔者所设计的视界模型所要求的系统资源要少一些，而且使用更为灵活。然而，本模型目前缺乏应用软件工具支持，只能在代码层面上控制模型的使用。因此它在实际使用方面比VS、Delphi等提供的界面开发工具更为复杂。笔者正在致力于编写可视化的工具来支持此模型。

参考文献：

[1] 吴华,岳晋生,刘德贵,等.Windows NT Win32软件开发使用详解[M].北京:电子工业出版社,1995.

[2] 陈向群,马洪兵,王雷,等.Windows内核实验教程[M].北京:机械工业出版社,2002.

[3] 卫东华,许为群,詹咏松.Visual C++应用实战演练[M].北京:科学出版社,2003.