对于微软的开发者来说，每一场BUILD大会都值得期待。这一次也充满了惊喜，除了万众瞩目的WP8.1发布之外，还有一项会让开发者兴奋不已的新技术：.NETNATIVE。让我们仔细看看它是什么。[小九的学校致力于用平凡的语言描述非凡的技术。如需转载请注明出处：小九的学校。cnblogs.com/xfuture] .Net最初出现是因为Java让人们明白了在计算机发展的今天，语言生产力的重要性高于性能。所以微软推出了CLR和.Net。JIT（运行时编译）消耗性能但大大提高了吞吐量。但ObjectC也告诉大家，在平板电脑和智能手机的内存和存储空间有限的情况下，机器码编译性能是多么重要，而且还能省电。这也很重要，不是吗？微软W8的出现就是平板时代的出现，所以就有了开发时的产能和运行时的性能结合：.NETNATIVE。.NETNATIVE的目的是生产流水线生产的手工产品，开发简单，运行时精美。.NETNATIVE以前叫做ProjectN，可以将C#语言编译成机器码原生代码，从而可以像C++一样运行。其实这个更笼统。具体来说，微软在NATIVE中重写了.NETFramework，在框架中加入程序需要的元素，不使用其他元素，生成可以运行的机器码，最终在运行时实现本地机器码，无需动态编译，节省内存和空间。这里有一个误区。许多人认为.NETNATIVE将C#编译成C++，其实不然。C++编译器的后端接受IL作为输入并生成MDIL。.NETNATIVE解决了许多.NET问题。例如，.NET运行时计算会消耗更多的内存和开销。.NETNATIVE编译时，只有用到的部分会被静态链接，其他部分会被忽略。只引入了一部分框架，所以内存占用很小，功耗也很低，非常适合平板等内存比较小的设备。.Netnative也实现了云编译。开发人员提供.NET代码，而消费者安装可由他们自己的设备使用的机器代码。.Netnative解决了.NET版本管理的问题。这个东西在开发中是最常遇到的。.NET的低版本不支持，或者一些低版本的机器需要支持，所以我们的开发环境一直都是用.NET的低版本进行的。.netnative编译成机器码就没有这个问题。我个人认为这就是它的商业价值所在。据官网介绍，使用native编译的windowsstore程序，启动速度可提高60%，内存占用降低近20%。现在.netnative支持windowsstoreapps，暂时不支持其他一些.net桌面程序，WPF等。但我们可以期待未来全面支持的时代。个人觉得WPF比较难，毕竟用的是GPU。Android也有类似的，ART出现在4.4。希望有ART开发经验的前来学习对比。http://www.pcpop.com/doc/0/967/967006.shtml个人认为它出现的有点晚了，XP已经下架了。现在基本上是.net3.5及以上。让我们拭目以待。运行时截图：安装：首先需要update2。关于3G（大于2013）。安装好后。下面有一个链接可以安装.netnative。.netnativepreview支持windowsstore，所以构建一个windowsstore应用：然后右键windowsstore项目，点击启用.netnative，会弹出一个说明界面：然后点击Runstaticnativeanalysis，这个应用兼容.net本机代码生成将出现。位置在release文件夹下：#p#下面是不使用.netnative后release文件夹的大小：使用.netnative后。去掉.net原生网页文件夹后可以展开的文件大小：显然编译后还是小了很多。第一次来，可能对文件和一些deployment了解不够。如有错误，望指正！.随后将进行更详细的审查。希望大家继续关注，谢谢！如果您仍有疑问，此链接可能会消除您的疑虑：http://msdn.microsoft.com/en-us/vstudio/dn642499.aspx它是否支持F#或VB或我最喜欢的语言？此预览版仅支持C#代码，因为它是大多数商店应用程序使用的.NET语言。但随着我们扩大关注范围，毫无疑问我们将支持所有.NET语言。该产品仅与性能有关，还是它还允许生成为Win32/64本机编译并且不需要在目标计算机上安装.NETFramework的C#代码（例如）？没错：.NETNative不仅仅关乎性能，它关乎生产力和一致的设备体验。使用.NETNative，您可以使用托管语言编写代码并像往常一样上传MSIL包。但是，应用程序将作为完全独立的本地编译代码部署在最终用户设备上（当.NETNative进入生产环境时），并且不依赖于目标设备/计算机上的.NETFramework。如您所知，.NET应用程序范围很广。因此，我们还对完整的.NETFramework进行了大量投资（例如，我们刚刚发布了RyuJIT的CTP）。设计这个产品时考虑了哪些场景？我们考虑的选项是设备的应用程序商店应用程序——使开发人员能够保持.NET和MSIL的生产力优势并将MSIL包上传到应用程序商店，为最终用户提供与本机代码(C++)类似的性能（类似到WindowsPhone8，在云中编译）。.NETNative会取代.NETMicroFramework吗？C#/.NET是否会完全适用于小型设备？.NETNative当前的重点是Windows应用商店应用程序。MicroFramework由WindowsEmbedded团队交付，.NET团队与他们携手合作，为客户提供最好的服务。开发人员预览是否可用于创建WindowsPhone应用程序和库？您可以创建用于.NETNative的通用类库。在此预览中，只能使用.NETNative创建Windows应用商店应用程序。正在实施使用.NETNative开发WindowsPhone应用程序。该产品能否改善C#开发人员开发高度图形化应用程序和/或游戏的体验？能。.NETNative编译器与MicrosoftC++优化器共享一些基本代码。服务器/桌面应用程序是否会受益于.NETNative和/或云中的编译器？桌面应用程序是我们战略中非常重要的一部分。最初，我们的重点是Windows应用商店应用程序和.NETNative。从长远来看，我们将继续改进所有.NET应用程序的本地编译。如何链接？框架代码会被编译到应用程序中吗？这将如何影响包/二进制文件的大小？是的，框架代码将被编译到应用程序中。对于包大小，差异并不明显，因为大多数应用商店应用程序都有很多多媒体。因此，代码大小确实发生了变化；但是，只有应用程序使用的框架部分链接到应用程序中。最终结果是使用.NETNative编译的二进制文件将与使用NGEN的二进制文件在相同的大小范围内。我们仍将研究可以进一步缩小尺寸差异的策略。使用.NETNative编译比使用MSIL编译慢。为什么？常规应用程序开发使用VisualStudio中的标准MSIL/JIT开发体验。.NETNative编译器仅在将应用程序部署到设备时调用，并且在大部分开发过程完成后，重点将转移到优化应用程序上。在这一点上，编译时间与使用链接时代码生成优化的C++相当。P/Invoke有什么变化？它们会被优化为标准DLL调用吗？即使使用二进制的本机编译，我们也保留了托管代码类型安全（和垃圾回收）和完整的C#异常模型的优势。借助.NETNative，我们还极大地优化了互操作路径-因此，虽然P/Invoke未针对标准DLL调用进行优化，但执行GC同步和任何所需封送处理的开销最小。有什么限制？该产品是否支持开放泛型和反射？.NETNative将支持目标平台在投入生产时支持的所有功能。由于这是预览版，许多功能正在开发中，因此目前存在一些限制。话虽如此，此预览版支持开放泛型和反射（是的，甚至支持静态编译！）。在此预览版中，编译器具有内置启发式方法，可尝试找出运行时需要哪些通用实例化和元数据。因此，大量的应用程序有望直接运行，而不必简??化源代码以获得编译器的好处。这些应用程序是如何修补或提供服务的？该应用程序的服务模型继续保持不变。对于框架，.NET的最新模型是自动提供库更新。我们将继续探索各种选择；我们期待听到您的建议和意见。如果删除了一个从未使用过的方法，是否有某种方法可以指示使用了一个方法（或整个类），即使它从未被直接调用过？是的;在此预览版中，支持开发人员声明使用某个方法（或类型），即使它不是直接调用的（请参阅运行时指令文档）。下面是一些.netnative相关链接：http://social.msdn.microsoft.com/Forums/en-US/home?forum=dotnetnativehttp://msdn.microsoft.com/en-US/vstudio/dotnetnativehttp://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspxhttp://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native如果你喜欢请关注并推荐。感谢您访问小九的学校。原文链接：http://www.cnblogs.com/xfuture/p/3684762.html
