Обновление живых иконок без разрядки аккумулятора

Во всех наших «экранах» все большее распространение получает идея упрощенных уведомлений. Первоначально такой тип функциональности должны были предоставлять гаджеты Windows — идея состоит в использовании дисплеев Heads Up Display (HUD), на которых могут быстро отображаться некоторые важные сведения (новости, прогноз погоды, спортивные результаты и бизнес-события — это только некоторые примеры). Однако время запуска и модель использования гаджетов не способствуют уменьшению общего потребления энергии (а это важно в настольных и переносных компьютерах) или работе по предоставлению полноэкранных платформ для разработчиков. Кроме того, экран «Пуск» в ОС Windows 8 предоставляет более обширную поверхность для отображения большего числа таких уведомлений, а также соответствующий пользовательский интерфейс для управления обновлениями (включая использование сетевых ресурсов). В современных условиях постоянно возрастает поток информации, получаемой через push-уведомления и в структурированных фрагментах. Это предоставляет уникальную возможность для разработчиков и конечных пользователей. В этой записи блога Райан Хэйвесон (Ryan Haveson) обсуждает разработку динамических значков в стиле Metro и возможности масштабирования архитектуры, позволяющие использовать большое количество значков, а также одновременно снижать общее потребление электроэнергии и нагрузку на систему.
– Стивен Синофски (Steven Sinofsky)

Все мы знаем, что производительность и время работы от аккумулятора — очень важные факторы для обеспечения успешности выпуска Windows, и в ваших комментариях постоянно подчеркивается их значение. В комментарии @KISSmakesmeSMILE это обобщено следующим образом:

«...попробуйте повторить или еще лучше превзойти ... достижения [конкурентов] по таким показателям, как время работы от аккумулятора при небольшой нагрузке».

В то же время мы знаем, что все современные среды (от ПК до ТВ и телефонов) имеют некую форму гаджета, виджета или подключаемой модели, которая позволяет получать информацию с одного взгляда. При просмотре новостей, спортивных результатов или прогноза погоды по телевизору вы видите структурированный экран информации со многими источниками, отображаемыми совместно в реальном времени. Люди хотят иметь возможность быстро, всего за несколько секунд просмотреть курс акций, прогноз погоды, количество полученных сообщений электронной почты, время назначенной встречи, бизнес-статус или состояние в социальной сети, а затем вернуться к выполнявшейся до этого задаче. Можно привести много различных аргументов, показывающих, что ПК несколько отстает в этой области по сравнению с другими устройствами. Когда мы решили разработать инфраструктуру уведомлений, наша основная проблема состояла в том, как обеспечить работу ПК в ответ на действия при одновременном сохранении максимально эффективного потребления энергии и использования полосы пропускания. В комментарии @AndyCadley эта цель отражена следующим образом:

«Относитесь ко всем своим приложениям в стиле Metro так, как будто они всегда запущены (но никак не влияют на заряд аккумулятора и производительность)».

Экран «Пуск» также обеспечивает такую возможность, достаточно эффективную с точки зрения пользователя, предоставляя полноэкранный дисплей HUD, но не мешая работе приложений для настольных систем или в стиле Metro, пока внимание пользователя сосредоточено на них. Кроме того, мы не только хотели предоставить такую эффективную возможность, но также хотели убедиться, что пользователи смогут установить столько уведомляющих приложений, сколько захотят, не беспокоясь о том, что это может повлиять на производительность системы или время работы от аккумулятора.

Используя Windows 8 для внутренних целей, мы заметили одну вещь — возможность использовать экран «Пуск» в качестве универсального удобного дисплея HUD для бизнес-приложений позволяет увеличить производительность. Эти приложения предоставляют много интересных возможностей, напрямую связанных с уведомлениями. Windows 8, благодаря масштабируемости нашей новой платформы push-уведомлений, может предоставлять эту возможность с минимальным воздействием на систему, что является большим улучшением по сравнению со множеством механизмов, которые сегодня существуют в Windows. Несложно придумать сценарий (особенно по прошествии небольшого срока), при котором даже самый большой приверженец настольных систем найдет много ценного на экране «Пуск», который используется в качестве централизованной и хорошо структурированной (а также управляемой) области уведомлений, вызываемой всего одним нажатием клавиши.

Цели платформы уведомлений

Использовать значки сотен приложений, реагирующих на действия, и одновременно не допустить снижения производительности. Похоже, что эти наши цели противоречат друг другу. Вообще говоря, «действие» по определению потребляет ресурсы: при получении уведомления из облака используется сеть, а при отображении уведомления на значке используются ресурсы графического/центрального процессора и т. д. Чтобы правильно выполнить проектирование, нам пришлось сосредоточиться на тех целях, с которых мы начинали.

