Жизненный путь приложений для Магазина Windows: Характеристики платформы Windows 8

Играя в собственной комнате: Контейнер приложения

Так же, как ваши планы могут меняться каждое утро, когда вы просыпаетесь после ночного отдыха, приложения для Магазина Windows могут просыпаться - то есть - активироваться, по самым разным причинам. Конечно, пользователь может коснуться плитки приложения на Начальном экране или щёлкнуть по ней мышью. Приложение, кроме того, может быть запущено в ответ на команды чудо-кнопок, такие, как Поиск или Общий доступ, посредством связей с файлами или протоколами, и в ходе действия большого количества других механизмов. Мы рассмотрим эти варианты в ходе обучения. Но, в любом случае, кое-что еще можно сказать об этом процессе для приложений, написанных на JavaScript.

В скрытой папке, где хранится пакет приложения, расположены такие же файлы, которые вы можете видеть в веб-проектах: .html-файлы, .css, .js-файлы и так далее. Здесь нет исполняемых файлов наподобие .exe-файлов приложений, написанных на C#, Visual Basic или C++. В итоге, что-то должно взять эти исходные файлы и сделать из них запускаемое приложение. Когда ваше приложение активируется, фактически, его исполняет специальный хост-процесс приложения, который называется wwahost.exe^{4"wwa" - это старый акроним для приложений для Магазина Windows, написанных на JavaScript; некоторые термины очень привязчивы…}, как показано на Рис. 1.4.

Рис. 1.4. Хост-процесс приложения - это программа (wwahost.exe), которая загружает, визуализирует и исполняет HTML, CSS и JavaScript, делая это практически так же, как браузер, в котором исполняются веб-приложения.

Папка приложения (App folder)

Хост-процесс приложения (App Host Process)

Движок JavaScript (JavaScript Engine)

Подсистема визуализации HTML/CSS (HTML/CSS Rendering Engine)

Контейнер приложения (App Container)

В памяти (In memory)

Дисплей (Display)

Хост-процесс - это что-то, напоминающее Internet Explorer 10 без графических элементов браузер. Их сходство определяет то, что ваши приложения исполняются на тех же HTML/CSS/JavaScript-движках, что и в Internet Explorer. Различия заключаются в том, что некоторые механизмы в двух этих средах работают по-разному. Например:

