UWP 一个技术上成功但商业上失败的框架之死；一个现代的操作系统究竟应该提供什么？

2023年初，我习惯性的打开 UWP 的 Mail app，来收发一下日常 Email。但是，令我遗憾的是，它已经建议我尝试新版 Mail App 了。

不出我所料，新的 Windows 自带的 Mail app 是网页套壳的，而不是 UWP。这意味着微软自从 VSCode 和 Teams 的成功之后，在网页套壳的道路上越走越远。以至于将网页套壳的魔爪继续伸向Outlook。

我曾经在 Windows 10 发布之初，盼望着会有一天用上 UWP 的 Visual Studio，谁知等了数年，却用上了 exe 的 MSEdge 和 网页套壳的 Mail。

UWP 这个本是 Windows 最后一次技术上的变革已经宣告失败。但，我想在念它的悼词之前，或许还可以回顾这个框架的一生。它诞生时的野心、困难、逆天的技术变革、解决了大量的问题、新的平台，还有它那悲惨的一生。

UWP 本是优秀的框架

如果一定要让我总结一下 UWP，我想最好的说法就是：成功的技术和失败的商业。

我和身边不少朋友聊起UWP，他们的反应大多都是：什么？UWP？那不是垃圾么？不是没什么App么？不是傻子才用么？不是一点三崩还没啥权限么？不是那个连下载进度条都做不好而且啥都买不到的商店里的东西么？不是给那些傻逼才买的 Windows 平板才用的App么？

但，从另一个角度来说，UWP又是微软最后一次变革优秀的机会。统一了所有设备和平台、显卡直通、动态DPI、自动更新、统一的下载中心、多语言、动态磁贴、更省电的后台运行、多语言、干净的安装和卸载、更优秀的权限控制、无病毒、ARM平台的支持、依赖处理、极低的配置要求……众多特性又决定了它几乎是一个理想的开发框架。

或许这仍然没有说服你接受UWP在技术上的优秀。我们还需要进一步讨论，Windows 平台的开发者究竟需要什么。

如今的 Windows “乱七八糟”

回顾 Windows ，我们发现 Windows 已经是一个什么奇葩都有的操作系统了。

例如，在 Windows 平台开发一个 App，应该采用何种技术？ WinForm？WPF？Electron？Qt？PWA？自研？你会发现并没有一个理想方案。

例如，在 Windows 平台，你认为一个 App 应该安装到哪里？正常的App可能会放在 C:\Program Files。可能有App会放在 C:\Users\You\AppData\Local。也可能会有 App 放在 C:\Users\You\FastCopy 底下。也可能会放在 C:\Ruby。更有奇怪的应用希望你把它放在 D:\Starcraft 盘的。。。

再比如，在 Windows 平台，你认为一个 App 的数据应该存放到哪里？正常的App可能会放在 C:\Users\You\AppData\Romaing。但也可能有App放在自己的安装目录下C:\Program Files(x86)\Steam\Userdata\1837648。有App放在当前目录。有App放在桌面上。有App放在 C:\Users\You\Documents\Tencent下……

众多匪夷所思的开发思路和“能跑就行”的新手代码总是喜欢 Hardcode 一些匪夷所思的路径，让一个用久了的 Windows 文件系统混杂的到处都是。

Windows本身还是多用户的。多个用户可能同时使用一个Windows。他们的数据会不会混杂？可不可以共享应用？你永远不知道你电脑上安装的众多应用究竟在多少你的系统路径里到处拉屎。甚至单纯卸载一个应用都不知道到底要删除多少地方，以及是给所有用户卸载还是给当前用户卸载这种问题都很难回答。

应用开发的困难

在 Windows 平台开发一个应用，不但下限极低，到处拉屎，还有更多匪夷所思的问题，本不应该让开发者解决，却最终都遗留给了开发者。

对于开发者来说，他们总是困惑与上述问题，以至于在开发一个应用时，往往更多的时间没有放在业务逻辑本身，而是放在了解决这些共同的问题上。