• Разрешить использование сотен динамических значков, не допуская уменьшения производительности
• Выйти за рамки использования выносок, значков и текста с помощью прекрасных изображений
• Облегчить работу для разработчиков, чтобы они могли просто «сделать и забыть»
• Обеспечить возможность доставки в реальном времени, так чтобы доставка «мгновенных сообщений» была действительно мгновенной

На основе этих целей мы приняли первое фундаментальное архитектурное решение — сделать платформу управляемой данными, то есть такой, чтобы код приложения не выполнялся в фоновом режиме, воздействуя на экран «Пуск».

Если вы задумаетесь о строении системы доставки уведомлений, то поймете, что она состоит из нескольких частей: логика, определяющая момент подключения, проверка подлинности, локальное кэширование, визуализация, обработка ошибок, алгоритмы возврата, регулирование и т. д. Кроме того, система должна выполнять задачи на стороне поставщика услуг, например определять, подключен ли компьютер пользователя или нет, что позволит ей обеспечить кэширование недоставленного контента и обработку сложных сценариев для повторения попыток. Можете ли вы представить, что каждое отдельное приложение с динамическим значком имеет свою собственную версию всего этого клиентского/серверного кода? В этом случае будут возникать не только различные ошибки при каждой реализации, но также будет происходить дублирование практически одинакового кода для каждого приложения, загруженного в память, с кодом, который постоянно загружается на диск и выгружается с него. Это действительно было бы неэффективно, поскольку означало бы, что все приложения работают одновременно, чтобы поддерживать активное состояние экрана «Пуск». Даже на компьютере с большим объемом памяти производительность системы была бы в итоге совсем низкой.

Если вы читали статью Била Карагониса (Bill Karagounis) о том, как мы сократили объем используемой памяти в Windows 8, то знаете, что производительность уменьшается по мере того, как увеличивается число запущенных процессов, библиотек DLL, служб и т. д. Если бы каждый динамический значок работал с собственным кодом, мы бы не смогли достичь нашей первой цели — разрешить использование сотен динамических значков без снижения производительности.

Нашим решением было построение модели, управляемой данными. Это означает, что разработчик может отображать значок, используя набор предварительно настроенных свойств и шаблонов. В этом случае — с помощью XML-схемы. После этого данные значки XML отправляются в службу push-уведомлений Windows (WNS) с помощью простого метода HTTP POST, а остальное уже наша забота. Во всем коде для реализации подключения, повторных попыток, проверки подлинности, кэширования, визуализации, обработки ошибок и т. п. обеспечивается единообразие и экономичность с точки зрения энергопотребления.

Ниже приведен пример одного из многих шаблонов значка, который разработчики могут использовать в своих приложениях для Windows 8. Данный шаблон состоит из текстового поля и одного изображения, но доступно и множество других шаблонов.

Рис. 1. Пример шаблона ( TileWideImageAndText )

Ниже приведен соответствующий XML-код, описывающий предыдущий значок:

 <?xml version="1.0" encoding="utf-8"?>
<tile>
  <visual lang="en-US">
    <binding template="TileWideImageAndText">
      <image id="1" src="https://www.fabrikam.com/kickflip.png"/>
      <text id="1">First ever surfboard kickflip recorded in Santa 
        Cruz</text>
    </binding>  
  </visual>
</tile>

Решение об использовании модели, управляемой данными, позволило нам обеспечить выполнение двух первых целей (производительность и высокая точность), но нам еще только предстоит выяснить, как обеспечить доставку в реальном времени и работу в режиме «сделать и забыть».

Существует два высокоуровневых конструктивных шаблона для доставки контента на клиент/сервер: опрос и принудительная отправка. Опрос означает, что клиент регулярно (например, каждые 90 минут) обращается к службе, чтобы проверить наличие нового контента. Принудительная отправка (push) означает, что при появлении нового контента служба отправляет эти данные непосредственно на клиент.

Единственный способ обеспечения поддержки мгновенных уведомлений в модели опроса заключается в выполнении опроса с достаточно высокой частотой (например, каждые 5 секунд), чтобы при получении нового сообщения вы узнавали об этом практически сразу же. Однако это ставит крест на наших целях по обеспечению производительности, так как с 5-секундным интервалом опроса радиостек сети будет постоянно занят, время работы от аккумулятора будет крайне низким и настольные компьютеры будут всегда расходовать дополнительную электроэнергию. Это можно сравнить с непрерывным разговором по сотовому телефону целый день — в этом случае аккумулятор телефона не сможет обеспечивать длительную работу. Исходя из этого, было бы крайне расточительным обращаться к серверу каждые 5 секунд для проверки наличия контента, так как в большинстве таких обращений новые данные отсутствуют. Сложилось так, что уведомления в панели задач и гаджеты рабочего стола, представленные в операционной системе Vista, были реализованы на базе механизма опроса. Но при использовании любого такого механизма интервал опроса все еще недостаточно мал для современных служб реального времени, которые работают мгновенно.

