WPF程序启动缓慢排查分享

一、概要

场景是这样的，一个陌生的WPF应用程序跑在的win7操作系统上（有人可能会猜是win7的问题其实不然继续往下看）。运行的时候发现程序启动需要30秒，这种问题在生产环境中肯定是不被允许的。好了，大家对场景有了一个认识接下来看看如何排查这类问题。

二、详细内容

遇到这种问题我的第一反映是程序启动时有什么耗时操作，一个成熟的产品少则拥有几十万行的代码多则百万行这么多代码我们该如何在万军丛中精确的找到耗时的操作呢？

第一个阶段

这个时候使用VS自带的Profile功能跑一份报告看看究竟是哪里耗时（下面为示例，并不是真是项目源码运行跑出的数据）。

跑完报告之后看到程序最高的耗时也就500毫秒，所有的方法跑起来总共不超过7秒。那么问题来了，我满怀信心的觉着这样做非常快且专业具有说服力的报告居然没有查出任何异样。对于这份报告我产生了质疑是不是这个工具漏监测到了什么关键信息收手段，结果通过代码的手段给我会认为会耗时的函数打上了“耗时统计”就是一个方法执行需要用多长时间。结果出奇的一致Profile显示的内容并没有偏差。在实际工作中如果不能有理有据的说明问题，纯依靠经验盲估是站不住的只能继续查。

第二个阶段

遇到这种情况该如何做呢？这时候我想起了远程调试，远程调试打上断点一步一步调试这个不出意外肯定能够调试出来。（具体的调试准备工作大家百度一下远程调试关键字有很多教程这里我就不一步一步写了贴张图大家知道是什么就行）。

逐步调试完成之后发现结果并不乐观，因为在进调试的时候就花了30秒的时间。这个方法似乎没有奏效但是又有了新的收获，起码能感觉到很有可能不是代码的问题（这个地方其实还有一个类似的办法直接在客户机器上跑dnSpy反编译调试工具也可以这样可以在无法使用远程调试的情况下直接调试收集线索，不过这里我能用远程调试这个手段就没必要使用了）。

第三个阶段

这一步我就不准备使用任何工具来继续验证，直接使用“注释法”来排除这个问题。只需要将所有有问题的代码注释掉就能做实不是代码导致问题启动缓慢，结果不出所料注释了所有代码居然跑起来还是慢，这个时候是不是环境的问题呢？爬到客户的机器上一看是win7操作系统，第一反应居然用这么老的系统但是用户的喜好你没办法左右的，不可以埋怨环境这个因素的。

第四个阶段

在经过一系列方法去查找启动慢的问题上，有进展但不多。起码知道不是代码导致的慢，那么跟环境有关系。

这个时候查看关键信息如下：

• 操作系统版本
• 操作系统位数
• 电脑配置
• 应用程序编译的版本（x64、x86、AnyCPU）

这一步检查发现了最终的问题所在，程序编译的版本是x86版本跑在了只有4G内存的x64的操作系统上。这个时候就明确了，只需要编译两个版本都跑一边就能向领导交差了。结论就是x86的版本在没有处理的时候跑在x64的操作系统上会出现启动慢的现象（具体原理大家搜一下即可），将程序编译成x64的版本即可正常使用。

Ref

https://learn.microsoft.com/zh-cn/visualstudio/debugger/remote-debugging?view=vs-2022