而显然，一个现代的框架或操作系统，早就应该提供这些东西，例如：

后台任务和资源调度

众所周知，在 Windows 右下角的任务栏通知区域，图标太多，可能意味着运行的进程太多，电脑会变卡。

但实际上电脑的性能可能和剩余的 CPU、内存、硬盘性能等关系更大。操作系统本身应该负责好调度前台的应用享受更高优先级的计算资源，并合理的让那些不常使用的应用的计算资源降级。例如我们在使用手机的时候并不需要刻意关闭一个App，而系统本身就会调度它们的计算资源让你始终都不会觉得卡。

这是一个现代操作系统的基础功能，但在 Windows 这里却非常困难。例如 Windows 也不清楚一个缩小到托盘图标的应用到底是不是可以杀死或暂停的。它可能是你的战网下载器，可能是你的微信，也可能是你的音乐播放器。杀死它们可能会影响体验。但给它们计算资源又可能意味着它们并不需要这些计算资源。

而实际上，Windows几乎任意一个进程都是可以直接吃光所有内存、CPU、硬盘资源的。在一个都无法正确处理后台任务的操作系统下开发应用，全靠每个App都当好人。一旦电脑变卡，用户可以怀疑任何一个App，或是单纯的埋怨“开得太多”。

自更新和包管理

众所周知，如今的应用很少有安装完，生命周期就停止的。几乎所有应用都需要更新来获取新的功能和安全更新。

自更新在手机上有完善的App Store或Google Play。在Linux里可以靠一个 apt upgrade。但在 Windows 这里，自己更新自己就成了一个非常神奇的事情。

Windows Update会更新系统本身和驱动。而具体那些应用的更新就都实现的非常花里胡哨。

• 有的可以靠 Winget来更新
• 有的需要自己敲命令npm update -g来更新
• 有的可以靠商店更新
• 有的是自己实现了 A\B 更新
• 有的是直接下载新版的安装程序静默安装
• 有的是下载新版的安装程序然后让用户手工覆盖安装
• 有的是直接弹出一个网页让用户自己下载新版本安装程序
• 有的直接就干脆不支持自动更新
• 游戏都还需要靠启动器和游戏平台来完成更新。
• ...

弄得想下个个大程序，还得下载和注册启动器，例如Adobe Creative Cloud、Steam这种，然后购买、更新才能开始玩\用。

或许我们习惯了这种模式后不觉得什么，但是这显然都是共同的逻辑，我们只是想让应用能够自己更新自己，让用户使用它们的时候得到一个尽可能新的版本。而不同的场景却更新的如此五花八门。

单纯的我想让我的 Windows 电脑更新上面所有组件到最新，就如此困难。

换句话说，Windows 非常欠缺一个靠谱的，能够帮我管理各个应用（甚至操作系统本身）的依赖关系和更新的东西（包管理）。

本地化和广告

本地化并非是简单的翻译。在不同国家和地区往往有不同的法律要求、语言、日期时间格式、排版习惯。例如在大部分手机上，只有一个地方可以设置语言，而这个语言设置会直接影响手机上所有的应用。

但是，这件事在 Windows 平台就显得如此困难。几乎每个应用都有独立的语言设置。哪怕是改一个 Windows 的语言， Office 的语言都不会跟着变。

再比如，应用都需要获得一个统一的广告ID，来向用户定制推送广告。或许因为这件事在 Windows 上太难了，甚至以至于 Windows 的应用都放弃了通过广告来盈利，而是只卖自家的附属服务了。而显然这件事在安卓上容易到泛滥了。

再比如说，开发者可能需要自己的 App 在不同的国家展示不同的内容或提供不同的功能，传统 Win32 应用仍然没有这种能力，而只能需要开发者自己需要开发 API 来判断这些事情。

权限

众所周知，任何一个 Windows 应用都能直接对着你的屏幕发起截图，或是重启计算机。而这一切都不需要管理员权限。