Таким образом, для операционной системы Windows 8 мы разработали службу на основе принудительной отправки. Это было важным решением, так как означало потребность в создании глобальной платформы, которая в конечном итоге должна обеспечивать использование значков для сотен тысяч приложений и быть пригодной для работы более чем одного миллиарда пользователей. Но преимущество было очевидным: разработчики смогли бы бесплатно предоставлять своим клиентам эффективные уведомления в реальном времени без необходимости создания или поддержания устойчивого подключения к клиенту.

Платформа push-уведомлений

Давайте подробнее рассмотрим различные компоненты данной платформы, чтобы прояснить некоторые тонкости ее структуры. На приведенной ниже схеме показаны три основных объекта:

1. Служба push-уведомлений Windows (WNS): эта служба обеспечивает работу динамических значков и всплывающих уведомлений.
2. Служба приложения: это веб-служба, которую запускает приложение Metro (например, с имеющегося веб-сайта), отправляющая всплывающие уведомления и обновления значков через службу WNS. Примером может служить серверная служба для приложения Weather, которое входит в состав предварительной версии для разработчиков, или серверная служба размещения фотографий для приложения социальной сети.
3. Клиентская платформа Windows 8: этот объект представляет фактический компьютер и подкомпоненты в операционной системе, которые обеспечивают сквозной принцип работы.

Рис. 2. Платформа push-уведомлений

Давайте рассмотрим типичный сценарий использования, чтобы проиллюстрировать работу данной системы. Предположим, что служба приложения является сайтом социальной сети, который отправляет обновление значка при появлении нового комментария к вашей фотографии (эта служба точно также может быть и бизнес-приложением, которое отправляет обновление, например, при назначении пользователю ошибки или авансового отчета для рассмотрения). При наличии обновления служба приложения отправляет уведомление в службу WNS (этап 1 в приведенной выше схеме). После этого служба WNS принудительно отправляет это уведомление клиенту (этап 2). Когда приходит время отобразить обновление значка на экране «Пуск», операционная система получает изображение из службы приложения с помощью URL-адреса, содержащегося в XML-коде уведомления (этап 3). После загрузки уведомления и изображения приложение выполняет отрисовку динамического значка с использованием шаблона, заданного в XML-коде, и отображает значок на экране «Пуск».

Как было указано ранее, одна из наших целей заключалась в обеспечении работы в режиме «сделать и забыть». Поэтому чтобы избавить разработчиков от необходимости создания сложных механизмов кэширования и выполнения повторных попыток для ситуаций, когда компьютер не подключен к сети (например, когда ноутбук находится в спящем режиме), мы кэшируем одно уведомление на приложение в облаке WNS до тех пор, пока данный компьютер снова не подключится к сети.

При разработке компонентов клиентской платформы мы во всем стремились обеспечить высокую производительность и низкое энергопотребление. Одной из ключевых частей данного процесса являлось разделение полезной нагрузки уведомлений и полезной нагрузки изображений. Типичный XML-код уведомления содержит менее 1 КБ данных, однако изображение может иметь размер до 150 КБ. Разделение этих данных позволило нам сэкономить значительную часть полосы пропускания сети в сценариях, где используется множество одинаковых изображений. Например, изображение для значка может быть изображением профиля друга, которое компьютер может загрузить и кэшировать локально для повторного использования. Отделение уведомления от изображения также позволило нам оперативно удалять неиспользуемые уведомления перед началом ресурсоемкой загрузки изображения. Если я оставил устройство дома и ушел на работу, нет смысла загружать изображения для значков, так как они будут заменены последующими обновлениями еще до того, как я снова воспользуюсь устройством.

Модель проверки подлинности

Поскольку динамические значки и уведомления представляют собой ключевую часть взаимодействия с приложением, важно, чтобы для канала связи — от службы приложения до значка на экране «Пуск» — обеспечивалась проверка подлинности и должный уровень безопасности. Было бы весьма неприятно, если бы несанкционированное приложение или несанкционированная веб-служба обновляли значок на вашем компьютере. Поэтому мы применили механизм анонимной проверки подлинности, который однозначно идентифицирует подключение между компьютером и службой WNS. Приложения и службы приложений также проходят проверку подлинности при взаимодействии со службой WNS. Такая защита обоих подключений к службе WNS помогает предотвратить применение динамических значков не по назначению (например, подделку данных). Используемый службой WNS механизм проверки подлинности явным образом связывает приложение и службу, чтобы другие приложения (или злоумышленники) не могли отправлять контент в значок, который им не принадлежит. И, конечно же, все взаимодействие осуществляется по безопасному каналу.

