微软已经在10月5日面向普通用户推送了Windows 11正式版，想必很多朋友已经用上了这最新一代的操作系统。

而如果你是一名微软粉丝，有长期关注微软生态，那么可能会注意到Win10时代被频频提起的UWP生态，在新系统的到来之际竟然近乎销声匿迹。

实际上，这并不是错觉。UWP这个在Win10时代，曾经扛起微软生态的大旗，在Win11时代已然倒了下去。

不久前，微软在Windows应用程序的开发文档中透露，主推Windows App SDK和WinUI 3开发，UWP不再作为开发基础。

因此，UWP事实上已被微软弃用，这个曾经被寄予厚望的微软新生态的引擎，已经成为了时代的弃子。

在Win8乃至Win10时代，人们诟病于Windows系统中残留的老旧痕迹，老软件乃至系统本身的风格和新设计格格不入，人们一度将Windows生态翻新的厚望寄予在UWP身上。

然而事情的发展却出乎人们的意料，UWP被放弃的同时，Win11却成为了近年来改版力度最大的Windows桌面系统，很多系统组件例如文件资源管理器都纷纷用上了新设计。

除了Win11系统本身，大量微软App也在Win11时代全面拥抱了Fluent Design等新设计。

这似乎是Windows生态华丽转身的一个好兆头。但归根到底，这仍是微软自发的行为，除了系统自带组件和第一方应用，更重要的是第三方软件。

在今后第三方的Win软件还会源源不断迎来翻新吗？还是说Win11的改版仍只会是昙花一现、大量Win软件仍旧积重难返？今天就来简单谈谈吧。

在展开话题之前，我们先来回顾一下微软为何要放弃UWP。实际上，UWP生态萎靡，已非一朝一夕之事。

早在Win11尚未公布之前，Win10上的UWP生态就已经半死不活，大量知名UWP应用早在去年前年就已经停止更新，大厂的UWP产品更是被Win32转制版软件取而代之，例如QQ、微信、网易云音乐都是其中典型。

UWP开发规范主打跨平台，从其名字“Universal Windows Platform”中就可窥一斑。

UWP应用可以同时适配移动和桌面平台，但随着WP/Win10M宣告失败，UWP这座桥梁的意义就很值得怀疑了。

UWP应用的API并不如传统的Win32软件来得丰富，收到诸多限制，例如UWP应用必须在App Container中以沙盒的形式运行，难以获取很多常见的系统权限，不少功能受到限制，例如UWP应用如何使用系统代理就是个难题。

和传统软件相比，UWP应用功能没有那么自由，能调用的资源更少，受到更严格的后台限制，而且某些应用还很容易闪退。这带来了很不好的用户体验。

Windows一大优点在于兼容性，无论使用新老开发工具，所编写的程序都能在最新的Win10中跑起来，这令很多开发者至今仍使用旧版本的开发工具，以同时兼容Win7、Win10等多个版本的系统，大家并没有太多动力为了UWP就把开发工具时时保持在最新。

，这都影响了开发者的开发意愿。

种种原因综合之下，UWP的发展长期处于低潮。而其中的很多问题，又是微软无法解决的。例如UWP的定位在于跨设备跨平台，要兼顾桌面和移动环境，这就意味着自由度高的桌面开发环境必须向存在种种限制的移动开发环境妥协，导致的结果就是UWP应用功能受限、向后兼容性受限。结合当前微软在移动市场的表现，UWP的确没有太大存在的意义了。

UWP不再被视为Windows开发的重心，但Windows 11中，大量软件应用反而焕然一新，这又作何解释呢？

事实上，UWP尽管没有取得什么大成功，但它的很多遗产，却被继承了下来，这让Windows在此后的生态建设中，更加顺风顺水。

就如文章一开头所提到的，微软将会把Windows开发的重心转向Windows App SDK和WinUI 3，但这两者又是什么来头呢？其实它们的构成，和UWP是脱不开关系的。

在Win10时代，微软推行UWP，而UWP所用的控件和样式库则被称为WinUI 2。WinUI 2和Windows 10 SDK集成，为UWP提供Windows UI控件以及其他UI元素。

然而，WinUI 2却有仅仅适用于UWP开发，对于传统的Win32软件，它无能为力，无法为传统的Win32软件提供界面、样式更新。

