微软承认Windows 11 WinUI 3应用窗口缩放效果不如被替代的UWP，夏季将推出修复方案
微软终于修复了 WinUI 3 应用窗口调整大小时的黑色撕裂问题。 作为微软努力重振 Windows 11 本地应用开发的一部分，公司现已确认 WinUI 3 将获得类似 UWP 应用的流畅调整大小功能。
Windows 11 目前正经历重大结构性转变。多年来，我们一直忍受着古老界面元素、缓慢的网页包装和现代本地应用的混杂状态。
对于开发者来说，最陈旧的视觉问题之一便是调整现代 WinUI 3 应用大小时出现的难看黑色撕裂边缘。值得庆幸的是，微软设计合伙人总监 March Rogers 表示修复方案正在开发中，并将很快推送给用户。
“我们正在进行平台改进以解决撕裂问题……预计夏季开始推送。”
说实话，我之前并不知道 WinUI 3 应用还没有流畅调整大小，或许是因为绝大多数内置 Windows 11 应用都是 UWP 应用。
这是因为 时钟 应用是 UWP 应用，所以支持流畅调整大小：
https://www.windowslatest.com/wp-content/uploads/2026/05/Smooth-resizing-in-Clock-app-as-it-is-UWP.mp4而 Windows 11 的 照片 应用是 WinUI 3 应用，因此调整大小时会出现明显撕裂，尽管我已使用了深色背景：
https://www.windowslatest.com/wp-content/uploads/2026/05/Photos-app-with-a-very-noticeable-tearing-as-it-is-a-WinUI-3-app.mp4不过，这种情况在几个月内可能会有所改变……
流畅调整大小功能将于今年夏天带给 WinUI 3 应用
在 X 平台上，一位开发者联系了 Windows 设计和工程团队负责人，询问 WinUI 3 应用是否能像较旧的通用 Windows 平台（UWP）应用那样实现流畅调整大小。
https://www.windowslatest.com/wp-content/uploads/2026/05/Developer-demonstrates-how-UWP-apps-resize-smoothly-but-WinUI-3-apps-have-tearing-around-the-edges.mp4他指出，微软商店和 Windows 时钟等传统 UWP 应用调整大小非常流畅。而他们正在开发的现代 WinUI 3 应用在调整窗口大小时则出现严重的视觉问题，出现明显黑色边框和撕裂。
March Rogers 表示，Windows 团队正在进行平台改进以解决撕裂问题。为确保最高稳定性，微软正在内置应用上测试流畅调整大小代码。一旦确认该修复在原生环境下表现良好，就会推送到 Windows 应用 SDK。Rogers 确认 推送将于夏季开始。这对高级用户和开发者而言都是重大利好。
我们正在进行平台改进以解决撕裂问题。我们在内置应用上测试以确保功能良好，然后再推送给 Windows 应用 SDK。预计将在夏季开始推送。
我觉得最有趣的是 March Rogers 提到他们正在内置应用上测试，意味着我们很快可能会看到原生的微软官方 WinUI 3 应用。这并不奇怪，因为我们此前报道过，微软合作架构师 Rudy Huyn 正组建团队，专注于打造 100% WinUI 3 的 Windows 11 应用。
最近，微软资深工程师 David Fowler 发帖称，“原生应用回归了！”
不过让我困惑的是，作为微软官方已放弃的平台，UWP 在调整大小时为何体验如此流畅，而 WinUI 3 则有明显撕裂。
话虽如此，WinUI 3 相关的进展依然十分令人期待……
替代数十年遗留桌面代码的艰难历程
微软首次推出 Win32 时并未预料它会沿用这么久，而如今 Windows 11 仍建立在这套遗留代码之上。试图在这套三十多年前编写的代码上层叠现代 GPU 加速的用户界面框架，必然引发大量渲染问题。
磁盘管理工具是 Win32 应用，至今在 Windows 11 中仍很实用内部设计团队非常清楚这些图形不一致问题。微软最近表示，已开始从设置应用着手，重视 Windows 11 设计，计划逐步替代陈旧的控制面板。March Rogers 和团队正系统地修复这些视觉缺陷，力求打造统一的桌面体验。
不过，理清这张遗留代码网络是一项艰巨任务。我们之前曾报道，微软为什么仍无法彻底剔除 Windows 11 中的控制面板。企业级深度依赖、注册表键和复杂 COM 对象无法一夜之间重写，否则会破坏关键管理工具。
这种缓慢的迁移导致用户体验割裂，现代圆润设计元素直接堆叠在过时的对话框上。这不仅限于遗留代码，Windows 8 的界面元素也依然存在，但幸运的是，微软已确认正在替换 Windows 11 中的旧 Windows 8 UI 元素。
Windows 11 登录界面在切换键盘布局时仍有 Windows 8 元素原生 WinUI 3 应用正在取代迟缓的网页包装
鉴于这些问题，微软加大了对 WinUI 3 的投入，力图拯救操作系统免受臃肿的网页应用困扰。经过多年的批评，这家软件巨头正强力转向，避免使用沉重的 React Native 和 WebView2 架构。
令人遗憾的是，像开始菜单这样基础的功能居然没有运行在原生代码上。好消息是，微软已经确认 Windows 11 的开始菜单将从基于网页的 React 组件转向 WinUI 3。
系统级对话框也在进行重大底层升级。我们看到 WinUI 3 的强大能力，新版 Windows 11 运行对话框比 Windows 95 时代的版本更快。这直接证明了现代的 C# 和 WinUI 3 框架在工程得当情况下完全可以超越古老的 Win32 代码。
这种势头正扩展至整个外壳界面。传统文件资源管理器的属性对话框正在被 WinUI 3 版本取代，并且支持暗模式。
这些进展以及即将给 WinUI 3 带来的流畅调整大小功能都非常令人期待，但最大挑战仍是说服开发者为 Windows 11 开发原生应用。
借助 Windows App SDK 2.0 重建第三方开发者信任
要让 Windows 11 真正作为平台成功，第三方开发者必须采用 WinUI 3。目前桌面生态正遭受困境。即使是微软也将 Copilot 降级为缓慢的网页应用，尽管新设计即将推出。
我们最近发布的一份报告中，有开发者解释了为什么 Windows 11 总是出现网页应用而非原生应用。主要原因是微软自己从未专注于单一框架。Windows 应用 SDK 历来存在 BUG 且难以使用。现在我们知道它还缺乏基础视觉功能如流畅调整大小。当开发者看到应用边界上的黑色撕裂时，缺乏原生开发动力，转而使用 Electron 或 WebView2 以保证视觉一致性。当然，微软尝试过多种框架后才最终选择 WinUI 3，这也不利于生态建设。
与此同时，macOS 因苹果 UI 框架开箱即用而持续获得高度优化的原生应用。
微软正积极扭转这一负面局面。最新发布的 Windows 应用 SDK 2.0 证明公司正在听取开发者反馈。SDK 2.0 引入了全新 XAML 功能、现代存储选择器、语义版本控制和扩展的弹出锚点 API。
他们甚至通过强大的命令行工具，大幅简化了构建精美本地 Windows 软件的过程。
使用命令行构建的 TabView 模板。来源：微软开发博客这套高度成熟的开发工具包，加上即将于夏季推出的流畅窗口调整大小功能，让 Windows 11 的未来格外光明。此外，五月份可选更新中引入的新低延迟模式所带来的硬件级 CPU 提升，将使这些原生应用启动时感受更快。
网页应用时代对桌面效率而言是黑暗时期，而微软对原生 WinUI 3 代码的重视正是 Windows 平台展现高级品质感所必需的。