reunion 流利说_微软的Project Reunion：Win32和UWP结合在一起

reunion 流利说

在Build 2020中，Microsoft推出了“ Project Reunion”，这是一套旨在最终将Windows的各种应用程序开发模型整合在一起的技术。 它以WinUI 3率先采用的方法为基础，合并了熟悉的旧Win32和较新的UWP（通用Windows平台），并支持桌面和商店安装程序。

我们在哪里以及如何到达这里

要了解Microsoft的计划，重要的是要从关于我们在哪里以及如何到达这里的背景开始。 过去很容易定义Windows应用程序，并了解如何将其组合在一起。 组成Win32的SDK，控件和API的集合是旧的Windows开发模型的演进，从Windows NT到XP到Vista和Windows 7。

[ 同样在InfoWorld上：隔离期间最好的免费编程课程 ]

然后Windows 8出现了，震动了Windows开发。 它的现代应用程序模型很大程度上要归功于新一代轻量级移动应用程序，该应用程序与雏形的云服务一起使用，可提供跨越Web和设备之间，不同操作系统和外形之间的界限的体验。 WinRT是一个功能强大的工具，但通过新规则工作却有所不同：为节省电量，应用程序不会在后台运行，并且在Hibernate状态下，如果系统需要它们的资源，它们可以随时终止。

熟悉旧Windows方式的开发人员必须从头重新考虑新平台的代码，而许多人没有进行迁移。 如果要为Windows 8构建应用程序，则必须在Windows Store WinRT代码和Win32代码之间进行选择，感觉好像已经降级到了较低级别的桌面联盟。 甚至台式机也不是熟悉的旧台式机。 它被视为一个应用程序，可以像任何WinRT应用程序一样Hibernate。

Windows 8.1和Windows 10旨在改变这种工作方式，返回“开始”菜单，并从以触摸为中心的“开始”屏幕移回熟悉的桌面。 但是商店应用程序和Win32之间仍然存在一堵墙，该墙可以破坏Windows 10桌面桥之类的工具。 在Windows 10中，WinRT现在是UWP，这是一种跨平台开发模型，将对桌面应用程序的支持与Xamarin混合在一起。

同时，熟悉的.NET也发生了变化，以系统编程为中心的.NET Core逐渐采用了API，并通过一组.NET标准API与.NET Framework保持一致，从而简化了从.NET实现中迁移代码的过程。到另一个。

团聚的基础

两个关键的开发为将UWP和Win32合并到一个开发框架中奠定了基础。 首先是引入MSIX ，这是一种新的安装格式，它将长期使用的MSI中的概念与Windows应用商店的APPX混合在一起。 MSIX应用程序不仅限于商店，还可以作为独立应用程序或通过现有的企业部署工具来交付。 通过将应用程序自定义与安装程序文件分开，MSIX确保企业部署的应用程序可以保持最新状态，而无需与每个新更新一起打包。 MSIX允许Win32代码利用Windows 10桌面桥并使用其隔离功能来提高应用程序安全性。

第二个开发是XAML Islands，它是一种允许UWP控件在Windows 10 Win32应用程序中运行的方法，并且可以选择在较旧的Windows平台上使用Win32控件。 随着Windows 7的使用寿命终止并从许多企业机队中退出，该选项的重要性已变得不那么重要。 在过去的几年中，XAML Islands方法得到了发展，导致UI组件与Windows UWP SDK分离，并且便携式WinUI 3诞生了 。

这将我们带到今天，并启动了“团聚计划” 。 在两种开发方法之间不断侵蚀的基础上，它旨在为您提供一种访问Win32和UWP API的通用方法，以同时托管库和捆绑的应用程序组件的NuGet软件包的形式提供。

[ 同样在InfoWorld上：每个开发人员心血来潮的17个聪明的API ]

从Windows解耦Windows SDK

团圆计划（Project Reunion）从WinUI书中摘取。 WinUI 3最终将UI组件与基础SDK分离开来，从而允许它们在必要时更快地发展，Project Reunion旨在对Win32和UWP API进行同样的处理，以将它们与OS分开。 这可能是Windows应用程序开发中最大的变化，因为SDK不再与Windows版本绑定。 Windows 10每六个月提供给我们新的SDK； 这种新方法将允许各个API在需要时进行更改。

为了使这种新的去耦方法起作用，将需要对应用程序的部署方式进行更改。 这就是MSIX的用武之地，它允许在不影响用户的情况下在后台更新应用程序组件。

Project Reunion的一项关键功能是对polyfill的支持，该代码会将现代API带入受支持的旧Windows版本。 这里有很多工作要做，提供翻译和填充以支持复杂的功能。 但是，这是必不可少的工作，正如我们从Web上了解到的那样，polyfills允许更快地推出新功能，在支持较旧版本的浏览器的同时，仍允许较新版本利用内置功能。

在较旧的Windows版本上运行Project Reunion代码可能不会获得相同的性能，但至少它将运行。 这将使您可以将其用于在长期支持版本上运行的软件，Windows IoT硬件，而无需交付特定于版本的代码。 管理下层支持可以阻止新版本发布，并且这种方法应该允许您在不损害新功能的情况下继续更新应用程序。

不可能的事情要花更长的时间：《团圆计划》路线图

微软已经发布了 《团圆计划》 的初步路线图 。 有一件事很清楚：不要期待发生大爆炸。 随着计划在未来几年发布，很明显，最好的策略是继续使用当前的应用程序开发模型，首先转移到WinUI 3，然后根据需要添加关键的合并API。 从头开始重写代码在时间和资源上都是昂贵的，这是Microsoft公认的并且正在尽最大努力减轻更改的影响。

第一步是在Build上宣布的： 用于UWP和Win32的WinUI 3预览版，对Azure托管的Windows虚拟桌面的MSIX支持以及基于Chromium的新WebView2控件的预览，该控件的更新时间表与新边缘。 到今年年底，将有更多API支持的预览版和进一步的WinUI预览版。 2021年及以后的目标是雄心勃勃：每年都会发布多个Project Reunion，最初的重点是与新API的应用程序兼容性。

[ 同样在InfoWorld上：我们不像以前那样编写代码的5个原因 ]

为项目团聚做准备

有两个任务可开始准备将代码准备用于Project Reunion。 首先，转向以MSIX打包和部署。 其次，开始将控件迁移到WinUI的过程。 在UWP中，使用WinUI 2已经可用并且在预览中使用WinUI 3，在UWP中更容易。 对于Win32，从XAML Islands开始并开始探索WinUI3。如果可能，还应该开始使用WebView2，以获得基于Chromium的Web控件的好处。

通过在现有项目的基础上，很明显，Project Reunion并不是全新的东西。 相反，它是一种经过深思熟虑的方法的一部分，为过去几年中正在开发和预览的一组技术起了个名字。 最终将Windows操作系统与应用程序SDK分离的地方超出了当前的工作范围，这是一个漫长的变化。

翻译自: https://www.infoworld.com/article/3545407/microsofts-project-reunion-win32-and-uwp-unite.html

reunion 流利说