.NET本机编译器和运行时在Visual Studio 2015 Update 2的新功能

  • [アーティクル]

[原文发表地址]: What’s new for the .NET Native Compiler and Runtime in Visual Studio 2015 Update 2

[原文发表时间]: April 18, 2016

 

上周我们发布了一个Windows通用应用程序（UWA）的Visual Studio2015工具的更新包，其中包括对整个库、运行环境和编译器的优化。这意味着开发将更快速，应用程序将更快响应和更易维护。应用程序如NCAA March Madness Live和Tuneln电台已经通过我们的新.NET工具在应用商店上线了。

 

获取Windows平台通用工具

针对Windows通用应用程序的最新版Visual Studio2015工具包，作为Visual Studio 2015 Update 2的一部分已于近期发布了。通过直接安装Visual Studio 2015 Update2或者选择修改已经安装的更新来安装这个更新包。当弹出您要安装的功能列表时，确认已经选择了通用Windows应用程序开发工具下的工具（ 1.3.1）和Windows10 SDK（10.0.10586） 。一旦Windows通用应用程序Visual Studio2015工具包安装后，现有的项目在重新编译后，将使用最新的编译器和运行环境。

 

更改Visual Studio 2015 Update2

修改Visual Studio 2015 Update 2，并安装最新的UWA工具包时，可以按照以下步骤：

  • 通过控制面板\程序\程序和功能,打开Visual Studio2015的安装程序。
  • 选择修改。
  • 确保位于通用Windows程序开发工具部分的工具（1.3.1）和Windows 10 SDK（10.0.10586）已经被选中。

        01

  • 选择下一步，并且确认选择的功能是正确的。
  • 选择更新。

 

更新 .NET核心库：

.NET核心库分布在NuGet.org的NuGet包中，下面介绍如何获取最新的.NET核心包。

  • 通过工具\NuGet包管理器\管理解决方案的NuGet程序包 找到NuGet管理器
  • 选择更新选项卡
  • 选择左侧的Microsoft .NETCore UniversalWindowsPlatform的NuGet包（.NET核心的UWP元数据包），检查将要升级的项目
  • 确保列表中的版本为最新的稳定版本5.1.0
  • 选择安装

02

 

.NET本机编译器和运行时的新功能

 

更好的反射支持 — 通用共享泛型

.NET应用程序大量使用反射，无论是直接使用还是作为使用库的一部分。在越来越多应用程序中，反射是“开箱即用”的。我们跟你们一样喜欢用反射，并且希望你们享受在.NET中使用它的乐趣。

反射使你能够在后期绑定的方式当中审查或者实例化类型 (比如不使用new)。 这个在低耦合架构或者动态的场景中非常有用。当编译本机代码时，动态是一种挑战，因为所有的代码必须是已知的并且在编译时编译。在运行时一个动态场景是使用新的泛型类型。

我们称List<T>为开放类型是由于它需要定义T。我们称List<MyValueType>为封闭类型是由于T已经被定义了。在程序内，我们称这些封闭泛型实例化。List<MyValueType>可以被看作第三种类型，既不是List<T>，也不是MyValueType， 而是泛型实例化的组合。

泛型是一种组合形态（成员）和行为（方法主体）。这个形态和行为会被编译到本机代码。本机代码对于List<MyValueType>和List<MyReferenceType>是不同的。这就意味着.NET 本机编译器必须查找所有的泛型实例以便于代码在运行时能够执行每个泛型。强大的反射API表达式使得通过静态分析查找所有泛型实例十分困难。特别是有代码调用Type.MakeGenericType 和 MethodInfo.MakeGenericMethod方法时就更复杂。

这个挑战导致我们本机编译泛型采用新路径。我们的结论是我们需要一个更通用的方式在运行时编译泛型。我们称这个新功能叫通用共享泛型（USG）。大多数泛型是高度优化的代码。现在，在特定类型代码没有生成的情况下，就会有一个可用的USG 版本了。

 

用HockeyApp更好的跟踪堆栈

通过这次更新和HockeyApp， 你现在可以从他们产品的应用程序当中获得高仿真，可操作的堆栈跟踪。我们已做的工作，以确保客户端集合更强大，并且HockeyApp后端会尽可能地生成可读性好的堆栈。该功能已经在build大会中公布而且先是可用的。 参照文档HockeyApp for UWP就可以简单快捷的使用该功能了。

 

更快的WinRT互操作

与WinRT互操作更快，在实验室中，我们目睹了相当于UWP 1.2工具8倍的速率。这个将是特别有用的，特别是对于那些有大量XAML元素的页面以及流处理场景的应用程序。

 

更快的本机代码

这个版本中包含许多和功能相关的代码质量的改进。涉及到的改进包括但不限于以下：

  • 改进的自动向量化
  • 减少枚举类型IEnumerable<T>集合的使用开销
  • 整个程序的内联分析
  • SharedFramework的按配置文件优化（PGO），这些功能有助于减少工作集和代码，也能更好的为.NET UWP应用程序生成高质量的代码

之前版本的.NET本机编译器使用了跟CLR JIT编译器相同的内联优化器。因为JIT编译器能够快速的生成代码，这使得本机能够决定哪些方法内联。预编译让. NET本机编译器在考虑到应用程序范围的同时，去评估内联决定。在1.3.1中这个已经完成，使用和高性能C++应用程序相同的程序内联引擎，在许多情况下提供重要改进。

通过给定应用程序在运行时会发生什么的信息，按配置文件优化功能允许编译器进行更好的生成代码决定。我们已经将PGO优化应用于共享库组件，使用的数据是收集自各种UWP应用程序中。我们很兴奋在未来版本的UWP工具中能够使这类优化功能通用。

共享和C++编译器相同的优化后端，使得.NET本机可以使用像开发高性能C++代码那样的先进的优化技术。 我们会继续说明这些集成所包含的功能。

 

开发时编译器的改进

许多内部的数据结构和.NET本机编译的算法现在更高效。大多数应用程序的编译器使用内存减少而且编译的时间也缩短了。对于应用程序的子集和库，改进体现在成功编译和长时间编译的差异。我们将继续优化和改进，以适应持续增长的UWP体系中类型和规模不多扩大的代码。

 

反馈

我们非常感谢您的反馈，因为它有助于指导我们的工作! 请继续发送问题或者建议到dotnetnative@microsoft.com。我们期待您的回信并希望您使用它去做出伟大的产品。

 

原文由微软的软件工程师Matthew Whilden和.Net项目经理Stacey Haffner 撰写