DirectUI再思考

DirectUI挺火,连QQ都是用它来做界面的。但是DirectUI真的这么好吗?DirectUI顾名思义,就是不靠控件,直接在主窗口上画图,实现控件的功能。


作为一个从TurboC 2.0时代走过来的老资格,我对于这样的方式有完全不同的看法。

在久远的TurboC年代,所有的界面当然都是直接在主窗口画出来的,所谓的“DirectUI”其实是在炒冷饭。没有经过那个时代界面开发的人可能很难想象我们第一次看到“界面控件库”时,那种喜大普奔的感受。我们终于不需要计算各个按钮的坐标了,终于可以随心所欲地设计各种界面了。如今再让我们用这种DirectUI,是想让我们忆苦思甜吗?

看网上某个专做DirectUI库公司的网页,说DirectUI有这么一些优势:

  • 界面完全换肤
  • 理论上更高的效率
  • 容易实现更加绚丽的动态效果
  • 防破解外挂
  • 界面与逻辑的完全分离

 

那么这些所谓的“优势”必须要采取直接绘图的方式吗,或者说,直接绘图有足够的好处让我们放弃控件库吗?让我们一个一个地分析吧:

  • 界面完全换肤

作为一个熟练使用各种脚本语言写界面的码农,界面当然是随时可以改变的。我曾经使用Tcl/Tk写过大量的商用界面,也曾经用javascript和C#干过同样的事情,随时改变布局不过是分分钟的事情。和应用工程师沟通的时候,我可以在半个小时之内提供数个版本以便挑选。界面换肤/改变布局简直是一件不言自明的能力。

不管用哪种语言,设计界面使用的都是现成的各种控件。改变界面当然不需要直接绘图,只要改改脚本就可以了。当然,现在的DirectUI一般用的是xml。但是,xml同样也可以看作是一种脚本,区别仅仅是解释器和语法。

界面完全换肤当然不需要使用DirectUI这种麻烦的办法。

  • 理论上的更高效率

就连专业做DirectUI库的公司也承认,效率问题不是关注的重点。要我说,如果界面的效率造成了问题,那开发人员统统应该拖出去枪毙十分钟。

界面的运行效率不是问题,那么开发效率呢?现在做DirectUI的公司好像没有谁能够做出来象CGridCtrl这样复杂而又好用的功能。

  • 容易实现更加绚丽的动态效果

那个公司的说法是“由于DirectUI的技术特点,使其更容易实现一些特效的动画效果,如菜单的动态徐徐展开和收缩,窗口的动态渐隐渐显的弹出和关闭,控件的动画展开和关闭。”但是,这中能力对于传统的,基于控件的界面开发应该不能构成绝对的障碍。事实上,Windows本身就已经实现了菜单的动态展开,只是大多数人都不用而已。

我相信,只要想,用传统的控件也能做出足够漂亮的动态效果。

  • 防破解/外挂

好吧,我承认,使用控件的界面确实容易通过Hook的方式进行跟踪分析和破解。但是,以我的经验,破解其实主要针对的是内部数据和内部处理。至于界面,老实说,我过去干过不少游戏跟踪修改的事情,但是从来没有在乎过界面。要说修改界面控件,我觉得大部分商用系统是不需要,也不会去做的。

  • 界面与逻辑的完全分离

那个公司的说法是这样的:

界面是指涉及界面元素操作的部分代码,比如控件位置大小,控件的状态;窗口的大小;控件界面的绘制代码;控件的动态创建。
逻辑是指软件的程序逻辑,与界面操作完全无关,如网络操作,内部事件与消息。

目前来说,基于Win32的大部分界面库已经能最大限度的分离界面与逻辑,最主要的是将界面控件的绘制代码分离出去,使得应用程序变得更加清晰,更加容易维护,容易重用;也能很容易适应界面UI设计的变化。

我认为,这种说法完全不能作为DirectUI的理由。如果哪个开发者会把界面和内部逻辑混在一起,那只能说明他的结构设计能力不合格。把界面和逻辑分离,应该是设计者的本能行动,而VisualStudio在创建工程的时候也会创建Doc和View类,让你去这样做。

 

综上所述,我认为DirectUI唯一的优点在于界面换肤,但是这个能力通过控件方式也可以非常容易地实现。上传了一个小例子,在点击打开链接

这是我花了不到两个小时做出来的一个小例子。在这个例子中,我通过加载不同的xml实现窗口背景的更换和按钮的重新放置。同时,这个按钮还实现了透明背景,主要的时间都花在了透明背景的实现上面了。作为一个小例子,这个按钮只能显示文字,没有做bmp按钮的支持。

使用方法:

压缩包里面有一个可执行文件,两个xml配置文件和两个bmp文件。这两个bmp就是配置文件里面指定的背景图片。你可以随便换。背景图片有点丑,随便做的就不要挑剔了吧。

这个例子其实是用VisualStudio 2012做出来的一个单文档应用程序,用File->Open打开xml配置文件。窗口上只有一个按钮,点击它会弹出About窗口。通过不同的xml配置文件可以改变按钮的文字和位置。

当你使用压缩包里面的1.xml的时候,窗口是这样的:

DirectUI再思考_第1张图片

如果打开2.xml,就会变成这样:

DirectUI再思考_第2张图片

Xml配置文件说明:

子节点bg指定背景图片,只要把bmp文件和可执行代码放在一起就可以了。

子节点button指定按钮,可以设置按钮的文字和位置(现在只支持left,center和right)。点击这个按钮会弹出About窗口。

显然,通过制定自己的xml文件格式和解释规则,实现完全换肤并不是什么太了不得的工作。我们完全不需要为了这点能力去直接绘图。直接绘图是一件非常辛苦而又没有什么成就感的工作。控件库就是为了取代这种工作而出现的。

 

DirectUI的未来怎么样?

至少,我本人并不看好。说实话,我觉得现在能看到的DirectUI的布局能力还不如Tk的功能,要想大规模推广到所有的商业应用恐怕不现实。毕竟,真的需要换肤的商用软件很少,只有个人应用才把花哨放在第一位。

但同时,基于MFC库的软件有那么完善的控件库可用,像我这个例子一样搞一个换肤的功能远比开发那么多控件容易。

这个现状让我想起了Windows3.1的时代。那个时候有火爆的中文之星和四通利方等一大批中文平台,但是随着Windows3.2的推出,这些中文平台全部死掉了。我觉得,当前这些DirectUI库就像是当年的中文平台,只能打一个时间差,等什么时候微软提供了一个动态换肤的工具库,就全都要死了。比如说,微软给所有的控件添加一个透明背景的风格选项,然后你自己可以方便地实现xml配置布局。那么你还会想要直接去绘图吗?

而现在使用DirectUI做产品的公司,可能就会面临一个巨大的鸡肋:过去的代码放弃可惜,但是维持这样的代码又很笨拙。

你可能感兴趣的:(开发模式)