Windows 8: Dele vida con mosaicos
La arquitectura orientada a datos de Windows 8 le ayuda a ejecutar varias aplicaciones al mismo tiempo, al mantener el rendimiento y la carga de las baterías.
Ryan Haveson
Estos días, casi cualquier PC, portátil o entorno móvil tiene algún tipo de gadget, widget o modelo de complemento que le da una idea general. Usted puede ver TV Noticias, deportes o tiempo dentro de una pantalla estructurada con muchas fuentes de datos que se reúnen en tiempo real. Esperas para poder comprobar rápidamente sus existencias, tiempo, correo electrónico, citas o estado redes social incluso en cuestión de segundos antes de volver a lo que estás haciendo.
Esto se traduce en una fuga masiva en rendimiento y duración de batería. De muchas maneras, podría argumentar que la PC moderna tiene algunos alcanzando a hacer en esta zona en comparación con los ordenadores portátiles y otros dispositivos móviles. En el diseño de la infraestructura de las notificaciones en Windows 8, el reto era cómo hacer viva la sensación de PC con actividad sin dejar de funcionar de manera eficiente con respecto al uso de energía y ancho de banda.
La pantalla de inicio de Windows 8 hace este tipo de operación eficiente desde una perspectiva de usuario dándole un Heads-up display de pantalla completa sin interferir en el escritorio u otras aplicaciones. Además haciéndolo eficiente, hemos querido asegurarse de que se podían instalar apps notificantes tantas como desee, sin tener que preocuparse por el impacto sobre la vida de la batería o el rendimiento. Puede utilizar la pantalla de inicio de Windows 8 como un Heads-up display unificado y altamente legible para aplicaciones de línea de negocio (LOB). De esta manera, se ha convertido en un potenciador de la productividad.
Con la escalabilidad de nuestra nueva plataforma de notificaciones de empuje, Windows 8 puede ofrecer esta capacidad con el impacto del sistema mínimo. Incluso la persona más hardcore de escritorio sólo encontrará un gran valor en la pantalla de inicio como un área de notificación centralizado, bien presentado y controlado que es sólo una tecla.
Objetivos de la notificación
Lo que permite cientos de azulejos de la aplicación activa garantizando al mismo tiempo que degradación del rendimiento no hace parecer que tenemos objetivos contradictorios. Después de todo, una "actividad" por definición consume recursos. Recibir una notificación de la nube, utiliza la red. Procesar la notificación sobre una baldosa utiliza recursos del procesador. Para obtener el diseño correcto, tuvimos que permanecer enfocado en los objetivos con que comenzamos:
- Permite cientos de azulejos vivos sin degradar el rendimiento
- Ir más allá de globos, insignias y texto, con imágenes atractivas
- Hacer fácil para los desarrolladores por lo que puede simplemente "dispara y olvida"
- Lograr la entrega en tiempo real para proporcionar "mensajes instantáneos" es instantánea
Basado en estos objetivos, la primera decisión de arquitectura fundamental fue que la plataforma serían controladas por datos. Ningún código de aplicación debe ejecutarse en segundo plano a la pantalla de inicio de la alimentación. Si se piensa en la anatomía de un sistema de entrega de la notificación, se trata de varias piezas. Hay lógica para cuando conecte, autenticación, almacenamiento en caché local, procesamiento, manejo de errores, back-off algoritmos, regulación y así sucesivamente. El sistema también tiene servicio de lado cuestiones como saber cuando está conectado. Debe ser capaz de almacenar contenido no entregado y manejar complejos escenarios para volver a intentarlo.
¿Te imaginas si cada aplicación solo con un azulejo vivo tuvo su propia versión de todo ese código de cliente/servidor? No sólo tendría diferentes errores en cada aplicación, pero duplicados de esencialmente el mismo código para cada aplicación cargada en memoria. Ese código sería constantemente paginar y salir en el disco. Esto sería más ineficiente, porque todas sus aplicaciones funcionaría todo el tiempo para mantener la pantalla de inicio. Incluso en un equipo con mucha memoria, el rendimiento del sistema sería moler eventualmente a un rastreo.
El rendimiento decrece a medida que aumenta el número de procesos, archivos dll y servicios que se ejecutan a la vez. Si se ejecuta cada azulejo vivo con su propio código, el objetivo de permitir que cientos de azulejos vivos sin degradar el rendimiento sería imposible. La solución fue construir un modelo de datos.
Esto significa que un desarrollador puede expresar su azulejo utilizando un conjunto de propiedades predefinidas y plantillas. En este caso, utiliza un esquema XML. Los datos XML de azulejo se enviaron a Windows empuje notificación servicios (WNS) a través de un simple POST de HTTP y Windows 8 se encarga del resto. Todo el código para conectar, volver a intentarlo, autenticación, almacenamiento en caché, representación y tratamiento de errores se realiza en forma uniforme y eficiente de energía.
La decisión de utilizar un modelo basado en datos nos ayudó a los dos primeros objetivos de rendimiento y una experiencia de alta fidelidad. Pero sigue siendo el desafío de determinar cómo lograr la entrega en tiempo real y fuego-y-olvidar-eficacia de TI.
Encuesta y empuje
Hay dos patrones de diseño de alto nivel con la entrega de contenido de cliente/servidor: sondeo y empuje. Sondeo significa que el cliente se comprueba con el servicio de forma regular (por ejemplo, cada 90 minutos) para buscar nuevos contenidos. Empuje significa que cuando hay contenido nuevo, el servicio envía los datos hasta el cliente directamente.
La única forma de apoyar las notificaciones instantáneas con un modelo de votación sería sondear en una frecuencia suficientemente alta (por ejemplo, cada 5 segundos). De esa manera, si llega un nuevo mensaje, verá lo instantáneamente. Pero hacerlo así mataría el nivel de rendimiento. Con un intervalo de sondeo de 5 segundos, la pila de radio de la red nunca sería ociosa, duración de la batería sería horrible y máquinas de escritorio siempre se enciende.
Sería un poco como hablar por teléfono celular durante todo el día. La batería del teléfono no duró mucho. Además de eso, sería extremadamente derrochadora comprobar el servidor cada 5 segundos para contenido, como la mayoría de las veces que no habría nada nuevo. Históricamente, las notificaciones de la bandeja de sistema y gadgets de escritorio en Windows Vista han utilizado un mecanismo de votación. Con cualquier mecanismo de votación, sin embargo, el intervalo es todavía no suficientemente corto para servicios en tiempo real de hoy.
Es por ello que Windows 8 utiliza un servicio de empuje. Esto fue una gran decisión, porque significa que la plataforma fue construida a escala global, finalmente alimentar los azulejos para cientos de miles de aplicaciones y más de 1 billón de personas. El valor fue claro. Desarrolladores obtendría eficientes notificaciones en tiempo real a sus clientes de forma gratuita, sin tener que construir o mantener conexiones persistentes en el cliente.
La plataforma de empuje
Echemos un vistazo a los distintos componentes de la plataforma para explicar algunas de las partes más sutiles de diseño. Hay tres entidades claves:
- **WNS:**Este poder vive azulejos y tostar las notificaciones.
- **Servicio de aplicación:**Este es el servicio Web que se ejecuta aplicaciones y envía notificaciones de tostado y azulejo de actualizaciones a través de WNS. Un ejemplo de esto sería el servicio de back-end de la aplicación de tiempo que se incluye en el Developer Preview, o un servicio de back-end hosting de fotos para una aplicación de redes social.
- **Plataforma de cliente de Windows 8:**Esto representa el PC real y los subcomponentes del sistema operativo que forman la tubería para la experiencia end-to-end.
Aquí es un escenario de uso típico para ilustrar cómo funciona esto. Supongamos que un servicio de aplicación es un sitio de redes sociales que envía una actualización de azulejo cuando alguien comenta una foto. Esto podría igual ser fácilmente una aplicación LOB que te actualiza con las nuevas asignaciones o cuando un informe de gastos necesita atención. Cuando hay una actualización, el servicio de aplicación envía una notificación a WNS.
Desde allí, WNS empuja la notificación hasta el cliente. Cuando es hora de mostrar la actualización de azulejo en la pantalla de inicio, el sistema operativo obtiene esa imagen del servicio de aplicación basado en la dirección URL en el XML de notificación. Una vez que se descargan la notificación y la imagen, la aplicación procesa el azulejo directo basado en la plantilla especificada en el archivo XML y lo presenta en la pantalla de inicio.
Para hacer esto verdaderamente "dispara y olvida" — y para garantizar que los desarrolladores no tienen complejo de caché de escritura y reintentar mecanismos para cuando la PC no está conectado — nos caché una notificación por aplicaciones en la nube WNS hasta la próxima vez que el PC está en línea.
Como diseñamos los componentes de la plataforma de cliente, queríamos garantizar que todo fue diseñado para alto rendimiento y bajo consumo de energía. Una de las partes claves de este fue separar la carga de la notificación de la carga de la imagen. Una típica notificación XML es menos de 1 KB de datos. Una imagen puede ser hasta de 150 KB. Separar estos nos ayudaron a ahorrar ancho de banda de red importantes escenarios donde hay un montón de duplicación de la imagen.
Por ejemplo, la imagen de un azulejo podría ser una foto de perfil de un amigo. Su PC puede descargar esto de una vez y tenerla en caché localmente. Separar la notificación de la imagen nos ayuda a ser inteligente sobre descartando las notificaciones no utilizadas antes de descargar la imagen. Si la pantalla de una dispositivo está apagado, no hay ningún punto en la descarga de imágenes para los azulejos que sólo serán sustituidos por actualizaciones posteriores antes de la próxima vez que se utiliza el dispositivo.
El modelo de autenticación
Porque las notificaciones y vivos azulejos representan una parte fundamental de la experiencia de la aplicación, es importante que el canal de comunicaciones se autentica y segura. Por lo tanto, Windows 8 utiliza un mecanismo de autenticación anónima que identifique la conexión entre el PC y WNS. Aplicaciones y servicios de aplicación también autentican al comunicarse con WNS.
Autenticación de ambas conexiones a WNS ayuda a proteger contra el abuso de la actualización de azulejo vivo, como ataques de suplantación. El mecanismo de autenticación que WNS utiliza explícitamente une la aplicación y el servicio. Lo hace de una manera que mantiene otras aplicaciones (o individuos) de envío de contenido a un azulejo no poseen. Y naturalmente, toda la comunicación se realiza sobre un canal seguro.
Esto funciona si o no haya iniciado sesión en Windows utilizando un Windows Live ID. Windows 8 es mejor cuando tienes una cuenta de conexión, como usted tendrá acceso a mejoras, tales como almacenamiento en la nube app; Windows móvil y configuración de la aplicación; y single sign-on para múltiples aplicaciones. La plataforma de notificación push utiliza un mecanismo de autenticación anónima, por lo que incluso que si usted iniciar sesión con un Windows Live ID, el desarrollador no puede utilizar la tubería de notificación para encontrar su Windows Live ID, información del sistema o ubicación.
Construcción a escala
La plataforma tiene que soportar un número increíblemente grande de usuarios y aplicaciones. Durante la fase de desarrollo pre-beta, nosotros ya estábamos enviando actualizaciones de azulejo de casi 90 millones por día. La aplicación de las existencias es uno de los populares pruebe las aplicaciones de la versión Developer Preview. Cuando fue lanzado el Developer Preview, vimos cuidadosamente tráfico entrante a través de los centros de datos para supervisar el scale-out.
El diseño WNS se basa en la arquitectura de servicios de Windows Live Messenger. De hecho, la parte de servicio de la plataforma de notificaciones fue construida por el mismo equipo. Aquí están algunas estadísticas para darle una idea de la magnitud de los servicios de Windows Live Messenger hoy:
- 300 millones de usuarios activos mensuales
- inicios de sesión diarias 630 millones
- notificaciones diarias 10 billones
- Máximo de más de 40 millones de conexiones simultáneas en línea (SOCs)
- Más de 3.000 máquinas de enrutamiento de mensajes en el mundo
Para vigilar cuidadosamente el desempeño de la plataforma de notificaciones, hemos añadido métricas en el administrador de tareas nuevas que le permiten realizar un seguimiento de cuánto ancho de banda de la plataforma de azulejo está consumiendo para cada aplicación. Uso de recursos para los azulejos debe ser relativamente baja.
En Windows 8, nos propusimos para diseñar una plataforma de notificaciones que proporcione información de un vistazo, sin todos los problemas de performance y batería vida que enfrentan a los modelos tradicionales basados en el gadget y plug-in. Para ello, cada decisión de diseño que hicimos fue visto a través del lente de la eficacia de vida rendimiento y batería.
Para que sea fácil para los desarrolladores de aplicaciones participar, construimos WNS por lo que los desarrolladores podrían crear azulejos vivos sin tener que escribir código de conectividad de red complicada. Ya WNS utiliza tecnologías Web estándar, como HTTP POST, resulta fácil a los desarrolladores integrar notificaciones basadas en sus servicios Web existentes.
El resultado es una plataforma de notificaciones que ofrece información de un vistazo. Sin embargo aún puede instalar tantas aplicaciones como desee sin preocuparse por el impacto sobre la vida de la batería o el rendimiento.
.jpg)
Ryan Haveson tiene más de 15 años de experiencia liderando equipos de ingeniería y entrega de software y servicios para algunas de las marcas más reconocidas del mundo, incluyendo Xbox y Windows. Fue un director de grupo en el equipo de experiencia de Windows para Windows 8. Él y su equipo diseñado y entregan al usuario final y características orientadas al desarrollador, incluyendo la plataforma de notificaciones de azulejo vivo y el administrador de tareas nuevas. Actualmente lidera al grupo de ingeniería de sistemas en Qualcomm Inc. para los de Windows/Windows Phone en División Snapdragon en sunny San Diego. Llegar a él en ryanhaveson@hotmail.com o en linkedin.com/in/ryanha.