Actualizar Live Tiles sin agotar la batería

Una de las cosas que se está convirtiendo en un lugar común en todas nuestras “pantallas” es la idea de las notificaciones “ligeras”. Originalmente, los Gadgets de Windows eran los que ofrecían este tipo de funcionalidad: la idea es tener un pequeño visor de acceso rápido a cierto tipo de información crítica (noticias, estado del tiempo, resultados deportivos, datos económicos o empresariales son algunos ejemplos). Pero el tiempo de arranque y modelo de los gadgets no son compatibles con el objetivo de reducir el consumo eléctrico general (un aspecto muy importante en ordenadores de escritorio y portatiles), ni con el de ofrecer una plataforma de pantalla completa a los desarrolladores. Además, la pantalla de Inicio de Windows 8 dispone de mucha más superficie para albergar más elementos de este tipo de notificaciones y una interfaz de usuario para gestionar las actualizaciones (incluyendo el uso de los recursos de red). En una experiencia moderna donde cada vez hay más información que nos llega desde fuera y en snippets estructurados, se abre ahora una gran oportunidad para usuarios y desarrolladores. En este artículo de Ryan Haveson escribe sobre el desarrollo de las Live Tiles estilo Metro y cómo escala la arquitectura para mantener un elevado número de Tiles al tiempo que conseguimos reducir el consumo de energía y la carga del sistema globalmente.

–Steven Sinofsky

Todos sabemos que el rendimiento y la duración de la batería son aspectos fundamentales para un exitoso lanzamiento de Windows y en vuestros comentarios se siguen alabando estas cualidades. Por ejemplo, @KISSmakesmeSMILE lo resumía bien al escribir hace poco:

“…intentad igualar, o mejor aún, superar… los logros de ejecución de la batería de [competidor] con usos de carga ligeros/bajos.”

Al mismo tiempo, sabemos que los entornos actuales (desde los PCs a las TVs y teléfonos) disponen de algún modelo de gadget, widget o complemento que les permite ofrecer información inmediata y directa. Al ver las noticias en la televisión, deportes o el tiempo aparece una pantalla estructurada con información que viene de muchos sitios y se nos ofrece agrupada, en tiempo real. La gente espera poder conocer de manera inmediata el precio de sus acciones, el estado del tiempo, los emails que le van llegando, las citas pendientes, ciertos datos económicos de su empresa o incluso informaciones de sus redes sociales en cuestión de segundos antes de regresar a lo que tengan que hacer en ese momento. En gran medida, podríamos decir que el PC todavía tiene mucho trabajo por delante en esta área si se compara con otros dispositivos. Cuando empezamos a diseñar nuestra infraestructura de notificaciones, nuestro reto consistía en cómo conseguir que el PC diera sensación de “vida” y actividad pero que al mismo tiempo siguiera conservando una excelente eficiencia en cuanto al consumo de energía y ancho de banda usado. Este objetivo quedaba bastante bien expresado en las palabras de @AndyCadley:

“Trata todas tus aplicaciones “Metro” como si estuvieran funcionando siempre (pero con nulo impacto en la batería/rendimiento)”

La pantalla de Inicio también ayuda a esta eficiencia desde el punto de vista del modelo de usuario, ya que nos proporciona toda una pantalla completa libre sin interferir en el escritorio o las aplicaciones estilo Metro cuando estamos centrados en ellas. Además, no solamente queríamos que fuera eficiente, queríamos asegurarnos de que el usuario podría instalar todas las aplicaciones de notificación que quisiera sin tener que preocuparse del impacto que podrían tener sobre el rendimiento o la duración de la batería.

Una de las cosas que notamos cuando empezamos a utilizar Windows 8 internamente es que la capacidad para utilizar la pantalla de Inicio como una pantalla unificada y fácil de leer para las aplicaciones de línea de negocio se convertía en un factor de mejora de la productividad. Vemos que hay un gran interés por las aplicaciones orientadas fundamentalmente a las notificaciones. Gracia a la escalabilidad de nuestra nueva plataforma de notificaciones en modo “push”, Windows 8 nos ofrece esta posibilidad con un impacto mínimo sobre el sistema, lo que supone una mejora sustancial sobre la multitud de mecanismos que a día de hoy podemos encontrar para Windows. No cuesta mucho imaginar un escenario, sobre todo en el futuro próximo, donde hasta el más furibundo partidario del PC de escritorio reconocerá el gran valor que tienen esta pantalla de Inicio como área de notificación centralizada y bien presentada (y controlada) a la que se llega con una simple combinación de teclas.

