仿迅雷播放器教程 -- C++界面制作方法的对比 (9)

    上一个教程对比的5个方向共7个界面框架，都是非常权威，应用很广泛的库，绝对是非常稳定，并且能够做出常见的界面出来，可以放心大胆的用在项目里。

    但那7个界面框架再好，也总是没有绝对的优势，不然其他框架早就淘汰了，那么以下几个才是目前真正的顶级理想状态（过几年可能这些理想状态也不理想啦~）：

1、用3D游戏的界面来做客户端界面，3D游戏的效果当然是世界顶级的啦，如果客户端能做成那样的效果，当然是非常爽，但其资源占用就决定了不可能用来做客户端。

    那么我们退而求其次呢？  用2D的总行了吧？ 其资源占用还是太大了！ 

    那再退一步呢？ 不需要动画效果和各种特效，只需客户端那样静态的页面。由于游戏框架做界面比客户端框架灵活N倍，这样就可以即有游戏框架的灵活性，又有客户端一样的低资源占用，岂不是客户端界面最好的组合？  嗯，技术方面可行，但是游戏框架本来就不是为客户端而生的，所以要调整成客户端框架，普通人只能小打小闹，做一个界面出来可以，但要做出通用的框架，难度就非常大了。 所以，如果没有大牛去提炼游戏框架，那么用游戏框架做客户端就是扯淡。

    马云说过：如果一个点子有70%的人赞同，就说明这个点子已经被千万人想过了。 既然Alberl能想到这个，那肯定很多大牛已经做过这种事情了，Alberl也搜到过一些开源库，但不成气候，不然早就火了~

 

2、用.NET 和 Native C++，既然没有好用的游戏框架，那我们来点现实的吧，用WPF做界面，用C++做逻辑。

    其实如上个教程所说，.NET已经被广泛应用了，很多领域根本无需Native。

    在工业领域，比如考勤机、点菜机、KTV等领域，由于终端数量不多，都是由厂家直接安装软件，并且不需要很炫的效果，所以.NET的大小根本就不是问题，而运行也很快，因此在这些领域，那几个问题根本就可以忽略不计。

    而在移动领域，之前微软的WinCE、WinMobile都是用C#做界面，非常方便。现在的WP8也是用C# + SilverLight，根本就不支持C++开发，所以更不用谈Native C++了。而android最开始也不支持C++，所以现在真的不是C++一统天下了，就别想着什么事都用C++来搞定了，语言真的只是个工具而已。

    那么转向我们的客户端领域吧，上面已经说了，在非客户端领域，要么对界面要求不高，要么已有其他框架代替，真的不用蛋疼界面，只有客户端这个领域才是上不上下不下的。即使对于客户端，.NET除了要装.NET库以及慢点，其他方便真的是目前最好的了，91手机助手已经开了先河啦。但是现在这么多客户端在用C++，咱们还是得用C++做界面吧，那就还是不方便吧。

    那么我们不用WPF的特效，只用静态效果，就不会感觉到慢了吧，只需要低版本的.NET库就行了，也就是几十M，并且只需要在XP下装。不过如上个教程所说，除了.NET大以外，更重要的是程序员的水平，即使是C++的高手，全部切换过去做.NET，也不见得能搞得好，所以.NET还是不能用，C++为啥就这么蛋疼呢o(╯□╰)o  但是微软提供了一种折中的方案：用C++的语法，用.NET的功能，即CLR。 这虽然离【.NET 和 Native C++ 】差一点，但好歹也是【.NET 和 C++ 】吧，这不就解决了刚刚的语言切换的问题吗？ 那看来就只剩下几十M  .NET库的问题啦，这听起来很不错，也确实能用将MFC的项目快速转换到.NET，这样老项目很快就可以用上.NET做漂亮界面啦。不过Alberl依旧相信一个道理：不管宣传得有多好，时间才是检验真理的唯一标准。显然，CLR出来很久了，没有被广泛运用起来。Alberl也说不出为什么，但Alberl会说：为什么这么久了，你还没火起来？

    可能有小伙伴想说了，以微软的实力，做一个用Native C++写逻辑，用.NET做界面，并且无需安装.NET库的框架出来，应该易如反掌吧？ 那确实^_^

    如上所述，你能想到的，早就有人去做啦，有人就去微软的VC++版块提意见，问为什么不出个NativeWPF，即使不用C++，也很好呀。那我们就真的不用蛋疼客户端啦，屌爆了！！！ 不过不要高兴，也不要期待微软会这么干。 VC++官方团队早就否定了这个意见，虽然没有说是公司的战略问题，但其实真的是微软的战略问题。C++好歹是别人的孩子，谁会丢下自己的亲儿子呢~ 从C#的功能来看，可以发现微软早十年就开始布局各大终端了，微软的目标就是一统天下，你干什么都用.NET就行啦。并且目前仍在继续，很多先进的NB功能都是只在C#里，C++只有仰望的份。 而WP8不支持C++开发，也让很多人转向了C#，总之，C++开发者越来越少，C#越来越多，那么微软一统天下的目标就更近啦。 可惜近几年被linux抢尽了风头，android已经严重威胁了微软，移动端的崛起已经让微软高度焦虑了。不说了，再说Alberl就有点担心客户端的命运了o(╯□╰)o   在其位谋其政，即使客户端未来可能会消亡，Alberl还是那句话，移动端还是需要一个漫长的发展，十年内还是不能完全代替客户端的，啥时不用PC敲代码了，才是终结的时候。 最重要的是，你十年的时间里只学习客户端？  Alberl可没这个打算，Alberl非常想学习各种知识，并且移动端的开发已经被安排在几年后的日程里了，所以Alberl从不担心MFC什么时候被淘汰，也不担心C++什么时候被淘汰。

    扯到哪里去了？哎，微软不愿意做NativeWPF，但C++的界面好歹也是要做的吧，方案总是要有的吧。那确实，很多大牛已经做了，还是那句话，必须有大牛的无私奉献，否则一切都是扯淡。这个将在后面的教程介绍~

    国内用WPF最著名的就是QQ概念版了，并且效果非常炫，但QQ概念版早就停止了开发，也许并不仅仅是因为界面，但可以知道的是：如果从零开始用.NET开发出一个QQ，无论是界面方面，还是逻辑方面，都要花费巨大的代价！

 

