在威锋网看到一个谈wp应用效率的文章，特来求证
节选如下：
C#是便捷好用开发快速语法糖无数，但是对于WinRT来说C#有着严重的性能损耗及内存消耗，WP用户遇到正在恢复以及正在恢复后就闪退已经不少了，这其中C#语言的特性占据了很大因素，而性能上的问题也导致了WP系统除了自身APP外，第三方APP明显“不流畅”，这甚至都不需要举什么例子，就微软自己把原先使用C++开发的“音乐+视频”应用换成C#编写的单独维护的应用后，卡顿和启动速度以及稳定性都大大降低可以看出端倪。
微软为C++开发者做了一个不三不四的CX语法，而XAML明显难以很好的配合CX来开发一个完整的APP，所以WinRT平台几乎难以看到完整使用C++开发和维护的一整个APP，而CX奇怪的语法则让很多C++开发者望而却步，加上微软在C++开发者中一直都存在的不良口碑也让CX奇怪的语法和微软对CRT的删减贯彻落实到了极致，这样则难以吸引Linux平台下的丰富传统C++开发者，在WinRT发布很多年后依然有无数开源库没考虑移植，VLC勉强移植了却效果极差，都可以看出一些端倪，难道是人家的开源组件有问题？不见得吧。
这是真的吗。。求问各位程序员大大
为防止不可控的内容风险，本站已关闭新用户注册，新贴的发表及评论；
你现在看到的内容只是互联网用户曾经发表的言论快照，仅用于老用户留存纪念，且仅与科技行业相关，全部内容不代表本站观点及立场；
本站重新开放前已针对包括用户隐私、版权保护、信息安全、国家政策在内的各种互联网法律法规要求，执行了隐患内容的自查、屏蔽和删除；
本站目前所属个人主体，未有任何盈利安排与计划，且与原WFUN.COM所属公司不存在任何关联关系；
如果本帖内容或者相关资源侵犯到您的合法权益，或者您认为存在问题，那么请您务必点此举报或投诉！
Quote***链接停止解析***
而全新的WinRT API特性，诸如完全异步等，让很多老的原生Win32程序员难以适应，以及微软没来由的就强制废止 ...
楼主发的那段待开发者来回答，你发的这段主观性太强，站不同角度有不同看法，而且还是针对一个未发布的项目。
本帖最后由 slice 于 2015-5-25 18:17 编辑
之前测试的.net native是基于.net 框架来静态编译，体积会比较大。
而目前随着开源的.net Core开始完善，微软已经把.net Core+.net native的静态编译成为默认选项。
意思就是VS2015新建的C#商店应用，默认就是.net native静态编译的了。
C#开发的程序会有普遍的性能提升，单就算如此也不过是接近C++的效率。
***链接停止解析***
这几天在测试我们的自己的APP，C#+XAML，通用架构APPX。
930启动速度1秒左右。
没有正在恢复。
正在加载视网络条件而定。‘
其实卡不卡，还得看应用本身的优化。
Quote***链接停止解析***
之前测试的.net native是基于.net 框架来静态编译，体积会比较大。
而目前随着开源的.net Core开始完善，微 ...
谢谢解释，虽然一知半解不太明白，看来vs2015对其还是有提升了。
Quote***链接停止解析***
这几天在测试我们的自己的APP，C#+XAML，通用架构APPX。
930启动速度1秒左右。
没有正在恢复。
期待新的App，这么说来未来的设备运行起来一定没问题
Quote说不好听的，如果没有诸如Unity这样的跨平台游戏引擎，WP甚至连游戏机都当不起。
可这不是有么，跨平台也不是说谁想跨就跨的。
在黑微软的开发环境时，不想想，Unity要想跨到WP平台上，首先也得微软提供相关的底层支持不是？
嗯，这几年，微软在操作系统上的变化太激进，无论是对用户还是对开发者，都让各种群体跟不上变化。
呵呵，智机网的讨论区改名，甚至改域名等等也是拜微软所赐。。
还是那样，微软继续他的变化，直到被接受。。
我只说，MS一直不支持标准C++开发，我一天不会对C#有好感，对WP开发有好感，特别在我学了点SL，还未学完再学WPF再转WINRT时的怒火，除了XAML有点共通外，API都不同了，现在好了，通用应用了，以前至少还有英文文档，现在连个英文文档都不齐了，别说啥还未正式发布，如果开发者不能先学，用户还能优先体验到？效率呀，这公司就是没有效率。
Quotewind 发表于 2015-5-25 18:31
这几天在测试我们的自己的APP，C#+XAML，通用架构APPX。
930启动速度1秒左右。
没有正在恢复。
6666666 不来发内测？
根本就不是语言的事。真论语言C#效率比java要高那么一点，毕竟java所有方法都是虚的。就语言本身而言C#早已超过java了。wp8.1之前的应用基于silverlight框架，这是个.Net下跨平台的一个框架，跨平台必然会有损失。.Net调用托管函数非常蛋疼，在移动平台上表现不佳。所以现在微软把非托管API封装成了一套类库，叫Windows Run Time，也就是WinRT了，appx格式的通用应用都是基于WinRT开发的。这个是纯本机实现，用C++编写效率肯定是最高的，因为不存在托管到非托管这一层。其次是C#，但效率不会差多少。至于安卓，效率跟WinRT根本没得比，纯笑话。还有威峰网的文章别当回事，毕竟在他们眼里A7秒I7，IPad是电脑。
c++好是好，但是如果没有C#，WP平台更没人了。。。。。。
C#语言效率不算差，至少比java好
做出的APP卡不卡，完全看程序架构
我现在的项目，源代码一水的静态全局变量，载入内存吓死人
然而甲方电脑牛，不在乎
Quote***链接停止解析***
根本就不是语言的事。真论语言C#效率比java要高那么一点，毕竟java所有方法都是虚的。就语言本身而言C#早已 ...
我在威风上可没见到过A7秒I7的 在这里到时见到了 。这边的人都把C#秒OC这话说的飞起。IPAD是电脑这话确实有不少人说，不过我现买了RT 然后买的IPAD 就个人认为 IPAD确实比 WIN RT更像平板电脑，WIN RT奇怪的操作逻辑让我用了不到十个小时就受不了了。
Quoteslice 发表于 2015-5-25 18:16
之前测试的.net native是基于.net 框架来静态编译，体积会比较大。
而目前随着开源的.net Core开始完善，微 ...
那为什么C++的效率高不干脆直接支持C++呢？
Quotenimoly 发表于 2015-5-25 21:36
我在威风上可没见到过A7秒I7的 在这里到时见到了 。这边的人都把C#秒OC这话说的飞起。IPAD是电脑这话确实 ...
这倒是大实话，微粉数量或许不及果粉，但极端言论却不见得少。作为娱乐平板，winrt的表现就是个笑话，至于工作方面还是放过平板吧，超极本也是可以有
关于平板，我觉得不能说架构是x86就不是平板了，x86的安卓怎么算？
现在的8寸10寸寨板，面对的就是各种同门的安卓板和iPad，你不能非要人家和MacBook比吧。
Quote***链接停止解析***
威锋网是果粉开的你又不是不知道…就像在XX之家喷WP就会被围攻一样…
我也这么想过，不过看到这个说得这么专业所以我就来求证其真实性了
Quote***链接停止解析***
我只说，MS一直不支持标准C++开发，我一天不会对C#有好感，对WP开发有好感，特别在我学了点SL，还未学完再 ...
听说是win8.1的相关开发没有准备完全，到win10就完备了？
Quotenimoly 发表于 2015-5-25 21:36
我在威风上可没见到过A7秒I7的 在这里到时见到了 。这边的人都把C#秒OC这话说的飞起。IPAD是电脑这话确实 ...
最后这句话你真不该说。
Quote***链接停止解析***
= =威锋可真是越来越高级黑了，普通用户都快信以为真了
其实想证明这事也简单，Unity3D这东西就是用C#的，为什么人家跑个游戏效率都跟得上，用C#写个应用，反倒就跟不上了呢？一般来说游戏更要求运行效率吧？
而且这篇文章其实也是转来的，原出处也不是威锋，不明真相的群众，哪都多得是。
Quote***链接停止解析***
其实想证明这事也简单，Unity3D这东西就是用C#的，为什么人家跑个游戏效率都跟得上，用C#写个应用，反倒 ...
原来如此，多谢解答
本帖最后由 rjohnny 于 2015-5-27 12:15 编辑
至于这文章小编说的大家笑笑就好了，关于WinRT APIs知乎上有详细的解答，内容也是暗影吉他手点赞的。我转过来给大家看看！
***附件停止解析***
总结起来就是，在针对ARM适配的Windows RT系统中，底层并没有使用.Net Framework，而是和x86架构的Windows一样，只是在Kernel层面对ARM指令进行了支持。在Kernel之上的不管是Windows APIs、Windows Runtime APIs还是.Net Framework，除了少部分实现可能需要做针对ARM指令的特殊处理，其它该是什么样就是什么样。至于更顶层的一般应用，在大部分时候甚至感知不到底层到底用了x86还是ARM架构的芯片。
在Windows中，基于ARM的Windows底层也是使用的Windows NT Kernel，只不过在一些硬件抽象层面以及驱动上编译成针对ARM平台的指令。
在Windows NT Kernel之上有一层完整的Win32 APIs，Win32 APIs关注的都是系统层面的接口，因此你不需要过多地关心Win32 API背后它是使用x86架构执行还是ARM架构执行。
在Windows 8中添加的Windows Runtime APIs是在Win32 APIs之上的一层实现（如果要细分的话中间应该还有一层COM APIs）。在Windows 8中，Windows Runtime APIs就已经非常庞大，但是其中相当一部分都是只定义了方法却没有实现（之前在听一名台湾的TechED讲师介绍的时候说是时间来不及所以在实现上做了取舍。由此可见巨硬这种不让程序员加班的公司是多么腐朽落没，必将被我大天朝BAT取代），不过在Windows 8.1中已经好了非常多。
在Windows Phone 8.0中，底层同Windows一样，都是在最底层的Kernel部分对ARM进行了改写和优化。在Kernel之上的Win32 APIs中，同Windows平台应该没有太大区别，***链接停止解析*** 提到有部分的接口被移除了。这个我没有确认过，不过可能性应该还是比较高的，毕竟手机的性能和存储摆在那里，一些必要的删减是必须的。
Windows Phone 8.0中Windows Phone Silverlight框架是一个简化的.Net Framework实现，在底层实现上同一般版本的.Net Framework一样，都是依赖Win32 APIs。在Windows Phone 8.1中，Universal App框架的引入实际上是微软将Windows 8中的Windows Runtime APIs迁移到了Windows Phone中，以期能够实现统一的开发环境，而这部分的框架同Windows一样，建立在Win32 APIs之上的。
简单说就是RT的APIs跟win32的是一模一样。
区别是完整的Win32（针对Windows RT而言）大部分完整的Win32，去除ANSI和GDI支持（针对Windows Phone而言）