WPF vNext 以及 NuGet

阅读数:909 2015 年 4 月 28 日

话题:语言 & 开发

在进行 WPF 开发过程中,一个常见的限制因素在于,WPF 本身实际上就是一个核心组件。由于它总是和.NET 框架一同发布,并且也经常伴随着操作系统一同发布,因此在兼容性方面的需求相当之高。当然,对于如此大型的框架来说,完美的向后兼容是不可能实现的。但其中出现的例如支持新版本的 DirectX 这样的改动确实存在风险,让人判断它的潜在破坏性。

在 WPF vNext 中,微软计划通过 NuGet 提供一种“应用本地化”的 WPF 版本。这一点其实与 ASP.NET MVC 的分布计划本质上完全相同。新版本中的关键特性包括以下内容:

  • 每个应用程序都能与其相应的 WPF 版本一同发布
  • 性能特性与现有版本相近,并且通常来说表现更好
  • 基于桌面版的.NET 框架进行开发,而不是基于.NET Core 进行开发
  • 与现有的版本高度兼容

请注意,“高度兼容”并不意味着完美兼容。由于 WPF 应用本地化这一特性是可选的,因此微软认为在应对维护兼容性这一方面的问题时应该会轻松不少。

在新版本中诸多的“基本兼容”变更之中,其中一个例子是新的默认模板。在示例中,使用 WPF 4.5 所创建的一个非常简单的测试窗体总共包含了 281 个元素,而切换到 WPF vNext 程序集之后,在不产生任何可见的变动的前提下,这一数字降到了 230 个元素。

之所以能够实现这一效果,部分原因在于新的“内容延迟加载”特性,这一特性允许控件对其内容进行延迟加载。在某些情况下,其内容甚至可能永远不会被加载,比方说,在组合框控件(combo box)中被禁用的可视元素就永远不会显示。

早期的测试结果显示,在使用内置控件的情况下,应用的启动时间和内存占用在某些情况下能够得到 10% 的优化。而在应用程序代码中使用这一特性之后,可以预期能够得到更大的性能提升。在微软的内部学习资料中表示,应用程序启动时加载的元素,其中最多有高达 40% 的元素是永远不会真正显示的。

之所以没有在.NET 4.6 版本中的 WPF 中提供这个新的特性,是因为某些应用程序可能仍然依赖于可视化树的现有设计。但由于 WPF vNext 是通过 NuGet 提供的可选版本,因此如果某些应用可能会受到这一变更的影响,那么可以针对它进行专门的测试。

与 DirectX 的互操作性

目前还没有关于这方面内容的细节披露,但微软的宗旨是倾向于在 WPF 中“原生支持 DirectX 11 和 12”。我们期望在 Build 2015 大会上获得更多的信息。

现代风格与触摸

下一版本的 WPF 也计划支持 Windows 10 的风格与设计指南。同样,具体的细节要在 Build 大会上才知道。

开源

微软目前并没有开源 WPF 的计划,不过,他们认为 WPF 应用本地化是最终迈向代码开源的一个重要步骤。微软还不想把步子迈得太大,他们希望先在某个开放的环境中对 WPF 的开发进行实验,这也意味着,在每次发布主要版本时,微软与开发者们的互动将大大增加。

在第三篇文章中,我们将讨论 Visual Studio 2015 与 Blend 2015 中的 WPF 工具的使用情况。

查看英文原文:WPF vNext and NuGet