В наше время в среде почти любого настольного компьютера, ноутбука или портативного устройства имеется какая-либо модель гаджетов, виджетов или подключаемых модулей для получения информации одним взглядом. Можно смотреть телевизионные новости, спортивные результаты и прогнозы погоды в структурированном окне, в которое в реальном времени поступает информация сразу из нескольких источников данных. Вы рассчитываете, что сможете быстро, в течение нескольких секунд посмотреть интересующие вас котировки, погоду, сообщения электронной почты, встречи и даже статусы в социальных сетях, а затем вернуться к своим прежним занятиям.
Все это может привести к существенным потерям в производительности и сроке работы от батарей. Можно утверждать, что в этом плане современные компьютеры во многих отношениях несколько отстают от ноутбуков и других портативных устройств. При проектировании инфраструктуры уведомлений для Windows 8 стояла сложная задача: добиться, чтобы компьютер работал быстро и в то же время эффективно использовал энергию и полосу пропускания.
Начальный экран Windows 8 позволяет пользователю эффективно работать в таком режиме, функционируя как полноэкранный пульт управления, не мешающий обращаться к рабочему столу или другим приложениям. Но помимо эффективности хотелось бы иметь возможность установить столько приложений, использующих уведомления, сколько требуется, не беспокоясь о снижении производительности или сроке работы от батарей. Начальный экран Windows 8 может служить единым и весьма удобным пультом управления для бизнес-приложений, выступая в роли средства повышения продуктивности труда.
Благодаря масштабируемости нашей новой платформы push-уведомлений Windows 8 предоставляет эти возможности, загружая систему по минимуму. Даже самый закоренелый сторонник классического рабочего стола согласится, что начальный экран крайне полезен в качестве централизованной, приятной для глаз и управляемой области уведомления, доступной буквально по одному нажатию клавиши.
Цели уведомления
Поддерживая сотни динамических плиток приложений и в то же время стремясь не допустить снижения производительности, мы, очевидно, преследуем противоположные цели. Все-таки, любые операции, по своей природе, потребляют ресурсы. При получении уведомлений из облака используются сеть. При рендеринге уведомлений на плитках используются ресурсы процессора. Чтобы все правильно спроектировать, нам потребовалось сосредоточиться на целях, которые мы ставили в самом начале:
- поддерживать сотни динамических плиток без потерь в производительности;
- вместо кружков, значков и текста показывать красивые изображения;
- облегчить жизнь разработчикам, чтобы они могли "запустить и забыть" (fire and forget);
- обеспечить доставку информации в режиме реального времени, чтобы мгновенные сообщения действительно доставлялись мгновенно.
В соответствии с этими целями нашим первым принципиальным архитектурным решением стало то, что платформа должна управляться данными. Для отображения информации в начальном экране не должно быть никакого кода приложений, работающего в фоновом режиме. Если вас интересует анатомия системы доставки уведомлений, эта система состоит из нескольких частей. Это логика, определяющая, когда устанавливать соединение, аутентификация, локальное кэширование, рендеринг, обработка ошибок, алгоритмы выдержки (back-off algorithms), регулирование нагрузки (throttling). Кроме того, система должна знать, что происходит на стороне сервисов, например о том, что вы соединены с ними. Она должна поддерживать кэширование не доставленного контента и поддерживать сложные сценарии повторной передачи.
Можете ли вы вообразить, что было бы, если каждое приложение, использующее динамические плитки, имело свою собственную версию клиентского/серверного кода? Помимо того, что в каждой реализации были бы свои собственные "баги", имело бы место дублирование, по сути, одного и того же кода, каждым приложением, загруженными в память. Этот код постоянно записывался бы на диск и считывался бы с него вместе со страницами памяти. Такое решение было бы наиболее неэффективным, поскольку для динамического отображения информации на начальном экране потребовалось бы постоянное выполнение всех ваших приложений. Даже на компьютере с большим количеством памяти система, в конечном счете, стала бы работать с черепашьей скоростью.
Производительность снижается по мере увеличения количества процессов, DLL и сервисов, выполняемых одновременно. Если бы каждая динамическая плитка выполняла бы свой собственный код, цель "поддерживать сотни динамических плиток без потерь в производительности" осталась бы недостижимой. Мы решили проблему, создав модель, управляемую данными.
Это значит, что разработчик приложения может описать свою плитку с помощью набора заранее определенных свойств и шаблонов. Для этого используется XML-схема. Затем XML-данные плитки просто передаются Windows Push Notification Services (WNS) методом HTTP POST, и Windows 8 делает все остальное. Весь код соединения, повторной передачи данных, аутентификации, кэширования, рендеринга и обработки ошибок единообразен и эффективен с точки зрения энергосбережения.
Решение использовать модель, управляемую данными, помогло нам достичь первые две цели - производительность и высокое качество отображения. Но по-прежнему остались две проблемы - доставка в режиме реального времени и эффективная разработка по принципу "запустить и забыть".
Poll и push
Имеется два высокоуровневых проектировочных шаблона доставки контента с сервера на клиент - poll (опрос) и push (проталкивание). Опрос означает, что клиент регулярно обращается к сервису (например, каждые 90 минут), чтобы проверить, не поступил ли новый контент. Push-уведомление означает, что когда появляется новый контент, сервис напрямую передает данные клиенту.
Единственным способом обеспечить мгновенное уведомление в модели опроса был бы опрос с достаточно высокой частотой (например, каждые 5 секунд). Тогда при поступлении новых сообщений вы сразу видели бы их. Но такой подход убийственен для производительности. При 5-секундном интервале опроса стек передачи данных по сети или радиоканалу никогда не будет простаивать, срок работы от батарей будет ужасно низким, а настольные компьютеры будут всегда потреблять энергию.
Это в какой-то степени напоминало бы разговор по сотовому телефону в течение всего дня. Батарея телефона столько не выдержит. Ко всему прочему, проверять каждые 5 секунд, не появился ли на сервере новый контент, крайне расточительно, поскольку большую часть времени ничего нового не появляется. Исторически сложилось, что область уведомлений (system tray) и гаджеты рабочего стола, появившиеся в Windows Vista, использовали механизм опроса. Однако при любом механизме опроса интервал не может быть достаточно коротким для нормальной работы современных сервисов реального времени.
Вот почему в Windows 8 используются сервисы, основанные на push-уведомлениях. Это крупное решение, поскольку оно влияет на платформу глобального масштаба, которую, в конечном счете, будут использовать сотни тысяч приложений и более миллиарда любой. Его преимущества очевидны. Разработчики смогут без каких-либо затрат предоставить своим пользователям уведомления в режиме реального времени, не требующие установки или поддержания постоянного соединения с клиентом.
Push-платформа
Давайте познакомимся с различными компонентами платформы поближе, чтобы поближе изучить кое-какие более тонкие детали архитектуры. В ней имеется три ключевых компонента.
- WNS: обеспечивает поддержку уведомлений динамических плиток и тост-уведомлений.
- Сервис приложения: это веб-сервис, который запускает приложение и отправляет тост-уведомления и данные для обновления плиток через WNS. Например, это может быть сервис для приложения Weather (погода), входящего в Developer Preview, или сервис фотохостинга, используемый приложением для общения в социальной сети.
- Клиентская платформа Windows 8: представляет собой компьютер и субкомпоненты ОС, которые образуют инфраструктуру, предоставляющую все необходимое для поддержки уведомлений.
Вот типичный сценарий использования, демонстрирующий, как все это работает. Предположим, сервис приложения - это сайт социальной сети, отправляющий данные для обновления плитки всякий раз, когда кто-то комментирует фотографию. Или это может быть бизнес-приложение, обновляющее плитки при новых назначениях или когда требуется рассмотреть отчет о расходах. Когда появляются обновления, сервис приложения направляет уведомление в WNS.
Затем WNS "проталкивает" уведомление клиенту. Когда наступает момент показать обновление плитки на начальном экране, ОС получает изображение от сервиса приложений по URL, содержащемуся в XML-данных уведомления. После скачивания уведомления и изображения приложение прорисовывает динамическую плитку в соответствии с шаблоном, содержащимся в XML-данных, и показывает ее на начальном экране.
Чтобы по-настоящему реализовать принцип "запустить и забыть" и добиться, чтобы разработчикам не приходилось писать сложные механизмы кэширования и повторной передачи данных для случаев, когда компьютер не подсоединен к сети, мы кэшируем по одному уведомлению для каждого приложения в облаке WNS до следующего раза, когда компьютер будет в сети.
При проектировании компонентов клиентской платформы мы стремились обеспечить, чтобы все разработанное нами отличалось высокой производительностью и низким энергопотреблением. Одним из ключевых решений было отделение полезных данных уведомления от полезных данных с изображениями. Типичные XML-данные уведомления по размеру меньше 1кБ. А изображения могут иметь размер более 150 кБ. Такое разделение помогло существенно сэкономить полосу пропускания в случаях, когда происходит многократное дублирование изображений.
Например, предположим, что плитка содержит аватар из профиля собеседника. Ваш компьютер может скачать его один раз и закэшировать локально. Отделение уведомления от изображения помогает нам интеллектуально отказываться от ненужных уведомлений перед скачиванием изображений. Например, если экран устройства выключен, нет смысла скачивать изображения для плиток, которые, скорее всего, заменятся последующими обновлениями до следующего использования устройства.
Модель аутентификации
Поскольку динамические плитки и уведомления являются ключевыми компонентами приложения, важно, чтобы канал передачи данных был безопасен и поддерживал аутентификацию. Поэтому в Windows 8 используется механизм анонимной аутентификации, уникально идентифицирующий соединение между компьютером и WNS. Приложения и сервисы приложений также используют аутентификацию при взаимодействии через WNS.
Аутентификация обоих соединений с WNS помогает защититься от передачи злонамеренных данных при обновлении динамической плитки, например, от атаки с подделкой идентификации (spoofing attacks). Механизм аутентификации, используемый WNS, явно связывает приложение и сервис между собой. Он реализован таким образом, что другие приложения (или пользователи) не могут отправить контент плиткам, которыми они не владеют. И, разумеется, все взаимодействия осуществляются по защищенному каналу.
Это работает независимо от того, вошли ли вы в Windows с помощью идентификатора Windows Live ID. При работе с Windows 8 лучше всего иметь учетную запись, связанную с этим идентификатором, поскольку это дает доступ к дополнительным возможностям: хранению данных приложений в облаке; перенос параметров Windows и приложений; и единый вход в несколько приложений. Платформа push-уведомлений использует механизм анонимной аутентификации, поэтому даже если вы вошли под Windows Live ID, разработчик приложения не сможет задействовать конвейер уведомлений, чтобы определить ваш Windows Live ID, системную информацию или местонахождение.
Платформа, нацеленная на масштабируемость
Платформа должна поддерживать невероятно большое количество пользователей и приложений. На этапе разработки, предшествовавшем появлению бета-версии, мы уже отправляли почти 90 миллионов обновлений плиток в день. Приложение Stocks - одно из наиболее популярных пробных приложений в сборке Developer Preview. После выхода Developer Preview мы внимательно отслеживали трафик через центры данных, наблюдая за горизонтальным масштабированием.
Архитектура WNS основана на архитектуре сервиса Windows Live Messenger. Сервисная часть платформы уведомлений разрабатывалась, по сути, той же самой группой. Вот кое-какая статистика, дающая представление о масштабируемости сервиса Windows Live Messenger в настоящее время:
- 300 миллионов активных пользователей в месяц;
- 630 миллионов входов каждый день;
- 10 миллиардов уведомлений в день;
- более 40 миллионов одновременных онлайновых соединений (simultaneous online connections, SOC) при пиковой нагрузке;
- более 3000 компьютеров, маршрутизирующих сообщения по всему миру.
Чтобы внимательно наблюдать за производительностью платформы уведомлений, мы добавили в новый диспетчер задач метрики, позволяющие видеть, сколько полосы пропускания платформы плиток потребляет каждое приложение. Использование ресурсов плитками должно быть относительно низким.
В Windows 8 мы предложили архитектуру платформы уведомлений, позволяющую получить информацию одним взглядом без снижения производительности и срока работы от батарей, с которым сталкивались традиционные модели, основанные на подключаемых модулях и гаджетах. Для этого каждое принятое нами проектировочное решение рассматривалось нами сквозь призму производительности и эффективного использования батарей.
Чтобы облегчить жизнь разработчикам приложений, мы реализовали WNS таким образом, что разработчики могут создавать динамические плитки без написания сложного кода, связанного с соединением с сетью. Поскольку WNS использует стандартные веб-технологии, такие как HTTP POST, для разработчиков не представляет сложности интегрировать уведомления в уже существующие веб-сервисы.
Результат - платформа уведомлений, позволяющая получать информацию одним взглядом. Можно установить столько приложений, сколько требуется, не беспокоясь о том, что это ухудшит производительность или срок работы от батарей.