Как Windows 8 Runtime (WinRT / приложения Магазина Windows / универсальное приложение Windows 10) сравнивается с Silverlight и WPF?
Я пытаюсь осмыслить новую среду выполнения Windows 8, которая используется для создания приложений в стиле Metro. Я знаю, что вы можете использовать его с XAML, и он основан на.NET, поэтому C# и VB.NET можно использовать для написания приложений, но, похоже, это как-то связано с HTML, CSS, DOM и JavaScript.
Может кто-нибудь объяснить, что это такое, в нескольких абзацах, в терминах, которые может понять программист.NET UI? (Я упускаю что-то "ключ", что необходимо, чтобы понять это.)
Мы все знаем, что WPF, Silverlight, Windows Forms и т. Д. Будут работать под Windows 8 (и Windows 10) хотя бы на системах Intel, поэтому, пожалуйста, не говорите мне об этом...
5 ответов
На самом низком уровне WinRT - это объектная модель, определенная на уровне ABI. Он использует COM в качестве основы (поэтому каждый объект WinRT реализует IUnknown и делает пересчет), и строит оттуда. Он добавляет довольно много новых концепций по сравнению с COM старых, большинство из которых приходят непосредственно из.NET - например, объектная модель WinRT имеет делегатов, а события выполняются в.NET-стиле (с делегатами и добавлением / удалением подписчика). методы, по одному на событие), а не старая COM-модель источников и приемников событий. Из других примечательных вещей WinRT также имеет параметризованные ("универсальные") интерфейсы.
Еще одно большое изменение заключается в том, что для всех компонентов WinRT доступны метаданные, как и для сборок.NET. В COM у вас вроде это было с typelibs, но не у каждого компонента COM они были. Для WinRT метаданные содержатся в файлах.winmd. Загляните в "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" в Developer Preview. Если вы поэкспериментируете, то увидите, что это на самом деле сборки CLI без кода, а только таблицы метаданных. Вы можете открыть их с ILDASM, на самом деле. Обратите внимание, это не означает, что WinRT управляется сам - он просто повторно использует формат файла.
Затем существует ряд библиотек, реализованных в рамках этой объектной модели - определение интерфейсов и классов WinRT. Снова, посмотрите на папку "Метаданные Windows", упомянутую выше, чтобы увидеть, что там; или просто запустите Object Browser в VS и выберите "Windows 8.0" в селекторе фреймворка, чтобы увидеть, что описано. Там много всего, и это касается не только пользовательского интерфейса - вы также получаете пространства имен, такие как Windows.Data.Json, или же Windows.Graphics.Printing, или же Windows.Networking.Sockets,
Затем вы получаете несколько библиотек, которые конкретно имеют дело с пользовательским интерфейсом - в основном это будут различные пространства имен под Windows.UI или же Windows.UI.Xaml, Многие из них очень похожи на пространства имен WPF/Silverlight - например, Windows.UI.Xaml.Controls близко соответствует System.Windows.Controls; то же самое для Windows.UI.Xaml.Documents и т.п.
Теперь.NET имеет возможность напрямую ссылаться на компоненты WinRT, как если бы они были сборками.NET. Это работает иначе, чем COM Interop - вам не нужны какие-либо промежуточные артефакты, такие как Interop сборки, вы просто /r файл.winmd, и все типы и их члены в его метаданных становятся видимыми, как если бы они были объектами.NET. Обратите внимание, что библиотеки WinRT сами по себе являются полностью нативными (и поэтому нативным программам на C++, использующим WinRT, вообще не требуется CLR) - магия для раскрытия всего, что управляется, находится внутри самой CLR и является довольно низким уровнем. Если вы ildasm.NET-программы, которая ссылается на.winmd, вы увидите, что на самом деле она выглядит как внешняя ссылка на сборку - здесь нет хитрости с ручными хитростями, такими как встраивание типов.
Это также не тупое отображение - CLR пытается адаптировать типы WinRT к их эквивалентам, где это возможно. Так, например, GUID, даты и URI становятся System.Guid, System.DateTime а также System.Uriсоответственно; WinRT коллекции интерфейсов, таких как IIterable<T> а также IVector<T> становиться IEnumerable<T> а также IList<T>; и так далее. Это идет в обе стороны - если у вас есть объект.NET, который реализует IEnumerable<T>и передать его обратно в WinRT, он увидит IIterable<T>,
В конечном итоге это означает, что ваши приложения.NET Metro получают доступ к подмножеству существующих стандартных библиотек.NET, а также к (нативным) библиотекам WinRT, некоторые из которых - особенно Windows.UI - выглядит очень похоже на Silverlight, с точки зрения API. У вас все еще есть XAML для определения вашего пользовательского интерфейса, и вы все еще работаете с теми же базовыми понятиями, что и в Silverlight - привязки данных, ресурсы, стили, шаблоны и т. Д. Во многих случаях можно портировать приложение Silverlight просто using новые пространства имен и настройка нескольких мест в коде, где был скорректирован API.
Сам WinRT не имеет ничего общего с HTML и CSS, и он имеет отношение к JavaScript только в том смысле, что он там также представлен, подобно тому, как это делается для.NET. Вам не нужно иметь дело с HTML/CSS/JS, когда вы используете библиотеки WinRT UI в вашем приложении.NET Metro (ну, я думаю, если вы действительно хотите, вы можете разместить WebView контроль...). Все ваши навыки.NET и Silverlight остаются очень важными в этой модели программирования.
Из основного лота Build:
Они предоставляют общие API как для приложений HTML/CSS/JavaScript, так и для приложений C#/XAML. Будут использоваться C# и XAML, но это точно не будет WPF или Silverlight.
Ключевая идея заключается в том, что теперь есть два пути разработки - рабочий стол и Metro.
- На рабочем столе живут старые приложения.
- Новый класс приложений, Metro-приложения, можно создавать несколькими способами, в том числе с помощью VB.NET, C# или C++. Эти три языковых опции могут использовать XAML для создания пользовательского интерфейса. Альтернативой является использование JavaScript/HTML5/CSS для разработки как пользовательского интерфейса, так и кода приложения.
Некоторые важные моменты:
- Windows 8 выглядит как расширенная ОС для мобильных телефонов.
- В Metro нет перекрывающихся окон верхнего уровня, как и на мобильном телефоне. Если вы хотите приложение в стиле MDI, вам нужно оставаться на рабочем столе.
- Приложения в стиле Metro автоматически приостанавливаются, когда не отображаются. Это было сделано для продления срока службы батареи. Это означает, что для многих существующих настольных приложений, которые выполняют фоновую обработку, даже если пользователь не взаимодействует с ними, перенос в Metro невозможен.
- ARM-версия Windows 8 не будет поддерживать настольные приложения. Так что, если вы хотите написать приложение и хотите, чтобы оно работало в любой версии Windows, тогда это должно быть приложение Metro.
Есть модифицированная версия архитектуры, которая, несомненно, поможет вам понять, где именно находятся вещи. Один из ниндзя Telerik поболтал с командой CLR и изменил картинку:
Здесь вы можете увидеть, где стоит CLR..NET Framework теперь имеет два профиля
1- .NET Metro профиль (CLR, который имеет дело с приложением Metro)
2- Профиль клиента.NET (среда выполнения CLR для приложений на C# и VB.NET)
Я надеюсь, что это дает вам более четкую картину. Прочитайте статью полностью в Плохая картина стоит тысячи долгих обсуждений.,
Много подробностей от Microsoft здесь.
Среда выполнения Windows предоставляется с использованием метаданных API (файлы.winmd). Это тот же формат, который используется в.NET Framework (Ecma-335). Базовый бинарный контракт упрощает доступ к API среды выполнения Windows непосредственно на выбранном вами языке разработки. Форма и структура API среды выполнения Windows могут быть понятны как статическим языкам, таким как C#, так и динамическим языкам, таким как JavaScript. IntelliSense доступен в JavaScript, C#, Visual Basic и C++.
Короче говоря, Windows Runtime - это новый набор библиотек, представляющих функциональность Windows и доступных для JavaScript/C#/VB/C++. Каждый язык был сделан, чтобы понимать и иметь возможность называть их напрямую, вместо того, чтобы проходить через какой-то громоподобный слой.
Silverlight и WPF - это разновидности XAML, которые работают на CLR. Среди других функциональных возможностей Windows Runtime предоставляет версию XAML, очень похожую на Silverlight, но делает это естественным образом, а не через CLR. Доступ к нему можно получить как из CLR, так и из C++.