×

第 683 期:微软承诺为 Windows 11 提供本地原生用户界面

独孤求败 独孤求败 发表于2026-05-18 15:32:40 浏览20 评论0

抢沙发发表评论

ScreenShot_2026-05-18_153306_925.jpg

为了明确对本地原生软件的回归,微软正在加倍投入 WinUI 3 框架,以清除 Windows 11 中的臃肿体验。

大部分用户对 “网页应用” 已经达到忍无可忍的地步。过去几年,开发者越来越多地放弃原生 Windows 应用程序,转而使用渐进式网页应用(PWA)或基于 Electron 的网页程序。虽然这些以网页为优先的框架让大型企业的跨平台开发成本大幅降低,但它们却是资源占用严重的桌面应用程序,即使只是显示一个基本的用户界面,也会吞噬您宝贵的内存并消耗电池。

这种挫败感在我们最近测试 Windows 11 的低延迟模式时达到了顶点,该后台功能会暂时提升 CPU 频率,从而让操作系统感觉瞬时响应。

有一些用户指责微软通过硬件的暴力手段来补偿臃肿、未优化的代码以提高性能。微软副总裁 Scott Hanselman 反驳称,临时提升 CPU 的做法是 macOS 和 Linux 的行业标准,并且微软同时也在进行优化底层软件的艰苦工作。

图片

本周,我们终于得到了微软正在履行其承诺的确凿技术证明。作为恢复性能和开发者信任的重要举措,微软公开加大了对 WinUI 3 的支持,宣布了全面的架构变更和新的开发者工具,这将帮助 Windows 11 摆脱其负面声誉,当然也包括其缓慢的问题。

微软对 WinUI 3 的承诺将使 Windows 11 更快

微软 Windows 工程团队在其官网上发布的一份新技术简报显示,WinUI 3 框架将迎来巨大的性能飞跃。这家软件巨头希望 “让 WinUI 3 成为 Windows 体验和应用程序的最佳原生界面平台。”

图片

为了证明他们不是在夸夸其谈,开发团队将注意力集中在启动时间上,并以文件资源管理器和记事本作为主要基准。如果您使用过之前版本的 Windows,Windows 11 中的文件资源管理器对于高级用户来说一直都比较缓慢。

WinUI 工程分支的初步基准测试结果确实令人震惊。对于文件资源管理器启动中的 WinUI 部分,微软已经成功实现了:

– 内存分配减少 41%:这大大降低了内存开销和突发垃圾回收暂停的频率。

– 临时分配减少 63%:较少的临时数据生成意味着 CPU 可以花更多时间执行任务,而不是在后台清理短生命周期对象。

– 函数调用减少 45%:简化代码路径直接减少了执行时间,因此用户界面在屏幕上渲染得更快。

– WinUI 代码执行时间减少 25%:用户界面框架本身更快地让位,这几乎可以让应用程序立即变得可交互。

图片

将这些框架级代码优化与低延迟模式的 “激进” 硬件调度结合起来,您会得到一个高度强效的复合效果。这就是 Hanselman 所说的工程团队正在做两者的意思。

Windows 11 正在从核心操作系统中消除网页封装

长期以来,Windows 11 似乎在自己的网页封装器中挣扎。即使是关键的系统组件也严重依赖 WebView2,这自然会在浏览界面时产生微小但非常明显的界面卡顿。

图片

然而,形势正在正式转变。我们最近报道,微软正在积极将 Windows 11 的开始菜单从基于 React 的 web 组件转向纯原生的 WinUI 3 代码。

WinUI 3 的性能改进何时会来到 Windows 11?

维护人员在 WinUI 3 更新文档中指出,这些框架改进很快将从开发分支迁移到主 winui3/main 分支,并最终进入 Windows App SDK (WinAppSDK) 2.x 版本。他们特别提到,其中一些更改 “可能过于冒险或复杂,无法作为服务更新提供”。

一些 WinUI 3 的性能提升目前是可选择开启的。

有趣的是,微软承认,要达到这种前沿性能水平,需要进行一些结构上的牺牲。公司正在对默认控件样式引入必要的破坏性更改。

