Windows 8运行时(WinRT / Windows Store应用程序/ Windows 10通用应用程序)与Silverlight和WPF相比如何?

小开

在构建主题中:

Keynote stack

他们为HTML/CSS/JavaScript应用程序和c# /XAML应用程序提供通用api。c#和XAML将被使用，但它不会是WPF或Silverlight。

小开

最佳答案

在最低级别上，WinRT是在ABI级别上定义的对象模型。它使用COM作为基础(因此每个WinRT对象都实现IUnknown并进行refcounting)，并从那里构建。与旧的COM相比，它确实增加了相当多的新概念，其中大多数直接来自于。net——例如，WinRT对象模型有委托，事件是。net风格的(带有委托和添加/删除订户方法，每个事件一个)，而不是事件源和接收器的旧COM模型。其他值得注意的是，WinRT还具有参数化(“通用”)接口。

另一个大的变化是所有WinRT组件都有元数据可用，就像. net程序集一样。在COM中，你有点类似于typelibs，但不是每个COM组件都有它们。对于WinRT，元数据包含在。winmd文件中-请查看开发人员预览中的“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本身内部，而且是相当低级的。如果你ildasm一个引用.winmd的. net程序，你会发现它实际上看起来像一个外部程序集引用——这里没有类型嵌入之类的花招。

这也不是一个生硬的映射——CLR试图在可能的情况下使WinRT类型适应它们的等量物。例如，guid、日期和uri分别变成System.Guid、System.DateTime和System.Uri;WinRT收集接口如IIterable<T>和IVector<T>变成IEnumerable<T>和IList<T>;等等。这是双向的——如果你有一个实现了IEnumerable<T>的。net对象，并将它传递回WinRT，它会将其视为IIterable<T>。

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

WinRT本身与HTML和CSS没有任何关系，它与JavaScript的关系只是在某种意义上，它也被暴露在那里，类似于它为。net所做的。当你在。net Metro应用程序中使用WinRT UI库时，你不需要处理HTML/CSS/JS(好吧，我猜，如果你真的想，你可以托管WebView控件…)你所有的。net和Silverlight技能在这个编程模型中仍然非常相关。

小开

来自Microsoft 在这里的大量细节。

Windows运行时使用API元数据(。winmd文件)。这与. net框架(Ecma-335)使用的格式相同。底层的二进制契约使您可以轻松地直接使用所选的开发语言访问Windows Runtime api。Windows运行时api的形状和结构可以被静态语言(如c#)和动态语言(如JavaScript)理解。智能感知支持JavaScript、c#、Visual Basic和c++。

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

Silverlight和WPF是运行在CLR上的XAML的变体。在其他功能中，Windows运行时公开了一个与Silverlight非常相似的XAML版本，但是是以原生的方式，而不是通过CLR。它可以从CLR访问，也可以从c++访问。

小开

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

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

以下要点:

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

小开

有一个修改过的架构版本，它肯定会帮助您了解事情的确切位置。其中一个Telerik忍者与CLR团队聊天并修改了图片:

Windows 8平台和工具(包括CLR)

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

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

2 . net客户端配置文件(CLR运行时为c#和VB。网络应用程序)

我希望这能让你更清楚地了解情况。阅读全文一张糟糕的图片胜过一千次长时间的讨论。