如此一来，如果软件不转向UWP开发，那么即使更新版本，那么往往也只会使用WPF、MFC等比较老旧的开发工具。软件不使用UWP开发，就无法用上WinUI 2，就没法跟上Windows系统的界面更新，这让Win10时代视觉效果极其割裂。这个情况，在Win11时代似乎要得以改观了。

在开发Windows 11的同时，微软也盘算起了整理软件开发生态的路子。在去年的Build 2020开发者大会上，微软公布了“Project Reunion”，这是一套整合UWP和Win32开发的方案。

微软试图通过Project Reunion，将Win32和UWP API与Windows 10脱钩，并将UWP中出厂的API提供给Win32使用，以 “弥合”两个平台之间的差距。现在，Project Reunion已经取得了初步的成果，那就是新的Windows App SDK以及WinUI 3。

全新的Windows App SDK融合了传统Win32以及UWP应用关键技术，并使用 WinUI 3作为UI框架。

此后，开发者为Windows开发软件，无论是开发Win32还是UWP，只要使用Windows App SDK，即可让软件用上新的界面——没有使用UWP重构的文件资源管理器得以翻新，就受益于此。

需要注意的是，Windows App SDK并不会取代掉之前的Windows SDK或现有桌面Windows应用类型，例如 .NET（包括Windows窗体和WPF）和桌面 Win32等。

而是使用一组通用API来补充这些现有工具和应用类型，开发人员可以在这些平台上依赖这些API来执行操作。

换言之，Windows App SDK通过拓展更多的API接口，让Win32开发也如UWP一样标准化，让开发者可以轻松调用WinUI 3来构建新的软件界面。为Win32软件开发新版，不需要将Win32软件重构为UWP，传统软件也能用上新界面了。

那么问题来了，Win10时代开发者并不愿意使用UWP，在Win11时代大家就会拥抱Windows App SDK和WinUI 3吗？恐怕其中仍有一些疑虑。

首先需要肯定的是，Windows App SDK的确解决了UWP力所不逮的一些问题。

例如UWP应用功能受限，而Windows App SDK可以用于Win32开发，就减少了很多限制。

Windows App SDK打破了软件开发在功能和API调用等方面的瓶颈，让Win32软件衔接最新Windows界面不再有功能方面的顾虑。

但与此同时，Windows App SDK并没有解决UWP开发的很多问题。

UWP向后兼容到Win10 1703，而Windows App SDK的兼容性更差，只兼容到Win10 1809。如果开发商打算让软件继续兼容Win7、Win8，那么必然不会选择Windows App SDK。

将老软件迁移到Windows App SDK，并不比将其重构为UWP简单，很多历史悠久的大型软件，已经累积起了稳定生态和客源，并不一定愿意做这方面的工作。

事实上，Windows App SDK才刚刚发布1.0稳定版，很多开发框架尚未稳定，也远称不上成熟。

根据微软的规划，Windows App SDK在未来还会通过XAML Islands支持WPF、WinForms和其他带有WinUI3的应用程序，但这些规划是否能落实？微软砍刀部会不会再次大发神威？恐怕很多人会选择观望。

当然，如果开发者迫切想要软件跟上Win11的节奏，或者想要让产品在Windows商店中上架，Windows App SDK还是颇具吸引力的。

Windows App SDK提供了更多适配Win11新系统特性的接口，例如电源管理、应用窗口管理、进程周期管理等等，使用它来开发软件，在Win11上的运行效果肯定会比传统开发来得更好。

简而言之，Windows App SDK有其价值所在，它为Win32软件提供了适配新系统的开发方案，并整合了UWP。

但与此同时，它并不成熟，也存在兼容性等问题。开发者是否会跟进Windows App SDK和WinUI 3？恐怕还是得视实际情况而定了。

Windows软件是否可以翻新？微软的确已经给出了Windows App SDK和WinUI 3的方案。然而，Windows系统的一大核心竞争力，在于强大的兼容，这既体现在新系统对老软件的兼容，也体现在新软件对老系统的兼容。

而无论是UWP还是Windows App SDK，都在试图打破这一局面，因此新开发规范的推广，也一定会遭遇障碍。

Windows并非是一个封闭的系统，微软很难让大家都跟随自己的脚步，拥抱应用商店和新的开发套件。

这意味着，微软必须在这些方面提供足够多的吸引力，才有可能让Windows的生态脱胎换骨。微软能在Win11时代做到这一切吗？我们拭目以待吧。