Saludos a tod@s. Como ya sabéis, Jelly Bean (Android 4.1) ha empezado ya a caminar entre nosotros, de momento en los Galaxy Nexus y la nueva tablet Nexus 7. Otros, como mi Nexus S, estamos esperando impacientemente nuestra ración.

Ya habréis visto algunas de las nuevas aplicaciones y opciones que incorpora Jelly Bean … pero hoy vamos a “bucear” más profundo. Vamos a (¿intentar?) explicaros cómo Jelly Bean consigue que un Galaxy Nexus se mueva como un Galaxy S3, 8 meses más joven.

Por supuesto, las “tripas” del terminal siempre tienen algo que ver. Pero, como también sabemos de sobra, muchas veces los procesadores más potentes, o el número de núcleos más elevado, no garantizan una experiencia completamente perfecta. Hay que optimizar lo que tienes. Y eso es lo que hace Jelly Bean.

La idea es la siguiente: para ver algo en una pantalla de modo “fluido” necesitas unos 60 fps (frames per second, fotogramas por segundo), o 60 Hz. Vale, pues forcemos esos 60 Hz, y ya está. No es tan fácil.

Esos 60 Hz significan que el procesador tiene unos 16 ms (divide un segundo en 1000 partes … y sólo tienes 16 disponibles) para hacer que un frame sea visualizado correctamente. El problema viene cuando te das cuenta de que las pantallas se “rellenan” línea a línea … y que los procesadores del terminal no sólo están dedicados a la pantalla. Vsync, un término muy conocido para cualquiera que haya usado el ordenador para jugar alguna vez, evita el efecto de “tearing”, que es cuando una de las líneas ya está en su sitio … pero la siguiente sólo lo está a medias. ¿En qué se traduce ésto, a 60 fps?. En que la pantalla no fluye, sino que se atasca. ¿A que os suena?

En ICS, al menos es así en mi Nexus S, se nota que “le cuesta arrancar” cuando quieres pasar pantallas. Una vez ese espacio de tiempo pasa, ya es mucho más fluido que GB. Pues bien, en JB, el proceso se controla de manera mucho más rígida, haciendo que los espacios vacíos de procesamiento sean más cortos, y dando siempre espacio a esos 16 ms para que el siguiente frame aparezca. El resultado es que todo se mueve con mucha suavidad, sin tirones.

Seguro que alguno se pregunta “¿y todo eso, qué lo hace?”, “¿necesito procesadores multinúcleo para ello?”. Buenas preguntas, chic@s. Todo lo que puedo deciros es que, obviamente, la potencia gráfica y de procesador de un Galaxy Nexus no va a ser la misma que la de un Nexus S … por lo que entiendo que éste último tendrá una versión adaptada. Obligar a que GPU (gráfica) y CPU (procesador) vayan sincronizados en todo momento no debe tener que ver con que tengas 1 ó 3 procesadores. Parece claro que se le exigirá más a un mononúcleo que a un multinúcleo, pero me da la impresión que es un tema más de “gestión de recursos” que de fuerza bruta. Es cierto que Android siempre ha utilizado un “doble buffer” (significa que hay dos espacios de memoria disponibles: uno almacena el frame que va a presentar, mientras el otro se reserva para trabajar ya en el siguiente), y en JB tendremos “triple buffer” (para evitar que, como antes, algún frame sea tan “pesado” que ocupe los 16 ms disponibles), que sólo será usado cuando sea necesario. El resultado es que la reacción de la pantalla, y lo que vemos en ella, van a la par.

Lo sé, todo esto suena muy denso, como la mantequilla (“Butter”, en inglés, el nombre del programa asociado a estas mejoras de rendimiento en Android). Espero que, al menos, la explicación haya sido lo suficientemente clara para que sigáis la idea de lo que corre debajo de Jelly Bean.

Y como siempre vale más una imagen que mil palabras, aquí tenéis, a velocidad súper-lenta, la diferencia entre ICS y JB en un Galaxy Nexus. Repetir conmigo: “mantequilla … mantequilla …”

La fuente de este artículo, aquí.