Atualizando mosaicos dinâmicos sem acabar com sua bateria

Criando o Windows 8

Nos bastidores com a equipe de engenharia do Windows

Atualizando mosaicos dinâmicos sem acabar com sua bateria

  • Comments 0

Algo que está se tornando cada vez mais comum em todas as nossas "telas" é a ideia de notificações simples. Originalmente, os Gadgets do Windows deveriam oferecer esse tipo de funcionalidade – a ideia é uma exibição rápida de alerta de algumas informações essenciais (notícias, previsão do tempo, placares esportivos ou eventos de linha de negócios são alguns exemplos). No entanto, o tempo de inicialização e o modelo de Gadgets não são compatíveis com a redução do consumo de energia geral (algo que é importante em um desktop e laptop) ou com o trabalho para fornecer a plataforma em tela inteira para desenvolvedores. Além disso, a tela Iniciar do Windows 8 fornece uma interface muito maior para ter mais dessas notificações, bem como uma interface do tipo usuário no controle para o gerenciamento das atualizações (incluindo uso de recursos de rede). Em uma experiência moderna onde cada vez mais informações estão disponíveis por push e trechos estruturados, isso fornece uma oportunidade única para desenvolvedores e usuários finais. Nesta postagem, Ryan Haveson escreve sobre o desenvolvimento de mosaicos dinâmicos no estilo Metro e como a arquitetura se dimensiona para grandes números de mosaicos, reduzindo ao mesmo tempo o consumo geral de energia e carregamento do sistema.
– Steven Sinofsky

Todos nós sabemos que o desempenho e a vida útil da bateria são extremamente importantes para uma versão bem-sucedida do Windows, e seus comentários continuam enfatizando esses atributos. @KISSmakesmeSMILE resumiu isso muito bem escrevendo:

“…tente corresponder ou, melhor ainda, superar … as realizações no tempo de execução de bateria da [concorrente] em relação à energia/baixo uso de carga.”

Ao mesmo tempo, sabemos que todos os ambientes modernos (incluindo PCs, TVs e telefones) têm alguma forma de gadget, widget ou modelo de plug-in que permite o consumo rápido de informações. Assistir a notícias de TV, esportes ou previsão do tempo mostra uma tela estruturada de informações com muitas fontes juntas em tempo real. As pessoas querem poder verificar rapidamente ações da bolsa, previsão do tempo, conta de email, próximos compromissos, status de linha de negócios ou até mesmo um status em uma rede social em uma questão de segundos, antes de voltar para o que estava fazendo. De muitas formas, é possível dizer que o PC ainda tem muito o que fazer nessa área quando comparado a outros dispositivos. Quando começamos a criar nossa infraestrutura de notificações, nosso desafio era como fazer o PC ser dinâmico com atividade e permanecer extremamente eficiente em relação ao uso de energia e largura de banda. As palavras de @AndyCadley expressam bem a meta:

“Trate todos os seus aplicativos "Metro" como se eles estivessem sempre em execução (mas com zero impacto para bateria/desempenho)”

A tela Iniciar também torna esse processo eficiente, em uma perspectiva de modelo de usuário, ao fornecer a você uma exibição rápida em tela inteira, sem interferir nos seus aplicativos da área de trabalho e de estilo Metro enquanto você estiver focado neles. Além disso, mais do que eficiência, queríamos garantir a instalação de quantos aplicativos de notificação você desejasse, sem que você precisasse se preocupar com o impacto no desempenho ou na vida útil da bateria.

Algo que observamos usando o Windows 8 internamente é que a capacidade de usar a tela Iniciar como uma exibição rápida unificada e extremamente legível para aplicativos de linha de negócios se tornou um aprimorador de produtividade. Estamos vendo que há muito interesse em aplicativos com notificações. Com a escalabilidade de nossa nova plataforma de notificações por push, o Windows 8 fornece esse recurso com um impacto mínimo ao sistema, uma grande melhoria em relação aos vários mecanismos que existem hoje no Windows. Não é difícil encontrar um cenário, especialmente no princípio, onde até mesmo o usuário de desktop mais hardcore valorize a tela Iniciar como uma área de notificação bem apresentada (e controlada) e centralizada, acessível com apenas um pressionamento de tecla.

