微软面临的最大问题之一是如何让 Windows 再次成为吸引开发者的平台。无论用户使用什么设备和操作系统，都可以很容易地将 Web 前端放在支持桌面和移动用户的云原生应用程序上。
我们处在一个奇怪的境地，唯一能利用最新 PC 硬件的应用程序是 Office、Photoshop 和游戏等工具。这使得微软宣布其 Copilot+ PC 的新硬件标准成为一个有趣的转折点。它旨在将 AI 推理引入桌面，并且（除了支持 WebNN 本地推理标准之外）需要本机代码才能使用该新硬件。
那么微软如何让开发人员回归桌面和 Windows？部分问题在于 Windows 开发方法不一致且支离破碎。您使用 Win32 和 Windows SDK 还是使用 WPF 和 WinUI 构建 .Net 应用程序？还是采用 Windows 8 提供的方法并使用 WinRT API？
这就是Windows 应用程序 SDK 的作用所在。它被认为是一种打包来自 Windows SDK 之外的 API 和组件的方式，也是 Microsoft 在正常 Windows 发布周期之外向开发人员提供新功能的方式。
正如 Microsoft 所指出的，它并不是现有工具和技术的替代品。相反，它旨在与它们协同工作，因此您可以继续使用熟悉的语言和框架构建 Windows 应用程序，并添加 Windows App SDK 作为一种现代化代码的方式。
Windows 应用 SDK 入门
Windows 应用程序 SDK 是 Visual Studio 扩展和应用程序组件的混合体。它们添加了模板以快速构建新项目。您需要安装 Win UI 3 工具才能使用其面向用户的功能。其他工具可帮助将代码迁移到新框架。
安装后，它会提供新的库，帮助您构建与现代 Windows 功能兼容的应用程序。这些包括 Win UI 3 控件、改进的文本渲染（以提高文本优先应用程序中的可读性）、更好的应用程序生命周期管理（包括利用操作系统级电源管理功能）和新的窗口管理工具。
其他新功能提供更好的应用程序资源管理，包括对多种语言字符串的支持、改进的推送和本地操作通知框架，以及确保二进制文件和其他应用程序工件中包含适当运行时的打包工具。
微软提供了大量文档，包括所有重要的迁移指南。微软积极鼓励使用 Win UI 3 和 Windows 应用程序 SDK（如果不弃用旧的 Windows 框架），它们是重要的工具，因为它们可以帮助您从 UWP 转向新的工作方式。迁移应该很简单，首先将控件从 Win UI 2 迁移到 Win UI 3，在此过程中更改命名空间，然后再复制应用程序业务逻辑。
如果您的代码是用 .Net 编写的，事情会更容易，因为 .Net 升级助手将帮助将 C# UWP 代码移动到 Windows 应用程序 SDK，从而自动完成大部分过程。
花时间阅读文档非常值得，因为它有助于将 UWP 功能映射到 Windows App SDK，从而允许您更新低级代码。一些更改只是更改命名空间的问题，而其他更改则需要新类来复制旧功能。大多数功能都受支持，但在极少数情况下，您可能需要开发自己的库和控件。Microsoft 提供了一个表格，显示了最常见的映射，这应该有助于迁移。
一些更大的平台级变化伴随着迁移而来。UWP 提供了应用程序级隔离，而当迁移到替代框架时，这种隔离就会消失。不过，还有一些选项，比如 Windows 的新 Win32 App Isolation 工具，它利用较新的 Windows 安全功能在隔离的沙盒中运行代码。
您可以在 Microsoft 学习网站上找到UWP 应用程序和 Windows 应用程序 SDK 之间的差异列表。其中包括可能存在解决方法的地方，以及尚未迁移的功能。一个关键问题是性能，因为应用程序将使用更多 RAM 并且加载时间会更长。
下载频道显示即将推出的功能
Windows App SDK 提供三种不同的渠道；您可以选择当前稳定版本、即将发布的功能预览版或试用新功能的实验渠道。当前支持的版本是 1.5.5 版，于 2024 年 7 月初发布。
下一个主要版本将在六个月左右发布。当前预览版早于当前版本，因此新版本应该很快就会发布。实验版本基于计划的 1.6 版本的开发树，第二个版本将于 2024 年 7 月发布。
微软提供了每个渠道中可用的功能列表以及当前的支持生命周期。版本从首次发布开始支持一年，因此当前的 1.5 版本将支持到 2025 年 2 月底，而 1.4 版本将在 2024 年 8 月底停止支持。
Windows App SDK 支持有一个不寻常的警告：虽然它提供了与 Windows 10 版本 1809 的兼容性，但从技术上讲，只涵盖支持中的 Windows 版本。
Windows App SDK 和 Copilot 运行时
Windows App SDK 旨在成为 Copilot Runtime 的一个关键组件，除其他功能外，它还托管基于 Phi Silica 本地生成 AI 模型的人工智能 API 和 AI 驱动的 OCR 服务。然而，在 Build 发布两个月后，当前的 1.6 版实验版本仍然缺少这些承诺的功能。如果微软想将开发人员的注意力转移到 Windows 上，它需要利用其新硬件的功能，尽快推出 Copilot Runtime API，并加速 1.6 版从实验版到生产的过渡。
Copilot+ PC 的早期推出似乎是一种将硬件推向市场的方式，但按照 Copilot Runtime 功能和开发工具推出的速度，我们最多要到 2024 年底或 2025 年初才能利用它。不仅在 Windows App SDK 的 AI 功能方面进展缓慢，而且在 Copilot Runtime 堆栈的所有元素方面进展缓慢，这仍然令人失望。
您无法将基于 SDK 版本的代码发送到 Windows 应用商店，因为它不受支持。用户希望能够使用基于这些新功能构建的软件，虽然电池寿命的提高对于新的基于 Arm 的硬件来说是一个巨大的优势，但我们等待新的 AI 端点功能的时间越长，开发使用它们的应用程序就越困难。
在几个月内零零碎碎地发布 Copilot Runtime 不会促使开发人员使用它，而使用 ONNX 的解决方法使得打包和部署应用程序变得困难。
是时候移植你的代码了
尽管如此，将应用程序移植到 Windows App SDK 的过程还是值得的。至少它为您提供了一种面向未来的代码方法，并利用了 Microsoft 首选的 Windows 开发路径。
由于它建立在熟悉的 .Net 工具和开源技术之上，因此学习曲线很浅。还有一些超越 Microsoft 工具的选项，允许您引入第三方控件和跨平台工具，例如 Uno 和 Avalonia UI。
Microsoft 提供了示例代码，帮助您通过其学习平台或现成的应用程序将 Windows App SDK 功能添加到您的代码中。过去，我曾接触过 Windows 社区工具包，这是一个提供功能示例以及用于实现这些功能的代码的采样器。
该应用程序定期更新；当前版本是 8.0 版。它不仅仅是为了演示如何使用控件和 UI；它还包括处理复杂数学运算的代码，这对于使用矢量和图形搜索算法至关重要。
Windows App SDK 对于实现桌面应用程序开发流程的现代化非常重要，它为新代码和现有代码提供了新功能支持。
如果您要为 Windows 构建应用程序，则需要使用它，因为它提供对基本 API 和库的访问，以及为最佳使用现代 Windows 功能提供保护措施和指南。
