wpf - 是什么使WPF应用程序启动缓慢？

Question

我注意到WPF应用程序的启动有时会很慢。有人知道原因是元素初始化或DLL加载还是其他原因？

Answer 1

下面的文本是从this MSDN article on Improving WPF applications startup time中提取的（编辑：现在已合并到WPF Application Startup Time中）

应用启动时间

WPF应用程序启动所需的时间可能会有很大的不同。本主题描述了各种用于减少Windows Presentation Foundation（WPF）应用程序的感知启动时间和实际启动时间的技术。

了解冷启动和热启动

当系统重新启动后首次启动应用程序时，或者启动应用程序后，关闭它，然后在很长一段时间后再次启动它，就会发生冷启动。应用程序启动时，如果Windows内存管理器的备用列表中没有所需的页面（代码，静态数据，注册表等），则会发生页面错误。将页面带入内存需要磁盘访问权限。

当主要公共语言运行时（CLR）组件的大多数页面已经加载到内存中时，就会发生热启动，从而节省了昂贵的磁盘访问时间。这就是为什么托管应用程序第二次运行时启动速度更快的原因。

实施启动画面

如果启动应用程序和显示第一个UI之间存在明显的，不可避免的延迟，请使用启动屏幕优化感知的启动时间。这种方法几乎在用户启动应用程序后立即显示图像。当应用程序准备显示其第一个UI时，初始屏幕消失。从.NET Framework 3.5 SP1开始，可以使用SplashScreen类实现启动屏幕。有关更多信息，请参见How to: Add a Splash Screen to a WPF Application。

您还可以通过使用本机Win32图形来实现自己的启动屏幕。在调用Run方法之前显示您的实现。

分析启动代码

确定缓慢的冷启动原因。磁盘I / O可能负责，但并非总是如此。通常，您应尽量减少使用外部资源，例如网络，Web服务或磁盘。

在测试之前，请确认没有其他正在运行的应用程序或服务使用托管代码或WPF代码。

重新启动后立即启动WPF应用程序，并确定显示所需的时间。如果应用程序的所有后续启动（热启动）都快得多，则您的冷启动问题很可能是由I / O引起的。

如果您的应用程序的冷启动问题与I / O不相关，则您的应用程序可能会执行一些冗长的初始化或计算，等待某个事件完成或在启动时进行大量JIT编译。以下各节将更详细地介绍其中一些情况。

优化模块加载

使用诸如Process Explorer（Procexp.exe）和Tlist.exe之类的工具来确定应用程序加载哪些模块。命令Tlist 显示进程加载的所有模块。

例如，如果您没有连接到Web，并且看到System.Web.dll已加载，则您的应用程序中有一个引用该程序集的模块。检查以确保参考是必要的。

如果您的应用程序具有多个模块，请将它们合并为一个模块。这种方法需要较少的CLR组件加载开销。更少的装配也意味着CLR保持更少的状态。

延迟初始化操作

考虑将初始化代码推迟到呈现主应用程序窗口之后。

请注意，初始化可能在类构造函数内部执行，并且如果初始化代码引用了其他类，则可能会导致级联效果，在该效果中执行许多类构造函数。

避免应用程序配置

考虑避免应用程序配置。例如，如果应用程序具有简单的配置要求并且具有严格的启动时间目标，则注册表项或简单的INI文件可能是更快的启动方式。

利用GAC

如果在全局程序集缓存（GAC）中未安装程序集，则由于强名称程序集的哈希验证和Ngen映像验证（如果计算机上有该程序集的本地映像）而导致延迟。对于GAC中安装的所有程序集，将跳过强名称验证。有关更多信息，请参见 Gacutil.exe (Global Assembly Cache Tool)。

使用Ngen.exe

考虑在您的应用程序上使用本机映像生成器（Ngen.exe）。使用Ngen.exe意味着要用CPU消耗来换取更多的磁盘访问权限，因为Ngen.exe生成的本机映像可能比MSIL映像大。

为了缩短预启动时间，您应该始终在应用程序上使用Ngen.exe，因为这样可以避免JIT编译应用程序代码的CPU成本。

在某些冷启动方案中，使用Ngen.exe也可能会有所帮助。这是因为不必加载JIT编译器（mscorjit.dll）。

