一种界面库架构方法

文档序号:6616151阅读:144来源:国知局

专利名称::一种界面库架构方法
技术领域
:本发明涉及软件开发库,具体的说,是涉及一种界面库的架构方法。技术背景软件的"UI界面"是应用软件与应用软件的用户之间进行交互活动的载体。不同应用软件的界面可以是千变万化的,但其中会有许多交互逻辑相对独立的元素,它们有相同的交互逻辑和相似的显示,简单的例如用于显示一行文字的静态文本框、按钮、用于接收输入文本的编辑框等等;复杂的比如一组互斥按钮、Tab等组合控件。这一类各个界面都能通用的元素,我们称之为UI界面控件或UI界面组件。应用软件的每一个界面都可以看作是数个UI界面控件的组合。而这些UI界面控件的实现完全可以放在一个通用的库中。界面库实际上就是提供给应用软件开发人员的一个工具包,提供已封装好的UI界面控件给软件开发人员使用,使得使用者无需关心每一个UI界面控件内部的逻辑实现,而只需要关心和管理控件与控件之间的业务逻辑关联和数据传递即可。通常一个完整的界面库大致应包含了以下几个方面的设计(A)—组UI界面控件类及它们的对外操作接口;(B)控件管理器或界面库管理器;(C)用于调用不同绘制引擎的绘制接口。其中,(A)是每个界面库必须包含的内容,应用软件开发者在使用界面库时,必须通过每个控件的接口操作这些控件以改变控件的状态、表现等。(B)的控件管理器是指用于管理所有属于同一界面库体系的UI控件之间的隐式联系的一个或一组对象。这种隐式联系与业务逻辑无关,仅与界面表现与交互响应相关,例如控件与控件之间由于某种关系(最常用的就是树型结构)而形成的位置遮挡、显示顺序、消息分发与传递、界面更新策略等等。并不是所有的界面库都会有这类对象。在windows系统中,如果界面库的每个控件都拥有一个windows窗口句柄,那么它即隐式地使用了操作系统作为它的控件管理器,操作系统会替它完成上述所有的管理工作。而对于在游戏中使用的的界面库,由于所有控件共用一个windows窗口,势必需要一个控件管理器来管理这种关系。有时,游戏要求的高刷新率使得界面库管理器抛弃更新区域处理功能,而采用定时(或在空闲时)更新整个界面的方式。一些界面库的控件管理器不仅实现这种控件之间关系的管理,还管理界面库的一些全局信息,如使用绘制引擎的类型,界面库风格等等,以提高其通用性,适应不同应用软件的需求。在设计UI库时,如果让UI控件在绘制时调用另一个对象做绘制工作,这个对象就叫作绘制引擎或对绘制引擎的一个封装。调用接口即称为绘制接口,它通常在游戏界面使用的界面库中出现。游戏界面由于需要较高的刷新率和更丰富的界面表现,一般不会使用微软公司的windowsGDI绘制引擎,而使用第三方开发的各种专门绘制引擎。而3D游戏则必须要使用这种绘制接口方便地更换专用的3D绘制引擎。桌面应用软件由于对用户界面的显示要求不高,使用的界面库通常在控件内部使用windowsGDI进行绘制即可,并不把这种操作独立出来,应此也没有绘制接口的设计。这种界面库的架构设计,对于想更换绘制引擎的需求将十分不利。目前界面库的架构设计根据应用场景可以分为两大类一类应用于桌面软件,即使用微软公司的windowsGDI绘制界面,不需要控件管理器和绘制接口设计,这类界面库的缺点是由于绘制引擎(GDI)功能和结构的局限,无法方便地实现更丰富的用户界面表现(如控件半透明等)。另一类应用于2D或3D游戏,采用了绘制引擎接口设计,可以使用第三方专用绘制引擎表现更丰富的用户界面。但由于控件管理器是在一个windows窗口句柄的基础上管理所有控件,使得界面库的使用者无法在这种控件体系中使用带有windows窗口句柄的子控件,即开发桌面应用软件如果想使用这种界面库,那么在其中加一个有windows窗口句柄的控件会十分麻烦,这样就大大局限了桌面应用软件使用控件的种类;同时,当应用软件每次更新整个界面时,将会占用大量的CPU资源,从而导致电脑的操作反应速度变慢,直接影响用户的使用感受。以上的这些问题,是在某些特殊的应用软件开发场景,例如开发桌面网络游戏软件(比如腾讯一^司的qq宠物软件)时产生的。这种应用软件的特点是,既有多窗口桌面软件界面的需求,某些界面又要达到游戏引擎的绘制水准,目前软件设计界尚没有出现能够同时满足这种需求的单一界面库。进一步的,基于上述的这些问题,软件开发界面库的设计者自然的会想到一种解决方案,即对于上述的这种桌面网络游戏软件的界面库需求,可以采用两套界面库和两种绘制引擎同时使用的方案对于界面表现要求不高的界面,使用基于windowsGDI的桌面软件界面库,对于界面表现要求高的界面,使用游戏专用界面库。但是,这种解决方案的缺点是(1)需要同时维护两套界面库,工作量大,成本较高;(2)在桌面软件界面库实现的界面上还是无法实现较丰富的界面效果。
发明内容本发明所要解决的技术问题是,提供一种能够满足桌面游戏软件界面开发需求,组件维护又非常简单的界面库架构方法。本发明的界面库架构方法是这样实现的一种界面库架构方法,其特征在于,自上而下依次包括了用户层,控件层,场景幻灯片层和引擎层;所述用户层通过创建控件层对象和调用控件层接口操纵界面元素;所述控件层包括了所有独立控件或组合控件,控件操作场景幻灯片层的场景对象和图层;所述场景幻灯片层包括了场景对象和图层,场景对象管理控件图层的绘制及更新,图层调用引擎层的绘制引擎接口将图层绘制在控件的画布上;所述绘制引擎层包括了绘制引擎接口,接受来自场景幻灯片层的图层的调用,实现图像和文字的绘制。优选实施方式是,控件层以一个顶层窗口体系为一个基本管理单位,在体系中以一棵树描述体系中所有控件的父子关系,树上的每一个结点为一个控件。优选实施方式是,所述控件包括了有窗口句柄的控件和无窗口句柄的控件;所述有窗口句柄的控件由用户层的用户创建后,生成窗口画布并创建相应的场景对象;所述无窗口句柄的控件由用户层的用户创建后,使用父控件的画布和场景对象,或者由用户层的用户设置该控件的画布和场景对象;所述场景对象管理该控件图层以及该控件的无窗口句柄子控件图层的绘制及更新。优选实施方式是,所述控件包括了可见控件和不可见控件;所述不可见控件用于控制多个逻辑相关的控件;所述可见控件包含一个多状态背景层,所述背景层由一个背景层工厂才艮据背景图片的身并接方式创建。优选实施方式是,所述场景幻灯片层中的场景对象使用线性列表结构保存每个图层在此场景上的位置信息。优选实施方式是,所述控件层的状态发生改变时,通知场景幻灯片层;场景对象将该图层所在区域收集入更新区域列表,并通知画布进行更新。优选实施方式是,所述控件层的状态发生改变时,通知场景幻灯片层;场景对象将该图层所在区域收集入更新区域列表;场景对象利用CPU空闲或定时器定时更新画布。优选实施方式是,所述绘制引擎层绘制图像时,先使用图像工厂创建图像对象,并根据图像对象的格式、画布对象的格式、混和模式创建混和器,混和器根据设定的混和参数将图像对象绘制到画布对象上。优选实施方式是,所述绘制引擎层绘制文字时,先使用文本工厂生成文字对象,并根据文字对象格式、画布对象格式、混和模式生成混和器对象,混和器对象将文字对象绘制到画布对象中。实施本发明的一种界面库架构方法,由于可以在桌面窗口模式中使用游戏绘制引擎,因此能4艮好地满足桌面网络游戏软件的界面需求;同时,场景幻灯片层的架构设计,使界面库可以支持桌面软件和游戏软件两种刷新模式和多种绘制引擎,因此,分离出来的控件层和图层模块可以作为独立的部分被两者复用,这大大方便了组件的维护。图l是本发明的架构模块示意图;图2是本发明控件架构的示意图;图3是本发明实施方式的模块示意图;图4是本发明中控件背景层创建图;图5是本发明画布被动更新时序图;图6是本发明绘制51擎层绘制图像时序图;图7是本发明绘制?1擎层绘制文字时序图。具体实施方式下面,结合附图对本发明作进一步的说明。如图1所示,本发明的一种界面库架构方法,自上而下依次包括了用户层,控件层,场景幻灯片层和引擎层。它们排列顺序的意义是(1)上层部分只能使用临近的下层的对象,不能越层调用;(2)下层对象不知道上层对象。本发明界面库架构方法的架构中,最上层是用户层,即界面库的使用者(桌面游戏软件的开发者),用户层通过创建控件层对象和调用控件层接口来操纵界面元素。控件层包含所有独立控件或组合控件的实现。这些控件由一棵树来管理父子关系,这棵树构成了一个顶层窗口管理体系,树上的每一个结点为一个控件。这些控件可以是建立在一个真实的windows窗口基础上,即带有windows窗口句柄(HWND),可以交由windows窗口体系来管理;也可以是一个逻辑上的窗口,即无windows窗口句柄,由本系统中的窗口管理系统管理。而本系统在逻辑上将这两种窗口纳入了一个管理体系。有窗口的控件2和无窗口的控件3都可以是控件1的子控件,而控件1可以是有窗口也可以是无窗口控件(如图2所示)。由于每个控件的显示是一个图层或数个图层显示的叠加,每一个真实的windows窗口都拥有一块画布作为它的图层最终显示的场所(最简单的画布就是窗口DC)和与其相对应的一个场景对象,无窗口控件则使用父窗口的画布作为自己的画布。场景对象用于管理它所对应的画布上应显示的所有图层的绘制及更新,但它并不需要关心这些图层是属于哪一个控件的,因此,如图2所示,控件l的场景l对象管理了图层l、图层4、图层5三个图层,而控件2的场景2对象只管理它自己的图层2和图层3两个图层。在本发明的界面库架构方法架构中,每个图层通过调用引擎层的对象将自己最终绘制在所属的画布上。在顶层窗口管理体系中,通常顶点控件一定是一个真实的windows窗口,这样所有的图层都可以找到一个场景管理自己。但如果顶点控件是非真实的windows窗口,那么需要从外部由桌面游戏软件的开发者单独设置画布和场景对象。控件每创建一个图层,都将它加入控件应显示的画布所对应的场景对象中。在具体的实现方案中,每一个有窗口句柄的控件都会创建自己的场景对象,并将这个场景对象的指针传递给它的所有无窗口句柄的子孙控件。所以,每一个场景所管理的图层有可能分属不同的控件。在实现中,通过查找本控件的最后一个图层在列表中的位置后插入新增图层,保证了同一个控件的图层在场景中的连续排列。前面提到,本发明的界面库架构方法架构中可以同时管理有窗口句柄控件和无窗口句柄控件,一个控件无论是否有窗口句柄,都可以拥有有窗口句柄的子控件或无窗口句柄的子控件。统一控件体系管理决定每一类控件只有一个供外部使用的控件接口,但可以有两种实现方式有窗口句柄实现和无窗口句柄实现。在本界面库架构方法设计中,它们共用一个对应于该控件的逻辑组件。如图3所示,表现了一个对话框(Dialog)控件的实现方式每一个控件都有一个"DialogCore"模块,用于管理该控件的状态逻辑和所有显示图层。对于一个按^L,有窗口按钮与无窗口按钮的公用逻辑就是当按钮响应鼠标消息时,按钮的背景图层会根据鼠标状态的变化发生改变。并向外界派发点击消息。但对于控件的其它操作,如在整个控件体系中的动作,这两种控件的实现在某些方面又各不相同,需要分由两个不同的对象来实现。其具体不同点如下表所示行为有windows窗口句柄的控件无windows窗口句柄的控件创建创建画布和场景不用创建画布和场景,使用父控件的场景管理图层移动沿控件树向上查找自己真实父窗口,换算坐标后,移动真实窗口移动所属图层,同时移动所有子控件显示(隐藏)显示(隐藏)真实窗口显示(隐藏)所属图层,同时显示(隐藏)所有子控件设置焦点设置自己的窗口为焦点窗口查找场景对应的窗口句柄,^没置它为焦点窗口设置是否可用设置自己的窗口属性仅需要将该控件ID标志为可用或不可用设置父控件查找自己的真实父窗口后,设置自己窗口的父窗口,重新换算坐标位置并移动查找自己的真实父窗口,重新计算所属图层在新场景中的位置和clip区域,并移动图层。重新设置所有子孙<table>tableseeoriginaldocumentpage13</column></row><table>以上只例举了具有代表性的不同点实现方案。由表中可以看出,无论是有窗口控件,还是无窗口控件,它们在体系中的行为和表现的本质都是对场景和层的操作。根据上面所述,控件的逻辑和控件的绘制更新在实现上是完全分离开来的。控件在创建时将自己拥有的图层的绘制和更新全部交给某个场景对象去管理,控件自己只需要关心软件的业务逻辑,比如对输入消息(鼠标,键盘等)的响应处理和由此引发的图层显示状态(是否显示,显示位置等)改变等;而图层在场景对象的管理下,可以调用各种绘制引擎的绘制接口,完成各种界面的绘制需求,包括图像的绘制和文字的绘制等。因此,本发明的这种界面库架构方法,可以在桌面窗口模式中使用游戏绘制引擎,能很好地满足桌面网络游戏软件的界面需求;同时,场景幻灯片层的架构设计,使界面库可以支持桌面软件和游戏软件两种刷新模式和多种绘制引擎,并且,分离出来的控件层和图层模块可以作为独立的部分被两者复用,这大大方便了组件的维护。在本发明界面系统中控件类型从功能角度看又分为两大类可见控件和不可见控件,不可见控件又称为控制型控件。可见控件指那些具有表现的控件。不可见控件主要用于控件多个逻辑相关的控件,其本身不需要表现。绝大多数可见控件包含一个多状态背景层。背景层根据背景图片的拼接方式由一个背景层工厂创建出来,这极大方便了背景层种类的扩充。请参阅图4所示VariableParam是外界传给控件的参数集对象。控件将它扔给背景层创建工厂,由工厂创建具体对象,并根据参数集中的数据初始化这个背景图层。最后由工厂返回一个IBGLayer指针给控件。场景(Scene)和图层(Layers)是本界面体系绘制过程中抽象出来的两个基本对象。可以作一个比喻场景相当于幻灯片框,而图层相对于幻灯片。许多重叠或不重叠的幻灯片,按一定的顺序排放在幻灯片框中,最后冲殳射到墙上的白布(Canvas)上,这个过程,就是本界面体系中所有界面的绘制过程。当然,相对于幻灯片框,Scene需要作更多的事情。每一个图层是一段相对独立可复用的绘制逻辑。它可以只包含单个简单元素,例如一幅图、一^a文字、一个边框、一个闪烁的光标等等;也可以是多个图层的集合,如由三张图或九张图拼接而成的背景图层,可根据状态ID变换表现的多状态图层,多帧动画图层等等。在本发明实现的UI库系统中实现了上述所有图层组件。每个类型的图层类都继承于一个父类ILayer,可以通过它的接口获得得每个图层组件的公共属性。图层组件有以下公共属性1)图层的尺寸;2)图层的可见性(Visible);3)图层的剪切区域(ClipRegion)。图层的尺寸通常由包含图层内容的最小外接矩形的长宽描述,它体现图层在无遮挡且画布足够大的情况下绘制内容的真实范围。图层的可见性决定图层最终是否被绘制到画布上。根据普遍使用的父子控件显示逻辑当子控件图层超出父控件范围时,超出部分不可见,即不可以被绘制。除去不可绘制部分,图层实际需要绘制的区域即它的剪切区域。每一类图层要根据图层的具体内容选择在剪切区域中绘制图层的算法。在本发明的UI库系统中使用矩形区域列表记录图层剪切区域。图层并不含有位置信息,图层位置取决于它^皮;改置的场景(Scene)。Scene管理一组图层的绘制位置、绘制顺序和更新区域。在Scene对象中,使用线性列表(list)结构保存每个图层在此Scene上的位置信息。列表是有序的,绘制时靠近列表头部的图层先被绘制,靠近列表尾部的图层后被绘制。当Scene将自己管理的所有图层绘制到Canvas上时,根据传入的Canvas上起始坐标将图层的Scene坐标转:换成Canvas坐标后再调用图层的绘制接口,将图层绘制到Canvas上。Scene另一个重要的设计功能是收集更新区域并提供更新区域合并处理。Scene管理的设计决定Scene可以支持界面通常使用的两种更新方式1)当界面局部显示发生变化时才通知画布更新(Canvas被动更新);2)利用CPU空闲或定时器定时更新画布(Canvas主动更新)。对于1)更新方式,请参阅图5所示,在桌面软件界面实现中,使用前一种方式,控件图层的状态发生改变时,通知Scene哪一个图层发生变化。Scene将该图层所在区域收集入更新区域列表,同时通知画布进行更新。画布更新时,只重新绘制Scene更新区域列表中的区域块。而要游戏界面实现中,使用后一种方式,Scene收到界面更新通知时,只收集更新区域,而不再通知Canvas进4亍更新。Canvas每次更新时仍重绘Scene更新区域列表中的部分。对于2)更新方式,Canvas主动更新时序图与图5类似,只是Scene不再通知Canvas更新,而由Canvas发起更新操:作。在游戏软件中多数采用主动更新的策略。本发明中针对混和器(Mixer)的界面图层与绘制引擎接口设计方法为混和器由混和器工厂在程序中自动生成,依据有三要素a)图像或文字元素,b)画布,c)混和才莫式。在系统中所有混和器对象均使用单件模式。控件依靠操纵图层将自己显示在画布上,图层通过调用引擎层的对象实现绘制。图层使用引擎层最基本的动作是图像绘制和文字绘制。请参阅图6所示,用户(在这里是构成控件的图层)首先使用图象工厂(ImageFactory)创建图像对象,然后根据图像对象的格式、画布对象的格式、混和模式创建出混和器,最后使用混和器根据设定的混和参数将图像对象绘制到画布对象上。请参阅图7所示,在画布上绘制文字时,首先使用文本工厂(TextFactory)生成文字对象,然后根据文字对象格式、画布对象格式、混和模式生成混和器对象,接着用户使用混和器对象将文字对象绘制到画布对象中,在混和过程中,首先根据混和参数里的字体信息从字体工厂(FontFactory)获得字体对象,然后^f吏用字体对象和混和参数进行绘制。Mixer技术为界面库在游?3i行扩展的可能。这时混和器相当于一个特效插件。当某个图层需要特效绘制时,只需要增加mixer对象的种类,并在MixerFactory(混合器工厂)中适当添加代码就可以满足需求,而且这些操作不会影响使用这套接口的其它程序。总之,上述所描述的几种实施方式,并不代表本发明所有的实现方式;以上实施例不是对本发明的具体限定,所有与本发明技术方案相类似的界面库架构,都应属于本发明的保护范围。权利要求1、一种界面库架构方法,其特征在于,自上而下依次包括了用户层,控件层,场景幻灯片层和引擎层;所述用户层通过创建控件层对象和调用控件层接口操纵界面元素;所述控件层包括了所有独立控件或组合控件,控件操作场景幻灯片层的场景对象和图层;所述场景幻灯片层包括了场景对象和图层,场景对象管理控件图层的绘制及更新,图层调用引擎层的绘制引擎接口将图层绘制在控件的画布上;所述绘制引擎层包括了绘制引擎接口,接受来自场景幻灯片层的图层的调用,实现图像和文字的绘制。2、根据权利要求1所述的界面库架构方法,其特征在于,所述的控件层以一个顶层窗口体系为一个基本管理单位,在体系中以一棵树描述体系中所有控件的父子关系,树上的每一个结点为一个控件。3、根据权利要求2所述的界面库架构方法,其特征在于,所述控件包括了有窗口句柄的控件和无窗口句柄的控件;所述有窗口句柄的控件由用户层的用户创建后,生成窗口画布并创建相应的场景对象;所述无窗口句柄的控件由用户层的用户创建后,使用父控件的画布和场景对象,或者由用户层的用户^:置该控件的画布和场景对象;所述场景对象管理该控件图层以及该控件的无窗口句柄子控件图层的绘制及更新。4、根据权利要求2所述的界面库架构方法,其特征在于,所述控件包括了可见控件和不可见控件;所述不可见控件用于控制多个逻辑相关的控件;所述可见控件包含一个多状态背景层,所述背景层由一个背景层工厂根据背景图片的4并接方式创建。5、根据权利要求1所述的界面库架构方法,其特征在于,所述场景幻灯片层中的场景对象使用线性列表结构保存每个图层在此场景上的位置信息。6、根据权利要求5所述的界面库架构方法,其特征在于,所述控件层的状态发生改变时,通知场景幻灯片层;场景对象将该图层所在区域收集入更新区域列表,并通知画布进行更新。7、根据权利要求5所述的界面库架构方法,其特征在于,所述控件层的状态发生改变时,通知场景幻灯片层;场景对象将该图层所在区域收集入更新区域列表;场景对象利用CPU空闲或定时器定时更新画布。8、根据权利要求1所述的界面库架构方法,其特征在于,所述绘制引擎层绘制图像时,先使用图像工厂创建图像对象,并根据图像对象的格式、画布对象的格式、混和模式创建混和器,混和器根据设定的混和参数将图像对象绘制到画布对象上。9、根据权利要求1所述的界面库架构方法,其特征在于,所述绘制引擎层绘制文字时,先使用文本工厂生成文字对象,并根据文字对象格式、画布对象格式、混和模式生成混和器对象,混和器对象将文字对象绘制到画布对象中。10、根据权利要求1所述的界面库架构方法,其特征在于,所述控件层包括可见控件和不可见控件;所述不可见控件用于控制多个逻辑相关的控件;所述可见控件包含一个多状态背景层,所述背景层由一个背景层工厂根据背景图片的拼接方式创建。全文摘要本发明属于软件开发库领域,公开了一种界面库架构方法,其特征在于,自上而下依次包括了用户层,控件层,场景幻灯片层和引擎层;用户层通过创建控件层对象和调用控件层接口操纵界面元素;控件层包括了所有独立控件或组合控件,控件操作场景幻灯片层的场景对象和图层;场景幻灯片层包括了场景对象和图层,场景对象管理控件图层的绘制及更新,图层调用引擎层的绘制引擎接口将图层绘制在控件的画布上;绘制引擎层包括了绘制引擎接口,接受来自场景幻灯片层的图层的调用,实现图像和文字的绘制。实施本发明的界面库架构方法,能很好地满足桌面网络游戏软件的界面需求,组件维护也非常方便。文档编号G06F9/44GK101216762SQ20071030808公开日2008年7月9日申请日期2007年12月29日优先权日2007年12月29日发明者燕杭申请人:腾讯科技(深圳)有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1