应用可以直接偷走你放在 D:\password.txt 里存着的机密，可以直接访问你 OneDrive 里塞着的小黄图，可以直接访问你 AppData 里的 Chrome Cookie 来盗你的号，可以直接把一个内网的端口暴露到公网(frpc)。

Windows的权限控制，就像：我只知道有两种情况：自己是管理员，和自己不是管理员。而对于一个不是管理员的应用，其权限又高到离谱。而有管理员权限的应用，甚至都可以替换系统文件来让你的操作系统本身变成监控工具，或是让你访问重要网站时看到假的网站，同时还有绿色的HTTPS证书。

而应用在做上述一切的事情的时候，甚至都不需要告知用户。

而一个成熟的应用框架，对于一个应用有哪些权限，何时何地访问了哪些权限，都应当告知用户，并且容易被开发者申请和管理。显然 Win32 App 在这里几乎什么都没做。

虚拟的沙盒文件系统

作为一个操作系统，本身就应该提供一个非常方便应用开发者开发各类应用的平台，包括提供应用一个好用的后台服务、推送通知、统一的存储、虚拟的文件系统、好用的权限管理，并且帮助开发者完成更新。

例如，应用本身存放的二进制就不应当让应用了解。应用更不能随意访问你的文件系统。应用只能申请到一个“虚拟的”空间，然后在里面存放自己的数据，而这个空间应当是安全、独立的。哪怕是不同用户访问同一个应用，都不应该有数据互相污染。

而操作系统本身则会优秀的调度这些虚拟的沙盒。例如：把你经常访问的应用的虚拟文件系统提前加载到RAM disk，或是可能经常用的应用文件放到NVME固态，而好几年都没打开过一次的应用，放在最慢最大的机械盘里。开发者根本不应该接触到具体的文件系统，而永远访问这个又快又大又安全的虚拟文件系统就好了。

个人使用的困难

即使对于开发者来说已经需要解决那么多问题，Windows 仍然使用门槛不低。或许你认为，如今大部分人都会使用 Windows。但让 Windows 变得好用也并不简单。就像很多人都会让一个 Windows 设备变得卡顿、不稳定而且频繁遭受病毒和黑客攻击之苦。

而操作系统本可以在这里解决这些问题，但看起来 Windows 并没有考虑把它们解决好一点。

我的电脑始终都应该快速

众所周知，让一台 Windows 电脑始终安全、稳定、快速是一个非常有挑战性的事情。即使是几十年的老 Windows 用户都可能不小心让电脑变得卡卡的。用户需要小心的组织 C 盘和 D 盘的内容，小心的处理分区，在安装新的软件前要验证它们的行为是否“清真”，还需要组织自己的桌面图标和开始屏幕等等……

而光是花这些时间维护还不够。用户需要不停的记忆自己何时打开了哪个应用，又应该关闭哪个暂时没用的应用。因为他们始终都记着 Windows的那个信条：“程序开得太多，电脑会变卡”。

一个优秀的操作系统应该始终保证，你无论如何操作，打开多少应用，你最可能操作的那几个都会响应很快。应用再次访问时，会自然的尽可能的回溯到你上次使用的状态。操作系统应当能够预测你会使用的应用，然后预先将其加载到高速缓存，并把那些你可能暂时不会用的 App 休眠（将其从高速缓存挪动到持久存储中）。

我的电脑始终都应该稳定

考虑到安装了如此多应用以后的 Windows 本身行为已经充满玄学，伴随着微软那更加玄学的自动更新，你甚至都很难保证下一次你的电脑重启后还能活着开回来。

一个优秀的操作系统应当能够正确处理依赖关系，并解决更新过程中的冲突，对各个组件有版本管理，可以对文件系统快照和回滚，并控制系统是只读和AB双份的，来保证始终都有可用的操作系统，并能在用户察觉不到的时候自己完成更新。

我的电脑始终都应该安全