Metas da plataforma de notificação

Permitir que centenas de mosaicos de aplicativos sejam dinâmicos com atividade e, simultaneamente, garantir que não haja nenhum prejuízo ao desempenho soa contraditório. Afinal de contas, "atividade", por definição, consome recursos: obter uma notificação da nuvem usa a rede, e processar a notificação em um mosaico usa recursos de GPU/CPU etc. Para obter o design certo, sabíamos que precisávamos manter o foco nas nossas metas iniciais:

  • Permitir centenas de mosaicos dinâmicos sem prejudicar o desempenho
  • Ir além de balões, emblemas e texto, com imagens lindas
  • Facilitar para os desenvolvedores, a fim de que eles possam apenas "disparar e esquecer"
  • Atingir entrega em tempo real para que a entrega de "mensagens instantâneas" seja realmente instantânea

Com base nessas metas, a primeira decisão de arquitetura fundamental que tomamos foi que a plataforma seria controlada por dados, ou seja, nenhum código de aplicativo deve ser executado em segundo plano para iniciar a tela Iniciar.

Se você considerar a anatomia de um sistema de entrega de notificações, ele envolve várias partes: lógica para quando conectar, autenticação, cache local, renderização, manipulação de erros, algoritmos de retirada, limitação etc. Além disso, o sistema precisa lidar com questões por parte do servidor, como saber quando você está conectado ou não, a fim de que ele possa armazenar em cache conteúdo não entregue e manipular cenários complexos para recuperação. Já pensou se cada aplicativo individual com um mosaico dinâmico tivesse sua própria versão de todo o código de servidor/cliente? Você teria não apenas diferentes bugs em cada implementação, mas teria duplicatas essencialmente do mesmo código para cada aplicativo carregado na memória, com código que é constantemente paginado dentro e fora do disco. Isso seria realmente ineficiente, pois significaria que todos os seus aplicativos estariam em execução o tempo todo para manter a tela Iniciar ativa. Mesmo em uma computador com muita memória, o desempenho do sistema eventualmente ficaria lento.

Se você leu a postagem de Bill Karagounis sobre como reduzimos o espaço de memória no Windows 8, você sabe que esse desempenho diminui conforme o número de processos, DLLs, serviços etc. em execução. Se cada mosaico dinâmico estivesse em execução com seu próprio código, nós não poderíamos atingir nossa primeira meta de permitir centenas de mosaicos dinâmicos, sem diminuir o desempenho.

Nossa solução foi criar um modelo controlado por dados. Isso significa que um desenvolvedor pode expressar seu mosaico usando um conjunto de modelos e propriedades predefinidas, nesse caso, usando um esquema XML. Os dados de mosaico de XML são então enviados para o WNS (Windows Push Notification Service, Serviço de notificação por push do Windows) através de uma HTTP POST e então tomamos conta do restante. Todo o código para conexão, recuperação, autenticação, cache, renderização, tratamento de erros etc. é feito de forma uniforme e com economia de energia.

Aqui está um exemplo de um dos muitos modelos de mosaico que os desenvolvedores podem usar para seus aplicativos do Windows 8. Este exemplo consiste em um campo de texto e uma única imagem, mas há muitos outros modelos para se escolher.

Imagem de um surfista, com ícone de RSS feed e o texto "Primeiro kickflip de surfboard gravado em Santa Cruz"
Figura 1: exemplo de modelo (TileWideImageAndText)

Aqui está o código XML correspondente que descreve o mosaico acima:

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

A decisão de usar um modelo controlado por dados nos permitiu atingir as primeiras duas metas (desempenho e experiência de alta fidelidade), mas ainda tivemos que descobrir como atingir entrega em tempo real e eficiência do tipo "disparar e esquecer".

