wpf ui框架_团圆计划：微软UI疯狂的终结？

经过多年的困惑，Windows开发将逐步改善……

> Microsoft Build Conference, 2020

有时，成为Microsoft开发人员似乎就像马克·吐温(Mark Twain)关于天气的老笑话。 您知道一个。如果您不喜欢他们今天提供的API，请等待一个星期，然后尝试下一个。

我最喜欢的Microsoft不断革新的例子是1990年代后期的数据库API，当时它们发布了由三字母技术(RDS，DAO，ADO，OLE DB)组成的字母汤。 但是自那以后的十年中，没有人遭受试图编写图形Windows应用程序的企业开发人员的痛苦。

二十年的Windows应用程序

当.NET 1.0首次出现时，生活很简单。 如果您是希望构建Windows桌面应用程序的.NET开发人员，则使用Windows窗体。 这很容易(在拖放方面几乎类似于VB)，并且功能相对完整。 是的，您可能需要解决奇怪的限制，并偶尔调用一次Win32 API。 但是，如果您想要一个看起来很受人尊敬并且不需要自定义镶边的简单的业务线应用程序，那么世界就是个好地方。

> Good ol' MDI in Windows Forms

然后事情就转了。 微软知道，他们永远无法通过渐进式的改进来摆脱Windows窗体固有的局限性，例如对高DPI显示的支持不佳以及自定义渲染的性能不佳。 没有内置的方法可以执行3D，动画，部分透明(感谢Vista)或任何当时被认为是尖端UI的事情。 因此，微软启动了一个名为WPF(Windows Presentation Framework)的大规模改造项目。

WPF几乎改变了所有内容，从定义窗口的方式(现在声明性地使用称为XAML的XML语法)到硬件基础(DirectX，即支持高性能游戏的技术)。 WPF的新功能令人印象深刻，足以使程序员参与其中，尽管其中一些更改很痛苦。 例如，WPF的第一个发行版没有办法拖放基本的窗口-自Visual Basic的第一个版本以来，该功能在Microsoft世界中就已经存在。

> Custom drawing in WPFWPF取得了成功，但还不足以替代不费吹灰之力，无处不在的Windows窗体工具包。 因此，两种技术共存-一种作为旧应用程序的成熟平台，另一种则是面向未来的新开发的最佳场所。 有一阵子，这似乎是一个合理的妥协。

微软2010年的身份危机改变了一切。 该公司决定需要朝一个完全不同的方向发展，并与一系列新的竞争对手竞争。 它想要一个安全，无痛苦的Microsoft Store来安装应用程序，例如iPad和iPhone。 它需要一个沙盒环境，因此可以与用JavaScript编写的单页Web应用程序竞争。 它想要一个具有十几个不同版本的新操作系统，以便能够支持低功耗移动设备(例如平板电脑，Surface RT和最被人们遗忘的Windows Phone)。 解决所有这些偏执的方法是另一个Windows开发框架，称为UWP(通用Windows平台)，并且在早期也称为Metro。

问题在于，UWP几乎没有普遍性。 是的，它可以运行在不同类型的Windows 10设备上，与WinForms或WPF不同，但是它不支持任何以前的Windows版本。 这个事实足以阻止成熟的开发人员加入UWP。 即使他们不需要用WPF之类的东西编写的完整桌面应用程序的功能，他们也不想将自己锁定在一个较小的计算机兼容性盒中。

UWP无法替换之前提供的任何台式机工具包。 加上微软宏伟愿景的其他部分的失败(已失效的Windows Phone，萎缩的Microsoft Store，步履蹒跚的移动操作系统Windows RT)，UWP的价值主张不断缩小。 UWP并不是一项糟糕的技术，而是因为它做出了种种妥协，但解决了很少人的问题。 毕竟，如果您愿意从头开始构建现代的沙盒应用程序，为什么不考虑在浏览器中使用JavaScript？

这使我们进入了当今Windows开发的状态。 Windows桌面应用程序的所有三个框架仍然共存，填补了一些细微的差异。 最重要的是，开发人员仍在维护基于MFC和Win32 API构建的C ++应用程序。

