vc界面库技术比较

这里不比较具体的界面库，而只比较它们所用的实现方式。

基于Win32的界面库和DirectUI界面库，哪种好？
这其实一句话就可以得出明确的结论，但我准备花些篇幅来解释它，因为有太多的人不相信我说的真话，有时候，我也不能完全说真话。
我接触界面开发也有十多年了，一直供职国内外一些知名软件公司。在一些QQ群里，也经常与人讨论关于界面开发方面的话题。
现阶段C++界面库主要有基于win32控件自绘的（包括基于mfc控件、wtl控件等带句柄的控件）和完全用图片或颜色来模拟win32控件的DirectUI界面库。前些年，我很怕别人问我哪种界面库好。你不论如何回答，都会引来无数口水，所以，我只能说：我自己写的最好。要想说清楚我为什么怕回答这个问题，就要从我同界面开发结缘说起。
04年毕业后，到了第一家公司，正好赶上做界面，从此十多年职业生涯，就一直做界面了。做界面的好处就是有成就感，什么效果可以直接看到。当时国内还没有用来开发QQ、360这种界面的界面库。大家做界面都是从MFC控件派生后自绘，再加到自己的工程中，网上也有一些零星的开源的控件，比较有名的就是CButtonST和CXPButton这两个按钮类，当时大家做界面，大部分也仅仅是换换按钮而已。其实那时候的样子真的很一般，当时有个著名的软件，叫Winamp，是一个mp3播放软件，它的界面在当时算标杆了，还有早期的QQ界面，就算做的相当不错的了。因为win32控件都是由微软封装好的，普通的win32控件就是那种灰色的标准外观，想要改变它的外观，就得子类化它，然后处理它的绘图消息自绘，但这方面的资料较少，当时互联网也不发达（即使现在，网上关于win32控件自绘的资料也不全），微软对它又做了很多限制，所以有些控件自绘难度很高。大约在05年06年的时候，出现了一个商业的mfc界面库，叫LibUIDK，这个界面库早期还有完全免费的版本，不过相对于它的商业版，提供的控件较少。我用过它早期的免费版，不得不说，设计思想在当时太牛B了，居然提供了所见即所得的界面编辑器，可惜的是，这个库的市场一直没做开，我估计是作者只懂技术，不懂销售吧。
后来学习LibUIDK的设计，我也为公司搞自己的界面库，由于只针对公司产品设计，所以，只提供公司产品用到的控件，这样省了不少研究、开发用不到的控件的时间。公司里的项目一直用这个库，直到我离职。我到了新公司，仍然是开发win32的界面库，当时国内的公司也开始逐渐重视UI体验了，QQ的界面做的越来越精致，360等公司也崛起了，界面也都不错。好像大约在2010年的时候，具体记不太清了，出现了一种无控件句柄的界面库，当时DirectUI的概念还不清晰，其实我刚毕业的时候，就采用这种方式了，第一家公司的一个项目，大量采用了无句柄的控件，就是把图贴到父窗口上，然后处理鼠标消息，让它有反应。不过当时只是为了完成任务，根本也没想到将来有一天有人会把它设计成一种界面库。当时之所以用无句柄方式，是因为我搞不定win32对应控件的自绘，没办法之举。
不过在后来开发win32的控件自绘的过程中，确实发现有些win32控件自绘起来特别麻烦，比如文本框、滚动条这些。
后来QQ采用了完全无句柄的控件，迅雷7也是无句柄控件的界面。像国内一些顶尖的互联网公司，也有一些无句柄控件的界面出来。再后来，DirectUI方式的界面越来越多，这时候，国内也出现了很多DirectUI界面库，比较知名的就是开源的Duilib。甚至很多牛公司也在用它，当然，都是经过各自修改后的，外人是拿不到的。加上我自己在自绘win32控件时碰到的各种限制，这个时候，我坚信，DirectUI方式是好的。
随着对界面研究的加深和经验的积累，我知道了一些情况：1. Win32控件由微软保证它的操作系统兼容性，当微软发布新的操作系统后，会自动为原来的win32加上新系统支持的一些功能。比如在XP年代开发了一个界面，里面用到一个list控件，不需要经过重新编译，直接把这个exe拿到win7系统上，如果屏幕支持多点触摸，那么你可以直接使用手指来滑动这个list控件。当把这个exe再拷贝到win8上运行后，打开win8系统的屏幕阅读，你就可以在操作这个软件时，让系统来阅读你的界面。同理，以后的操作系统，会持续为win32控件增加一些功能，作用程序员，你不需要修改任何代码，甚至都不需要重新编译你的项目，到时候，就可以享受这些功能。
2. 认识了一些UI界的老前辈（程序员这个行业吃青春饭，我虽然只工作了十来年，也有很多人叫我前辈了。），他们说win32自绘控件更好，退而求其次，就是从CWnd派生自绘，最差的就是DirectUI无句柄方式。因为国内这些程序员，水平再高，仍然处在整个软件开发金字塔最底层的水平，改用一句广告词就是：不掌握核心科技。所以，无论如何，也不可能完整实现一个控件应该拥有的所有feature，甚至连一半都无法实现。
在我做界面开发后期这几年，虽然不在坚信DirectUI好，但我也不确定win32自绘好。因为我还是有一些疑问：如果Win32自绘好，那为什么像腾讯等顶尖公司会从win32自绘换到dui？为什么它们要用这种重复造轮子，又造不好的东西。就这个问题，我也咨询了很多人，有很多种说法，我甚至咨询过LibUIDK的作者和一些做Dui界面库的作者，结合自己多年的开发经验，感觉靠谱的说法有：
1. Dui界面开发难度低、可以绕开win32自绘的各种限制，快速出项目。只需要前期花点时间写好一套dui界面库，之后做项目就可以复用，很快了。
2. 在很多人开始写界面库时，腾讯的影响力实在太大，腾讯已经实现了dui界面用到QQ上的成功案例。其它作者只需要跟进了，没有人愿意做出力不讨好的事。采用其它方式，万一不成功呢。
3. 写dui界面库的作者很多，其中很多商业的做过市场推广，又有很多开源的。而win32界面库几乎没有免费的。
随着对界面的理解加深，它的神秘感逐渐消失，我不再理会人们的说法，我选择了相信规范、稳定与安全、相信微软！
现在，我已经确认了哪种更好，当有人再问我时，是不是可以告诉他们实情了？No! 没有那么简单，程序员大多数是盲从和随波逐流的，这也不能怪程序员，我也是程序员，也是用了多年才敢确认哪种方式更好。程序员是无法直接判断哪种更好的，他们认的是品牌，现在使用dui方式的知名公司很多，我如果说win32自绘好，又拿不出来很多知名的产品（其实早期QQ都是mfc采用带句柄控件实现的，现在的效果，原来也都能做），徒留了让人反驳的话柄。
此时，遇到不同的程序员，我会说不同的话，对于自己供职的公司，我会极力推荐使用win32自绘的方式。对于大部分程序员，我还得说dui方式好。
其实很多时候，大家也不必这么纠结，做到现在，我经常是主体采用win32自绘，当实在搞不定某个控件自绘的时候，我就直接从CWnd派生一个类，去模拟这个控件。因为微软的HWND，帮我做了很多前期工作，像裁剪、消息映射等等，我只需要专心于自绘即可。
这里有个小插曲，大家都认为DirectUI这个名字来自微软的DirectUIHWND类名，表示直接绘制到父窗口，没有句柄。其实只对了前半部分。微软的DirectUIHWND并不是把内容绘制到父窗口的，恰恰相反，DirectUIHWND只是一个类名叫“DirectUIHWND”的子窗口，它是一个HWND，它是有句柄的。