Los objetivos de la plataforma de notificación

Conseguir que cientos de Tiles de aplicación se mantengan activos y al mismo tiempo garantizar que no se degrada el rendimiento del equipo parecen objetivos contradictorios. Después de todo, el término “actividad”, por definición, significa consumo de recursos: obtener una notificación desde la nube exige el uso de la red, y mostrarla en una Tile exige recursos de CPU/GPU, etc. Para llegar al diseño adecuado sabíamos que nos teniamos que centrar en los objetivos con que habíamos empezado:

• Permitir la presencia de cientos de Live Tiles sin degradar el rendimiento
• Superar los globos, etiquetas y textos, dando paso a imágenes atractivas
• Hacerlo fácil para los desarrolladores de modo que puedan hacerlo de forma casi inmediata
• Conseguir notificaciones en tiempo real y que los “mensajes instantáneos” sean instantáneos

A partir de estos objetivos, la primera decisión fundamental de arquitectura fue que la plataforma debería estar gestionada por datos, o sea, que no se tenía que ejecutar ningún código de aplicación en segundo plano para que funcionase la pantalla de Inicio.

Si consideramos la anatomía del sistema de entrega de notificaciones, vemos que consiste en una serie de piezas: la lógica para determinar el momento de la conexión, autenticación, caché local, rendering, manejo de errores, algoritmos de back-off, throttling, etc. Además, el sistema tiene que resolver una serie de problemas en el lado del servicio, como saber en todo momento si está conectado o no, de manera que pueda cachear contenidos no entregados y manejar escenarios complejos de reintento. ¿Puedes imaginar cómo sería si cada una de las aplicaciones con una Live Tile tuviera su propia versión de todo este código cliente/servidor? No solamente podríamos tener errores en cada implementación, sino que acabaríamos teniendo en memoria copias y más copias de prácticamente el mismo código, una vez por cada una de las aplicaciones cargadas en la memoria, y este código estaría paginándose continuamente desde y hacia el disco. Sin duda sería realmente ineficiente ya que supondría que todas las aplicaciones tendrían que estar funcionando todo el tiempo para mantener la actividad de la pantalla de Inicio. Incluso en máquinas con mucha memoria, el rendimiento del sistema puede venirse abajo.

Si leéis el artículo de Bill Karagounis que explica cómo hemos reducido el consumo de memoria en Windows 8, ya sabemos que el rendimiento se degrada a medida que aumenta el número de procesos, las DLLs, los servicios, etc. en ejecución. Si cada Live Tile ejecutase su propio código, no podríamos conseguir nunca nuestro primer objetivo de hacer posible la ejecución simultánea de cientos de Live Tiles sin perjudicar el rendimiento.

Hemos optado por crear un modelo orientado a datos. Esto significa que el desarrollador puede expresar su Live Tile utilizando un conjunto de propiedades y plantillas predefinidas, en este caso, con un esquema XML. Los datos de la Tile en XML se envían al servicio WPNS (Windows Push Notification Service) utilizando un sencillo procedimiento POST de HTML y nosotros nos encargamos de lo demás. Todo el código necesario para la conexión y reconexión, autenticación, cacheo, presentación en pantalla, gestión de errores, etc. se hace de una manera uniforme y con un consumo eficiente de recursos.

Este es un ejemplo de las muchas plantillas de Live Tiles que pueden utilizar los desarrolladores para sus aplicaciones de Windows 8. Esta consiste en un campo de texto y una imagen, pero puede haber muchas otras plantillas donde elegir.

Figura1: plantilla de ejemplo ( TileWideImageAndText )

Este es el código XML que describe esta Live Tile concretamente:

<?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>

La decisión de optar por un modelo orientado a datos nos permite cubrir nuestros dos primeros objetivos (rendimiento y una experiencia de fidelización alta), pero teníamos aún que resolver cómo conseguir la entrega de notificaciones en tiempo real y un modelo de desarrollo lo más simple posible.

Existen dos patrones de diseño de alto nivel para la entrega de contenidos cliente-servidor: el modelo activo o “polling” y el pasivo o “push”. El polling es cuando el cliente consulta al servicio a intervalos regulares (p.ej. cada 90 minutos) para ver si hay contenidos nuevos. El modo push es aquel en el que, cuando aparecen contenidos nuevos, el servicio envía los datos al cliente directamente.

La única manera de dar cobertura a notificaciones instantáneas con un modelo polling sería aplicando una frecuencia de consulta suficientemente elevada (por ejemplo cada 5 segundos), así que si llega un mensaje nuevo, se vería casi de manera instantánea en pantalla. Pero esta opción se cargaría directamente nuestros objetivos de rendimiento: con un intervalo de polling de 5 segundos, la pila de red de la conexión inalámbrica nunca estaría inactiva, la batería estaría sometida a un régimen de consumo insostenible y las máquinas de escritorio estarían siempre activas. Sería más o menos como estar hablando todo el día con el móvil: la batería no puede durar tanto tiempo. Pero por encima de todo ello, pensemos en la sobrecarga y el despilfarro que supone consultar cada 5 segundos si hay algo nuevo cuando la probabilidad es ciertamente muy escasa. Históricamente, las notificaciones en la bandeja del sistema y en los gadgets que se empezaron a utilizar con Windows Vista, empleaban el mecanismo de polling. Pero sea cual sea la configuración de polling que tengamos en  los actuales servicios de tiempo real no existe ningún intervalo lo suficientemente corto para considerarse instantáneo.

Así que, para Windows 8 optamos por una arquitectura de servicio basada en el modo pasivo (push). Fue una decisión importante porque suponía que tendríamos que montar una plataforma a escala global para poder alojar las Tiles de cientos de miles de aplicaciones para más de mil millones de clientes. Pero teníamos claro su valor: los desarrolladores podrían enviar de manera gratuita, súper-eficiente y en tiempo real sus notificaciones a los clientes gratis sin tener que crear o mantener sus propias conexiones permanentes con el cliente.

La plataforma de notificación “push”

Veamos con más detalle los distintos componentes de la plataforma, de manera que pueda explicar los aspectos más sutiles del diseño. En el siguiente diagrama se ven tres entidades principales:

1. El servicio WNS (Windows Push Notification Service): se encarga de la ejecución de los Live Tiles y las notificaciones.
2. Servicio de aplicación: Es el servicio web que ejecuta una aplicación estilo Metro (p.ej. desde su actual sitio web) que envía notificaciones y actualizaciones de Tiles a través del WNS. Un ejemplo de esto puede ser el servicio de back-end para una aplicación de pronóstico del tiempo que viene en la Preliminar de Desarrollo, o un servicio de back-end que mantenga fotos en una aplicación de red social.
3. Plataforma de cliente de Windows 8: Es el PC en sí y los subcomponentes del S.O. que componen la infraestructura de la experiencia en su conjunto.

Figura 2: La plataforma de notificaciones Push

Vamos a explicar cómo funciona esto tomando como ejemplo un caso de uso muy común. Supongamos que el servicio de aplicación es un sitio de red social que envía una actualización para la Live Tile cuando alguien hace un comentario en tu foto (podría también ser una aplicación de línea de negocio que me avise cuando se me asigna algún fallo que hay que resolver o una hoja de gastos que tuviera que revisar, por ejemplo). Cuando hay una actualización, el servicio de aplicación envía una notificación al WNS (el Paso 1 en el diagrama anterior). Desde ahí el WNS envía la notificación al cliente (Paso 2). Cuando llega la hora de mostrar la nueva información en la Tile dentro de la pantalla de Inicio, el S.O. captura esa imagen del servicio de aplicación basándose en la dirección URL contenida en el XML de la notificación (Paso 3). Cuando se han descargado la notificación y la imagen, la aplicación muestra en la pantalla de Inicio la Live Tile utilizando la plantilla indicada en el XML.