而在 Windows 平台的信息安全则更加全靠经验和验证了。哪怕是运行了一段未经验证的三行的 NodeJS 的代码都可能会泄露自己的 Cookie 或 OneDrive 里的机密文件，用户不得不手工验证所有自己将要跑的东西是否是可信的。

这对于一位专业的开发者或许来说可行，但 Windows 更多的用户实质上可能是你的只会用电脑搜索菜谱的阿姨，或是一位只用电脑来打游戏的网红。

别说如今的 UEFI、TPM、Secure Boot、BitLocker、UAC、Windows Hello这些技术他们是否能够正确开启，他们甚至都无法确定自己的电脑的操作系统来源。Windows 平台的安全性仍然是上限极高下限又极低的局面。

考虑你的 Android 手机

或许你无法对上面的观点共鸣，但是当你看向自己的手机的时候，就会发现它似乎无比简单：你并没有为了安全的使用手机而学习 BitLocker 、TPM 等知识，也没有时刻都注意关闭暂时不需要用的软件，更不会担心手机放一会儿就开不开了。

你只知道，你缺什么，就打开 Google Play，然后下载那个你需要的东西就好。

而这些要求似乎在 Windows 这里，已经存在了几十年，问题在于我们并没有看到好转的迹象。

开发者和用户需要什么？

综上，

开发者希望自己可以省事儿+懒。无脑写自己的业务逻辑。操作系统本身就会帮你销售到合适的市场，推广合适的广告，在合适的时机加载到合适的缓存里，尽可能快的打开，并且有省电高效的推送和后台服务机制，而且还能原生自动更新。你无脑的访问自己的那块虚拟文件系统就好了。它永远都是那么的快，那么的安全，那么多大。至于它到底是什么，都不用管。

而对于个人用户来说，他们也希望省事儿和懒。操作系统告诉自己可能喜欢哪些App，无脑点安装就好了。不需要操心多用户；不用担心它们的权限；不用担心它们的语言不对或政策问题；不用担心它们耗电或占用后台资源；不用操心是装到C盘还是D盘；更不用自己手工更新它们。它们就是那样好用，装上就能用就完事儿了。哪怕坏了，也可以一键重置，或将特定的App恢复出厂设置。

而 UWP 明明就是希望

或许你已经发现了：我上述提到的问题，UWP都解决了！

UWP有完善的商店，能够帮助你恢复之前购买的内容，帮助你下载到正统的应用，用户只需要点点点就好了。

UWP有完善的版本管理和依赖管理，你不需要重复下载重复的依赖项。实际上大部分应用可能只需要下载几 KB 的内容就可以用了。

UWP有完善的存储空间管理和虚拟文件系统。用户完全不用管是装在 C 盘还是装在哪个目录。它们只会装在合适的目录。而且用户可以看到应用有多大、数据有多大，可以随时重置一个应用。

UWP有完善的自动更新。我从来没有手工更新过 UWP App。它们始终都是最新的。

UWP有完善的本地化。在你本国的应用商店，你下载到的App一定是面向你本国市场和本国语言的。而且当你到了其它国家，你又可以直接下载到对方国家的版本。

UWP根本不用担心开得太多或后台运行。我曾经试过，打开我电脑上已安装的所有 UWP 应用，它们仍然都丝般顺滑，使用很快，几乎不占用计算资源。而哪怕我把它们关闭了，它们又能在合适的时间给我推送通知。

UWP有完善的权限控制。我从来不担心运行一个未知来源的 UWP。我知道它的权限已经决定了它逃不出那个小方框。它读不到我的文件和硬件，也改不了我的DNS，跑不了自定义命令，也不会对着我截图，不会读我的 Cookie。

UWP还天生跨平台，几乎在 Windows 平台开发好的 UWP，不需要修改代码就可以前往 Windows Phone 或 Xbox 上继续用，而且使用习惯和界面几乎都是一样的。而且几乎所有 UWP 应用都可以快速迁移到 ARM 平台，这本应该是微软争夺移动端的一大杀器，和 Android、iOS 平起平坐的最后机会。

