Microsoft 新版 Outlook 通知响应迟缓：WebView2 架构下的性能困境

背景

Windows 11 系统目前预装了两款 Outlook 客户端：一是长期存在的 Outlook Classic，这是一款面向高级用户的传统 Win32 桌面应用程序；二是微软大力推广的 New Outlook（新版 Outlook），被视为 Windows 平台上电子邮件的未来。

New Outlook 基于 WebView2 构建，本质上是一个加载 Outlook.com 的浏览器窗口。这一架构转变并非一蹴而就。多年来，传统的 Win32 版 Outlook 因臃肿和配置复杂而声名狼藉，微软因此决定抛弃原生代码，从 Web 端重新构建应用。这一举措取代了部分 Windows 用户熟悉的轻量级 UWP 版“邮件和日历”应用。早在 2023 年，当微软宣布计划退役 UWP 应用并转向 Web 包装器时，用户曾提出抗议，但微软仍按计划推进，并于 2024 年底正式关闭了 UWP 版的邮件和日历应用。

尽管微软在企业端也大力推动 New Outlook 的迁移（并将强制迁移截止日期从原定的 2026 年 4 月推迟至 2027 年 3 月，这一年的延期本身就表明微软承认该应用尚未完全准备好应对所有工作负载），但其性能表现，特别是在处理通知时的响应速度，成为了用户诟病的焦点。

核心内容

通知响应的巨大落差

尽管 New Outlook 在启动速度上已大幅改善，几乎与 Outlook Classic 持平，但在处理 Windows 11 的新邮件通知时，两者体验存在显著差距。

当新邮件到达时，Windows 11 会在屏幕右下角显示通知横幅。

• Outlook Classic：点击通知或从通知中心进入，会几乎瞬间直接打开触发该通知的特定邮件。
• New Outlook：点击通知后，应用需要先打开，加载完整的收件箱，然后大约需要 10 秒 才能将特定的邮件显示在屏幕上。

这种延迟甚至显得荒谬：如果用户忽略通知横幅，直接从开始菜单打开 Outlook，手动找到并点击新邮件，整个过程（包括打开应用和点击邮件）通常只需 5 秒左右，比直接点击通知还要快。

技术根源：WebView2 的架构限制

New Outlook 的性能瓶颈源于其基于 Microsoft Edge 的 WebView2 运行时，这是一个基于 Chromium 的渲染引擎。

1. 进程链复杂：每次与应用交互（包括点击通知），都需要经过类似浏览器的进程链处理。应用必须初始化或恢复其 Web 层、进行身份验证、加载相关的邮件线程，并通过 Web 引擎渲染它。
2. 资源占用高：在任务管理器中，New Outlook 运行着 10 个独立的进程，包括 WebView2 Manager、多个 WebView2 Utility 进程、WebView2 GPU 进程、WebView2 Service Worker 等。每个进程本质上都是浏览器组件，它们各自消耗内存，且在从挂起状态恢复时都需要时间。
   • 内存占用：New Outlook 在空闲状态下占用 490 MB 至 636 MB 的 RAM（具体取决于邮箱大小），而 Outlook Classic 仅占用约 117 MB 至 148 MB，相差约四倍。
   • CPU 占用：New Outlook 空闲时占用约 4% 的 CPU，而 Outlook Classic 不到 1%。
3. Web 应用的固有缺陷：正如 Windows Latest 在 2025 年 12 月报道的那样，微软已承认这一缓慢问题，并正在测试名为“Delayed Message Timing”的新 API 来诊断 WebView2 应用的性能问题，但目前尚未在通知点击中看到该 API 的应用。此外，Web 应用设计上是始终与服务器通信的，这与 Outlook Classic 本地缓存邮件的原生离线处理方式截然不同。

改进与未来展望

尽管存在性能问题，New Outlook 仍在逐步改进：