Há dois padrões de design de alto nível com entrega de conteúdo por parte do cliente/servidor: sondagem e push. Sondagem significa que o cliente verifica o serviço regularmente (por exemplo, a cada 90 minutos) para ver se há novo conteúdo. Push significa que, quando há novo conteúdo, o serviço envia os dados diretamente para o cliente.

A única forma de oferecer suporte a notificações instantâneas com um modelo de sondagem seria sondar em uma frequência suficientemente alta (como a cada 5 segundos), de forma que se uma nova mensagem chegasse, você a veria instantaneamente. Mas fazer isso eliminaria nossas metas de desempenho – com um intervalo de sondagem de 5 segundos, a pilha de rádio de rede nunca ficaria ociosa, a vida útil da bateria seria terrível e computadores desktop sempre estariam funcionando. Seria como usar o seu celular o dia inteiro – a bateria dele não dura tanto. Além disso, seria uma extrema perda de tempo verificar o servidor a cada 5 segundos à procura de novo conteúdo, pois na maior parte do tempo não haveria nada de novo. Historicamente, as notificações da bandeja do sistema e Gadgets de área de trabalho introduzidos no Vista seriam implementados usando um mecanismo de sondagem. Mas com qualquer mecanismo de sondagem, o intervalo ainda não seria breve o suficiente para os serviços em tempo real de hoje em dia, que são instantâneos.

Assim, para o Windows 8, arquitetamos um serviço baseado em push. Essa foi uma importante decisão, pois significou que precisaríamos criar uma plataforma em escala global, eventualmente capacitando os mosaicos para centenas de milhares de aplicativos e mais de um bilhão de pessoas. Mas o valor estava claro: os desenvolvedores obteriam notificações em tempo real supereficientes para seus clientes gratuitamente, sem precisar criar ou manter suas próprias conexões persistentes para o cliente.

A plataforma de notificação por push

Vejamos mais detalhadamente os vários componentes da plataforma para explicar algumas das partes mais sutis do design. No diagrama a seguir, você verá três entidades principais:

  1. WNS (Windows Push Notification Service): isso capacita mosaicos dinâmicos e notificações toast.
  2. Serviço de aplicativo: este é o serviço Web no qual um aplicativo estilo Metro é executado (p. ex., de seu site existente), que envia notificações toast e atualizações de mosaico via WNS. Exemplos seriam o serviço de back-end para o aplicativo de previsão do tempo, que é fornecido no Developer Preview ou um serviço de back-end hospedando fotos para um aplicativo de rede social.
  3. Plataforma do cliente Windows 8: representa o PC real e os subcomponentes no sistema operacional, que formam a estrutura para a experiência completa.

São mostrados três gráficos: serviço de back-end de aplicativo, Windows Push Notification Service (WNS), (que também contém um "Cache") e a Plataforma do cliente Windows 8 (que também contém as caixas "Renderizador de mosaico", "Cache de imagem" e "Conexão do WNS"). Uma seta marcada como "1. Notificação por push" aponta do serviço de back-end de aplicativo para WNS. Seta marcada como "2. Notificação" aponta de WNS para a Conexão do WNS na Plataforma cliente. Uma seta bidirecional marcada como "3. Busca de imagens" é executada entre o Serviço de back-end de aplicativo e o Cache de imagem na Plataforma de cliente.
Figura 2: a plataforma de notificações por push

Vejamos um cenário de uso característico para ilustrar como isso funciona. Vamos supor que o serviço de aplicativo seja um site de rede social que envia uma atualização de mosaico quando alguém comenta sua foto (isso poderia ser perfeitamente um aplicativo de linha de negócios que me atualiza quando um bug é atribuído a mim ou um relatório de despesas precisa de atenção, por exemplo). Quando houver uma atualização, o serviço de aplicativo enviará uma notificação para o WNS (Etapa 1 no diagrama acima). O WNS, então, enviará a notificação por push para o cliente (Etapa 2). Quando for o momento de exibir a atualização de mosaico na tela Iniciar, o sistema operacional buscará essa imagem no serviço de aplicativo, com base na URL contida no XML de notificação (Etapa 3). Assim que a notificação e a imagem tiverem sido baixadas, o aplicativo renderizará o mosaico dinâmico com base no modelo especificado no XML e o apresentará na tela Iniciar.

