微软承认 Windows 11 原生应用占用大量内存，承诺在重写开始菜单前提升 WinUI 性能
拖慢 Windows 11 的一个主要问题是内置应用和原生框架，而 Windows Latest 了解到，微软正在准备一次侧重内存管理的重大更新。据我所知，基于 WinUI 的开始菜单和通知中心中的议程视图仍在推进中，但微软会在推出前先优化 WinUI。
微软也在 Build 2026 上面向开发者透露了内存管理相关细节，不过其中大部分都与 WinUI 直接相关。
在 Build 2026 上，微软表示一直在对 WinUI 进行调整，让它占用更少的内存；而在开始菜单等 Windows 核心元素改用 WinUI 重写之前，这一点尤为重要。
https://www.windowslatest.com/wp-content/uploads/2026/06/WinUI-basics.mp4据微软 Windows UI 团队工程师 Chris Anderson 介绍，后续还会有更多改动，并笼统提到了针对 WinUI 的“性能、基础和质量”修复，以配合更大的规划。
一个值得注意的变化是，微软计划将 WinUI 迁移到 Windows 系统合成器，这应该会让应用和操作系统快一些。
Anderson 说：“在性能方面，我们投入了大量精力来大幅改善内存使用，并切换到系统合成器，这应该还能带来更好的性能提升。而这些内容其实都已经在我们的 Git 仓库里公开了。”
尽管大家都希望在 Windows 中看到原生应用，尤其是使用 WinUI 构建的应用，但不可否认，这个框架在性能优化方面并不理想。它可能会显得很慢，而且你们大多数人应该都已经亲身体验过。
例如，试着把文件资源管理器设置为打开“此电脑”，并将其性能与“主页”标签页比较；后者加载时间明显更长，尤其是在低端硬件上：
https://www.windowslatest.com/wp-content/uploads/2026/04/File-Explorer-slow.mp4据我所知，微软正在内部测试 WinUI 的内存占用、性能和可靠性修复，然后才会推出使用该框架构建的新开始菜单。
开始菜单部分使用 React Native
当 WinUI 版开始菜单推出时，外观上大体不会有明显变化，但在低端电脑上卡顿应该会少一些，整体内存占用也会更低。可能有人不知道，开始菜单中的“所有应用”列表和“推荐”信息流（在较新版本中也称为“最近”）是使用 React Native 构建的。微软在 2023 年的 Chain React 大会上证实了这一点：
微软开发者在 2023 年解释 Windows 11 开始菜单中 React Native 的使用我可以确认，与 WinUI 相关的修复会让 Windows 明显更快，但目前我们还没有具体数字，所以我无法告诉你：一个使用 300MB 内存的应用在采用这些改动后，是否会降到 250MB、200MB，或者其他数值。
在 Build 2026 上，微软还表示计划推出新的 WinUI 功能，但前提是性能问题得到解决。现在的重点完全是修复漏洞，让 WinUI 反应更灵敏，而这也是开始菜单改动之前所必需的。
Anderson 说：“在我投入那些我认为很吸引人、闪闪发光的新功能之前，我真的想先把时间花在……”
“……这些才是真正的核心功能，是人们一直在要求、也确实需要的，只有建立在 WinUI 之上才能提高生产力。首要任务是性能、基础、质量，以及修复大量漏洞。”
微软也在为 WinUI 准备内置的 DataGrid 和 Charting 控件，以说服企业开发者转向使用
Anderson 说：“我们还加入了很多新控件。DataGrid 和 Charting 也在推进中，应该很快就会推出。这些会出现在 WinUI 核心组件中，并让你能够覆盖更多这类面向数据的场景。”
微软向 WinUI 加入这些控件有两个原因。首先，它希望减少开发者对独立库的依赖，以实现常见的企业应用功能。
其次，它希望当企业开发者能够在库中使用更高级的图形和数据展示控件时，开始用 WinUI 构建应用。如果真能如此，你可以预期微软会在 WinUI 上投入更多，也会有更多旧应用迁移到这个新的原生框架。
https://www.windowslatest.com/wp-content/uploads/2026/06/Datagrid-and-Charting-in-WinUI.mp4不过，微软并没有表示使用这些内置控件就一定能降低应用的内存占用。
微软希望先把 WinUI 做好，再把更多 Windows 11 组件迁移到原生框架
微软表示，它正更快地把 WinUI 集成到 Windows Shell 中，更多第一方 Windows 体验也会基于它构建，但在那之前，它需要先让 WinUI 变得更快。
“我们真的在努力推动 WinUI 扩展到我们希望的任何使用场景。我们已经开始以更快的速度把它集成进 Shell。所以你会看到很多来自微软的第一方功能都是构建在 WinUI 之上的。”
换句话说，微软的意思是，如果核心框架 WinUI 本身很慢，就无法让 Windows 11 变快。
微软认为，WinUI 被用于 Windows Shell 内部，也出现在许多原生 Windows 应用中。框架开销会对 Windows 性能产生负面影响，因此公司才想优化 WinUI。WinUI 还存在其他问题，比如拖动和调整窗口时出现画面撕裂：
https://www.windowslatest.com/wp-content/uploads/2026/05/Photos-app-with-a-very-noticeable-tearing-as-it-is-a-WinUI-3-app.mp4据我所知，这些问题会尽快修复，而且这也是下一次重大设计更新前所必需的。
微软没有说明接下来哪些 Windows 11 功能会迁移到 WinUI。它也没有确认现有 Shell 组件是否会立即更新以使用这些内存优化。不过我们知道，开始菜单和通知中的议程视图是会迁移到原生代码的两个重点功能。
Anderson 说：“我们希望看到很多第三方开发者真正开始采用它。我们已经看到一些增长，但我们也知道，采用一个新的 UI 框架可能需要很长时间，尤其是在企业环境中。”
“我们认为现在是时候真正展示我们在全力支持这项工作，并且我们致力于推动 WinUI 向前发展了。这完全符合我们的目标。”
微软承认 WinUI 仍有重大功能缺口
性能并不是开发者不愿将应用迁移到 WinUI 的唯一原因。
微软表示，开发者仍然依赖开源库，是因为 WinUI 缺少他们需要的能力，包括完整的系统托盘实现和更丰富的数据控件。
Anderson 说：“第二个我们经常听到的问题是，除了 DataGrid 和 Charting 之外，这个平台还有大量功能缺口。”
“从系统托盘你能做什么，到你对 Windows 的使用都很受限。很多人用开源库来弥补这些缺口，我们能不能把平台本身修好？”
Anderson 说：“我们有大量积压工作。我们会开始逐步处理，真正着手解决大家指出的功能缺口。但这一直是最大的问题之一。”微软还认为，它正在开发新的 AI 工具，以帮助使用 AI 辅助开发 WinUI 应用。
https://www.windowslatest.com/wp-content/uploads/2026/06/AI-coding-for-WinUI.mp4此外，Anderson 还回应了那些仍然担心微软可能放弃 WinUI、改用其他框架的开发者。
“最主要的问题可能是，你们这次真的认真的吗？你们会坚持用这个框架吗？WinUI 3 已经四年了。你们会继续推进，还是又要在今年宣布一个全新的框架？”
“我可以明确说，不，我们没有打算构建新的框架。”
微软也在从框架名称中去掉版本号，以暗示不会再推出其他框架。
Anderson 说：“实际上，我们正在去掉这个数字，把它直接称为 WinUI，因为我们并没有打算对它做出真正重大的转变或破坏性更改。”