同时拥有Ngen和JIT模块的效果可能最差。这是因为必须加载mscorjit.dll，并且当JIT编译器处理您的代码时，当JIT编译器读取程序集的元数据时，必须访问Ngen映像中的许多页面。

Ngen和ClickOnce

您计划部署应用程序的方式也会影响加载时间。 ClickOnce应用程序部署不支持Ngen。如果决定对应用程序使用Ngen.exe，则必须使用其他部署机制，例如Windows Installer。

有关更多信息，请参见 Ngen.exe (Native Image Generator)。

变基和DLL地址冲突

如果您使用Ngen.exe，请注意当本机映像加载到内存中时，可能会发生重新基准化。如果由于已经分配了该地址范围而未在其首选基地址处加载DLL，则Windows加载程序将在另一个地址处加载DLL，这可能是一项耗时的操作。

您可以使用虚拟地址转储（Vadump.exe）工具来检查是否存在所有页面都是私有的模块。在这种情况下，该模块可能已被重新定位到其他地址。因此，其页面无法共享。

有关如何设置基址的更多信息，请参见 Ngen.exe (Native Image Generator)。

优化Authenticode

Authenticode验证会增加启动时间。 Authenticode签名的程序集必须通过证书颁发机构（CA）进行验证。此验证可能很耗时，因为它可能需要多次连接到网络才能下载当前的证书吊销列表。它还可以确保在通往受信任根目录的路径上有完整的有效证书链。加载装配件时，这可能会延迟几秒钟。

考虑在客户端计算机上安装CA证书，或者尽可能避免使用Authenticode。如果您知道自己的应用程序不需要发行者的证据，则不必支付签名验证的费用。

从.NET Framework 3.5开始，有一个配置选项允许绕过Authenticode验证。为此，请将以下设置添加到app.exe.config文件：

<configuration>
 <runtime>
    <generatePublisherEvidence enabled="false"/>
  </runtime>
</configuration>

比较Windows Vista上的性能

Windows Vista中的内存管理器具有一项称为SuperFetch的技术。 SuperFetch会分析一段时间内的内存使用模式，以确定特定用户的最佳内存内容。它持续工作以始终保持该内容。

此方法与Windows XP中使用的预取技术不同，后者在不分析使用模式的情况下将数据预加载到内存中。随着时间的流逝，如果用户在Windows Vista上频繁使用WPF应用程序，则应用程序的冷启动时间可能会缩短。

有效使用AppDomain

如果可能，将程序集加载到与域无关的代码区域中，以确保在应用程序中创建的所有AppDomain中都使用本机映像（如果存在）。

为了获得最佳性能，请通过减少跨域调用来强制进行有效的跨域通信。如果可能，请使用不带参数或带原始类型参数的调用。

使用NeutralResourcesLanguage属性

使用 NeutralResourcesLanguageAttribute指定 ResourceManager的中性文化。此方法避免了不成功的程序集查找。

使用BinaryFormatter类进行序列化

如果必须使用序列化，请使用 BinaryFormatter类而不是 XmlSerializer类。 BinaryFormatter类在mscorlib.dll程序集的基类库（BCL）中实现。 XmlSerializer在System.Xml.dll程序集中实现，这可能是要加载的其他DLL。

如果必须使用 XmlSerializer类，则如果预先生成序列化程序集，则可以获得更好的性能。

配置ClickOnce在启动后检查更新

如果您的应用程序使用ClickOnce，请通过配置ClickOnce在应用程序启动后检查部署站点的更新来避免启动时的网络访问。

如果您使用XAML浏览器应用程序（XBAP）模型，请记住，即使XBAP已经在ClickOnce缓存中，ClickOnce也会检查部署站点是否有更新。有关更多信息，请参见 ClickOnce Security and Deployment。

配置PresentationFontCache服务以自动启动

重新启动后运行的第一个WPF应用程序是PresentationFontCache服务。该服务缓存系统字体，改善字体访问，并提高整体性能。启动服务会产生开销，在某些受控环境中，请考虑将服务配置为在系统重新引导时自动启动。

以编程方式设置数据绑定

与其使用XAML为主窗口声明性地设置 DataContext，不如考虑以编程方式在 OnActivated方法中进行设置。