c# - 在 UWP 中加速编译？

Question

我在 WPF 中工作了很长时间后正在研究 UWP，编译速度非常慢。

我明白为什么发布编译很慢(净本地编译)但是在调试中被禁用，但在 F5 和屏幕上显示的应用程序之间仍然需要很多时间，即使对于空白应用程序也是如此。

有什么方法可以加快速度(即使以运行时性能为代价)？当您习惯了 C# 时，它真的很难使用，它为您提供极快的编译时间并在每次小的更改后进行测试。

例如，只需右键单击并在一个非常简单的(4 页，每行 < 200 行 xaml，以及几乎 0 个 C#)上重新构建 uwp 项目，在没有项目引用的情况下调试(没有 .net native)几乎需要 20 秒。与此同时，一个更大的 WPF 应用程序(几十个窗口，成千上万行代码)需要几秒钟的时间，而且大部分时间是复制子项目!

根据建议，您可以在此处找到一个最小的下载示例:
https://www.dropbox.com/s/0h89qsz66erba3x/WPFUWPCompileSpeed.zip?dl=0

这只是一个带有空白 wpf 和空白 uwp 应用程序的解决方案。 WPF 的编译时间刚好超过 1 秒，UWP 的编译时间为 12 秒，在每种情况下都清理了解决方案，并右键单击并重建了我正在测试的单个项目。这是在调试中(没有 .net Native 编译)

Answer 1

我绝对同意 UWP 编译明显慢于 WPF。每当我达到大约 5-6 打 xaml 窗口或 View 时，我总是不得不分解我的 WPF 程序集，以便将增量编译时间保持在 10-20 秒。事情看起来，我的 UWP 程序集可能会增长到只有大约 2 或 3 打项目，然后它们才需要很长时间来编译。当您尝试进行迭代编码和调试时，任何编译时间超过 10 秒的程序集都是有问题的。

如果您还没有尝试过，这里有两个建议。首先要做的是转到构建选项卡，并始终记得取消选中“使用 .NET native 工具链编译”。这对于正常的调试/测试迭代来说毫无用处。

接下来要做的是使用 procmon 监控您的构建操作。这将显示可能特定于您的工作站的任何问题(如病毒扫描、其他可能干扰的应用程序)。

以下是我注意到与 WPF 相比会减慢 UWP 编译速度的因素:

许多编译过程(在构建输出窗口中查看它们):

> MarkupCompilePass1:
> XamlPreCompile:
> MarkupCompilePass2:
> 生成TargetFrameworkMonikerAttribute:
> 核心编译:
> CopyGeneratedXaml:
> 复制文件到输出目录:
> ComputeProcessXaml 文件:
> CustomOutputGroupForPackaging:
> 获取包装输出:
> _GenerateProjectPriConfigurationFiles:
> _GenerateProjectPriFileCore:

核心/Nuget 依赖项

与 .Net Framework 不同，UWP 的所有依赖项都来自 .Net core 和 nuget。您应该能够使用 procmon 并查看对 VS 保存内容的目录的大量读取:C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages。请注意，依赖项本身与 .Net 框架依赖项(在 WPF 中)的质量并不完全不同。但是在编译操作期间如何收集这些依赖项以及如何将它们推送到输出目录中(最终在最终的 Appx 目录中结束)存在很大差异。

没有用于优化的“共享输出目录”。

使用 WPF，我们可以发送类库目标 个人 到共享输出目录(通过检查它们的构建，同时 取消选中 其他库和应用程序 exe 本身)。然后我们可以启动调试器，而无需编译大量不一定会改变的东西。但是，UWP 要求我们构建入门级应用程序，无论我们是否尝试配置共享输出目录。

UWP 中需要新的“部署”步骤

WPF 没有每次构建 UWP 应用时都需要的新“部署”步骤。您将在构建配置中看到复选框，它适用于入门级应用程序。如果不部署，则在调试时将看不到所有更改。

UWP 仍在积极变化(与 WPF 不同)

他们不断改变 UWP 编译操作。很快，我们将开始看到称为“WinUI”库的东西，它将为 UWP 应用引入 NuGet 的另一个依赖项。在编译性能方面，这可能无济于事。

我认为一旦变化的步伐开始放缓，微软可能会决定专注于寻找提高编译性能的方法。在阅读 procmon 输出时，似乎很清楚 devenv.exe 完成的工作只有不到一半是专门为我完成的。它的其余部分是拉入所有依赖项，以便我的代码可以针对它进行编译。必须有一种方法来优化重复处理。