Como mencionado antes, uma de nossas metas era "disparar e esquecer". Assim, para garantir que os desenvolvedores não precisassem criar mecanismos de recuperação e cache complexos para quando o PC não estiver conectado (por exemplo, um laptop em espera), armazenamos uma notificação em cache por aplicativo na nuvem do WNS até a próxima vez que o PC ficar online.

Quando criamos os componentes da plataforma cliente, queríamos garantir que tudo fosse projetado para atingir um alto desempenho com baixo consumo de energia. Um dos pontos fundamentais foi separar a carga de notificação da carga de imagem. Um XML de notificação típico tem menos de 1 KB de dados, mas uma imagem pode ter até 150 KB. Fazendo essa separação, pudemos economizar largura de banda de rede significativa para cenários em que há muita duplicação das imagens. Por exemplo, a imagem para um mosaico pode ser uma imagem de perfil de um amigo, que seu PC pode baixar uma vez e armazenar em cache localmente para ser reutilizada. Separar a notificação da imagem também permitiu um processo mais inteligente de descarte de notificações não utilizadas: não perdemos mais tempo baixando a imagem. Se o meu dispositivo estiver no meu quarto com a tela desligada e eu estiver no trabalho, não faz sentido baixar imagens para mosaicos que logo serão substituídos por atualizações subsequentes antes da próxima vez que eu usar o dispositivo.

O modelo de autenticação

Como as notificações e os mosaicos dinâmicos são uma parte essencial da experiência do aplicativo, é importante que o canal de comunicações seja autenticado e seguro – desde o serviço de aplicativo até o mosaico em sua tela Iniciar. Seria ruim se um aplicativo ou serviço Web não autorizado pudesse apenas atualizar qualquer mosaico no seu computador. Por esse motivo, usamos um mecanismo de autenticação anônima que identifica exclusivamente a conexão entre o PC e o WNS. Os aplicativos e serviços de aplicativos também são autenticados ao se comunicar com o WNS. Autenticar ambas as conexões com o WNS ajuda a proteger contra o abuso de atualizações de mosaicos dinâmicos, como em falsificações. O mecanismo de autenticação usado pelo WNS vincula explicitamente o aplicativo ao serviço, de forma que isso impeça outros aplicativos (ou indivíduos desprezíveis) de enviar conteúdo para um mosaico que não seja deles. E, é claro, toda a comunicação ocorre em um canal seguro.

Tudo isso funciona independentemente de você entrar ou não no Windows usando um Windows Live ID. Claro, como Katie Frigon falou em sua postagem sobre como entrar com um Windows Live ID, o Windows 8 é melhor quando se tem uma conta conectada, pois ele permite muitas experiências aprimoradas, como armazenamento na nuvem do aplicativo, configurações de aplicativo e Windows em roaming, bem como logon único em vários aplicativos. Como a plataforma de notificação por push usa um mecanismo de autenticação anônima, mesmo se você entrar com um Windows Live ID, o desenvolvedor do aplicativo não poderá usar o pipeline da notificação para descobrir seu Windows Live ID, informações do sistema ou local.

Desenvolvendo o serviço para dimensionamento

Como mencionado anteriormente nesta postagem, precisávamos criar a plataforma para dar suporte a um número incrivelmente grande de usuários e aplicativos. Para que você tenha uma ideia desse dimensionamento, o gráfico abaixo mostra o número de notificações que os aplicativos estão enviando para o Windows 8 por dia. Algumas semanas atrás, já estávamos enviando praticamente 90 milhões de atualizações de mosaico por dia, e não estamos ainda nem na versão beta!

O gráfico mostra notificações em 0 em 12 de setembro de 2011, atingindo 64 milhões em 16 de setembro de 2011, e caindo novamente para 36 milhões em 18 de setembro e, gradualmente, aumentando para a faixa de 80 a 85 milhões no início de outubro.
Figura 3: notificações por dia enviadas para a compilação Windows 8 Developer Preview