Como dijimos al principio, uno de nuestros objetivos era que los desarrolladores pudieran crear este tipo de Tiles con el mínimo esfuerzo. Así, para evitar que tengan que programar sus mecanismos de cacheo y reintento de conexión para cuando el PC no está conectado a la red (por ejemplo un portátil en modo de suspensión), lo que hacemos es cachear una notificación por cada aplicación en la nube WNS y se mantiene hasta que el PC recupera la conexión.

Al diseñar los componentes de la plataforma del cliente, queríamos estar seguros de que todo iba a hacerse respetando los objetivos de alto rendimiento y bajo consumo. Una iniciativa fundamental en este sentido fue la separación del bloque de notificación con respecto al bloque de la imagen. Un mensaje XML de notificación típico tiene menos de 1 Kb de datos, pero una imagen puede llegar fácilmente a los 150 Kb. Al separarlos, conseguimos ahorrar una gran cantidad de ancho de banda en situaciones donde se produce una gran duplicidad de imágenes. Por ejemplo, la imagen de una Tile puede ser una foto del perfil de un amigo nuestro, que tu PC ha descargado en una ocasión y la mantiene en la cache local para reutilizarla. Al independizar la notificación con respecto de la imagen también hemos podido mejorar el tratamiento de notificaciones no utilizadas, ya que nos evitamos la descarga innecesaria de la imagen. Si la pantalla de mi equipo está apagada y está en el dormitorio de mi casa mientras estoy en la oficina, no tiene mucho sentido que descargue imágenes para las Tiles que terminarán por sustituirse por sucesivas actualizaciones antes de que vuelva a usar el dispositivo.

El modelo de autenticación

Por que las Live Tile y las notificaciones suponen un aspecto clave de la experiencia de aplicación, es muy importante que el canal de comunicaciones esté autenticado y sea seguro, desde el propio servicio de aplicación hasta la Tile en nuestra pantalla de Inicio. Sería verdaderamente alarmante que una aplicación o un servicio malintencionado pudieran actualizar cualquier Live Tile en nuestros equipos. Por esta razón, utilizamos un mecanismo de autenticación anónimo que exclusivamente identifica la conexión entre el PC y el WNS. Las aplicaciones y los servicios de aplicación también se validan al comunicarse con el WNS. La autenticación de ambas conexiones con el WNS contribuye a protegernos frente a posibles abusos en la actualización de las Live Tiles, por ejemplo frente a ataques de suplantación de la identidad. El mecanismo de autenticación utilizado en el WNS vincula explícitamente la aplicación y el servicio juntos de tal manera que impide que otras aplicaciones (o algún indeseable) envíe contenidos a una Tile que no le corresponde. Y por supuesto, toda la comunicación se establece a través de un canal seguro.

Todo esto funciona con independencia de que el usuario haya iniciado su sesión con un ID de Windows Live. Sin duda, como nos explicaba Katie Frigon en su artículo sobre el inicio de sesión con un ID de Windows Live, Windows 8 va mejor cuando se utiliza una cuenta de conexión a servicios en la nube, ya que permite disfrutar de experiencias más avanzadas, como el almacenamiento en la nube, persistencia de nuestros datos y configuraciones entre distintos equipos Windows y logon único para múltiples aplicaciones. Puesto que la plataforma de notificación push utiliza un mecanismo de autenticación anónimo, aun en el caso de que el usuario inicie su sesión con un ID de Windows Live, el desarrollador de la aplicación no puede aprovechar el canal abierto por cuenta de la notificación para capturar ese ID de Windows Live, información del sistema o lugar.

Escalabilidad del servicio

Al principio de este artículo comentaba que tuvimos que crear una plataforma capaz de dar soporte a un número inmenso de usuarios y aplicaciones. Para darnos una idea de la escala que representa, en el siguiente gráfico se ve el número de notificaciones que las aplicaciones envían a Windows 8 al día. Hace un par de semanas estábamos enviando ya cerca de 90 millones de actualizaciones de Live Tiles al día, y ¡ni siquiera es una beta!