3、用Web界面来做客户端界面，既然NativeWPF也没有非常权威的框架，那我们再现实一点吧，用Web做界面，这个可是有很多著名框架的哟。

    虽然前面两个方案做界面都是很nice的事情，但是没有知名的框架，对于我等菜鸟，目前是不可能去开发一个框架了，所以我们再退一步吧，虽然HTML的界面效果有很多限制，但是已经能满足绝大部分客户端需求了，并且其方便程度简直令小伙伴们惊呆了。但是总有人站出来说：又是几十M的库。好吧，Alberl觉得如果不大于40M，应该不用太在意吧，如果小于20M，那真的可以忽略啦。

    不过Web框架除了库的大小，真的有致命的缺点：

1、界面效果有限制，虽然HTML5可以解决这个问题，但是木有知名的框架。所以如果对界面要求不是特别高，只是想比普通客户端好看一点，用Web还是不错的。

2、跟JS交互搞死人，这个Alberl没有去做过，但是听朋友以及网上的大牛说，绝对可以搞死人。 不过有现成的框架在，这个也不用太担心啦。 但是如果没有验证好就贸然去用，后面如果实现不了某些功能，那就悲剧了。  所以推荐先验证一下某些重点功能能否实现，再做选择。

3、速度很慢。 这个倒可以忽略了，因为现有框架已经解决了这个问题。

    其中WebQQ也可以说是Web界面的顶峰了，上面有一整套QQ的产品，比如QQ客户端、QQ音乐、QQ飞车等一系列产品，整个WebQQ简直就是一个OS。但是光看WebQQ的桌面背景还好，如果一打开QQ客户端，或者QQ音乐、QQ飞车，那肯定会让你失望的。其实失望的不是界面效果，而是比较，因为界面效果确实很炫，比起很多客户端都好，但如果和PC上的QQ音乐、QQ飞车比起来，那真是失望了。所以Web界面的效果真的不是那么NB。

 

 

    好啦，三种做客户端的界面方法都介绍啦，第一种方法最好，但没有知名的框架；第二种其次，并且有一些框架，但离知名才差得远；  第3种最差，但已经有很多知名的开源库啦。后面的教程会一一介绍。虽然这三种方法看起来都比上一个教程中的7个框架方便，但实际上还有很多需要完善的地方。

    不得不说的是，其中WebQQ可以说是Web界面的顶峰，而QQ概念版可以说是.NET的顶峰，而QQ正式版是VC++的顶峰。所以QQ已经花了巨大财力、人力、时间去研究了几乎所有方式的界面，重要的是都付诸行动，并且达到了顶峰，TX真的很强大！ 

    所以Alberl在这里做一个总结：

1、你能想到的，别人已经做了；你能做的，别人已经做到顶峰了；你醒悟时，别人早就成功了。

2、没有大牛无私奉献，任何方式都是扯淡。

3、如果不是专业人士，就不要重复造轮子了，看看巨头们都干了啥！

 

    而Alberl不是大牛，所以无法去做一套框架；也不是专业人士，所以无法去利用现有成果重复造轮子；Alberl只是个小小菜鸟，什么好用就用什么，就算没有满意的，也只能选一个不满意的框架啦。下一个教程将介绍Alberl怎么在不满意的框架中选一个满意的~O(∩_∩)O~

 

 

来自为知笔记(Wiz)