Windows 8 Runtime(WinRT / Windowsapp store应用/ Windows 10通用应用)与Silverlight和WPF相比如何?

我正试图让我的脑袋围绕用于创buildMetro风格应用程序的新的Windows 8 Runtime。 我知道你可以在XAML中使用它,它基于.NET,所以C#和VB.NET可以用来编写应用程序,但是这似乎与HTML,CSS,DOM和JavaScript有关。

一个.NET UI程序员可以理解的话,有人能解释几个段落中的内容吗? (我错过了理解它的必要的“钥匙”。)


我们都知道,至less在英特尔系统上,WPF, Silverlight , Windows Forms等将继续在Windows 8(和Windows 10)下工作,所以请不要告诉我…

在最低级别,WinRT是在ABI级别上定义的对象模型。 它使用COM作为基础(所以每个WinRT对象都实现了IUnknown并进行refcounting),并从那里构build。 与旧的COM相比,它增加了许多新的概念,其中大部分是直接来自.NET的 – 例如,WinRT对象模型具有委托,事件被完成.NET风格(带有委托和添加/删除订阅方法,每个事件一个),而不是事件源和汇的旧COM模型。 其他值得注意的事情,WinRT也有参数化(“通用”)接口。

另外一个大的变化就是所有的WinRT组件都有可用的元数据,就像.NET程序集一样。 在COM你有一个types库,但不是每个COM组件都有它们。 对于WinRT,元数据包含在.winmd文件中 – 在Developer Preview中查看“C:\ Program Files(x86)\ Windows Kits \ 8.0 \ Windows Metadata”。 如果你捅了一下,你会发现它们实际上是没有代码的CLI程序集,只是元数据表。 事实上,你可以用ILDASM打开它们。 请注意,这并不意味着WinRT本身是被pipe理的 – 它只是重用了文件格式。

然后有一些库实现的对象模型 – 定义WinRT接口和类。 再次,看看上面提到的“Windows元数据”文件夹,看看有什么; 或者只是启动VS中的对象浏览器,并在框架select器中select“Windows 8.0”,以查看涵盖的内容。 这里有很多,它不会单独处理UI,还可以获得名称空间,如Windows.Data.JsonWindows.Graphics.PrintingWindows.Networking.Sockets

然后你得到几个库,这是专门处理用户界面 – 大多数这些将是Windows.UIWindows.UI.Xaml下的各种名称空间。 其中很多与WPF / Silverlight命名空间非常相似 – 例如Windows.UI.Xaml.ControlsSystem.Windows.Controls紧密匹配; Windows.UI.Xaml.Documents等同上

现在,.NET能够直接引用WinRT组件,就好像它们是.NET程序集一样。 这与COM Interop的工作方式不同 – 不需要任何中间工件(如互操作程序集),只需/a.winmd文件,其元数据中的所有types及其成员都可以像.NET对象一样可见。 请注意,WinRT库本身是完全原生的(所以使用WinRT的原生C ++程序根本不需要CLR) – 将所有这些东西作为受pipe理的东西在CLR本身内部展现出来的魔力是相当低的。 如果你是一个引用.winmd的.NET程序,你会发现它实际上看起来像一个外部程序集引用 – 没有任何欺骗手段,比如typesembedded。

这不是一个钝的映射,或者 – CLR在可能的情况下试图使WinRTtypes适应它们的等价types。 因此,例如,GUID,date和URI分别变为System.GuidSystem.DateTimeSystem.Uri ; WinRT收集接口如IIterable<T>IVector<T>成为IEnumerable<T>IList<T> ; 等等。 这是双向的 – 如果你有一个实现了IEnumerable<T>的.NET对象,并将它传递给WinRT,它会将其视为IIterable<T>

最终,这意味着您的.NET Metro应用程序可以访问现有标准.NET库的一个子集,也可以访问(本地)WinRT库,其中一些特别是Windows.UI与Silverlight,API非常相似-明智的。 您仍然有XAML来定义您的用户界面,而且您仍然使用与Silverlight中相同的基本概念 – 数据绑定,资源,样式,模板等。在很多情况下,只需using新的名称空间即可移植Silverlight应用程序,并调整API调整的代码中的几个地方。

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

从构build基调:

Keynote堆栈

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

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

  • 桌面是旧的应用程序的生活地点。
  • 新一类的应用程序Metro应用程序可以通过多种方式构build,包括VB.NET,C#或C ++。 这三种语言选项可以使用XAML来构build用户界面。 另一种方法是使用JavaScript / HTML5 / CSS来开发UI和应用程序代码。

一些重要的观点:

  • Windows 8的感觉就像一个升级的手机操作系统。
  • 在地铁里,没有重叠的顶层窗户,就像没有手机一样。 如果你想要一个MDI风格的应用程序,你需要保持在桌面上。
  • Metro风格应用在不可见时自动挂起。 这是为了延长电池寿命。 这意味着许多现有的桌面应用程序(即使在用户不与其进行交互时执行后台处理)将被移植到Metro也是没有意义的。
  • ARM版本的Windows 8将不支持桌面应用程序。 所以,如果你想写一个应用程序,并希望它在任何版本的Windows上工作,那么它必须是一个Metro应用程序。

这个架构的修改版本肯定会帮助你理解事物的确切位置。 其中一名Telerik忍者与CLR团队聊天并修改了照片:

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

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

1,.NET Metroconfiguration文件(处理Metro应用程序的CLR)

2- .NET客户端configuration文件(用于C#和VB.NET应用程序的CLR运行时)

我希望这给你一个更清晰的画面。 阅读完整的文章一个坏的图片值得一千年的讨论。

这里有很多来自微软的细节。

Windows运行时使用API​​元数据(.winmd文件)公开。 这与.NET框架(Ecma-335)使用的格式相同。 底层的二元契约使您可以轻松地以您select的开发语言直接访问Windows运行时API。 Windows运行时API的形状和结构可以通过静态语言(如C#)和dynamic语言(如JavaScript)来理解。 智能感知可用于JavaScript,C#,Visual Basic和C ++。

简而言之,Windows运行时是一组新的库,提供了Windowsfunction,可用于JavaScript / C#/ VB / C ++。 每种语言都被理解并能够直接调用它们,而不必经过一些thunking层。

Silverlight和WPF是在CLR上运行的XAML的风格。 除了其他function之外,Windows运行时还公开了与Silverlight非常相似的XAML版本,但以原生方式执行,而不通过CLR。 它可以从CLR访问,也可以从C ++访问。