Outlook 2010 中有关关闭的更改
**摘要：**作为提高性能目标的一部分，Microsoft Office Outlook 2007 Service Pack 2 (SP2) 和 Microsoft Outlook 2010 包含一些重要更改，用于确保 Outlook 能够在用户尝试关闭它时正常关闭。本文将介绍对 Outlook 2010 所做的更改。
上次修改时间： 2011年11月4日
适用范围： Office 2007 | Office 2010 | Outlook 2007 Service Pack 2 (SP2) | Outlook 2010
本文内容
背景
Outlook 2010 中有关加载项关闭的更改
有关加载项关闭的最佳实践（适用于开发人员）
有关加载项关闭的最佳实践（适用于 IT 管理员）
结论
其他资源
目录
背景
Outlook 2010 中有关加载项关闭的更改
有关加载项关闭的最佳实践（适用于开发人员）
有关加载项关闭的最佳实践（适用于 IT 管理员）
结论
其他资源
背景
在 Outlook 2007 SP2 之前，Outlook 根据命令进行关闭的时间通常要超过预期的时间。Outlook 2010 中的目标是确保它始终能快速、可靠地关闭。
在 Outlook 2007 SP2 中，当用户关闭 Outlook 之后，Outlook 会阻止外部 COM 加载项让 Outlook 继续运行（有关详细信息，请参阅 Outlook 2007 SP2 中有关应用程序关闭的更改（该链接可能指向英文页面））。Outlook 2007 SP2 还为 MAPI 提供程序进行了新的设计，以防止在 Outlook 退出之前丢失数据。此设计的缺点是，所有 MAPI 提供程序都必须选择使用此设计并支持新行为。
在 Outlook 2010 技术预览版中，对此设计进行了修改，使 MAPI 提供程序实现 IMAPIProviderShutdown : IUnknown 接口以便及时执行必要的步骤。这些步骤可以防止客户端在退出之前断开与外部引用的连接时发生的数据丢失情况。所有 MAPI 提供程序默认情况下均采用快速关闭机制，那些通过将 MAPI_E_NO_SUPPORT 返回给 IMAPIProviderShutdown::QueryFastShutdown 方法而明确选择退出此机制的提供程序除外。即使 MAPI 提供程序未实现 IMAPIProviderShutdown 接口，Outlook 2010 仍使用快速关闭机制。有关 MAPI 客户端和提供程序快速关闭机制的详细信息，请参阅Client Shutdown in MAPI。
这些外部 COM 加载项和 MAPI 提供程序的更改做了大量工作来确保 Outlook 始终能按用户预期的那样快速关闭。但是，一些 Outlook 进程内加载项在关闭事件期间会执行需大量占用处理器的操作和网络 I/O。由于这会对 Outlook 性能造成可使人察觉的影响，因此，Outlook 2010 包含了一个针对进程内加载项的快速关闭模型，以进一步改进 Outlook 中的关闭行为。
Outlook 2010 中有关加载项关闭的更改
从 Outlook 2010 开始，Outlook 在默认情况下不会通知加载项它将要关闭。具体而言，Outlook 在快速关闭期间不再调用 IDTExtensibility2 接口的 OnBeginShutdown 和 OnDisconnection 方法。类似地，当 Outlook 关闭时，使用 Microsoft Visual Studio Tools for Office 编写的 Outlook 加载项不再调用 ThisAddin_Shutdown 方法。
这些更改对加载项所产生的影响取决于加载项在这些事件期间执行的操作。大部分加载项通过使用这些事件释放对 Outlook COM 对象的引用，并清理会话期间分配的内存。在这些情况下，这些更改对加载项的影响最小；Outlook 释放剩余的 COM 对象引用并关闭，而当 Outlook 进程退出时，Windows 将回收内存。
对一些加载项而言，这些更改会产生较大影响。如果加载项使用这些事件来提交数据（例如，将用户设置存储到 Web 服务器或将使用情况报告给 Web 服务器），则相应的活动将不会再发生。根据应用场景的不同，这可能会（也可能不会）对用户造成明显的影响。为了避免这种情况，加载项开发人员可以修改加载项使之与这些更改相兼容，或者，IT 管理员可以使用组策略来还原特定加载项的原始行为。
.gif "重要说明") 重要说明 |
|---|
在其他应用场景中，例如，如果加载项是手动断开连接的，或者缓慢关闭是通过使用组策略还原到 Outlook 2007SP2 之前的行为来启用的，则仍可以调用 OnBeginShutdown 和 OnDisconnection 方法。因此，开发人员一定要继续实现这些方法。 |
为什么现在进行更改？
Outlook 开发人员深知此更改会产生重大影响，但在对大量性能数据进行仔细分析之后，仍然做出了此决定。
例如，来自 Outlook 2007 SP2 中的数据表明，如果用户安装了"行为不良的"加载项，则关闭的平均延时为 13 秒。来自 Outlook 2010 技术预览版的数据表明平均延时为 15-20 秒。
其他用于演示加载项在关闭或断开连接事件期间所执行的操作的测试表明，尽管大多数加载项只是执行一些简单的任务（例如，释放引用），但有一些加载项在这些事件期间会同步调用 Web 服务或其他长时间运行的操作。
此更改的好处是，对于大多数加载项和客户而言，Outlook 在关闭时会明显表现出比过去更好的性能。此更改改进了 Outlook 响应用户意图并快速退出的能力，以便用户能够继续下一项任务或关闭计算机。
有关加载项关闭的最佳实践（适用于开发人员）
对加载项开发人员来说，新的关闭方式最初看起来似乎有些复杂。开发人员一定要遵循有关加载项关闭的最佳实践，以确保最终用户能够继续获益于快速响应的 Outlook 关闭体验。
实践 1：继续在 OnDisconnection 中释放引用
一定要继续编写包含 OnDisconnection 或ThisAddin_Shutdown 的代码，以便释放任何剩余的对 Outlook 对象的 COM 引用。在 Outlook 2003 中和 SP2 之前的 Outlook 2007 中，这些 COM 引用会阻止 Outlook 关闭。在 Outlook 2010 中，您应继续实现这些事件以释放引用和已分配的内存，这是因为在有些场合下，管理员可能会通过组策略来还原缓慢关闭，或通过**"COM 加载项"**对话框手动断开与加载项的连接。
实践 2：检测 Outlook 何时关闭
为了检测 Outlook 是否正在关闭，可以使用 Outlook 对象模型中的 Application 对象的 Quit 事件，接收有关进程正在关闭的通知。务必快速响应此事件，并尽可能快地将控制权交还给 Outlook。您的加载项不应在 Outlook 关闭过程中造成可让用户察觉的延迟。对 Outlook 关闭在只运行您的加载项和不运行任何加载项的情况下分别所需的时间进行比较，以发现任何明显的差异。
如果您的加载项在关闭时需要执行长时间运行的或运行时间不定的操作，请考虑以下问题：
当 Outlook 关闭时，每项操作是否都需要发生？
当 Outlook 崩溃时以及当这些操作对应的代码无法运行时会发生什么情况？
操作是否可以在关闭之前提前执行（例如，当用户做出更改时提交更改而不是保存操作供日后使用）？
操作是否可以在后台线程上执行而不是在退出事件期间同步执行？
备注
您无法从后台线程调用 Outlook 对象模型，但是如果您在加载项中正确初始化 MAPI，则可以直接使用 MAPI。有关详细信息，请参阅Starting a MAPI Session。
很显然，不要在任何退出事件期间执行网络 I/O 操作，包括在 Application.Quit、OnBeginShutdown、或 OnDisconnection 期间将数据保存到网络共享、将数据写入到 Outlook 联机模式存储或调用 Web 服务。
在使用 Application.Quit 事件时，请不要在 Outlook 进程空间中释放任何 Outlook COM 对象或已分配的内存。当您的进程退出时，Outlook 和 Windows 会负责处理这些工作。
提示
在加载项的兼容性测试期间，有一个示例内部 Outlook 加载项会在关闭事件期间，将使用情况报告给 Web 服务。开发人员对此加载项进行了修改，以便在下次启动 Outlook 时保存并报告后台线程上前一个会话的使用信息，而不是在关闭期间将数据直接报告给 Web 服务。这样，仍可上载数据，但该操作永远都不会阻塞 Outlook，这是一项非常有用的技术。
如果您的解决方案包含另一个可执行文件，请考虑将某些操作从加载项移动到该可执行文件。这样，无论 Outlook 是否运行，该操作都将进行，并且不会阻塞 Outlook 快速启动或关闭的功能。
实践 3：通过使用快、慢两种方法来测试关闭
作为一名开发人员，您应确保您的加载项对 Outlook 用户性能的影响是可以忽略不计的。至少，应测试您的加载项对 Outlook 启动时间、常见应用场景（例如，撰写新消息、答复消息、切换文件夹和发送邮件）和 Outlook 关闭的影响。具体地说，应根据加载项用于控制 Outlook 的关闭方式的不同 Windows 注册表设置，来测试 Outlook 的关闭时间。
有关加载项关闭的最佳实践（适用于 IT 管理员）
对于 IT 管理员而言，如果您的内部加载项或解决方案无法更新以支持新设计，则可以通过两种方式在 Outlook 2010 中启用针对 Outlook 加载项的关闭通知，并还原为早期关闭行为：
根据不同的加载项进行选择（首选方法）
作为加载项部署的一部分，IT 管理员可以启用各个 Outlook 加载项的关闭通知。尽管您无法通过组策略来实现这一点，但是如果您对于特定加载项具有向后兼容性要求，则会大有帮助。
全局性针对所有加载项
IT 管理员可以使用组策略针对所有加载项全局性启用关闭通知。如果组织具有大量内部解决方案或桌面需要部署此设置以确保在推出 Outlook 2010 期间的兼容性，建议使用此方法。
单个的加载项设置
通过使用此设置，Outlook 可以有选择地为指定的加载项提供关闭通知，而不用通知所有加载项。通过在 HKCU 或 HKLM 注册表配置单元中进行加载项注册（为加载项注册添加其他值），可以为每个加载项配置此设置。请在一行中键入以下文本。
HKCU\Software\Microsoft\Office\Outlook\Add-ins\<ProgID>[RequireShutdownNotification]=dword:0x1
如果将此值设置为 0x1，则会使加载项在 Outlook 关闭期间接收已阻塞的回调。此设置会对 Outlook 的关闭性能造成影响，应作为部署的一部分进行评估。只有在某个加载项与新的关闭机制之间存在明显的兼容性问题时，才能使用此设置。如果将此值设置为 0x0，则会使用 Outlook 2010 的默认行为。
全局设置
可以使用此设置更改新的关闭机制，以使其与 Outlook 2007 所使用的机制相匹配。可以通过组策略（每个用户或每台计算机）来部署此设置。请在一行中键入以下文本。
HKCU\Policies\Microsoft\Office\Outlook\14.0\Options\Shutdown[AddinFastShutdownBehavior]=dword:0x1
如果将 AddinFastShutdownBehavior 设置为 0x1，则会为所有加载项启用关闭通知。如果将此值设置为 0x0，则会使用 Outlook 2010 的默认行为。
这两个设置可以让管理员完全控制这种新行为对在企业中使用的自定义解决方案和加载项的影响。各个组织一定要对所有使用 Outlook 加载项的自定义解决方案进行测试，确保它们与此更改兼容。
结论
Outlook 2010 为进程内 Outlook 加载项提供了一种新机制来进行关闭，而不会影响 Outlook 关闭给人的总体感觉。不过，尽管 Outlook 不再调用 IDTExtensibility2 接口的 OnBeginShutdown 和 OnDisconnection 方法，但加载项仍应实现这些方法或 ThisAddin_Shutdown 以释放引用和已分配的内存，这是因为在有些情况下，管理员可能会通过组策略还原为缓慢关闭，或者用户可能会通过"COM 加载项"对话框手动断开与加载项的连接。加载项开发人员应主动修改其加载项，使之能与 Outlook 2010 一起使用，仅执行那些在关闭期间必须发生的任务，并对其加载项在不同应用场景和用于控制 Outlook 关闭的不同 Windows 注册表设置下的性能进行评估。如果有些加载项已经部署到企业中，而且 IT 管理员无法将其升级为与新的关闭机制兼容，则 IT 管理员可以求助于几个新的 Windows 注册表设置，将其还原为缓慢关闭行为。
其他资源
有关详细信息，请参阅以下资源：