回到 XAML 的原点：WPF 的诞生与文艺复兴之路

时钟拨回 2003 年微软为下一代 Windows Longhorn 设计了一个全新的用户界面框架几个核心理念深深影响了它的基因图形能力相比 MFC 和 WinForms新框架需要硬件加速才能支持丰富的视觉效果和动画角色分工让设计师专注界面设计让开发者专注业务逻辑建立各自独立的模式专业工具不仅仅是简陋的可视化设计器而是真正的专业级设计工具开放生态支持多种开发语言而不仅仅是 C#。经过多年探索最终的答卷就是 Windows Presentation FoundationWPF。它不仅提供了强大的图形能力更重要的是引入了 XAML可扩展应用程序标记语言把界面定义从代码中解放出来。这是一个革命性的想法也深刻影响了后来的类似框架开发。# 最初的光荣与现实的挑战理想很美好但现实总是很复杂。## 大棒硬件的残酷现实WPF 对硬件加速的依赖在当时是个出乎意料的问题。显卡驱动质量参差不齐导致 WPF 程序频繁出现显示异常、崩溃。用户怨声载道开发者信心受打击。同时代其他采用 GPU 加速的产品还有谷歌的 Chrome 浏览器。所以微软和谷歌联合多家厂商一起推动了显卡驱动质量的改进。这种先驱者排雷的过程虽然对早期用户造成了痛苦但最终让后来的框架、产品集体受益整个生态的硬件支持也随之改善。但对于 WPF 开发者来说这仍然意味着早期部署就需要仔细的硬件兼容性测试。后来微软也在 WPF 中加入了软件加速的回退机制在极端情况下保证程序至少能运行。## 挑战设计与开发的距离WPF 一开始的雄心也体现在它的配套工具上。Expression Blend 是个独立的专业设计工具微软甚至希望包括它在内的 Expression Studio 产品线能与 Adobe 相关产品竞争。但讽刺的是这个「专业性」反而限制了它的普及。大多数 WPF 开发者根本不会单独再买一套 Blend就只能回到 Visual Studio 2008 自带的简陋设计器无法发挥 XAML 设计方面的真正优势。从工具产品这样的安排上我们还能体会从理论上 WPF 的设计基于一个预想——设计师和开发者的工作要分离但快速普及的敏捷开发观念让这个分离变成了遥不可及的梦想。边界模糊沟通频繁开发设计环节越来越需要紧密交互所以强行分离之后效率反而下降。Expression Studio 产品线最终被微软放弃Blend 的功能被合并进了 Visual Studio 2012。虽然这意味着 WPF 单独的设计工具生态没有得到持续的投资和发展但 WPF 开发者至少得到了一个更集成的开发环境这倒是个有趣的结果。## 难题XAML 的学习曲线XAML 很强大但也很复杂。对于没有编程背景的设计师来说XAML 的语法和概念可能是巨大的学习障碍。换个角度习惯了 C# 等代码编程的开发者也需要时间才能真正掌握这门设计语言玩转样式、模板、数据绑定、动画等核心特性。WPF 还有其他“野心”例如支持多种开发语言。但现实中只有 C# 和 VB.NET 这两种 .NET Framework 的语言最后做了 WPF 程序开发的适配使得还在使用 C 等其他语言的开发者不得不完全放弃了 WPF 这个新技术。这严重限制了 WPF 的应用范围。# Web 战争、内部竞争与逐渐的边缘化为了对抗 Flash微软把 WPF 技术拓展到了 Web 平台形成了 Silverlight 平台。技术不错但时代浪潮已经改变。HTML5 作为开放标准的崛起让闭源的 Flash 和 Silverlight 都成为了注定失败的尝试很多从 WPF 转向 Silverlight 的开发者也因此失望而归。同时期 iPhone 和 Android 的火爆使得微软不得不抽调资源应对移动化的挑战。从 Windows 8 到 Windows 10一系列的新界面框架涌现出来例如 WinRT、UWP直到最近的 WinUI 3……每一次宣传都会提到“这次真的不一样了”。但 WPF 的用户群体内心已经波澜不惊了因为这些碎片化的平台很快就被微软自己束之高阁。随着这些走马灯似的的新框架XAML 语法在微调控件体系在变化设计工具在弱化。快速迭代本来是好事但对于已有数千个生产系统的 WPF 开发者来说这简直就是灾难。假使紧跟微软的步伐那每一次变化都意味着需要重新学习、重新适应。到了现在情况变得清晰。WPF 仍然被官方支持甚至已经迁移到了 .NET Core 3.0 以及更新的 .NET 平台上。但是微软的研发重心已经转向 WinUI 3、MAUI、Blazor甚至是有紧密合作关系的 Uno Platform。WPF 的更新已经变得非常有限在过去几个 .NET 发布版本中几乎停滞了。更扎心的是MAUI 最近开始在10和11两个版本加入简化 XAML 语法、内嵌 C# 表达式等新功能。而 WPF 开发者们感受到了什么一种被微软忽视的压力。但这个故事本不必这样。# 社区的觉醒不必事事等微软这里有个关键问题WPF 的进步一定要由微软主导吗不必。WPF 仍然强大、成熟、稳定。数千个企业级应用还在日常运行。这些应用的开发者完全有能力通过社区的力量来推动 WPF 的进化或者更稳妥地迁移到其他框架。方式有很多开发第三方工具链——开放的设计工具、性能优化、调试工具提供不被 VS 锁定的开发体验。这方面一直有欠缺。丰富控件库——社区可以维护和扩展 WPF 的生态。这方面多年以来还是有一些成果的。提供迁移桥梁——帮助需要的开发者平滑地采用新技术而不是草草放弃在 WPF 平台的前期投资贸然重写。这一块的市场还有待挖掘。# WPF 的真正困境不是工具匮乏而是工具的身份限制重新审视 WPF 开发者的处境有一个很少被提及的事实是WPF 的工具链其实非常好问题在于它被牢牢锁定在微软的封闭生态里。这听起来矛盾但事实是如果你用 Windows 上的 Visual Studio那么做 WPF 项目有着完整而现代的体验代码编辑有丰富的语言服务、热重载和可视化设计器、参考代码和成熟教程。这套工具链足以给后继者压力。比如微软自家 MAUI 和 WinUI 的初学者至今还需通过 WPF 的 XAML 学习资料才更容易达成入门目标而且这两个微软新框架都没有同等级别的设计器或者系统性书籍。但 WPF 和它的工具链有三个致命的局限Windows 专有。对于一部分需要跨平台支持的开发者来说WPF 就不再是一个他们可以考虑的选项。Visual Studio 专有。用户自身或者开源社区无法轻易去扩展这些工具来达成自己的需求。进入了相对平静的维护阶段微软似乎已经没有专门的团队在推进也没有明确的新版本规划只是保持现状和打补丁。结果就是WPF 拥有微软能提供的最好最稳定的工具链无法跳出这些限制。而其他采用 XAML 几个框架Uno Platform 等如果想要达成相同级别的开发体验又完全无法充分借用微软这些已经存在的工具。这就是下面将介绍的 XAML Source Generator (XSG) 的根本价值所在。它的出现不是为了修复 WPF 的工具链WPF 的工具已经够好而是便于各框架能在统一基础上创新避免各自去复刻微软的闭源工具链。# XSG从单一框架创新到多框架采用XSG 的发展故事很能说明一些现实问题。Uno Platform 官方是最先研发采用 XSG 技术的。微软也看到 XSG 的价值因此开始在 MAUI 10和11周期中挖掘这项技术的潜力。这两者都是由厂商官方支持的。也很正常作为公司项目他们有资源来追求最佳实践。但 Avalonia 和 WPF 的 XSG 技术落地就有着不同的故事线。两个框架都由社区先行驱动 XSG 工具的落地项目。Avalonia 那边的 AXSG 工具链是知名社区贡献者开发的WPF 也是由开源社区推进着 WXSG 项目的实现。Avalonia 生态中因为 AXSG 而导致的波澜更是值得单独章节讨论这里就暂且按下。不过相似点是在官方优先级并不在接纳 XSG 技术的情况下开源社区仍然看到了这项新技术的价值并推进它的落地。这就是开源社区的真正力量不依赖厂商的支持和决定凭借对技术本身的认识自己去推动创新。这不是平台的分裂而是理性的技术选择。**透露一下我的立场**作为 WXSG 的主要参与者之一我并不是站在完全旁观者的角度来写这篇文章。我对 XSG 这个技术方向有实际的投入和信念。这不是说文章的观察就不可信而是希望透明地声明后面的判断既来自对 WPF 生态历史的理解也来自在这个方向上实际工作后的体会。严肃的评论应该允许有这样的立场关键是要把立场亮出来而不是假装完全中立。# XSG不仅仅是性能更是开发体验的革命XSG 通过源代码生成的方式增强了 XAML 的开发体验但它的意义并不只是“把 XAML 变成更多 C# 代码”这么简单而是把原本主要供运行时消费的各种标记转化为编译器、语言服务器、设计器和热重载系统都能更好理解的结构化输入。## 更早暴露问题而不是把问题留到运行时传统 WPF 的很多能力建立在运行时加载、对象树构建和绑定解析之上因此不少问题往往只有在运行时才能充分暴露出来。XSG 把其中一部分信息前移到编译期和设计期让工具能够更早理解 XAML 的结构、类型和上下文。这意味着更早发现类型或命名错误更可靠地提供补全、跳转和诊断让绑定和设计时反馈更及时减少一部分运行时才暴露问题的情况这里更重要的变化不是简单宣称“彻底消除运行时开销”而是让 XAML 在开发阶段变得更透明、更可分析。## 让设计工具重新获得上下文当 XAML 能以更结构化的方式被编译器和工具链理解后设计工具就不再只是“猜测”开发者想表达什么而是能够基于更充分的信息提供支持更精确的类型分析更实时的智能提示更可靠的设计时诊断更一致的编辑器、预览和热重载体验这并不意味着 XSG 本身就是设计器而是说它为设计器、语言服务器和预览系统提供了更好的基础。## 为现有 WPF 项目补上一层现代工具链能力XSG 的价值不在于替换 WPF 这个成熟框架本身而在于为它补上一层更现代的构建与工具链能力。这样做的结果是现有 WPF 应用不必先放弃 WPF 也能逐步获得更好的编辑、诊断、预览和开发体验。这是一条渐进式演进路线而不是一次彻底迁移。它证明的不是“老框架应该被替换”而是“成熟框架仍然可以通过新的工具链设计继续进化”。现在你可以开始体验。在 VS Code Marketplace 搜索“VS Code Tools for WPF”就可以获得完整的 WPF 开发体验——包括实时的 XAML 验证、设计工具支持甚至包含热重载支持。# 展望一条持续演进的道路XSG for WPF WXSG现在还处于早期阶段。目前的成果包括语言服务器和诊断支持VS Code 中的热重载和设计工具集成编译期类型检查和绑定验证对 C# 和 VB.NET 比较全面的支持试验性的 F# 支持也在研究范围内这已经大幅改变了开发体验。重要的是这些改进完全是通过工具链创新达成的而不需要修改 WPF 框架本身。即使你使用着旧版 .NET Framework 或 .NET依然可以从 WXSG 工具链受益。如果你维护的 WPF 应用已经有数年历史可以体验一下 WXSG。项目已经通过 ILSpy 等知名开源项目进行过兼容性测试并及时修复了一些相关问题。**对 WPF 开发者的建议** 不必被”遗留框架”的标签左右决策。WPF 应用运行着数千个企业级系统这些系统的价值也不因微软的战略转向而改变。社区创新如 WXSG证明了成熟框架仍然可以通过新的工具链设计继续演进。# 现在的选择未来的可能如果你维护的 WPF 应用需要现代化可以从 WXSG 和 VS Code Tools for WPF 开始。这不是死守 WPF 平台而是让现有投资获得最大化并为未来迁移留出选择空间。更重要的是WXSG 的未来计划就包括平滑的迁移工具帮助你在最终迁移到 WinUI、Uno 等框架时能在工具链层面获得健壮的兼容层和平滑的过渡而不是大幅改写或是从零开始重写。这是 WXSG 作为社区创新最实用的价值既能让 WPF 在现代环境中重获生命力也能在需要时提供迈向未来的桥梁。---想深入了解以下是一些相关链接AXSG: GitHub 仓库 wieslawsoltes/XamlToCSharpGeneratorWXSG: GitHub 仓库 lextudio/wxsgVS Code 工具: VS Code 商店内搜索 VS Code Tools for WPF 插件