• Многие методы в API DOM либо модифицированы, либо недоступны, в зависимости от их устройства и воздействия на систему. Например, функции, которые отображают модальные диалоговые окна, блокирующие поток пользовательского интерфейса, не доступны, наподобие window.alert, window.open, и window.prompt. (Вместо этого, если вам нужна такая функциональность, попробуйте команду Windows.UI.Popups.MessageDialog.)
• Движки поддерживают дополнительные методы, свойства и даже медиа-запросы CSS, которые специфичны для приложений, в отличие от веб-сайтов. Например, специальные медиа-запросы применяются для обработки различных состояний представления (просмотра) Windows 8 (смотрите следующий раздел). Элементы наподобие audio, video и canvas так же имеют дополнительные методы и свойства. В то же время, объекты, такие как MSApp, и методы, такие как requestAnimationFrame, которые доступны в Internet Explorer, так же доступны приложениям для Магазина Windows.
• Страница приложения, запускаемая по умолчанию, написанная на JavaScript запускается в так называемом локальном контексте (local context), где код на JavaScript может получать доступ к WinRT, может совершать кросс-доменные запросы XmlHttpRequest и имеет доступ к удалённым мультимедийным данным (видео, изображения и так далее). Однако, вы не можете загрузить удалённый скрипт (например, из источника http[s]://), и скрипт автоматически отфильтровывает всё, что может воздействовать на DOM и открывать приложения для атак методом внедрения (например, свойства document.write и innerHTML).
• Другие страницы в приложения, так же, как отдельные элементы iframe внутри страницы локального контекста, могут выполняться в веб-контексте (web-context), где вы можете видеть поведение, похожее на веб-поведение (такое, как использование удаленных скриптов). Однако, такие страницы не имеют доступа к WinRT, не могут выполнять кросс-доменные запросы XHR (хотя, вы можете использовать большую часть функциональности WinJS). Обычно iframes, работающие в веб-контексте, используются для поддержки веб-контента на страницах локальных приложений (такого, как элемент управления, отображающий карту), как мы увидим в "Быстрый старт" "Быстрый старт", или для загрузки страниц, которые расположены на веб-ресурсах, при этом, не давая веб-страницам доступа к управлению приложением. Использование подобных iframe-элементов, если говорить кратко, позволяет вам создавать гибридные приложения, использующие как собственный, так и веб-контент.

Для того чтобы узнать подробности обо всём этом, посмотрите материалы "Список изменений API для модели DOM и HTML" (http://msdn.microsoft.com/library/windows/apps/hh700404.aspx) и "Возможности и различия HTML, CSS и JavaScript" (http://msdn.microsoft.com/library/windows/apps/hh465380.aspx) в Центре разработчиков Windows (http://msdn.microsoft.com/ru-RU/windows/apps/). Вы должны подружиться с Центром разработчиков так же, как подружитесь с файлом-манифестом приложения.

Сейчас все приложения для Магазина Windows, подразумевающие наличие хост-процесса или нет, выполняются внутри окружения, которое называется контейнером приложений (app container). Это уровень изоляции, если угодно, который блокирует локальное взаимодействие между процессами и, кроме того, блокирует доступ к системным ресурсам или служит брокером (broker), посредником. Ключевые характеристики контейнера приложения описаны ниже и проиллюстрированы на Рис. 1.5.

• Все приложения для Магазина Windows (кроме встроенных в Windows) запускаются внутри выделенной среды, они не могут взаимодействовать с другими приложениями или подвергаться влиянию других приложений, равно как и вмешиваться в деятельность системы.
• Приложения для Магазина Windows, по умолчанию, имеют неограниченный доступ на чтение и запись только к собственным папкам приложения на жёстком диске (локальной, перемещаемой и временной). Доступ к чему угодно другому в файловой системе (в том числе, к съемным носителям информации) осуществляется только через брокера. "Привратник" даёт доступ только в том случае, если приложение объявило о соответствующих возможностях в файле-манифесте, и/или если пользователь явным образом разрешил это. Скоро мы рассмотрим список возможностей.
• Доступ к особенно важным устройствам (таким, как камера, микрофон и GPS) контролируется похожим образом - API WinRT, которые взаимодействуют с этими устройствами блокируются, если брокер заблокирует подобные вызовы. Доступ к критическим системным ресурсам, к таким, как реестр, полностью запрещен.

Приложения для Магазина Windows не могут программно запускать другие приложения по имени файла, или используя путь в файловой системе, но могут сделать это посредством файла или URI-схемы для связи. Так как всё это, в конечном счете, находится под управлением пользователя, нет гарантии, что подобное действие приведет к запуску определенного приложения. Однако мы приводим разработчиков к мысли об использовании схем URI, специфичных для приложений, которые могут эффективно идентифицировать ваше конкретное приложение в качестве целевого. Говоря техническим языком, другое приложение может прийти и зарегистрировать ту же самую схему URI (таким образом, предоставляя пользователю выбор), но это маловероятно со схемой URI, с которой тесно связаны идентификационные данные приложения.

Приложения для Магазина Windows изолированы одно от другого для защиты от различных форм атак. Это так же означает, что некоторые вполне безобидные приложения (такие, как инструмент для создания копий экрана и вырезания их фрагментов) не могут быть созданы в виде приложений для Магазина Windows. Они должны быть настольными приложениями.

Прямое межпроцессное взаимодействие заблокировано между приложениями для Магазина Windows (за исключением некоторых случаев отладки), между приложениями для Магазина Windows и настольными приложениями и между приложениями для Магазина Windows и локальными сервисами. Приложения, по-прежнему, могут взаимодействовать через облако (вбе-сервисы, сокеты и так далее), и большинство общих задач, которые могут требовать совместную работу приложений - такие, как Поиск и Общий доступ к данным - обрабатываются посредством контрактов (contract), при реализации которых приложения не нуждаются в знании подробностей друг о друге.

увеличить изображение
Рис. 1.5. Изоляция процессов у приложений для Магазина Windows

Данные приложения, локальные, временные, перемещаемые (AppData Local, Temp, Roaming)

Все остальные области (All other areas)

Прямой доступ (Direct Access)

Доступ через брокера (Brokered Access)

Файл-манифест (Manifest)

Хост-процесс приложения (App Host Process)

Контейнер приложения (App Container)

Системные API (System APIs)

Взаимодействие через облако (Communication via Cloud)

Контракты (Contracts)

Процесс приложения (App process)

Врезка: Приложения на смешанных языках

Приложения для Магазина Windows, написанные на JavaScript могут получать доступ к API WinRT только напрямую; приложения или библиотеки, написанные на C#, VisualBasic и C++, кроме того, имеют доступ к подмножествам Win32 и .NET API, как описано в "Win32 и COM для приложений Магазина Windows" (http://msdn.microsoft.com/library/windows/apps/br205757.aspx). Нечестно? Не вполне, так как вы можете писать WinRT-компоненты (WinRT components) на этих языках, чтобы создать функциональность, включающую в себя доступ к иным API в окружении JavaScript (посредством того же механизма проецирования, который использует сам WinRT). Так как эти компоненты компилируются в двоичные динамически связываемые библиотеки (DLL), они так же обычно выполняются быстрее, нежели аналогичный код, написанный на JavaScript, и, кроме того, предоставляют некоторый уровень защиты интеллектуальной собственности (например, с использованием алгоритмов скрытия).

Подобные приложения на смешанных языках (mixed language apps) используют HTML/CSS для своего презентационного уровня и некоторую логику, размещая наиболее чувствительный к производительности или критически важный код в скомпилированных DLL. Динамическая природа JavaScript, фактически, делает его отличным языком для соединения вместе множества компонентов. Подробнее об этом мы поговорим в "Коллекции и элементы управления для вывода коллекций" курса "Программная логика приложений для Windows 8, созданных с использованием HTML, CSS и JavaScript и их взаимодействие с системой".

Обратите внимание на то, что приложения на смешанных языках время от времени называют "гибридными" приложениями, но последний термин уже имеет применение в контексте мобильной и веб-разработки. В данном курсе я использую "приложение на смешанных языках" для того, чтобы избежать неверного понимания этого понятия.