Android, iOS, WP7, QNX y WebOS, mirando estas 5 maravillas de la tecnología nos salto una pregunta al aire ¿por qué iOS, Windows Phone 7, QNX y webOS son más fluidos que Android? Esto traerá comentarios por parte de los seguidores de los 5 sistemas operativos. Ahora, para comenzar con el análisis debemos ver esto como algo que tiene su razón de ser. Según Andrew Munn un joven ingeniero y ex integrante del equipo Android que ahora esta trabajando con Microsoft en WP7, nos dice:
[quote]“iOS la hace una renderización de la interfaz de usuario con un thread dedicado en tiempo real. Por otra parte, Android sigue el modelo de PC tradicionales de la representación de un theread que se asocia al principal con prioridad normal.”[/quote]
De forma gráfica le mostramos lo que nuestro amigo Andrew nos quiere decir:
En la imagen de Android se ve claramente como los threads son manejados con la misma prioridad y a uno solo. Sin embargo, los otros sistemas operativos tienen prioridades diferentes y threads dedicados.
Pero esto no es así por si solo, hay unas razones por la cual Android utiliza ese método.
- Aceleración: La aceleración de hardware hace una gran diferencia en aplicaciones como la pantalla de arranque y el Android Market. La descarga de la prestación a la GPU también aumenta la duración de la batería, ya que las GPUs son hardware de función fija, por lo que operan con menor potencia.
- Basura [.tmp, cache, etc]: Si por ejemplo has usado una aplicación para fotos, según vas usándola ves como los “frames” por segundos [FPS] bajan su velocidad.
- Equipo: El Tegra 2, pese a las afirmaciones de marketing grandioso de Nvidia, se ve perjudicado por el ancho de banda de memoria y sin apoyo conjunto de instrucciones de NEON [instrucciones de neón son el equivalente ARM de SSE de Intel, que permiten una matriz matemática más rápido en la CPU].
- Madurez: Android tiene mucho camino por recorrer hacia una interfaz de usuario eficiente. En iOS, cada interfaz de usuario se procesa por separado y almacenado en la memoria, por lo que muchas animaciones sólo requieren de la GPU las opciones de la interfaz de usuario. El GPU es muy bueno en esto. Por desgracia, en Android la jerarquía de la interfaz de usuario hace un desbordamiento de pila antes de rendir, por lo que requieren en cada sección de animación volver a dibujar.
- La maquina Virtual: El Dalvik no es tan maduro como JVM de PC. Java es conocido por el rendimiento y la horrible interfaz gráfica de usuario en las PC. Sin embargo, muchos de los temas no se traspasan a la aplicación Dalvik. Swing era terrible porque había una plataforma cruzada en la parte superior de las API nativas. Es interesante notar que el núcleo de Windows Phone 7 de la interfaz de usuario se basa en código nativo, a pesar de que el plan original era que se base exclusivamente en Silverlight, Microsoft finalmente decidió que para obtener el tipo de rendimiento necesario de la interfaz de usuario, el código tendría que ser natural.
Como podemos notar, Android tiene mucho que hacer. En la siguiente tabla vemos como Android ha crecido en sus 2 años desde su primera version 1.5.
Al ver la tabla anterior notamos la Fe que Google le tiene a su plataforma Android. Y no es para menos, es por esto que siempre nos deja con el sabor de querer ver más.
A Google le queda mucho trabajo y se espera que con la llegada del nuevo Android 4 Ice Cream Sandwich mejore un poco esta situación. Aunque realmente es una tarea bastante difícil dado que desde un principio, Android se pensó para una era pre-iPhone, una en donde solo existían Blackberries y los dispositivos no contaban con pantallas “multitouch”. Esto explica claramente el por qué la interfaz de usuario no tiene prioridad en Android.
Por último, Munn comenta que Android debería re-escribir todo ese código si quiere seguir con lo que siempre buscan, velocidad. Pero para esto es posible que, de no encontrar una solución, tengan que rehacer su ecosistema de aplicaciones para soportar “legacy code”.
¿Ustedes que piensan?
Web Developer, JQuery, extJS,asp.net, vb.net,C#,flash AC,Database Designer, Windows Developer, SQLServer 2000-2008. MySQL, PHP, SQLIte, Android Developer.
3 Comments
Pienso que Google deberia poner a prueba esto, aunque sea para ellos probarlo y suministrarlo a unos pocos para ver que fama obtienen.
Si alguien todavía no entiende el porqué de las prioridades en Android versus prioridades de los demás sistemas, aquí un ejemplo:Twitter en iOS y Android. Ahora tienen el mismo UI, ¿verdad? Hasle refresh a ambos, y mantén el dedo puesto en la pantalla para que detecte que todavía estás usando la pantalla. Notarás una diferencia increíble. En el caso de iOS, el sistema *nunca* va a hacer refresh al timeline hasta que dejes ir del dedo, ya que la primera prioridad es hacer “rendering” al tacto y luego todo lo demás. Por eso iOS visualmente es más fluido, ya que el GPU esta haciendo todo su esfuerzo a hacer rendering a donde el tacto vaya. El “approach” de iOS siempre ha sido ser una experiencia linda, nunca ha tenido una experiencia polifacética hasta su cuarta versión.
Android, por el contrario, usa “real time multitasking” desde su primera versión, haciendo que haga todos los comandos a primera prioridad (como la tabla muestra) y va a actualizar el timeline de Twitter aunque tengas el dedo presionado en la pantalla. Pero en parte esto es una espada de doble filo, ya que el código que ya no sirve o que está sin usarse va a ser una carga para el compilador. Para eso se hizo el JIT Compiler en 2.2 FroYo y el Garbage Manager en 2.3 Gingerbread, para que DalvikVM no tenga tanta carga en sus manos para compilar y distribuir código. La visión de Android es “no me importa que sea más lento después que haga todo el trabajo bien”, no como otros sistemas en donde su código se desarrolla en vanidad y no en funcionalidad.
Quiero recordar que los dos updates en UI para Android lo han sido 2.1 Éclair y 4.0 Ice Cream Sandwich. Como bien dijo el compañero, Android nunca ha tenido su experiencia de UI como prioridad hasta que asimiló a Matias Duarte, ex Director de Experiencia de Interfaz de Palm webOS, a su equipo de trabajo.
En mi opinión, hay una manera (en teoría) para que Android sea código nativo *y* todavía tenga estas funciones. En el principio, DalvikVM es necesario para que el sistema fluya visualmente ya que era el “traductor” de su vértebra que es Linux. Ya no es tanto el caso. El problema es decidir entre dejar su código Linux o dejar su código Java-like (Java-like, ya que es una versión de Java que sólo Dalvik VM puede compilar). Prefiero que pongan Linux ya que es un sistema probado que es seguro y rápido, con extenciones de Java para compilar “legacy code”. Literalmente, es la completa fusión de Linux con DalvikVM, muy diferente al sistema híbrido que tiene ahora mismo. De ahí, puedes hacer que el “legacy code” muera dentro de dos updates más y sea completo en base Linux. Eso hace que la adaptación por parte de usuarios y desarrolladores no sea tan destructiva como decidir entre uno u otro y decir “ah, voy a hacer Android en código nativo, y todos tienen que cambiar su código de cantazo, y punto”.
P.S: Antes de que me digan “ah, eres un Apple hater por mencionar iOS nada más en tu ejemplo”, literalmente puedes hacer el mismo ejemplo en QNX ya que tiene la misma prioridad de ser lindo… “by default”. Si no me equivoco, las prioridades de WP y webOS es de dar información en tiempo real, haciendo que movimiento por tacto sea su segunda prioridad. ¿Porqué creen que todas las aplicaciones de WP siempre tienen la misma animación de introducción lindo y fluido antes de poder tocar la pantalla? Para ofrecer la información más reciente al principio y dar unos segundos de ventaja antes de que la persona pueda usar el UI para navegar el contenido. No estoy muy bien informado en cuanto las prioridades en WP, so alguien con experiencia en ese OS puede ayudar o corregir en mi explicación. :)