directUI

　　MFC界面开发中，习惯了使用控件，亦或者是自绘制控件来美化界面，但操作起来繁琐，还不太美观。DirectUI的出现，对于界面开发，给了我们一个新的选择，目前很多公司使用了该技术对其产品进行了美化，效果还是可以得到肯定的。

　　接下来，分析一下DirectUI可以完成哪些功能，可以简化哪些操作。以及该项技术的关键点技术。

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

界面完全换肤

完全焕肤问题，虽然传统的哦MFC也可以获取窗体句柄等器件对窗体样式大小进行修改定制，但是这操作起来会有很多的类以及对象，首先在内存上也会占用很多，其次操作上也有些混乱。

而DirectUI这里的“界面完全换肤”，是指用户可完全定制化的换肤，软件界面控件大小，位置等都可能有变化等。DirectUI界面库一般都是用XML定义界面虚拟控 件并直接布局界面，因此可以实现此功能。但实际上完全的换肤涉及到很多问题，目前很少有界面库产品可以实现这种完全换肤。从界面设计的发展来看，目前已经 不流行这种界面的完全换肤，因为这不仅对技术要求比较多，同时也对UI设计要求很高。目前界面换肤大量采用的是更换色调，局部的背景更换（如MSN/QQ最新版本）。

理论上更高的效率
由于在DirectUI控件中，更多的控件为逻辑上的虚拟控件。因此理论上来讲DirectUI运行效率会更高一些，但这个效率也与DirectUI界面
库整体的软件架构及软件实现有密切关系。在实际考虑时，效率问题应该不是关注的重点，因为目前设计及实现良好的Win32
界面库在效率方面也没有任何问题。只是实现技术上难度高了些。

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

由于DirectUI的技术特点，使其更容易实现一些特效的动画效果，如菜单的动态徐徐展开和收缩，窗口的动态渐隐渐显的弹出和关闭，控件的动画展开和关闭。当然以上这些特性也取决于开发团队的技术实力，同时也需要顶尖优秀的UI设计师配合，方能带来所期望的炫丽效果。

防止软件被破解，防外挂

众多知名互联网公司不遗余力研发DirectUI 界面，这一点也是重要考量。传统的Win32控件由于其消息、原理公开，使得通过一些简单的Hook或其他方式可以很容易破解软件。而一个完全的 DirectUI界面，其界面元素及内部逻辑完全为私有实现，外界无从得知。这就使得破解变得困难的多。充分利用了类的安全性 性能优势。

界面与逻辑的完全分离（需要完整脚本支持）

在说明这个问题前，我们来了解这个基本问题：

什么是界面与逻辑的分离？
分离的目的是为了简化程序猿的操作复杂度。
界面是指涉及界面元素操作的部分代码，比如控件位置大小，控件的状态；窗口的大小；控件界面的绘制代码；控件的动态创建。

逻辑是指软件的程序逻辑，与界面操作完全无关，如网络操作，内部事件与消息。
  
       
在Win32控件或者MFC等设计里，实际上是将界面和程序逻辑完全糅合在一起，这样做的缺陷在于如果界面UI设计有一些改变，我们可能要大面积的修改程
序代码并重新编译，同时程序也难以重用，我们可能需要重载好多类如CCongfigButton，CSettingButton，CXXXButton
等。每一个新的界面效果的增加，我们都需要去修改程序，添加支持。

        目前来说，基于Win32的大部分界面库已经能最大限度的分离界面与逻辑，最主要的是将界面控件的绘制代码分离出去，使得应用程序变得更加清晰，更加容易维护，容易重用；也能很容易适应界面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的设计者忽略。也许正因为这些功能太平常，太常用了，
   所以容易被人忽略。如剪贴，拖拽，热键，快捷键，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脚本为开源项目，其特点是灵活，高效，容易扩展。

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

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

摘录修改自：http://blog.csdn.net/a199228/article/details/7027717。谢谢原作者。