Question

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

我了解为什么发行版编译速度较慢（网络本机编译），但是在调试中禁用了该功能，但F5和屏幕上显示的应用程序之间仍然需要花费很多时间，即使对于空白应用程序也是如此。

是否有任何方法可以加快速度（甚至以运行时性能为代价）？当您习惯使用C＃时，要给您非常快的编译时间和每次小的更改后进行测试，这真的很难工作。

例如，只需右键单击并在非常简单的页面上重建（4页，每行<200行xaml，几乎包含0 C＃）uwp项目几乎需要20秒的调试时间（没有.net native），而没有项目参考。同时，更大的WPF应用程序（数十个窗口，几行代码）需要几秒钟的时间，而大部分时间是在复制子项目！

根据建议，您可以在此处找到一个最小的示例下载： https://cloud.google.com/container-registry/docs/access-control#granting_users_and_other_projects_access_to_a_registry

这只是空白wpf和空白uwp应用程序的解决方案。 WPF的编译时间仅超过1秒，UWP的编译时间仅为12秒，在每种情况下，解决方案均已清洗，右键单击并重建我正在测试的单个项目。这是在调试中（没有.net本机编译）

Answer 1

我绝对同意，UWP编译比WPF慢得多。每当我到达5-6打xaml窗口或视图时，我总是不得不拆开WPF程序集，以使增量编译时间减少到10-20秒。从外观上看，我的UWP程序集可能会增长到大约2到3打项目，然后才花费太长时间进行编译。尝试进行迭代编码和调试时，任何花费10秒钟以上的程序集都会出现问题。

如果您没有尝试过，这里有两个建议。要做的第一件事是转到“构建”选项卡，并始终记得取消选中“使用.NET本机工具链进行编译”。对于正常的调试/测试迭代而言，这是毫无用处的。

接下来要做的是使用procmon监视您的构建操作。这将浮出水面，特别是您的工作站可能遇到的任何问题（例如病毒扫描，可能会干扰的其他应用程序）。

与WPF相比，以下是我注意到会降低UWP编译速度的因素：

许多编译通过（在构建输出窗口中查看）：


> MarkupCompilePass1:
> XamlPreCompile:
> MarkupCompilePass2:
> GenerateTargetFrameworkMonikerAttribute:
> CoreCompile:
> CopyGeneratedXaml:
> CopyFilesToOutputDirectory:
> ComputeProcessXamlFiles:
> CustomOutputGroupForPackaging:
> GetPackagingOutputs:
> _GenerateProjectPriConfigurationFiles:
> _GenerateProjectPriFileCore:

核心/ Nuget依赖项

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

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

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

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

UWP仍在积极变化（与WPF不同）

他们不断更改UWP编译操作。很快，我们将开始看到一个名为“ WinUI”的库，它将引入来自NuGet的UWP应用程序的另一个依赖项。就编译性能而言，这可能无济于事。

我认为，一旦变化的步伐开始放缓，Microsoft可能会决定专注于寻找提高编译性能的方法。读取procmon输出时，似乎很清楚，尤其是devenv.exe完成的工作不到我的一半。剩下的就是引入所有依赖关系，以便我的代码可以针对它进行编译。必须有一种优化重复处理的方法。

Answer 2

一个空项目的编译时间（十二秒？）似乎有点高。我的程序通常运行五秒钟（空时）。

您可能想看看CPU发生了什么。单个项目的编译应完全由CPU约束，尤其是在文件系统缓存了源代码（并下载了所有nuget依赖项）之后，尤其是在第二次或第三次尝试时。您可能需要关注任务管理器，并确保在单核上全速运行（例如，如果有四个核，则为25％；对于八个核，则为12％，等等）。如果您看到CPU下降太多，则说明出现了问题。另外，请确保检查您所期望的常规对象（例如devenv.exe，VBCSCompiler.exe和MSBuild.exe）正在使用仅 CPU。

对于那些声称自己编译UWP项目的速度比其他人快得多的人来说，听听他们对Windows社区工具包的基准测试可能会很有趣。（https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/rel/5.0.0）最有趣的编译时间是针对xaml最为繁重的项目。这是我的时间：

Microsoft.Toolkit.Uwp.UI.Controls 10秒
8秒Microsoft.Toolkit.Uwp.UI.Controls.Graph
8秒Microsoft.Toolkit.Uwp.UI.Controls.DataGrid

基本的Van Arsdel库存应用是要进行基准测试的另一件事。 https://github.com/Microsoft/InventorySample这是我的结果：

Inventory.App为14秒

VanArsdel示例应用程序将是另一个不错的基准。（请注意这一点；您可能必须使用Windows内部人员构建，这可能会像弄到我的VS那样弄乱您的VS）。网址在这里：https://github.com/microsoft/vanarsdel这是我的结果：

VanArsdel项目需要13秒

请记住，以 xaml为导向的项目通常也是最慢的，因为它们在各种编译过程中涉及更多的处理工作。

使用诊断输出

尽管构建项目所花费的总时间至关重要，但了解时间从何而来也可能会有所帮助。如果转到“工具”->“选项”->“构建并运行”，然后将项目构建输出的详细程度调高为“诊断”，则可以获取摘要。然后编译有问题的项目。最后，您将看到一个任务绩效摘要，如下所示。请注意，CompileXaml应该花费最多的时间。这五个项目似乎很常见。

任务绩效摘要：

  100 ms  ValidateAppxManifest                       1 calls
  400 ms  ExpandPriContent                           1 calls
  400 ms  Csc                                        2 calls
  600 ms  ResolveAssemblyReference                   1 calls
 7000 ms  CompileXaml                                2 calls

如果每次编译时您看到其他内容（例如，GenerateAppxManifest）占用几秒钟，则可能是项目内的损坏问题。您应该能够通过搜索单词“完全”来进行故障排除，如“完全构建目标_GenerateCurrentProjectAppxManifest”中所述。当您找到它时，它应该告诉您为什么要进行额外的工作。

最低版本定位

我注意到在“定位”选项卡上更改最低版本将使我的“ CompileXaml”时间减少三秒钟。

请参见下文，将最低版本更改为15063有助于减少编译时间。我怀疑这与相关依赖项中的膨胀有关。

15063 (creators update) [4 seconds]
16299 (fall creators) [7 seconds]
17134 (version 1803) [ 7.5 seconds]

并非总是可以选择针对创建者更新的选项，因此这可能不是通用修复程序。但是，了解获得更新的Windows 10 SDK的影响很有趣。

在UWP中加速编译？

2 个答案: