Windows 8 运行时（WinRT/Windows 应用商店应用程序/Windows 10 通用应用程序）与 Silverlight 和 WPF 相比如何？ [关闭]答案

【问题标题】：How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? [closed]Windows 8 运行时（WinRT/Windows 应用商店应用程序/Windows 10 通用应用程序）与 Silverlight 和 WPF 相比如何？ [关闭]
【发布时间】：2011-11-17 00:37:00
【问题描述】：

我正在尝试了解用于创建Metro 样式应用程序的新 Windows 8 运行时。我知道您可以将它与XAML 一起使用，它基于.NET，因此可以使用C# 和VB.NET 来编写应用程序，但它似乎与HTML、CSS、DOM 和JavaScript 有关。

有人可以用 .NET UI 程序员可以理解的几段来解释它的含义吗？（我遗漏了一些理解它所必需的“关键”。）

我们都知道 WPF、Silverlight、Windows Forms 等将至少在英特尔系统上继续在 Windows 8（和 Windows 10）下工作，所以请不要告诉我...

【问题讨论】：

它不是基于 .NET，只是暴露给它（有点像 COM 互操作，但更无缝......例如没有互操作程序集）。
您是否要求将 WinRT 作为平台（ABI、对象模型等）——在这种情况下，将其与 COM 或 .NET 进行比较更有意义——或者关于 WinRT 标准类库，包括那些用户界面？
请注意，您应该区分底层技术、对象模型等 - 类似于例如COM - 以及使用该技术实现的特定库。即使是后者，也不是所有的标准库都是 UI 库——如果你在 VS 中查看对象浏览器，你可以看到 Windows.* 命名空间涵盖的功能的广度。到目前为止，术语在这里有些混乱，因为 WinRT 指的是技术和整套标准库。我不认为只有 UI 库 (Windows.UI.*) 有任何简洁的标签。
@TrueWill：学习所有三个更有意义，这样您的知识就会更加全面，因此您可以决定哪种解决方案最适合给定问题。不要只学习三种中的一种。
@TrueWill：Silverlight 不会有任何未来版本：zdnet.com/blog/microsoft/microsoft-releases-silverlight-5/…

标签： wpf windows-runtime windows-store-apps windows-10 win-universal-app

【解决方案1】：

在最低级别，WinRT 是在 ABI 级别定义的对象模型。它使用 COM 作为基础（因此每个 WinRT 对象都实现 IUnknown 并进行引用计数），并从那里构建。与旧的 COM 相比，它确实添加了很多新概念，其中大部分直接来自 .NET - 例如，WinRT 对象模型具有委托，并且事件以 .NET 样式完成（具有委托和添加/删除订阅者方法，每个事件一个），而不是事件源和接收器的旧 COM 模型。在其他值得注意的方面，WinRT 还具有参数化（“通用”）接口。

另一个重大变化是所有 WinRT 组件都有可供它们使用的元数据，就像 .NET 程序集一样。在 COM 中，你有点像 typelibs 那样，但不是每个 COM 组件都有它们。对于 WinRT，元数据包含在 .winmd 文件中 - 查看 Developer Preview 中的“C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\”。如果您四处寻找，您会发现它们实际上是没有代码的 CLI 程序集，只是元数据表。实际上，您可以使用 ILDASM 打开它们。请注意，这并不意味着 WinRT 本身是受管理的 - 它只是重复使用文件格式。

然后有许多根据该对象模型实现的库 - 定义 WinRT 接口和类。再次，查看上面提到的“Windows 元数据”文件夹，看看里面有什么；或者只是在 VS 中启动对象浏览器并在框架选择器中选择“Windows 8.0”，以查看涵盖的内容。那里有很多，而且它不仅仅处理 UI - 您还可以获得诸如 Windows.Data.Json、Windows.Graphics.Printing 或 Windows.Networking.Sockets 之类的命名空间。

然后你会得到几个专门处理 UI 的库——大部分是Windows.UI 或Windows.UI.Xaml 下的各种命名空间。其中很多与 WPF/Silverlight 命名空间非常相似——例如Windows.UI.Xaml.Controls 与 System.Windows.Controls 非常匹配； Windows.UI.Xaml.Documents 等也一样。

现在，.NET 能够直接引用 WinRT 组件，就像它们是 .NET 程序集一样。这与 COM 互操作不同 - 您不需要任何中间工件，例如互操作程序集，您只需 /r 一个 .winmd 文件，并且其元数据中的所有类型及其成员对您来说都是可见的，就好像它们是 .NET 对象一样.请注意，WinRT 库本身是完全本机的（因此使用 WinRT 的本机 C++ 程序根本不需要 CLR） - 将所有这些东西公开为托管的魔法在 CLR 本身内部，而且级别相当低。如果您创建一个引用 .winmd 的 .NET 程序，您会发现它实际上看起来像一个外部程序集引用 - 没有诸如类型嵌入之类的花招。

这也不是一个生硬的映射 - CLR 会尽可能将 WinRT 类型调整为它们的等效类型。所以例如GUID、日期和 URI 分别变为 System.Guid、System.DateTime 和 System.Uri； IIterable<T>和IVector<T>等WinRT集合接口变成IEnumerable<T>和IList<T>；等等。这是双向的 - 如果您有一个实现 IEnumerable<T> 的 .NET 对象，并将其传递回 WinRT，它会将其视为 IIterable<T>。

最终，这意味着您的 .NET Metro 应用程序可以访问现有标准 .NET 库的子集，以及（本机）WinRT 库，其中一些 - 特别是 Windows.UI - 看起来非常类似于Silverlight，API 方面。您仍然有 XAML 来定义您的 UI，并且您仍然处理与 Silverlight 中相同的基本概念 - 数据绑定、资源、样式、模板等。在许多情况下，只需通过 using 即可移植 Silverlight 应用程序新的命名空间，并调整了代码中调整 API 的一些地方。

WinRT 本身与 HTML 和 CSS 没有任何关系，它与 JavaScript 的关系只是在某种意义上它也暴露在其中，类似于它为 .NET 所做的事情。当您在 .NET Metro 应用程序中使用 WinRT UI 库时，您不需要处理 HTML/CSS/JS（好吧，我想，如果您真的想要，您可以托管一个 WebView 控件...）。您的所有 .NET 和 Silverlight 技能在此编程模型中仍然非常重要。

【讨论】：

WPF-WinRT 兼容性怎么样？会有 WPF-Silverlight 之类的不一致吗？
@Den WPF 在这里不是一个很好的比较基点——API 非常非常接近 Silverlight。如果这样看，两者之间存在不一致之处，但规模更接近桌面 vs WP7 Silverlight，而不是 Silverlight vs WPF。
很好的答案。 WinRT 是直接访问 NT 内核（当它需要操作系统支持时）还是通过 Win32 访问？
轻微修正/补充：A WinRT component implements the IInspectable interface, which derives from IUnknown ...

【解决方案2】：

来自Build 主题演讲：

他们为 HTML/CSS/JavaScript 应用和 C#/XAML 应用提供通用 API。将使用 C# 和 XAML，但不会完全是 WPF 或 Silverlight。

【讨论】：

这有点复杂，因为新的 XAML 东西可用于 C# 和（本机）C++。它既不是 WPF 也不是 Silverlight，但与后者非常接近 - 正如主题演讲中所展示的，您通常只需更改现有 Silverlight 代码中的一堆使用和其他此类琐碎的重构即可。 WPF/Silverlight 背后的核心思想——声明性标记、资源、样式、模板、数据绑定等——都在那里。大多数控件也在那里。
今天早上我看到了一张更好的图片，但我再也找不到了。编辑：找到，感谢关于这个问题的另一个答案。 dougseven.files.wordpress.com/2011/09/win8-new-platform.png
WPF 适合幻灯片的什么位置？
右下角与.NET/Silverlight方式组合在一起。
就现有作品而言，那张照片完全不正确。您几乎可以通过将“Windows Kernel Services”替换为“Win32 kernel32.dll”和“Win32”替换为“Win32 user32.dll+gdi32.dll”来修复它......但 IE 和 .NET/Silverlight 应该主要放在顶部user32.dll+gdi32.dll，以及 C/C++/Java/Delphi/etc 也下到 kernel32.dll。重要的是 user32.dll 和 gdi32.dll 不是 WinRT 的基础，而且 Windows 应用商店应用程序无法超越 WinRT 直接达到 kernel32.dll 的全部功能。

【解决方案3】：

关键的想法是现在有两个开发轨道——桌面和地铁。

桌面是旧应用程序所在的位置。
新的应用程序类别 Metro 应用程序可以通过多种方式构建，包括通过 VB.NET、C# 或 C++。这三种语言选项可以使用 XAML 来构建 UI。另一种方法是使用 JavaScript/HTML5/CSS 来开发 UI 和应用程序代码。

一些要点：

Windows 8 感觉有点像升级后的手机操作系统。
在 Metro 中，没有重叠的顶层窗口，就像在手机上一样。如果你想要一个 MDI 风格的应用程序，你需要留在桌面上。
Metro 风格的应用程序在不可见时会自动暂停。这样做是为了延长电池寿命。这意味着将许多现有的桌面应用程序移植到 Metro 是没有意义的，这些桌面应用程序即使在用户不与它们交互时也会执行后台处理。
Windows 8 的 ARM 版本不支持桌面应用程序。因此，如果您想编写一个应用程序并希望它在任何版本的 Windows 上运行，那么它必须是 Metro 应用程序。

【讨论】：

在 Metro 中，没有重叠的顶级窗口。还有Popup (msdn.microsoft.com/en-us/library/windows/apps/…)，所以如果你愿意，你可以做一些类似 MDI 的东西。显然不建议滥用它，因为您可能会遇到非触摸友好的 UI。
@Pavel - 这很有趣 - 这是否意味着您可以让几个顶级窗口并排运行，但不能重叠？例如平铺...例如，每个共享一半屏幕？我正在开发的 WPF 应用程序现在需要这种功能。
每个 Metro 应用程序只有一个顶级窗口。您可以让两个 Metro 应用程序并排运行，但这是由用户决定的 - 应用程序无法强制自己进入此配置。此外，即使您有两个并排运行的应用程序，它们也无法进行通信以进行协调（除非通过明确的用户手势，例如“共享到”）。
另一方面，您当然可以将自己的单个顶级窗口细分为任意数量的区域，并提供一个可移动的分隔器来调整它们的大小 - 从用户的角度来看，看起来像两个平铺的顶层窗户。不过，它们仍然会在应用切换器中显示为一个单一的东西（但你可能想要它？）。
根据 Martyn Lovell 的说法，没有任何有意的机制来实现这一点，并且一些可以用于它的机制被有意限制。例如，命名管道不存在，内存映射文件也不存在。有socket（包括服务器socket），但是连接localhost时，只能连接同一个app。您可以在共享的“已知文件夹”（文档、图片等）之一中使用普通文件，但这是一种相当粗暴的 hack，需要轮询并且对用户可见。

【解决方案4】：

架构的修改版本肯定会帮助您了解事物的确切位置。 Telerik 的一位忍者与CLR 团队聊天并修改了图片：

在这里您可以看到 CLR 的位置。 .NET 框架现在有两个配置文件

1- .NET Metro 配置文件（处理 Metro 应用程序的 CLR）

2- .NET 客户端配置文件（C# 和 VB.NET 应用程序的 CLR 运行时）

我希望这能给你一个更清晰的画面。在 A bad picture is worth a thousand long discussions. 中阅读全文。

【讨论】：

【解决方案5】：

来自 Microsoft here 的大量细节。

使用 API 元数据（.winmd 文件）公开 Windows 运行时。这与 .NET 框架 (Ecma-335) 使用的格式相同。底层二进制合约使您可以轻松地以您选择的开发语言直接访问 Windows 运行时 API。 Windows 运行时 API 的形状和结构可以通过 C# 等静态语言和 JavaScript 等动态语言来理解。 IntelliSense 可用于 JavaScript、C#、Visual Basic 和 C++。

简而言之，Windows 运行时是一组新的库，它公开了 Windows 功能并可用于 JavaScript/C#/VB/C++。每种语言都可以理解并能够直接调用它们，而不必经过一些思维层。

Silverlight 和 WPF 是在 CLR 上运行的 XAML 风格。在其他功能中，Windows 运行时公开了一个与 Silverlight 非常相似的 XAML 版本，但以本机方式而不是通过 CLR 这样做。它可以从 CLR 访问，也可以从 C++ 访问。

【讨论】：

可能存在“thunking layer” - 例如CLR 实际上使用 RCW——但它现在是一个实现细节。从开发人员的角度来看，您可以直接引用 WinRT .winmd 文件，并直接使用其中的类型。
虽然 thunking 层确实使用 RCW，但 Windows 运行时的 RCW 比旧的 P/Invoke RCW 更轻量级。