Windows 8: Dê vida aos blocos
A arquitetura direcionada para dados do Windows 8 ajuda a executar vários aplicativos de uma vez enquanto mantém o desempenho e a vida útil da bateria.
Ryan Haveson
Nos dias de hoje, apenas cerca de qualquer PC, portátil ou ambiente móvel tem alguma forma de gadget, widget ou modelo plug-in que lhe dá informações em um relance. Você pode assistir TV Notícias, esportes ou tempo dentro de uma tela estruturada com muitas fontes de dados, reunindo-se em tempo real. Você espera ser capaz de verificar rapidamente seus estoques, tempo, email, compromissos ou status de rede social mesmo em questão de segundos antes de voltar para tudo aquilo que você está fazendo.
Isso se traduz em um enorme sorvedouro vida desempenho e bateria. Em muitos aspectos, pode-se argumentar que o PC moderno tem algumas alcançando a fazer nesta área, quando comparados aos portáteis e outros dispositivos móveis. Ao projetar a infra-estrutura de notificações no Windows 8, o desafio era como fazer a sensação de PC vivo com actividade, continuando a operar eficientemente em relação ao uso de energia e de largura de banda.
A tela iniciar do Windows 8 faz com que este tipo de operação eficiente de uma perspectiva do usuário, dando-lhe um heads-up display de tela cheia sem interferir em sua área de trabalho ou outros apps. Além de fazer eficiente, queríamos certificar-se de que você poderia instalar apps notificantes como muitos como você quer, sem se preocupar com o impacto na vida de desempenho ou bateria. Você pode usar a tela de iniciar do Windows 8 como uma exibição unificada e altamente legível de heads-up para aplicativos de linha de negócios (LOB). Desta forma, tornou-se um potenciador de produtividade.
Com a escalabilidade da nossa plataforma de notificações push novo, Windows 8 pode entregar esse recurso com sistema de mínimo impacto. Mesmo a pessoa mais hardcore somente desktop vai encontrar um monte de valor na tela inicial, como uma área de notificação centralizado, bem apresentado e controlada que é apenas uma tecla de distância.
Metas de notificação
Permitindo centenas de azulejos de app ao vivo enquanto simultaneamente assegurando que nenhuma degradação de desempenho faz parecer que temos metas contraditórias. Afinal, uma "atividade" por definição consome recursos. Receber uma notificação da nuvem usa a rede. A notificação em uma telha de renderização usa recursos do processador. Para acertar o desenho, nós tivemos que manter o foco sobre os objetivos, com que começamos:
- Permitir que centenas de telhas ao vivo sem comprometer o desempenho
- Ir além de balões, crachás e texto, com imagens atraentes
- Tornar mais fácil para os desenvolvedores para que possam apenas "disparar e esquecer"
- Conseguir a entrega em tempo real para que entregar "mensagens instantâneas" é instantânea
Com base nestes objetivos, a primeira decisão arquitetônica fundamental era que a plataforma seria orientado a dados. Nenhum código do aplicativo deve ser executado em segundo plano para a tela inicial do poder. Se você pensar sobre a anatomia de um sistema de entrega de notificação, que envolve várias peças. Não há lógica para quando se conectar, autenticação, cache local, renderização, erro de manipulação, retirada algoritmos, otimização e assim por diante. O sistema também tem de lidar com questões de lado do serviço, como saber quando você está conectado. Ele deve ser capaz de armazenar em cache conteúdo não entregue e lidar com cenários complexos para tentar novamente.
Imagina se cada app único com uma telha ao vivo tinha sua própria versão do todo esse código de cliente/servidor? Não somente você teria erros diferentes em cada implementação, mas duplicatas de essencialmente o mesmo código para cada aplicativo carregado na memória. Que o código iria ser constantemente paginado de dentro e para fora para o disco. Isso seria mais ineficiente, porque todos seus apps estaria correndo o tempo todo para manter viva a tela inicial. Mesmo em uma máquina com muita memória, desempenho de sistema que eventualmente moer para um rastreamento.
Desempenho degrada como você aumentar o número de processos, DLLs e serviços em execução ao mesmo tempo. Se cada telha ao vivo estava correndo com seu próprio código, o objetivo de permitir que centenas de telhas ao vivo sem comprometer o desempenho seria impossível. A solução foi construir um modelo orientado a dados.
Isto significa que um desenvolvedor de aplicativo pode expressar sua telha usando um conjunto de propriedades predefinidas e modelos. Nesse caso, ele usa um esquema XML. Os dados XML de telha são enviados para Windows empurrar notificação serviços (WNS) através de um simples POST de HTTP e Windows 8 cuida do resto. Todo o código para ligar, repetindo, autenticação, cache, processamento e manipulação de erro é feito de uma maneira uniforme e eficiente.
A decisão de usar um modelo orientado a dados nos ajudou a alcançar os dois primeiros objetivos de desempenho e uma experiência de alta-fidelidade. Mas o desafio de determinar como alcançar a eficiência do fogo-e-esquecer-se e entrega em tempo real ainda permanecia.
Enquete e empurrar
Existem dois padrões de design de alto nível, com a entrega de conteúdo de cliente/servidor — sondagem e empurrar. Sondagem significa que o cliente verifica-se com o serviço em uma base regular (por exemplo, a cada 90 minutos) para verificar se há novos conteúdos. Empurrar significa que, quando há um novo conteúdo, o serviço envia os dados para o cliente diretamente.
A única maneira de dar suporte a notificações instantâneas com um modelo de sondagem seria sondar sobre uma freqüência suficientemente alta (por exemplo a cada 5 segundos). Dessa forma, se uma nova mensagem chegar, você veria instantaneamente. Mas fazendo assim mataria o nível de desempenho. Com um intervalo de sondagem de 5 segundos, a pilha de rádio de rede nunca seria ociosa, vida da bateria seria horrível e máquinas desktop sempre iriam ser ligadas.
É um pouco similar falando em seu telefone celular durante o dia. Bateria do seu telefone não iria durar muito tempo. Em cima disso, seria extremamente dispendioso verificar o servidor a cada 5 segundos para o conteúdo, como na maioria das vezes que não haveria nada novo. Historicamente, as notificações de bandeja do sistema e do desktop gadgets introduzidos no Windows Vista têm usado um mecanismo de pesquisa. Com qualquer mecanismo de pesquisa, porém, o intervalo é ainda não suficientemente curto para serviços em tempo real de hoje.
É por isso que Windows 8 usa um serviço de push-based. Esta foi uma grande decisão, porque isso significava que a plataforma foi construída em escala global, alimentando eventualmente as telhas para centenas de milhares de apps e mais de 1 bilhão de pessoas. O valor foi claro. Desenvolvedores iria ficar eficientes notificações em tempo real para seus clientes gratuitamente, sem a necessidade de construir ou manter conexões persistentes para o cliente.
A plataforma de envio
Vamos dar uma olhada em vários componentes da plataforma para explicar algumas das partes mais sutis do design. Existem três entidades principais:
- **WNS:**Este poderes vivem telhas e notificações de brinde.
- **Serviço de App:**Este é o serviço de Web que executa aplicativos e envia notificações de brinde e telha atualiza via WNS. Um exemplo disso seria o serviço de back-end para o app de tempo fornecido no Developer Preview, ou um serviço de back-end, Hospedagem de fotos para um aplicativo de rede social.
- **Plataforma de cliente do Windows 8:**Isso representa o PC real e subcomponentes no so que formam o encanamento para a experiência de ponta a ponta.
Aqui está um cenário típico de uso para ilustrar como isso funciona. Suponha que um serviço de aplicativo é um site de rede social que envia uma atualização de telha quando alguém comenta em uma foto. Isso poderia facilmente ser um app LOB que atualiza-lo com novas atribuições, ou quando um relatório de despesas precisa de atenção. Quando houver uma atualização, o serviço de aplicativo envia uma notificação ao WNS.
A partir daí, WNS envia a notificação para o cliente. Quando é hora de mostrar a atualização de telha na tela, o sistema operacional busca essa imagem do serviço app baseado na URL da notificação de XML. Uma vez que a notificação e a imagem são baixados, o aplicativo processa a telha ao vivo, baseada no modelo especificado no XML e apresenta-lo na tela.
Para tornar esta verdadeiramente "fogo e esquecer" — e garantir que os desenvolvedores não tem que escrever cache complexas e repetição de mecanismos para quando o PC não está conectado — podemos armazenar em cache um notificação por app na nuvem WNS até a próxima vez que o PC está online.
Como nós projetamos os componentes da plataforma cliente, nós quisemos garantir que tudo foi projetado para alto desempenho e baixo consumo de energia. Uma das peças-chave deste foi separa a carga de notificação a carga da imagem. Uma notificação típica XML é menos de 1 KB de dados. Uma imagem pode ser de até 150 KB. Separar estas nos ajudou a poupar largura de banda de rede significativa para cenários onde há muita duplicação de imagem.
Por exemplo, a imagem de uma telha pode ser uma foto de perfil de um amigo. Seu PC pode baixar isso vez e tê-lo em cache localmente. Separando a notificação da imagem nos ajuda a ser esperto sobre descartando as notificações não utilizadas antes de baixar a imagem. Se uma tela de dispositivo estiver desligado, não há nenhum ponto em baixar as imagens para azulejos que apenas serão substituídos por atualizações subseqüentes antes da próxima vez que o dispositivo é usado.
O modelo de autenticação
Porque as notificações e telhas ao vivo representam uma parte fundamental da experiência do app, é importante que o canal de comunicação é autenticado e segura. Portanto, o Windows 8 usa um mecanismo de autenticação anônima que identifica a conexão entre o PC e WNS. Aplicativos e serviços da app também autenticam ao comunicar-se com WNS.
Autenticar conexões para WNS ajuda a proteger contra o abuso de atualização de telha ao vivo, tais como ataques de falsificação. O mecanismo de autenticação que WNS usa explicitamente une o aplicativo e serviço. Ele faz isso de uma forma que mantém outros aplicativos (ou indivíduos) de envio de conteúdo para uma telha que não possuem. E, naturalmente, toda a comunicação ocorre através de um canal seguro.
Isso funciona se você está conectado no Windows usando um Windows Live ID. Windows 8 é o melhor quando você tem uma conta conectada, como você vai ter acesso às melhorias, tais como armazenamento de nuvem de app; móvel do Windows e configurações do app; e single sign-on para vários aplicativos. A plataforma de notificação push usa um mecanismo de autenticação anônima, por isso mesmo que se você entrar com um Windows Live ID, o desenvolvedor do aplicativo não é possível usar o pipeline de notificação para encontrar o seu Windows Live ID, sistema de informação ou localização.
Construção de escala
A plataforma tem de sustentar um número incrivelmente grande de usuários e aplicativos. Durante a fase de desenvolvimento pre-beta, nós já estavam enviando atualizações de telha quase 90 milhões por dia. O app de estoques é um dos populares apps da compilação Developer Preview de Test-Drive. Quando foi lançado o Developer Preview, assistimos atentamente a tráfego vindo através de datacenters para monitorar o scale-out.
O design WNS baseia-se na arquitetura de serviço Windows Live Messenger. Na verdade, a parte de serviço da plataforma notificações foi construída pela mesma equipe. Aqui estão algumas estatísticas para lhe dar uma idéia da escala do serviço Windows Live Messenger hoje:
- 300 milhões de usuários ativos mensais
- 630 milhões de logins diários
- notificações diárias 10 bilhões
- Mais de 40 milhões de conexões simultâneas de on-line (SOCs) pico
- Mais de 3.000 máquinas para roteamento de mensagens em todo o mundo
Para monitorar atentamente o desempenho da plataforma notificações, adicionamos métricas para novo Gerenciador de tarefas para que você mantenha o controle de Quanta largura de banda a plataforma de telha está consumindo para cada aplicativo. Uso de recursos para telhas deve ser relativamente baixo.
No Windows 8, partimos para projetar uma plataforma de notificações que fornece informações em-um-olha de relance, sem todas as desempenho e bateria vida preocupações que enfrentam os modelos tradicionais de plug-in e baseada no gadget. Para o efeito, cada decisão de design que fizemos foi visto através da lente da eficiência de vida desempenho e bateria.
Para tornar mais fácil para desenvolvedores de aplicações para participar, nós construímos WNS assim os desenvolvedores poderiam criar telhas ao vivo sem precisar escrever código de conectividade de rede complicada. Porque WNS usa tecnologias padrão da Web como HTTP POST, é fácil para os desenvolvedores a integrar as notificações com base em seus serviços Web existentes.
O resultado é uma plataforma de notificações que oferece informações em um relance. No entanto, você ainda pode instalar apps como muitos como você deseja sem se preocupar com o impacto no desempenho ou bateria de vida.
.jpg)
Ryan Haveson tem mais de 15 anos de experiência principais equipes de engenharia e fornecimento de software e serviços para algumas das marcas mais reconhecidas do mundo, incluindo a Xbox e Windows. Ele era um gerente de grupo da equipe de experiência do Windows para Windows 8. Ele e sua equipe projetado e entregues a usuários finais e recursos voltados para o desenvolvedor, incluindo a plataforma de notificações de telha ao vivo e o novo Gerenciador de tarefas. Ele atualmente lidera o grupo de sistemas de engenharia na Qualcomm Inc. para o Windows/Windows Phone na divisão de Snapdragon na ensolarada San Diego. Contatá-lo em ryanhaveson@hotmail.com ou em linkedin.com/in/ryanha.