UWP能够正确的使用显卡渲染它们的界面。改变窗口大小不会卡顿而是实时刷新。半透明效果也不占用CPU又非常华丽。菜单的动画和手势曾经也都响应迅速，哪怕是修改 DPI 也不会变糊。怎么看都是一个非常现代化的框架。

看起来，UWP都解决了上面所有问题了！无论对于开发者来说，还是用户来说，它都代表着下一代 Windows 应用的形态，代表着微软想解决 Windows 这些陈年老问题的一份完美答卷。它好开发、好分发、好管理、好更新、好使用。连卸载都能实现1秒卸载，简直是充满未来感的一个框架。

是吗？

但现实却是……UWP死了。

UWP之死

就像我说的，UWP是未来；是完美；是答案。

但现实就是，技术上最好的框架，往往可能在商业上是最失败的。UWP就是一个典型的，构想和理念超越了一切，功能强大又简直在技术上绝对完美，又在商业上形成了绝对失败：没什么应用，仅有的应用质量也普遍底下。

一个再好用的操作系统，如果无应用可用，那么它还是废物。用户不在乎系统本身，用户在乎系统是否能够让自己运行自己喜爱的游戏和社交软件。

而在 UWP 这里，要么软件稀缺，要么即使装上了也是网页套壳、功能砍了九成。

我曾经很喜欢 UWP 的 QQ，它简洁、好用、不占资源和权限、还能后台推送。但它无法登录；我曾经很喜欢 UWP 的微信，它也简洁好用，但它后来不能后台推送消息了；我曾经很喜欢 UWP 的光环斯巴达突袭，但它又不能跨设备同步游戏进度了；我曾经还很喜欢 UWP 的知乎和 Bilibili……但后来它们都不再维护了。。。

应用的稀缺如果说需要时间打磨，功能的稀缺则是妥妥的硬伤。到后来以至于各个互联网公司彻底放弃了这个框架，不再为 Windows 开发桌面 UWP 了。似乎微软本身也放弃了这个框架，开始推出网页套壳的 Mail 和 exe 的 edge。

UWP，更像是一位新生代的太子，练就一身本领，却生不逢时。出生时，对手就已经跑了很远。即使它承担着解决老一辈遗留的众多问题的使命，它也在竞争中无能为力，又苦于无人支持，哪怕是亲生父母，又对它不管不顾的可怜命运。

已经失去了市场

一个优秀的平台，随着开发者进驻的越来越多，用户也会得到更多好用的 App。而随着用户越来越多，开发者也可以收获更多用户。

平台本身一旦成功，对于吸引用户和开发者来说是双向的胜利。

但失败的平台，往往用户也不愿意用，开发者也不愿意开发。在微软已经失去了移动端市场以后，或许短期内还可以靠支持和补贴强行拉拢开发者，但这种话语权的丧失不是一天就能重新争夺回来的。

随着微软放弃移动端市场，我看到的更多的，像是微软放弃这种用 UWP 去重新争夺消费者市场的野心。反而对于消费者的产品变成了："凑合能用就行"的态度。这种情况下，几乎没有开发者愿意用一个“只能在Windows 10上跑”的框架去写一个Windows应用了。

UWP 初期，应用和平台普遍质量都不高

UWP应用初期质量都很差。当然这我可以理解。但是连微软自己的 UWP 大部分功能都不咋地。

就比如那个应用商店，下载进度条就都是玄学。经常半天不转，又一下转一大半。

就比如微软自家的 News，能不能打开都是玄学。经常自己非要认为自己没网了，也不说到底是什么错误信息。

作为微软自家的老 UWP Edge，打开网页又经常莫名其妙白屏不动，也没有任何响应或进度，多标签又经常崩溃，所谓的高性能又完全只能在理想环境里复现，而体验上根本不是 Chromium 的对手。

