微软证明Windows 11的WinUI现代界面性能表现能击败传统Win32

微软一直在尝试让 Windows 现代化。这里所说的“现代化”，主要是指将传统功能迁移到 WinUI——微软目前主推的原生用户界面框架。从“属性”窗口、“自动播放”对话框，到 Windows“运行”工具，越来越多功能都在获得支持深色模式的现代化设计。但问题在于，性能表现如何？

过去几个月里，WinUI 的稳定性确实有所提升，但微软似乎没有得到足够多的认可。Windows“运行”对话框就是一个很典型的例子。

正如许多用户已经注意到的那样，Windows“运行”功能正在获得基于 WinUI 的重新设计。如果用户在“设置”>“系统”>“高级”中手动启用这一功能，它将取代传统的“运行”对话框，也就是通过 Win+R 快捷键打开的旧版本。

新的“运行”对话框保留了用户熟悉的操作体验，同时加入了深色主题以及现代化的图标和界面元素。更令人意外的是，它的运行速度实际上比当前版本更快。

微软表示，在重建“运行”功能时，性能是首要考虑因素之一。

这个全新的“运行”对话框采用 C# 和 WinUI 3 构建，但实际性能却略胜于基于 Win32 的传统版本。微软在一份文件中公布了内部基准测试数据，并表示：“重写‘运行’时，我们始终将性能放在首位。其显示时间中位数为 94 毫秒，比以往任何时候都更快。”

现有的 Win32 版本“运行”对话框，显示时间中位数为 103 毫秒；而新版本的测试结果为 94 毫秒。两者相差 9 毫秒，意味着新的 WinUI 实现比传统版本快约 8.7%。

当然，这并不意味着只要把某个传统对话框或应用改用 WinUI，就一定能够提升速度。很多情况下，结果很可能恰恰相反。微软自己也承认，WinUI 仍需要在性能方面进行大量改进。

微软在“运行”功能上的一个关键做法，是采用 .NET AOT，也就是“预先编译”技术。新的“运行”对话框是一款使用 C# 编写的原生 WinUI 3 应用，但它会在发布前完成编译，而不是等到启动时再由常规的 .NET JIT 编译器进行即时编译。微软表示，这种方式可以让应用在保留 C# 和 WinUI 3 优势的同时，获得“原生代码般的极致速度”。

微软还表示，公司与 Windows 平台的多个团队进行了密切合作，以确保这些界面能够快速加载。因此，这次的结果并不是因为 WinUI 默认就比 Win32 更快，而是多方面优化共同作用的成果。

微软正在证明，Windows 11 可以实现现代化，同时不牺牲性能。

长期以来，人们一直认为，用 WinUI 或 XAML 界面取代 Win32，会让 Windows 变得更慢。这种看法并非完全没有依据。比如，将新版任务管理器与旧版进行比较，就会发现新版在低端电脑上的运行速度明显更慢。

文件资源管理器的情况也类似。它的运行速度曾经非常缓慢，直到微软开始着手进行性能优化。即便如此，它目前仍然没有 Windows 10 版本那么快。例如，在 Windows 11 中，用户右键点击文件夹时，甚至可以亲眼看到上下文菜单中的项目逐个加载出来。

“运行”对话框对于微软来说，是检验现代 Windows 界面的一个有趣案例。

微软一直不太愿意对一些传统对话框进行现代化改造，其中一个重要原因就是 WinUI 存在性能问题。如果一个界面框架拥有明显的启动开销，那么“运行”功能几乎是最难改造的对象，因为传统版本本来就能瞬间打开。

微软表示：“我们知道现有对话框的速度很快。”公司还指出，如果希望让“运行”功能符合 Windows 11 的整体设计，就必须在保持界面简洁的同时，“维持相同的性能表现”。

用户可能无法凭借肉眼察觉 103 毫秒和 94 毫秒之间的差异，但真正值得关注的并不是这 9 毫秒。

“运行”是一个已经存在了 30 多年的极其轻量级 Windows 功能。微软使用现代 C# 和 WinUI 3 技术栈对其进行重写，却没有出现现代化改造一个原本已经很快的功能时通常会产生的性能倒退。相反，根据微软的测试结果，新版本的速度还略有提升。

微软认为，这项功能仍有继续改进的空间。更重要的是，公司表示，这些工作并不只是在优化“运行”对话框本身。

微软称：“我们对平台所做的改进，不仅能让‘运行’更快，也有助于提高整个操作系统的效率。”

如果这些改进能够扩展到 Windows 11 的其他部分，那么“运行”对话框或许会成为一个早期案例，证明微软终于可以在不接受性能下降这一代价的情况下完成 Windows 的现代化改造。

无论如何，更好的 WinUI 对所有用户来说都是好消息，因为 Windows 已经不可能重新回到完全依赖 Win32 的道路上，而另一个替代方案 WebView，也并不是用户希望看到的选择。