O aplicativo Stocks é um dos aplicativos mais populares de "test drive" da compilação do Developer Preview. O gráfico a seguir mostra o número total de mosaicos dinâmicos registrados com esse aplicativo no primeiro mês desde o lançamento da compilação do Developer Preview.

Total de mosaicos dinâmicos para o aplicativo Stocks
Figura 4: mosaicos dinâmicos registrados no aplicativo Stocks do Developer Preview

Quando o Developer Preview foi lançado, começamos a observar o tráfego proveniente de data centers, monitorando atentamente nosso dimensionamento. Aqui está uma visualização da distribuição geográfica real de notificações nos primeiros dias após o Developer Preview ter sido lançado na //build. Observe que os dados representam unidades por milha quadrada e foram ajustados a uma escala logarítmica para contabilização em uma ampla variedade de valores de densidade.


Baixe este vídeo para vê-lo no seu media player favorito:
MP4 de alta qualidade | MP4 de qualidade inferior

O design do WNS foi baseado na arquitetura de serviço do Windows Live Messenger e, na verdade, a parte do serviço da plataforma de notificações foi criada pela mesma equipe. Não há muitas equipes no mundo com expertise e conhecimento para poder criar um serviço escalonável globalmente, que possa aumentar a tais números elevados tão rapidamente. Aqui estão algumas estatísticas para que você tenha uma ideia do dimensionamento do serviço do Windows Live Messenger atualmente:

  • 300 milhões de usuários ativos mensalmente
  • 630 milhões de logins diários
  • 10 bilhões de notificações diárias
  • Mais de 40 milhões de SOC (conexões online simultâneas) de pico
  • Mais de 3.000 máquinas roteando mensagens no mundo inteiro

Transparência do uso de recursos de mosaico pelo Gerenciador de tarefas

Ficamos tão entusiasmados com o aspecto de desempenho da plataforma de notificações, que agregamos as métricas no novo Gerenciador de tarefas, a fim de permitir que você controle quanto de largura de banda a plataforma de mosaicos está consumindo para cada um de seus aplicativos. Em geral, o uso de recursos para mosaicos deve ser relativamente baixo. Quem estiver executando a compilação do Developer Preview, acesse a guia de histórico de aplicativo no Gerenciador de tarefas e verifique a coluna “Tiles” (Mosaicos), a fim de ver quanta largura de banda cada um de seus mosaicos dinâmicos consumiu nos últimos 30 dias.

Mapa de calor do histórico de uso de aplicativos estilo Metro de 17 de setembro de 2011 a 17 de outubro de 2011. O aplicativo "Notícias" mostra 71,9 MB usados para rede; 57,2 MB para rede limitada, mas somente 0,1 MB para mosaicos. Há 18 aplicativos relacionados e todos mostram 0 ou 0,1 MB de uso na coluna "Tiles".
Figura 5: uso de recursos de mosaicos dinâmicos mostrados no histórico de aplicativo do Gerenciador de tarefas

Resumo

No Windows 8, decidimos criar uma plataforma de notificações que fornecesse informações rápidas, sem todos os problemas de desempenho e vida útil da bateria apresentados por modelos tradicionais baseados em gadget e plug-in. Para isso, cada decisão de design tomada foi vista pela ótica da eficiência de vida útil da bateria e do desempenho. Para facilitar a participação de desenvolvedores de aplicativos, criamos o Windows Push Notifications Service. Assim, os desenvolvedores podem criar mosaicos dinâmicos sem precisar escrever código complicado de conectividade de rede. E como o WNS usa tecnologias Web padrão, como HTTP POST, ficou fácil para os desenvolvedores integrar notificações com base em seus serviços Web existentes.

O resultado é uma plataforma de notificações que fornece informações rápidas, permitindo que você instale quantos aplicativos precisar, sem se preocupar com o impacto no desempenho ou vida útil da bateria.

--Ryan Haveson