Figura 3: Notificaciones enviadas cada día a la versión Preliminar de Desarrollo de Windows 8

La aplicación de cotizaciones de bolsa es una de las aplicaciones más populares de todas las que empleamos en el entorno de test de la versión Preliminar de Desarrollo. En el gráfico siguiente se ve el número total de Live Tile registrados para esta aplicación en el primer mes desde la publicación de la Preliminar de Desarrollo.

Figure 4: Live Tiles registrados para la aplicación de Cotizaciones de Bolsa en la Preliminar de Desarrollo

Cuando sacamos la Preliminar de Desarrollo empezamos a observar el tráfico procedente de los centros de datos y a monitorizar con mucho cuidado su evolución. Aquí tenéis un diagrama de la distribución geográfica de las notificaciones en los primeros días después de la publicación de la Preliminar de Desarrollo en el //build. Como veis, los datos se expresan en unidades por milla cuadrada y se han convertido a escala logarítmica para poder representar una gran variación en los valores de densidad.

El diseño del WNS se basa en la arquitectura del servicio Windows Live Messenger y en realidad, la parte del servicio de la plataforma de notificaciones la ha hecho el mismo equipo. No hay muchos equipos en el mundo con la experiencia y conocimientos necesarios para crear un servicio escalable de nivel mundial que pueda hacerse cargo de estos volúmenes de trabajo en tan poco tiempo. Aquí os muestro algunos datos estadísticos que nos dan una idea de la escala a la que opera el servicio Windows Live Messenger en la actualidad:

• 300 millones de usuarios activos al mes
• 630 millones de inicios de sesión diarios
• 10.000 millones de notificaciones al día
• Mas de 40 millones de conexiones online simultáneas en momentos de máxima actividad
• Más de 3.000 máquinas enrutando mensajes en todo el mundo

Transparencia en el uso de recursos del Tile mediante el Administrador de Tareas

Estábamos tan apasionados con el tema del rendimiento de nuestra plataforma de notificaciones que incluso hemos añadido valores de medida en el nuevo Administrador de Tareas para poder controlar el consumo de ancho de banda de la plataforma de Live Tiles para cada una de las aplicaciones. En general el uso de recursos por parte de las Tiles debería ser relativamente escaso. Para quienes ya estáis utilizando la versión Preliminar de Desarrollo, podéis ir a la pestaña de historial de las aplicaciones en el Administrador de Tareas y mirar en la columna “Tiles” para ver cuánto ancho de banda ha consumido cada uno de las Live Tiles en los últimos 30 días.

Figura 5: Uso de recursos por parte de las Live Tiles en el historial de aplicaciones del Administrador de Tareas

Resumen

En Windows 8 hemos preparado una plataforma de notificaciones capaz de ofrecer información de primera mano sin penalizar el rendimiento ni la duración de la batería, como sucede con los modelos tradicionales de complementos y gadgets. Para ello, todas y cada una de las decisiones de diseño se han adoptado teniendo como objetivo en todo momento los objetivos de eficiencia, rendimiento y duración de la batería, Para que los desarrolladores puedan participar de manera más sencilla, hemos preparado el Servicio de Notificaciones Push de Windows (WNS) de forma que pueden crear Live Tiles sin tener que perder tiempo en desarrollar un complejo código de conexión a la red. Y puesto que el WNS emplea tecnologías web estándar como el método POST HTTP, les resultará muy sencillo integrar sus notificaciones en sus actuales servicios web.

El resultado es una plataforma de notificaciones que envía información prácticamente al instante y que permite instalar cuantas aplicaciones queramos sin tener que preocuparnos de que ello perjudique al rendimiento del equipo ni al tiempo útil de las baterías.

--Ryan Haveson

FUENTE: Steven Sinofsky - https://blogs.msdn.com/b/b8/archive/2011/11/02/updating-live-tiles-without-draining-your-battery.aspx

Saludos,

El equipo de MSDN España