各种界面技术比较

前言
纵观这几年，界面库的发展可谓风声水起，讽刺意味的是：大家对PC上的界面重视程度，来源于手机界面的发展。当苹果出现时，彻底让人们对界面的需求，提高了一个台阶。随之而来的是粗糙界面的塞班界面的没落。

过去，人们不太重视软件界面，把更多的精力放到程序功能上。现在人们越来越意识到，一个好的界面对产品的成功有时起着关键性作用。这是好现象，在产品同质化严重的今天，一个好的界面，就会让产品脱颖而出。

界面库的分代

在VC++开发上，界面大致经历了这么几代：
第一代Win32原生态界面：包含对它进行封装的MFC、ATL等。由于它足够兼容、足够稳定、足够淳朴，一直到现在还占有大量的市场。不过它逐渐被压缩到一些专业软件上。在IM、播放器、杀毒等领域，已经不能想像一个原生态界面会是什么样子了。


第二代Hook换肤库：这是为了解决Win32原生态界面“淳朴”外观而诞生的。以SkinMagic、SkinPlusPlus、SkinSharp等为代表。它有一个看起来美丽、又特别唬人的特性：一句代码换肤。是的，它能做的也仅限于此了。因为它不介入界面开发，所以不会提高界面开发效率；因为你只调用了它一行代码，所以，Hook换肤库里有任何bug，你都无法绕开，除非你注释掉这行代码，不用它，而bug几乎是一定有的；因为Hook界面库只认识控件类型，不认识具体控件，也就是说，换肤后，所有同类型控件，都会长一个样，很难做到个性化。兼于种种原因，所以Hook界面库早已光荣退休了。


第三代DUI界面库：dui是Directui的简称，也称作windowless，意思是无句柄,以duilib为代表。前两年，大家都搞dui，dui着实火了一阵儿。当初产生dui，其中一个原因是自绘某些win32控件特别困难，与其花大力自绘这些win32控件，还不如干脆自己开发一个得了；另一个原因是他们自认为dui比win32控件安全，实际上完全不是的。随着这两年使用的深入，dui的各种弊端都逐渐暴露出来了。dui控件是比照着win32控件来实现的，这句话的潜台词是：win32控件是标准，是被模仿的对象。虽然理论上，dui可以完整的模拟出一个win32控件，但一个比较糟糕的现实是：国内做dui的程序员，几乎没有人知道一个完整的win32控件应该是什么样、具有什么功能。所以他们只能模仿他们看到的部分。dui界面库虽然相对于win32原生态控件，提供了控件贴图的功能、但却失去了更多本来应有的功能，变成了一朵艳丽的假花儿。我们知道，win32控件是windows操作系统提供的基础控件，windows可以保证它一直拥有着最新特性。举个例子，我们在windows xp上，制作了一个界面，界面上有个Tree控件。当把这个编译好的exe放到装了Win8系统且带多点触摸屏的电脑上运行时，Tree控件会自动具有惯性滑屏的功能，虽然xp不支持多点触摸。当我们打开系统的界面朗读功能时，用键盘在Tree控件上操作，系统会自动根据您所选的Item，正确朗读出来。（这正是Accessibility法案的一条要求，对于出口到欧美国家的软件，Accessibility法案是强制规定。所以，目前还没有任何一个国产的dui库做的界面，达到这一强制规定）。当将来的Win9、win10等系统有新功能时，这些Win32控件，会自动拥有这些功能。这一点是dui界面完全不具备的。

现在还有一种界面库,为了区分,暂称之为DirectHWND技术吧：以LibUIDK为代表。它从原生win32控件派生，保留了win32控件所有特性、拥有完整的消息机制、与win32控件完全一样的编程思想（意味着几乎忽略不计的学习和维护成本、更小的风险，如果是dui库，你得按它的方式来调用，它封装成com，你就得懂com）、又提供了dui界面的自绘功能。是win32控件与dui的完美组合。下图可以表示win32控件、dui控件和HWND-DirectUI控件三者的关系。