C#在Windows UI开发中的衰落
其实这方面有个之前在Hacker News上的博客讲过了，但是我最近还是要气死了。总而言之，如果你想要开发一个小软件（单文件），那么你现在应该选择C++（MFC）、Rust（Winio）、Rust（windows-reactor，需要等待这个bug被修复），没有任何选择C#的理由。
在今年的Microsoft Build上你软又双叒叕重申了对UI开发的承诺，将WinUI3改名为WinUI并保证没有下一个UI框架了（first time？）。看到这我的内心毫无波动甚至还想再给MFC续一秒。然后Build上发了个大的，就是Rust上的WinUI3框架，windows-reactor，还有一个很好玩的VibeOS，没啥别的了。
在WPF推出后，C#上的UI framework基本上就已经变成了现在的样子，那个时候是C#3.0，现在是C#14。直到WinUI3出现，半死不活的C#拉了一坨大的，我们看看微软员工自己给出的对比（来自添加windows-reactor的PR）：
| 指标 | Rust | C#（JIT） | C#（PublishAOT） |
|---|---|---|---|
| 从零构建 | 11.0 s | 23.9 s | 50.8 s |
| 部署体积 | 3.34 MB | 128 MB | 163 MB |
| 首个窗口出现时间 | 160 ms | 465 ms | 364 ms |
| 稳定后的工作集内存 | 109.5 MB | 162.6 MB | 128.4 MB |
| 私有内存 | 101.0 MB | 121.0 MB | 117.3 MB |
| CPU 时间（启动 + 稳定） | 594 ms | 1,063 ms | 906 ms |
| 重渲染时间（4,900 个单元格，10%） | 3.1 ms | 27.0 ms | 29.4 ms |
真的是给我看笑了。windows-reactor理论上可以单文件发布（实际上最少三个文件，等修吧，winio是可以真单文件），而C#来写WinUI3不仅依赖又臭又长还大。
WinForms和WPF的问题
第一关，你应该使用dotnet Framework还是dotnet？前者随Windows一起分发，但是性能和现代特性的支持都非常的烂；后者因为UI框架的原因无法使用AOT，要么打一个巨大的自包含EXE要么让用户手动安装运行时，好在没有运行时的时候还会弹窗让你下载（不过还是很阴间，因为Framework没有的时候会自动跳疑难解答安装不用手动下载）。
第二关，DpiAwareness。这关基本上把WinForms应用判了死刑，这东西做支持真的太狗屁了，不要尝试手动做。兼容模式和manifest有些时候也会不起作用。WPF在这方面则好一些，起码在大部分情况下Dpi是正常的，不会在你的高分屏上糊成一坨屎。
第三关，高低版本上的WPF库的兼容差异，以及GPU的引入。先不说你要遴选用的三方控件库或者DataConverter库，GPU这个东西有好有坏吧。其实WPF用GPU渲染挺好的，但是这会导致某些笔记本或者多显卡可弹出的台式电脑独显一直占用无法被关闭。使其不能够进入最省电的状态，占用GPU这块。然后默认的WPF主题也是很丑的，如果你用了ModernWPF这种库又会导致Designer和占用内存的大幅度提升，我还能说什么。
最后是大小。基本上，你无法在10M内发布整个软件，这对于一些工具软件来说是不可接受的。我只有一个窗口，用MFC来实现可能只要500K，但是用WPF可能就要十几个DLL+巨大的体积，所以这两个东西真的很不好用，当然企业级应用用着没问题。
值得一提的是生命周期。Winforms早就已经进入维护模式，WPF一直半死不活偶尔诈尸一下，性能优化也不怎么吃的到。现在的新欢是MAUI（以前叫Xamarin），但是这东西手感一坨，也是又大又垃圾，令人忍俊不禁。
MFC和Avalonia
MFC是个老东西了，会写的人都知道坑点在哪里。至于Avalonia，我建议你可以看看Flutter，这两个原理上都差不多，但是目前来说Flutter提供了更高的自由度。
MFC说实话真的应该被淘汰了。先不说被喷烂的Windows + C++开发；手动处理并分发Win32消息循环，手动处理UI线程和工作线程的切换，手动处理DpiAwareness，手动处理高分屏适配就已经很恶心了。MFC过于底层，非常的新手不友好，而且会非常容易写出来一个屎山项目。
View/Document模型也已经实际上过时了。总之从现代性的角度来看MFC已经输了一切。但是它实在太小了，依赖也太少了，一个vcrt就解决了，基本上不会缺。性能也好，只要你能够正确的写出App，这基本上是Rust方案出现前的唯一选择了。
Avalonia，阿瓦隆。确实是一个幻想中的地方。这东西依赖Skia，所以不可能单文件部署，而且性能也挺差的，不如看看隔壁Flutter。
C#与MFC
我之前写小东西的时候都想笑。我居然在C# AOT的ConsoleApp中call kernel32和user32来做UI。这大概率是C#中写出最小GUI应用的方法了吧。当然还有个叫cs-gui的TUI库，总之也一般。
MFC的特点是，if you want it, then you have to take it。什么组件都需要自绘。看xxx不爽？不好意思没有主题自绘去吧。无障碍和响应式则是根本想屁吃。不过起码是一个非自绘原生应用，不是吗？
Electron和Tauri
先说结论：很少有人用Tauri上生产，这个东西真的烂到家了。所以你只能选Electon（电子）。
是啊，电子垃圾。这东西能够在和WinUI3原生框架差不多大小的发布大小中塞入更多先进的特性，并且提供更好的性能。谁会在乎一个小工具居然要占用200M空间呢？进入AI时代后，因为AI真的很会写前端，Electron也越来越成为了一个开发首选项，虽然在AI时代来临前大家都在用Electron了。
Fun fact：React Native相较于C#，离WinUI3更近。
最后
不难看出，C#似乎并不关心Windows UI开发，这倒也符合微软一贯以来的尿性。在CLI，TUI和Web Server上（甚至包括前端），C#都工作的不差，除了最本职的Windows开发以外，在别的平台也过的挺好的。
我不知道下一个良好的C# UI framework到底是什么，但是至少不会是现在的这些。让我们把应用重写到Rust吧。
一个更大的议题是原生应用的衰落，但是我确实不怎么了解其他平台的问题，虽然知道问题很大。一些神经病公司也开始转向跨平台框架（弱智小米的新的安卓桌面是Flutter写的你敢信，大小性能还有手感全部稀烂），似乎没有人在关心原生应用了。All in Web和Web类似物喵。