• 功能更新：2026 年 3 月的更新增加了更好的文件夹搜索功能和改进的共享邮箱访问权限；2026 年 5 月的更新引入了自动映射的日历支持，解决了共享日历丢失的问题。
• 近期承诺：微软确认 2026 年 6 月的更新将包含五项重要新增功能，包括 2026 年 8 月推出的全账户收件箱视图（统一收件箱）、改进的邮件合并功能以及扩展的 .PST 支持（2026 年 7 月的 .PST 导入更新将允许用户从本地归档文件中导入日历项目和联系人）。
• 迁移推动：微软在 2026 年 6 月初列出了 15 项生产力功能作为从 Classic 迁移的理由，包括离线访问、更丰富的 Copilot 集成、更快的搜索和改进的日历控件等。值得注意的是，其中许多功能 Classic 用户早已拥有，这凸显了微软推动迁移的决心。

然而，只要通知体验无法达到 Outlook Classic 的水平，New Outlook 就仍在受限于 WebView2 架构的根本约束。微软已全面转向 WinUI，Rudy Huyn 正在组建团队开发原生 Windows 应用，未来可能会出现原生的 Outlook 应用，但这需要时间。

关键要点

• 性能对比悬殊：New Outlook 处理邮件通知需耗时约 10 秒，而 Outlook Classic 几乎瞬间完成。甚至手动打开应用查找邮件比点击通知更快。
• 架构导致资源浪费：New Outlook 基于 WebView2（Chromium 引擎），空闲时内存占用约为 Classic 的四倍（~500MB+ vs ~130MB），CPU 占用也高出四倍。
• 进程复杂度高：New Outlook 在后台运行约 10 个独立进程，每次通知点击都需唤醒多个浏览器组件，导致恢复延迟。
• 微软已承认问题：微软内部测试了“Delayed Message Timing” API 以诊断性能问题，但尚未在通知场景中有效应用。
• 功能正在追赶：新版 Outlook 在共享日历、文件夹搜索、.PST 导入等方面正在逐步缩小与 Classic 的功能差距。
• 强制迁移仍在继续：尽管性能有短板，微软仍通过关闭旧版 UWP 应用和推迟企业迁移截止日期（至 2027 年）来推动用户转向 New Outlook。
• 根本解决方案：要彻底解决此类性能问题，最终可能需要从 Web 包装器转向原生的 WinUI 架构应用。

意义与影响

这一案例深刻揭示了微软在软件现代化进程中面临的典型矛盾：架构革新与用户体验之间的权衡。

1. Web 化带来的技术债：虽然基于 WebView2 的架构有助于统一跨平台体验、降低维护成本并集成现代 Web 技术（如 Copilot），但它牺牲了原生应用的性能和响应速度。对于邮件这类高频、即时性要求高的工具，10 秒的延迟是难以接受的体验断层。
2. 企业迁移的阻力：微软将企业迁移截止日期推迟至 2027 年，表明即使内部也意识到 New Outlook 尚未完全准备好替代 Classic。这种“先迁移，后完善”的策略可能会引发企业 IT 部门的抵触，尤其是在关键业务依赖快速邮件处理的场景下。
3. 原生应用的回归趋势：New Outlook 的性能困境再次证明了原生应用（Native App）在系统级集成和资源管理上的优势。微软全面转向 WinUI 并计划开发原生 Outlook 的迹象，表明其可能正在反思纯 Web 包装器的局限性，未来可能会采取“混合”或“原生优先”的策略来平衡功能创新与性能体验。
4. 行业警示：Meta 的 WhatsApp 等应用也出现了类似的资源占用激增问题。这提醒科技行业，将原生应用简单包装为 Web 应用并非一劳永逸的解决方案，特别是在 Windows 这样对资源敏感且强调系统集成的平台上，性能优化必须作为核心考量，而非事后补救。

对于普通用户而言，如果工作流程高度依赖快速处理邮件通知，Outlook Classic 目前仍是更可靠的选择；而对于期待新功能的用户，