Вся эти система работает независимо от того, выполнили ли вы вход в Windows с помощью Windows Live ID или нет. Конечно, как и говорила Кэти Фригон (Katie Frigon) в своей статье о входе в систему с помощью Windows Live ID, для операционной системы Windows 8 удобнее всего иметь подключенную учетную запись, так как это предоставляет доступ ко множеству возможностей, например к облачному хранилищу приложений, перемещению параметров Windows и приложений и единому входу в несколько приложений. Поскольку платформа push-уведомлений использует механизм анонимной проверки подлинности, даже при входе пользователя с помощью Windows Live ID разработчик приложения не может использовать канал уведомлений для определения Windows Live ID, сведений о системы и других данных этого пользователя.

Построение службы в нужном масштабе

Ранее в данной статье мы отметили, что нам пришлось создавать платформу, поддерживающую огромное число пользователей и приложений. Чтобы получить представление о масштабности данной платформы, ознакомьтесь со следующим графиком, на котором показано число уведомлений, ежедневно отправляемых приложениями в операционную систему Windows 8. Всего две недели назад мы уже отправляли почти 90 миллионов обновлений значков в день, а ведь мы еще даже не выпустили бета-версию!

Рис. 3. Число уведомлений, ежедневно отправляемых в сборку предварительной версии Windows 8 для разработчиков

Приложение Stocks является одним из наиболее популярных тестовых приложений в сборке предварительной версии для разработчиков. Следующий график показывает общее число динамических значков, зарегистрированных с помощью данного приложения за первый месяц после выпуска данной сборки предварительной версии для разработчиков.

Рис. 4. Динамические значки, зарегистрированные в приложении Stocks из предварительной версии для разработчиков

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

Ваш браузер не поддерживает HTML5-видео.

Загрузите это видео, чтобы просмотреть его в своем мультимедиа-проигрывателе:
MP4, высокое качество | MP4, низкое качество

Структура службы WNS основана на архитектуре службы Windows Live Messenger, а в действительности компонент данной службы для платформы уведомлений был разработан той же самой группой. В мире существует не там много групп разработчиков, обладающих достаточными знаниями и опытом для построения глобальной масштабируемой службы, которая может настолько быстро разрастаться до такого громадного размера. Ниже приведено немного статистических данных, которые позволяют получить представление о масштабе современной службы Windows Live Messenger:

• 300 миллионов активных пользователей в месяц
• 630 миллионов входов в день
• 10 миллиардов уведомлений в день
• Более 40 миллионов одновременных подключений к сети
• Более 3000 компьютеров, перенаправляющих сообщения, по всему миру

Прозрачность использования ресурсов значков с помощью диспетчера задач

Мы были настолько увлечены аспектом производительности платформы уведомлений, что даже добавили в новый диспетчер задач метрики, позволяющие отслеживать часть пропускной способности, которую платформа значков использует для каждого из приложений. В общем случае уровень использования ресурсов для значков должен быть относительно низким. Те из вас, кто использует сборку предварительной версии для разработчиков, могут перейти на вкладку журнала приложений в диспетчере задач и просмотреть столбец «Tiles» (Значки), чтобы узнать, какую часть полосы пропускания каждый из значков использовал за последние 30 дней.

Рис. 5. Использование ресурсов для динамических значков в журнале приложений диспетчера задач

Заключение

В Windows 8 мы решили разработать платформу уведомлений, которая бы позволяла получать информацию с одного взгляда без проблем с производительностью и временем работы от аккумулятора, которые возникают при использовании традиционных моделей на базе подключаемых модулей и гаджетов. Поэтому каждое из принимаемых решений по разработке рассматривалось с точки зрения обеспечения производительности и экономичного использования электроэнергии. Чтобы разработчикам приложений было проще принимать участие в данном процессе, мы построили службу push-уведомлений Windows, с помощью которой они могут создавать динамические значки без написания сложного кода реализации сетевого взаимодействия. А поскольку служба push-уведомлений Windows использует стандартные веб-технологии, такие как HTTP POST, разработчики легко могут интегрировать уведомления в свои существующие веб-службы.

В результате получилась платформа уведомлений, которая позволяет получать информацию с одного взгляда и устанавливать любое количество приложений, не заботясь о сокращении производительности или времени работы от аккумулятора.

-- Райан Хэйвесон (Ryan Haveson)