Direct UI

在界面开发中，眼下DirectUI是个热门的技术名称，由于众多的知名公司都是用DirectUI方式作出了非常炫丽的界面。而对于大多数熟悉Win32控件，熟悉MFC开发的开发者来说，我们应该做何选择？

由于传统的Win32/ MFC大家都比較了解，所以首先我们分析DirectUI，看看DirectUI能完毕哪些普通Win32控件难以实现的功能，同一时候实现一个完整的DirectUI有那些关键点。

基于DirectUI技术的界面库的优势

下面是我们总结的一个完好的DirectUI库的优势，这些特性Win32控件方式难以实现的：

1. 界面全然换肤
   
   这里的“界面全然换肤”，是指用户可全然定制化的换肤，软件界面控件大小，位置等都可能有变化等。DirectUI界面库一般都是用XML定义界面虚拟控件并直接布局界面，因此能够实现此功能。但实际上全然的换肤涉及到非常多问题，眼下非常少有界面库产品能够实现这样的全然换肤。从界面设计的发展来看，眼下已经不流行这样的界面的全然换肤，由于这不仅对技术要求比較多，同一时候也对UI设计要求非常高。眼下界面换肤大量採用的是更换色调，局部的背景更换（如MSN/QQ最新版本号）。
2. 理论上更高的效率
   
   由于在DirectUI控件中，很多其它的控件为逻辑上的虚拟控件。因此理论上来讲DirectUI执行效率会更高一些，但这个效率也与DirectUI界面库总体的软件架构及软件实现有密切关系。在实际考虑时，效率问题应该不是关注的重点，由于眼下设计及实现良好的Win32 界面库在效率方面也没有不论什么问题。
3. easy实现更加炫丽的动态效果
   
   因为DirectUI的技术特点，使其更easy实现一些特效的动画效果，如菜单的动态徐徐展开和收缩，窗体的动态渐隐渐显的弹出和关闭，控件的动画展开和关闭。当然以上这些特性也取决于开发团队的技术实力，同一时候也须要顶尖优秀的UI设计师配合，方能带来所期望的炫丽效果。
   
   
   
4. 防止软件被破解，防外挂
   
   关于这一点，可能是众多关注DirectUI的人没有考虑到的。但实际上恰恰是这一点可能是最为关键的。众多知名互联网公司不遗余力研发DirectUI界面，这一点也是重要考量。传统的Win32控件因为其消息、原理公开，使得通过一些简单的Hook或其它方式能够非常easy破解软件。而一个全然的DirectUI界面，其界面元素及内部逻辑全然为私有实现，外界无从得知。这就使得破解变得困难的多。
5. 界面与逻辑的全然分离（须要完整脚本支持）

   在说明这个问题前，我们来了解这个基本问题：
   
   
   
   什么是界面与逻辑的分离？
   
   
   
   界面是指涉及界面元素操作的部分代码，比方控件位置大小，控件的状态；窗体的大小；控件界面的绘制代码；控件的动态创建。
   
   
   逻辑是指软件的程序逻辑，与界面操作全然无关，如网络操作，内部事件与消息。
   
     
   
           在Win32控件或者MFC等设计里，实际上是将界面和程序逻辑全然糅合在一起，这样做的缺陷在于假设界面UI设计有一些改变，我们可能要大面积的改动程序代码并又一次编译，同一时候程序也难以重用，我们可能须要重载好多类如CCongfigButton，CSettingButton，CXXXButton等。每个新的界面效果的添加，我们都须要去改动程序，加入支持。
   
   
           眼下来说，基于Win32的大部分界面库已经能最大限度的分离界面与逻辑，最基本的是将界面控件的绘制代码分离出去，使得应用程序变得更加清晰，更加easy维护，easy重用；也能非常easy适应界面UI设计的变化。

   什么是界面与逻辑的全然分离？
   
   全然分离是指程序中不出现不论什么界面控件元素属性的相关操作，如调整界面控件位置，控制控件的显示/隐藏。即在不又一次编译程序的情况下，仅通过改动界面配置文件(XML)和脚本文件，就可以载入一个新的界面效果。

   理论上来说，Win32控件库不能做到界面与逻辑的全然分离。比方MFC框架，更是将界面与逻辑全然融合在一起。这也是非常多大的互联网公司花重金研发全然的DirectUI界面引擎的原因，这类公司基本都是高速开发模式，产品更新快，界面UI设计更新快，经常一个软件开发出来，皮肤已经换了好几套了，界面调整无数次了。假设採用传统的方式，这里面会带来巨大的工作量及反复工作。

以上几点是一个基于DirectUI技术的界面库能够实现的，但基于Win32控件的界面库难以实现的。但同一时候我们也会发现，还没有一个通用的DirectUI界面库产品中实现以上全部特性；即DirectUI的真正优势还未能在实践中实现。下面的关键点是一个完整，通用的DirectUI界面库难以实现的原因。

 
DirectUI界面框架开发的关键点（或者称为难点）

1. DirectUI界面库总体架构设计
   
           一个完整的DirectUI界面库，能够等同于一个Mini的QT、WPF，Flash等。须要一整套的系统级别的架构，而不只不过界面元素的绘制。这个架构很重要，同一时候也对软件架构师有很高的要求。
