我有 Office 2007 VSTO 加载项,它使用功能区 XML,等等。重新启动后首次启动 Office 时,所需时间明显长于第二次启动时。加载项在安装期间使用 VSTO 包含列表注册为 vstolocal 并受信任。据我了解,这避免了将其安装到 ClickOnce 并验证发布者。
那么首次启动时间过长的可能原因是什么?你能给我一些想法吗?
我有 Office 2007 VSTO 加载项,它使用功能区 XML,等等。重新启动后首次启动 Office 时,所需时间明显长于第二次启动时。加载项在安装期间使用 VSTO 包含列表注册为 vstolocal 并受信任。据我了解,这避免了将其安装到 ClickOnce 并验证发布者。
那么首次启动时间过长的可能原因是什么?你能给我一些想法吗?
我们有带有 VSTO 加载项的 Word,第一次启动需要 20-30 秒,第二次启动需要 6-7 秒。这适用于 Word 2007、.NET 3.5 和 Windows XP。没有加载项的 Word 冷启动大约需要 5 秒,热启动需要 2-3 秒。在我们的冷启动测试中,Word 是启动后启动的第一个应用程序,也是第一次使用任何 .NET 代码。
和您一样,我们发现加载项中代码的执行时间对加载时间没有明显影响。使用 VSTO 意味着必须加载和初始化 .NET Framework 和 VSTO 运行时。速度下降完全取决于从磁盘加载的开销和 .NET/VSTO 初始化的某种组合。
当然,提出的第一个“解决方案”是在登录期间不可见地启动 Word,然后终止 Word 进程,以预热磁盘缓存。当然,这只是让机器在启动过程中多出 45 秒无响应(我猜是因为它增加了磁盘争用)。但是,哇,Word 在那之后启动得很快(只要它是在登录后不久启动的)。幸运的是,我们没有将此解决方案强加给我们的用户。
我们还编写了一个简单的 .NET 应用程序,它会简单地启动、加载一些与我们的 Word 加载项相同的依赖项并退出。它也将在登录期间进行安排。Word 启动确实需要几秒钟的时间并增加更多的登录时间,但是当一些用户甚至可能在他们的会议。更无意义的是,如果他们确实想使用 Word,并且他们在桌面响应后立即启动 Word,那么 Word 最终将与应该为其铺平道路的自定义应用程序竞争资源!
我们的情况很复杂,因为我们也有 Word 模板 (VBA) 加载项。这些也占了启动时间的很大一部分,因为它是需要初始化的第二个运行时,并且需要从磁盘的一些分散区域加载更多文件。从仅 Word 到仅包含 VSTO 加载项的 Word 或仅包含 VBA 加载项的 Word,再到包含 VBA 和 VSTO 加载项的 Word,冷启动时间呈非线性增加。也就是说,添加更多依赖项会增加总加载时间,然后是单个依赖项本身的加载时间。
我们还尝试了 COM shim 向导。使用 COM Shim 消除了 VSTO 运行时,但仍允许您在加载项中安全地使用 .NET。将我们的 VSTO 代码转换为与生成的 COM Shim 一起工作并不难。这大大提高了加载时间(我没有数据,我认为它将冷启动时间减半,但这是包含 VBA 加载项的情况)。我们理想的解决方案是使用 COM Shim 加载 .NET 插件,并将所有 VBA 代码迁移到 .NET。当这个解决方案突然出现时,冷启动时间并不是它被证明的大问题,并且优先级被降低了!
我在 Outlook、Visual Studio 2010 和使用 .NET v4.0 的插件中也遇到了这个问题。我找到了这个页面:http: //blogs.msdn.com/b/vsod/archive/2012/05/19/resolving-performance-issues-with-loading-office-add-ins-vsto-add-ins-or -shared-add-ins.aspx
只是我的观察:一个空的 (VSTO) 加载项也需要最多 5 秒才能加载。
所以这可能是加载 .NET 库的问题。
(至少在我找到这篇文章之后,我知道这个问题是真实存在的。)
编辑:重新启动后的问题可能与 .NET 冷启动有关。但同样奇怪的是,Windows系统控制->程序和功能中插件的安装日期是当前日期。所以看起来插件每天都是新安装的?!?