因为这些优化可能会破坏高度依赖控件模板中自定义容器元素的旧应用程序,微软目前将这些性能路径设置为 “可选择开启”。然而,最终目标是在 WinAppSDK 3.0 或 4.0 中将这些高性能路径默认切换为 “非开启”,推动 Windows 生态系统朝着更高的效率发展。

文件资源管理器会启动快 40% 吗?

需要明白的是,内存分配和函数调用的减少并不自动意味着应用程序启动时间会减少 40%。基准测试指标专门衡量的是 WinUI 框架在文件资源管理器启动序列中的部分,而不是完整的端到端加载过程。

图片

现实世界的速度提升需要多个 Windows 开发团队之间的深入协作。然而,在微软对 WinUI 3 的长期承诺中,显著精简 UI 框架自身的开销是必须的第一步。

微软表示,开发者可以使用命令行工具和人工智能来构建 WinUI 3 应用

修复微软自己的 Windows 应用只是战斗的一半。如果微软想要消除 Web 应用的低效,他们必须说服第三方开发者,相比启动一个臃肿的 Electron 项目,构建原生 WinUI 3 应用同样简单。

这完全说得通。正如我们报道的,Windows 11 不断推出网页应用而非原生应用,是因为开发者对像 WinUI 3 这样的平台缺乏信任和激励,而微软直到现在才真正支持它。更别提他们不断更换应用开发框架,却没有一个合理的策略。

传统上,原生 Windows 开发需要下载庞大的 Visual Studio 集成开发环境,并理解极其复杂的 XAML 结构。

为了彻底消除这一入门障碍,微软刚刚宣布了一套功能强大的新开源 dotnet new 项目和模板,专门用于 WinUI,再次证明了他们对该框架的承诺。

图片
开发者现在可以直接从命令行生成、构建并运行完整打包的原生 WinUI 应用,而无需使用 Visual Studio。这些模板是以现代 Windows 设计轮廓为目标设计的。
图片
如果使用 dotnet new winui-navview 命令,您将立即获得一个项目,该项目拥有现代化的标题栏、响应式导航,并且在浅色和深色模式下开箱即用采用 Fluent 设计模式的架构。此外,这些模板利用了新的 WinApp CLI,它通过即时处理松散布局包的注册,彻底消除了以往手动 MSIX 打包和证书管理的历史性难题。
图片
微软还刚刚为像 Claude Code 这样的 AI 助手推出了一个专用的 WinUI 代理插件。我觉得这正是本地开发变得令人非常兴奋的地方。
图片
您现在可以打开命令行,并用自然语言向 Copilot 提出请求,例如 “创建一个带有缩略图和 EXIF 元数据的 WinUI 3 照片浏览器”。专门的 winui-dev AI 代理将自动选择合适的原生模板,编写 MVVM(模型-视图-视图模型)架构,生成 XAML 布局,并自动修复任何编译错误。它甚至具备深度集成的 winui-ui-testing 技能,可以从命令行驱动真实的 UI 自动化,以在无需您干预的情况下发现并修复功能性错误。
图片

微软正在大幅减少构建原生软件所需的时间和成本。

通过为 AI 代理提供对 WinUI 和 Windows 应用程序 SDK 的深度、扎实的知识,公司完全否定了使用跨平台网页封装的主要理由!

微软正在告别网页应用

业界对占用大量内存的网页应用的抵制从未如此强烈。随着全球内存价格飙升,用户对占用超过 1GB 的聊天应用越来越感到沮丧,软件效率已成为绝对必要。

随着大规模框架级代码优化、开始菜单向原生代码的架构转变、2026 年 5 月更新中的关键功能的修复,以及出色的新命令行开发工具,来自雷德蒙德的信息是,他们终于提供了必要的基础设施,以帮助开发者消除网页应用的冗余,使 Windows 11 感觉像是一款高级、高响应性且深度原生的操作系统。

您怎么看待时下泛滥成灾的各种网页套壳应用?


群贤毕至

访客