2. 完整的事件响应模块
   
         Win32控件的事件非常多，而一般的DirectUI界面库指实现主要的几个事件如单击，mouse in, mouse leave。其它一些事件如双击，右键，滚轮这些，或许不经常使用，但假设不能提供这些事件，会是一个比較头疼的问题。
3. 复杂控件的支持
   
        复杂控件的支持也是众多DirectUI界面库的软肋。复杂的控件如Menu，list control，tree control，Edit等，或许实现起来必须并不复杂，但要实现一个可全然替代Win32标准控件的控件就比較麻烦了。这涉及到三个方面： 
   
   
       功能特性的完整性
   
       非常多DirectUI提供商实际上仅仅实现了部分的功能就宣称支持某某控件，这样的说法是不负责任的。比如树形控件，其涉及的接口函数有40多个，Notify消息有20多个。这些函数和消息中，可能经常使用的仅仅有小部分，但其它不经常使用的也是不能忽略的。 
   
   
      效率问题
   
       拥有这个功能的实现，不一定代表能广泛通用。能否承受大数据量的插入？是否保证内存的占用问题？这些都是我们在測试一个自绘控件须要考虑的问题。 另外也须要保证在自绘模式下的效率问题。
4. 剪贴，拖拽，热键快捷键等
   
          Windows标准控件我们用了好久了，但当中非常多我们非经常常使用的功能，会经常被的DirectUI的设计者忽略。或许正由于这些功能太寻常，太经常使用了，所以easy被人忽略。如剪贴，拖拽，热键，快捷键，tooltips等。这些功能特性也是不能缺少的，由于太经常使用了！
5. 界面样式多样性的支持
   
         眼下有些DirectUI类的产品在控件设计时仅仅是模仿MFC等对应控件的API。比如：
   
   ListView::SetItemImage函数，用来为list的一个item设置图片。但实际上当前软件界面中，设置一张图片是远远不够的，一般Item中不仅须要依据程序逻辑动态显示多个图片，并且还须要显示一些能够响应事件的图片，如QQ好友列表树。对于DirectUI类产品来说，应该对这些提供完整支持，而不是只提供一个自绘结构，让用户自己来处理。
6. 高效灵活的自绘机制
   
       当前的软件界面控件的样式是多样的，须要有灵活高效的自绘机制来保证。
   
        Windows标准控件提供了很灵活的自绘处理，我们能够在WM_PAINT，WM_ERASEGRND等消息中绘制自己的界面。同一时候对于Button，Menu，List Control，Tree Control， list Box等控件，微软提供WM_DRAWITEM, CustomDraw 等机制，使得我们能够随心所欲的绘制item内容。而各种情况下的效率则由标准控件内部保证。我们仅仅须要在OnDrawItem等消息中绘制item内容就可以。
   
   
        众观全部UI框架，QT，WPF等都提供了完整的自绘机制。如QT甚至提供了CSS等方式来配置界面。足以看出灵活的自绘机制对一个界面产品的重要性。假设DirectUI类界面库不能提供一种高效，灵活的自绘机制，则无法满足软件对界面库的基本需求。
7. 与脚本语言的整合       
   
          我们坚持觉得一个完整的DirectUI界面库应该提供完整的脚本支持。假设将内部的XXLabel, XXButton, XXProgress,  XXSliderCtrl等内部类或结构暴露给界面库的使用者，则势必带来界面和逻辑的又一次糅合，同一时候使得应用程序变得深度依赖界面库，带来非常多不稳定因素。如无法将界面和逻辑非常好的分离，DirectUI就变得没有意义。

   一些知名的互联网公司不但在自己的DirectUI系统中深度整合脚本语言，在脚本语言的选择上也在变化，之前经常使用的是vbscrip/jsscript语言，眼下多使用lua脚本语言，lua脚本为开源项目，其特点是灵活，高效，easy扩展。

 
与DirectUI界面库相比，DSkinLite界面库的优势

1. 对开发者界面开发能力要求低
   
   如上面所描写叙述的，因为眼下还未有一个完整的DirectUI类型界面库，大多数情况我们须要在DirectUI界面库的源代码上做开发，这对參与二次开发的人员有非常高要求，须要对界面开发的各方面有所积累。而DSkinLite界面库主要基于Win32控件，封装完整，无需开发者熟悉界面开发，同一时候我们设计时非常重视界面库的易用性，对MFC，WTL，Win32控件有些基本了解的开发者就可以胜任。
2. 可迅速实施到项目中
   
   假设已有VC项目，使用DSkinLite这类Win32控件库，能够非常easy整合到现有项目中，基本无需改动已有程序逻辑。对于新的项目因为省去了整合并扩展DirectUI框架的工作，使用DSkinLite也会比較快。
3. 项目风险小，投入少
   
   因为一个完整的DirectUI库相当于一个新的GUI Framework框架，这样DirectUI界面库本身在架构设计，程序代码质量等方面会给项目带来新的风险。同一时候须要对项目添加对应的界面开发者，用以维护DirectUI界面库产品。而基于Win32控件的DSkinLite界面库没有方面的问题。