UWP的早期，闪退、莫名其妙没有响应，等了半小时都没打开……这些问题都成了日常问题。这种极差的用户体验已经让用户默认：UWP = 低质量App。

同一件事，一大堆方案

例如，让你在 Windows 上安装 Outlook，你有多少方法？

你可以使用 UWP 的 Mail。你可以安装 Office 来访问桌面版 Outlook。你可以使用 PWA 的 Outlook。你可以使用下一代 Mail 的网页套壳，你甚至还能使用 安卓子系统的 Outlook。关键它们功能还各不相同？！

你在 Windows 11 上使用 OneNote，仍然可以使用经典桌面 OneNote，还可以使用 OneNote PWA，还可以使用一个叫 OneNote For Windows 10 的 UWP ？！ 而且它们功能也不相同？？

你在 Windows 11 里打开一个视频……你可以使用 Videos，你可以使用 Photos，你可以使用 Media Player，你甚至还可以使用 Windows Media Player ！？而且它们的功能也不相同？？

最离谱的是，微软自己似乎对于如何设计一个 UWP 应用都没有统一的设计风格。哪怕是自家的应用都似乎分裂成了数种不同的风格。

开发一个 UWP 应用的难度其实不低

和传统 Win32 上来就干不同，UWP 的学习曲线陡峭了许多。考虑到它更像是托管模式下舞台的演员，它更多的开发过程需要让开发者正确的学习如何使用这个“舞台”。例如，UWP不能直接访问文件系统、不能直接访问硬件、不能直接访问进程和命令，那么大量应用直接就几乎无法使用 UWP。

你不会找到 UWP 的垃圾文件清理器、硬盘诊断器、CPU跑分器，不会找到 UWP 的硬件测试小工具，不会找到UWP的数据库，更不会找到 UWP 的安全工具。

• UWP 最多做一个压缩文件管理器，也因为无法在右键菜单注册而显得不是那么容易使用。
• UWP 很难去截取屏幕，也更不会看到 UWP 的直播工具；
• UWP 很难覆盖在另一个窗口显示内容，你不会看到 UWP 的辅助工具；
• UWP 很难和其它进程通信。你不会看到 UWP 的开发工具，最多只有代码编辑器；
• UWP 很难使用一些高级网络特性，你不会看到 UWP 的网络工具，最多只有网速测试器；

这显得 UWP 似乎更适合开发 Twitter、Instagram、Youtube这些社交媒体应用。微软都亲自示范了 UWP 的社交媒体 App 究竟能有多难用。显然这些社交媒体公司又看不到投资这么一个框架有何种前景……

此时，个人学习开发者、DIY爱好者、大型企业、需要让自己应用跑在 Windows 7上的开发者……他们几乎全部放弃了这个框架。那么剩下的又还有谁呢？

UWP 之死

到这里，只能见证了这件事： UWP 死了。而且毫无生的希望。

我认识一位，以熟练开发 UWP 闻名的微软MVP，阿迪王。或许他对微软最大的怨恨，就是放弃了 UWP。随着WinUI从UWP中迁移出来，UWP似乎是一个尸体，再从尸体中搬走一些能用的组件去发挥点儿余热吧。

新的开发框架：MAUI 正在重生。它们放弃了上面 UWP 的所有优点，重新回到了 Win32 的开发模式，但世界已经很难接受它了：虽然有了新的跨平台特性，却仍然卡得像是网页套壳。

我时常问自己：难道我的子孙，将来用到的所有应用，都会在改变窗口大小的时候卡得像 Teams 一样吗？都会在一个系统里解决一个事情能有四五种方法吗？都需要和其它进程互相抢夺资源再在硬盘上到处拉屎吗？都需要安装前仔细验证吗？

UWP 像是新生代又生不逢时的太子，也像是一位过客，让 Windows 的历史上出现了这么浓墨重彩的一笔，让我还知道，曾经 Windows 里的应用，是可以用赛扬处理器跑也不会卡的。