Windows 8 运行时(WinRT / Windows 应用商店应用程序 / Windows 10 通用应用程序)与 Silverlight 和 WPF 相比如何?
我正在尝试了解用于创建 Metro 风格的应用程序。我知道您可以将它与 XAML 一起使用,并且它基于 .NET,因此 C# 和 VB.NET可以用来编写应用程序,但它似乎与 HTML、CSS、DOM 和 JavaScript 有关。
有人可以用 .NET UI 程序员可以理解的术语用几段话来解释它是什么吗? (我错过了一些理解它所必需的“关键”。)
我们都知道 WPF,Silverlight、Windows 窗体等将在 Windows 8 下继续工作(并且Windows 10)至少在英特尔系统上,所以请不要告诉我......
I am trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.
Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something “key” that is necessary to understand it.)
We all know that WPF, Silverlight, Windows Forms, etc. will keep working under Windows 8 (and Windows 10) on at least on Intel systems, so please don't tell me that...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
在最低级别,WinRT 是在 ABI 级别定义的对象模型。它使用 COM 作为基础(因此每个 WinRT 对象都实现 IUnknown 并进行引用计数),并从那里进行构建。与旧的 COM 相比,它确实添加了很多新概念,其中大部分直接来自 .NET - 例如,WinRT 对象模型具有委托,并且事件以 .NET 风格完成(使用委托和添加/删除订阅者)方法,每个事件一个),而不是事件源和接收器的旧 COM 模型。其他值得注意的事情是,WinRT 还具有参数化(“通用”)接口。
另一项重大变化是所有 WinRT 组件都有可用的元数据,就像 .NET 程序集一样。在 COM 中,类型库有点像这样,但并不是每个 COM 组件都有它们。对于 WinRT,元数据包含在 .winmd 文件中 - 查看开发人员预览版中的“C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\”。如果你仔细观察,你会发现它们实际上是 CLI 程序集,没有代码,只有元数据表。事实上,您可以使用 ILDASM 打开它们。请注意,这并不意味着 WinRT 本身是受管理的 - 它只是重用文件格式。
然后有许多根据该对象模型实现的库 - 定义 WinRT 接口和类。再次查看上面提到的“Windows Metadata”文件夹,看看里面有什么;或者只需在 VS 中启动对象浏览器并在框架选择器中选择“Windows 8.0”,即可查看所涵盖的内容。那里有很多东西,而且它不仅仅处理 UI - 您还可以获得诸如 Windows.Data.Json 或 Windows.Graphics.Printing 或
Windows.Data.Json
之类的命名空间。代码>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 Interop 的工作方式不同 - 您不需要任何中间工件,例如互操作程序集,您只需
/r
一个 .winmd 文件,并且其元数据中的所有类型及其成员都对您可见,如下所示如果它们是 .NET 对象。请注意,WinRT 库本身是完全本机的(因此使用 WinRT 的本机 C++ 程序根本不需要 CLR) - 将所有这些内容公开为托管内容的魔力就在 CLR 本身内部,并且级别相当低。如果您查看引用 .winmd 的 .NET 程序,您会发现它实际上看起来像外部程序集引用 - 那里没有诸如类型嵌入之类的花招。这也不是一个生硬的映射 - CLR 会尽可能使 WinRT 类型适应其等效类型。因此,例如 GUID、日期和 URI 分别变为
System.Guid
、System.DateTime
和System.Uri
; WinRT 集合接口(例如IIterable
和IVector
变为IEnumerable
和IList
)代码>;等等。这是双向的 - 如果您有一个实现IEnumerable
的 .NET 对象,并将其传递回 WinRT,它会将其视为IIterable
。最终,这意味着您的 .NET Metro 应用程序可以访问现有标准 .NET 库的子集,以及(本机)WinRT 库,其中一些库 - 特别是
Windows.UI
-从 API 角度看,它与 Silverlight 非常相似。您仍然使用 XAML 来定义您的 UI,并且仍然处理与 Silverlight 中相同的基本概念 - 数据绑定、资源、样式、模板等。在许多情况下,只需使用以下命令即可移植 Silverlight 应用程序: 新的命名空间,并在代码中调整 API 的一些地方。WinRT 本身与 HTML 和 CSS 没有任何关系,它与 JavaScript 的关系只是在某种意义上它也暴露在那里,类似于 .NET 的做法。当您在 .NET Metro 应用程序中使用 WinRT UI 库时,您不需要处理 HTML/CSS/JS(好吧,我猜,如果您真的愿意,您可以托管一个
WebView
控件...)。您的所有 .NET 和 Silverlight 技能在此编程模型中仍然非常相关。At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements
IUnknown
and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.
Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as
Windows.Data.Json
, orWindows.Graphics.Printing
, orWindows.Networking.Sockets
.Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under
Windows.UI
orWindows.UI.Xaml
. A lot of them are very similar to WPF/Silverlight namespaces - e.g.Windows.UI.Xaml.Controls
is closely matchingSystem.Windows.Controls
; ditto forWindows.UI.Xaml.Documents
etc.Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just
/r
a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become
System.Guid
,System.DateTime
andSystem.Uri
, respectively; WinRT collection interfaces such asIIterable<T>
andIVector<T>
becomeIEnumerable<T>
andIList<T>
; and so on. This goes both ways - if you have a .NET object that implementsIEnumerable<T>
, and pass it back to WinRT, it'll see it asIIterable<T>
.Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly
Windows.UI
- look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply byusing
the new namespaces, and tweaking a few places in code where the API was adjusted.WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a
WebView
control...). All your .NET and Silverlight skills remain very much relevant in this programming model.来自构建主题演讲:
他们为 HTML/CSS/JavaScript 应用程序和 C#/XAML 应用程序提供通用 API。将使用 C# 和 XAML,但不完全是 WPF 或 Silverlight。
From the Build keynote:
They're providing common APIs to both HTML/CSS/JavaScript apps and C#/XAML apps. C# and XAML will be used, but it won't be WPF or Silverlight exactly.
关键的想法是现在有两个发展轨道——桌面和Metro。
一些要点:
The key idea is that now there is two development tracks - the Desktop and Metro.
Some important points:
该架构的修改版本肯定会帮助您了解事物的确切位置。一位 Telerik 忍者与 CLR 团队聊天并修改了图片:
在这里您可以看到 CLR 的位置。 .NET 框架现在有两个配置文件
1- .NET Metro 配置文件(处理 Metro 应用程序的 CLR)
2- .NET 客户端配置文件(C# 和 VB.NET 应用程序的 CLR 运行时)
我希望这能让您更清楚地了解。阅读一张糟糕的图片值得一千次长时间的讨论。。
There's modified version of the architecture that'll surely help you understand where exactly the things lies. One of the Telerik ninjas had chat with the CLR team and modified the picture:
Here you can see where the CLR stands. The .NET framework now has two profiles
1- .NET Metro profile (CLR that deal with Metro application)
2- .NET Client profile (CLR runtime for C# and VB.NET applications)
I hope this gives you a clearer picture. Read the full article in A bad picture is worth a thousand long discussions..
Microsoft 此处提供了大量详细信息。
简而言之,Windows 运行时是一组新的库,公开 Windows 功能并可用于 JavaScript/C#/VB/C++。每种语言都可以理解并能够直接调用它们,而不必经过一些转换层。
Silverlight 和 WPF 是在 CLR 上运行的 XAML 风格。除其他功能外,Windows 运行时公开了与 Silverlight 非常相似的 XAML 版本,但以本机方式实现,而不是通过 CLR。它可以从 CLR 访问,也可以从 C++ 访问。
Lots of detail from Microsoft here.
In short, Windows Runtime is a new set of libraries exposing Windows functionality and available to JavaScript/C#/VB/C++. Each language has been made to understand and be able to call them directly rather than having to go through some thunking layer.
Silverlight and WPF are flavors of XAML that run on the CLR. Among other functionality, Windows Runtime exposes a version of XAML very similar to Silverlight, but does so in a native way, not via the CLR. It can be accessed from the CLR, but also from C++.