> Four Windows UI frameworks, all still in use in 2020

输入项目聚会

有一阵子，微软似乎在等待桌面计算的时代，希望其忠实的开发人员最终将其窗口应用程序换成Blazor这样的基于Web的框架。 但是在今年的Build大会上，Microsoft撤消了逐步协调其不同台式机模型的新策略。 旅程始于"团圆计划"。

团圆计划是一项分离和共享UWP用户界面部分的举措。 换句话说，Microsoft正在将UI工具包与UWP(称为WinUI 3)分开，以便可以在其他类型的应用程序中使用。 是的，您仍然可以使用WinUI来制作UWP应用程序，这些应用程序仍可以在其沙盒环境中运行(即使不需要通过越来越靠边的Windows应用商店来部署它们)。 但是-更重要的是-您还可以在其他类型的应用程序中使用WinUI工具包。 实际上，您可以将其与Microsoft过去二十年来创建的所有Windows应用程序框架一起使用，从旧版MFC应用程序到WinForms和WPF。

这很有价值，因为WinUI包含用于构建Fluent用户界面的控件，这是一种受Web影响的设计风格，可以帮助您创建现代，美观的界面。 细边框，过渡动画和可重排布局是Fluent UI的一些标志。

> The humble Calendar app uses Fluent UI

如果您过去的几年中一直在忽略Fluent UI，因为它也带来了很多额外的负担(例如Windows Store和沙盒环境)，则您无需再缴纳该税。 现在，您可以使用WinUI库构建具有完全硬件支持的.NET 5桌面应用程序。

但是，有一个陷阱。 与UWP一样，WinUI也需要Windows10。这似乎将它排除在仍支持僵化的商业环境的大量开发人员中-也许不是。 这是因为Microsoft计划将WinUI兼容性扩展回Windows 8.1。 这不只是天上掉馅饼的希望。 Microsoft需要Windows 8.1兼容性来支持Windows React Native项目，该项目也使用WinUI。

今天的WinUI

大问题显而易见。 如何将WPF或WinForms应用程序迁移到WinUI？ 那你应该吗

即使WinUI与较旧类型的桌面应用程序兼容，其用户界面模型也有所不同。 有兼容性，但不是和谐。 迁移的一种方法是从UI中重构出尽可能多的代码，然后移植到新的WinUI构建的外观上。 另一个选择是零碎的。 单个应用程序可以使用称为XAML Islands的技术将使用WinUI的窗口与使用WinForms或WPF的窗口组合在一起。 这为您提供了一种缓慢向前发展的方式(但同时也保证了您的应用程序将具有某种精神分裂性的视觉风格，将旧时尚和新时尚融合在一起)。 无论哪种方式，Microsoft都将提供可靠的IDE支持。 例如，您不仅可以轻松地将WinUI视图添加到WinForms或WPF项目中，还可以使用将不同的UI框架混合在一起的项目模板。

下一个问题很明显-准备好了吗？

今天，WinUI 3存在于公共预览版本中。 足以开始使用，甚至计划下一个版本。 但是它还没有准备好投入生产。 仍然缺少计划的功能，例如Xbox和HoloLens支持。 WinUI 3的最终版本定于11月，与.NET 5同时发布。

> The short-term plan for WinUI 3

WinUI 3是否太少或太迟的情况还有待观察。 在UWP局部失败后，许多桌面开发人员开始着手使用Electron等网络技术制作桌面应用。 但是对于那些需要保留在Windows桌面世界中的人来说，通往未来的道路看起来比过去几年更有希望。 理智回到了拥挤的桌面API世界。 接下来的步骤不是另一个全新的框架，而是试图重新整合我们已经拥有的框架。

要获取每月一次的电子邮件，其中包含我们最好的技术故事，请订阅Young Coder新闻通讯。

(本文翻译自Matthew MacDonald的文章《Project Reunion: An End to Microsoft's UI Madness?》，参考：https://medium.com/young-coder/project-reunion-an-end-to-microsofts-ui-madness-1af662e36386)