本文告诉大家 UWP 和 WPF 的一些不同之处
从技术上讲 Universal Windows Platform (UWP) 和 Windows Presentation Foundation (WPF) 是不相同的，虽然都可以做界面和桌面开发，但 WPF 是 Win32 系的，而 UWP 作为一个新的 UI 框架，属于 WinRT 系的。在微软的野心驱动下 UWP 是支持很多平台，虽然这些平台除了 Windows 外，几乎没一个能打的，但从支持的平台数量上就是比 WPF 多
开始之前必须说明的是 WPF 和 UWP 不是两个对立的框架，而是两个可以相互嵌套同时使用的框架。换句话说我可以在一个应用里面同时使用 WPF 和 UWP 框架。我可以按照我的心情决定哪部分界面使用 UWP 写哪部分界面使用 WPF 写
那么 UWP 可以使用什么语言写？
-
xaml 做的 UI 和 C#、VB 写的后台逻辑代码
-
xaml 的 UI 和 C++ Native 写的后台逻辑代码
-
DirectX 的 UI 和 C++ Native 写的后台逻辑代码
-
JavaScript 和 HTML 的组合，只不过这个和废物一样
而 WPF 呢？他可以使用 xaml 做的 UI 界面，使用 C#、VB、F#、C++写的后台逻辑代码
不过需要知道的是，以上说的 WPF 的 C++ 后台逻辑代码，使用的是托管的 C++ 方式，而不是传统的 C++ 方式
那么网上怎么好多小伙伴说 UWP 的性能比 WPF 好？
性能好不好有多个方面，讨论性能问题可以分为两个方面，一个是框架级方面，一个是业务级方面。框架级上核心的不同在于 UWP 默认用上了 DirectComposition 技术进行渲染，而 WPF 框架默认没有用上。 从渲染上的性能差倒是和 DX9 等差异不大。业务级上的最大不同在于 UWP 砍掉了大量的 WPF 功能，将那些可能会影响性能的控件和写法大量的砍掉，从而减少开发者写出降低性能的代码，比如说 VisualBrush 等
发布时间
WPF 在 2006 年发布，那时使用的 .NET Framework 3.0 ，现在已经是 WPF 7 了，支持的 .NET 已经到 7 了
UWP 在 2015 年发布，那时还没有 .NET 1.0 的发布，这也导致了 10240 这个版本的存在许多诡异的问题。在 2302 年的时候，应该很少有开发者会考虑使用 10240 如此低的版本了
系统要求
采用 WPF 框架搭配 .NET Framework 4.0 可以最低支持到 XP 系统。 但值得一提的是 .NET Framework 在 4.5 之后才是大力优化提升，修复了大量的问题，不仅仅只是 WPF 框架层的问题，也修复了 .NET Framework 的问题
跟随 Win10 发布的 UWP 自然没话说，最低系统要求就是 Win10 系统。由于 UWP 使用了 Win10 系统的 WinRT 且使用 Win10 系统的 Pointer 输入系统，同时也使用到 Win10 的渲染架构，这就意味着从技术上 UWP 就不能在 Win10 以下的版本运行
输入
默认的 WPF 是触摸友好的，但也要说版本，在 .NET Framework 4.7 之前的触摸支持较弱，会有一些诡异的触摸问题。这里说的 .NET Framework 4.7 指的是运行时框架版本，而不是开发 SDK 版本。意味着即使开发者使用 SDK 版本是 .NET Framework 4.5 版本，但只要用户端安装的是 .NET Framework 4.7 以上版本，即可修复许多触摸问题
和 UWP 相同的是 WPF 也可以在 .NET Framework 4.7 或 .NET Core 以上版本开启 Pointer 消息。通过 Pointer 消息可以支持触摸、鼠标、视线等输入
界面
虽然 WPF 和 UWP 都使用 xaml 做界面，但是渲染是不相同的。 WPF 的渲染都是使用托管代码计算，然后通过 Channel 通道给到 GFX 层，底层调用 DirectX 9 的 API 进行渲染。渲染完成给 DWM 显示到屏幕上
而 UWP 的渲染底层采用 DirectX + DirectComposition 方式，通过 DirectComposition 方式提升了渲染输出性能
从 Demo 级应用上来说，采用 UWP 的渲染损耗更低，性能更高。从大应用来说，由于性能点不会在渲染输出等的性能损耗上，总的来说 WPF 和 UWP 的渲染差异极限情况下可以持平，或者说 WPF 略弱于 UWP 的渲染性能。在使用 Windows App SDK 后，即可在 WPF 用上 DirectComposition 渲染，此时两者底层渲染相同，理论上渲染性能相同
两者相同的是，界面也可以完全扔掉 XAML 换成完全的 C# 代码完成界面
定制
古老的 WPF 是完全封闭的，也是闭源的，定制不友好。但是在 2016 年之后，整个 WPF 具有极高的定制性，当前的 WPF 在 https://github.com/dotnet/wpf 完全开源，使用友好的 MIT 协议，意味着允许任何人任何组织和企业任意处置，包括使用，复制，修改，合并，发表，分发，再授权，或者销售。在仓库里面包含了完全的构建逻辑，只需要本地的网络足够好（因为需要下载一堆构建工具），即可进行本地构建。开源的，也就完全可以定制，例如我现在就使用自己的定制版
而 UWP 的定制性就非常有局限了，如果想要有更高的定制，可以考虑采用 WinUI 3 框架
样式
虽然看起来 WPF 和 UWP 的样式定义是一样的，但是 UWP 没有了功能很好的 Trigger 和样式继承。这样 UWP 的功能就没有 WPF 那么容易定制。
而且 WPF 和 UWP 的设计器经常无法使用，好在这两个都可以在运行修改样式。另一个差别是在运行时 WPF 可以通过 Snoop 工具查看元素的值，但是 UWP 不可以，总的来说调试 UWP 界面还是比较难的
调试
在 WPF 如果有一个代码抛异常，那么 VisualStudio 很容易告诉大家是哪里异常，也许 VisualStudio 也是 WPF 写的原因，一切工作的挺好的
如果是 WPF 框架层抛出的异常，在采用 .NET Core 版本时，可以在 VisualStudio 2022 或以上版本自动拉取 GitHub 上开源的代码，如此调试更加方便。在采用 .NET Framework 版本时，可以找到部分源代码，也可以辅助调试
由于 UWP 大量使用到 WinRT 组件，基于 COM 的 WinRT 组件经常只能给出一个 COM 异常，接近无法更近一步进行调试，除非开启本机代码调试
安装
现在的 WPF 可以做绿色版，直接运行就可以。在 .NET Core 3.1 及以上版本，可以带上框架环境，完全绿色不需要用户环境安装框架
现在的 UWP 可以通过应用商店正常发布，也可以通过旁加载方式做私有发布。在国内发布 UWP 产品应用，我基本都是通过私有发布方式。详细请看 加强版在国内分发 UWP 应用正确方式 通过win32安装UWP应用
文件权限
关于权限方面，基于 Win32 的 WPF 绝对能完成基本所有的流氓任务，没有什么限制。对比 WPF 这么不安全的方式，如果开发者使用 WPF 去做坏事，那肯定用户会将锅砸在微软头上，于是微软十分机智的给 UWP 加上了一大堆限制。想要使用 UWP 做什么都会缺少权限
成熟程度
总的来说 WPF 是比较成熟的，距离 WPF 第一个版本已经差不多 20 年了，而且这差不多 20 年的时间内都在不断更新迭代，有大量的开发者踩过了大量的坑留下大量的经验，也有非常多的基础库可以快速实现功能
而 UWP 发布到现在快 10 年了，也算比较成熟的技术了，只是在 2023 年时我的测试发现了 UWP 依然受系统环境影响极大，从质量的角度上还是不能和 WPF 比
参见：UWP vs. WPF · jbe2277/waf Wiki
感谢
特别感谢 Naruto Mouri 指出文章的不足
原文链接: http://blog.lindexi.com/post/UWP-%E5%92%8C-WPF-%E5%AF%B9%E6%AF%94
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。 欢迎转载、使用、重新发布，但务必保留文章署名 林德熙 (包含链接: https://blog.lindexi.com )，不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请与我 联系。