Uno de los puntos que innegablemente tenemos que admitir en pos de iOS es el apartado visual y de sensación de fluidez, donde resalta especialmente por su rapidez a la hora de sacar a la luz todo el potencial de unas aplicaciones con un apartado visual muy cuidado, sin embargo, esas mismas aplicaciones, ejecutadas en Android en unos terminales de similares características, no dan tanto resultado.
Muchos nos podemos quejar de las empresas, de los desarrolladores que no cuidan una línea de estilo conjunta para todas sus aplicaciones intentando que no sean inguales. Muchos nos hemos estado preguntando por qué si tienen un código prácticamente idéntico en ambas versiones y si se tienen terminales con capacidades idénticas en iOS se ve más fluído que en Android. Pero por fin nos encontramos una respuesta, y para gozo de muchos, no tiene que ver con las aplicaciones en sí.
La respuesta viene gracias al Google+ de uno de los más recientes ingenieros de Google, Andrew Munn, que ha decidido dar explicaciones de por qué esta aparente discriminación a Android, que resulta no ser tal.
No son por pausas GC. Tampoco es porque Android ejecute bytecode y porque iOS en cambio haga lo propio código nativo. La causa es que en iOS toda interfaz se procesa en unos procesos dedicados las interfaces con una alta prioridad a tiempo real que ocurre cuando se paran algunas acciones. Sin embargo Android ejecuta al estilo de un ordenador tradicional, donde el modelo de renderización ocurre en el proceso principal con una prioridad normal, causando que todo parezca menos fluido
Por ejemplo, coged un iPad o iPhones y ejecutad Safari y cargad una página web compleja como puede ser Facebook. A mitad de la carga pulsad la pantalla y moveos por ella. Se parará porque está constantemente renderizando a tiempo real y parará hasta que dejéis de pulsar la pantalla
Sin embargo, si usáis un terminal Android y cargáis la misma página, a la par que os movéis se irá cargando tanto la interfaz como el contenido, proceso para el cual los terminales con doble núcleo vienen a la perfección
La explicación, más compleja que el resumen que hemos hecho, incluye diversos factores como la aceleración de hardware, la optimización del código y las prioridades a la hora de procesar, pero nos explica el problema base de una de las preguntas que más se hacen en la guerra ente Android e iOS.
El problema de la latencia en Android es fundamentalmente un problema del scheduler. Android funciona mucho mejor con el “multitask” (en realidad “multiprogramación”) porque es un Linux y no han tocado prácticamente la gestión de procesos. Para arreglar este problema sólo tienen que mejorar el scheduler. Seguramente están trabajando en ello, y de hecho se ha mejorado mucho.
El otro problema que tiene Android es que cada proceso es una máquina virtual de Java separada al que han optimizado haciendo que se comparta la memoria de las librerías comunes (como hace naturalmente el Linux/UNIX) y código muy optimizado.
Los programas en Android están en ese código intermedio que es interpretado por la máquina vitual, en cambio en iOS es nativo del procesador (que da ventajas de velocidad, pero desventajas de portabilidad y diversidad, lo que solucionan con un sólo tipo de hardware). Seguramente hay cosas que se pueden mejorar, pero esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché.
Los schedulers no son una ciencia exacta, es algo bastante quisquilloso, con montón de “casos exremos” (corner cases) al que ir detectactando y agregando heurísticas que se aprenden con la experiencia.
Es más que probable que el problema desaparezca (por tres razones fundamentalas, las mejoras en el scheduler, la gestión de la máquina vrtuale de Java y la mejora del hardware), lo que no se puede decir, a estas alturas, es que siempre será así, y que es un problema de diseño original
Via: Xataka Android
Comentarios
Publicar un comentario