c++的性能, c#的产能？！鱼和熊掌可以兼得，.NET NATIVE初窥

　　对于微软开发者来说，每次BUILD大会都是值得期待的。这次也是惊喜满满，除了大众瞩目的WP8.1的发布还有一项会令开发者兴奋的技术出现：.NET NATIVE。下面就来详细了解一下其为何物。

[小九的学堂，致力于以平凡的语言描述不平凡的技术。如要转载，请注明来源：小九的学堂。cnblogs.com/xfuture]

　　

    .Net当初的出现是因为Java让人了解到计算机发展的今天，语言的产能重要性是高于性能的。于是微软便出了CLR和.Net。JIT（运行时编译）虽然消耗了性能，却大大增加了产能。但是ObjectC又告诉了大家在平板和智能手机内存和存储受限的情况下，机器码编译性能是多么重要，而且也省电，这也很重要不是吗。

微软W8出现是平板时代应运而生的，于是便出现了开发时的产能，运行时的性能的合体：.NET NATIVE。

　　.NET NATIVE目的是为了生产上的流水线产出的手工产品，易于开发，运行时精致。

.NET NATIVE之前被称为Project N, 它可以把C#语言编译成机器码native code，使之可以像C++一样运行。其实这样讲比较笼统，具体是在NATIVE里微软重写了.NET Framework，将程序所需要的framework里的元素加进去而其他的则不用，生成可以运行的机器码，最终实现运行时本地机器码，不用动态编译，节省了内存和空间。

　　这其中有个误区，很多人认为是.NET NATIVE把C#编译成了C++，其实并不是，C++编译器后端接受IL作为输入，生成MDIL。

　　.NET NATIVE解决了很多.NET的问题，比如.NET运行时计算，是消耗内存和开销更多电量，.NET NATIVE编译时只有用到的才会静态链接，其他部分就不要了，内存中放入的只有框架的一部分，所以内存占用很少，电量消耗也少，很适合平板等内存相比较小的设备。

　　.Net native也实现了云编译，开发者提供.NET代码，而消费者安装的是自己设备可以使用的机器码.

　　.Net native解决了.NET 版本管理的问题。开发中最常遇到这个东西.NET 低版本不支持，或者是要支持一些低版本机器，导致我们开发的环境一直是以低版本.net来进行的。.net native编译成机器码就不存在这种问题了。个人认为这个是其商业价值所在。

　　据官网，用native编译的windows商店程序, 启动速度加快60%,占用内存减少将近20%.

　　现在.net native支持windows store apps，暂时不支持其他的一些.net桌面程序，WPF等。但我们可以期待以后会出现全盘都支持的时代。私人认为WPF是难点，毕竟是用了GPU.

　　安卓也有类似的，4.4出现了ART。希望有ART开发经验的来一起研究进行对比。http://www.pcpop.com/doc/0/967/967006.shtml

　　个人认为出现的有点略晚，XP已经下架了。现在基本都是.net 3.5及以上了。还是以观后效吧。

运行时的截图

：

安装：首先需要update2.大概3G（比2013还要大）。安装OK后。安装.net native 下面有链接。

.net native preview支持windowsstore 所以建立一个windowsstore的app:

然后右键点击windowsstore项目，点击 enable .net native

会弹出一个说明界面：

之后点击Run static native analysis 会出现This application is compatible with .net native code generation。

位置在release folder下：

　　假如还有问题，这个链接也许会解决您的疑惑：

　　http://msdn.microsoft.com/zh-cn/vstudio/dn642499.aspx

是否支持 F# 或 VB 或我最喜欢的语言？

此预览版仅支持 C# 代码，因为它是大多数应用商店应用使用的 .NET 语言。但在我们拓宽工作重点之后，毫无疑问，我们会支持所有 .NET 语言。

此产品是仅与性能有关，还是也允许生成针对 Win32/64 本机编译并且不需要在目标计算机上安装 .NET Framework 的 C# 代码（举例来说）？

没错：.NET Native 不仅仅与性能有关，而且与工作效率和一致的设备体验有关。利用 .NET Native，您能够使用托管语言编写代码并且能够像往常一样上载 MSIL 包。但是，应用将作为完全自包含的本机编译代码部署在最终用户设备上（当 .NET Native 进入生产时），并且不依赖目标设备/计算机上的 .NET Framework。如您所知，.NET 应用程序的范围很广。因此，我们对完整的 .NET Framework 也进行了重大投入（例如，我们刚刚发布了  RyuJIT 的 CTP）。

设计此产品时考虑了哪些方案？

我们考虑过的方案是用于设备的应用商店应用 - 使开发人员能够保持 .NET 和 MSIL 的工作效率优势并且能够将 MSIL 包上载到应用商店，为最终用户提供性能类似的本机代码 (C++)（与 Windows Phone 8 类似，在云中进行编译）。

.NET Native 是否将取代 .NET Micro Framework 以及 C#/.NET 是否将完全可供小型设备使用？

.NET Native 当前的重点是 Windows 应用商店应用。Micro Framework 由 Windows Embedded 团队交付，.NET 团队与他们一起携手为客户提供最佳服务。

开发人员预览版是否适用于创建 Windows Phone 应用和库？

可以创建与 .NET Native 一起使用的通用类库。在此预览版中，仅 Windows 应用商店应用可使用 .NET Native 进行创建。正在实现使用 .NET Native 开发 Windows Phone 应用。

此产品能否提高 C# 开发人员开发高度图形化的应用和/或游戏的体验？

可以。.NET Native 编译器与 Microsoft C++ 优化器共享部分基本代码。

服务器/桌面应用是否将受益于 .NET Native 和/或云中的编译器？

桌面应用是我们策略中的非常重要的部分。最初，我们的重心是 Windows 应用商店应用与 .NET Native。从长远来看，我们将继续改进所有 .NET 应用程序的本机编译。

如何进行链接？框架代码是否将编译到应用程序中？这将如何影响包/二进制文件大小？

是的，框架代码将编译到应用程序中。对于包大小，由于大多数应用商店应用都有大量多媒体，因此差异不明显。 因此，代码大小确实会发生变化；但是，仅会将应用使用的框架部分链接到应用中。最终结果是，使用 .NET Native 编译的二进制文件将与执行 NGEN 的二进制文件处在相同的大小范围中。 我们仍将研究可进一步减少大小差异的策略。

使用 .NET Native 编译比使用 MSIL 编译慢。为什么？

常规应用开发使用 Visual Studio 中的标准 MSIL/JIT 开发体验。只有在将应用部署到设备才会调用 .NET Native 编译器，在大多数开发过程完成之后，重心将转移到应用的优化上。此时，编译时间与使用链接时间代码生成优化的 C++ 的差不多。

P/Invoke 有什么变化？是否会将它们优化为标准 DLL 调用？

即使对二进制文件进行本机编译，但我们保留了托管代码类型安全性（以及垃圾回收）和完整 C# 异常模型的好处。利用 .NET Native，我们还极大地优化了互操作路径 - 因此，尽管 P/Invoke 不会优化为标准 DLL 调用，但开销极低，以便执行 GC 同步和任何必需的封送。

有什么限制？此产品是否支持开放的泛型和反射？

.NET Native 将在进入生产时支持目标平台支持的所有功能。由于这是预览版，很多功能正在开发中，因此目前有一些限制。话虽如此，此预览版中支持开放的泛型和反射（是的，甚至支持静态编译！）。在此预览版中，编译器具有试图弄清运行时需要的泛型实例化和元数据的内置启发机制。因此，大量的应用有望直接运行，而不必简化源代码来获得编译器的好处。

如何修补这些应用或为这些应用提供服务？

应用的服务模式继续保持不变。对于框架，.NET 的最新模式是自动提供库更新。我们将继续探索选项；我们期待听到您的建议和意见。

如果删除了从未用过的方法，是否有某种方式表明某个方法（或整个类）已使用，即使从未直接调用过？

有；在此预览版中，支持开发人员声明某个方法（或类型）已使用，即使未直接调用（请查看运行时指令文档）。

　　下面附上一些.net native相关的链接：

　　http://social.msdn.microsoft.com/Forums/en-US/home?forum=dotnetnative

　　http://msdn.microsoft.com/en-US/vstudio/dotnetnative

　　http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx

　　http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

　　如果喜欢，请关注和推荐。谢谢光临小九的学堂。

http://www.cnblogs.com/xfuture/p/3684762.html