A todos nosotros nos encanta Android. Pero si hemos manejado Android e IOS nos hemos dado cuenta que en IOS el rendimiento parece ir mucho más fluido. Hoy voy a resolveros la pregunta de ¿Por qué Android no es tan fluido como IOS?
Pues la respuesta nos la da el ingeniero de Google Andew Munn a través de Google+:
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
Un ejemplo a esto sería por ejemplo si navegáis por internet, en IOS si a mitad de cargas la página os movéis por ella ésta dejara de cargar y cuando soltéis el dedo volverá a cargar. En Android mientras os movéis por la página se terminara de cargar a la vez.
Esto por ejemplo no pasa en los dispositivos Android con doble núcleo, ya que cada núcleo se encarga de hacer una cosa (cargar la página y cargar la interfaz de pantalla).
Claro que esta es la explicación sencilla. Para los más enterados en el tema os pongo la explicación completa (que ya interviene la aceleración por hardware, optimización de código, prioridades, etc.), hecha por Ricardo Galli:
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 virtual, 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 extremos” (corner cases) al que ir detectando y agregando heurísticas que se aprenden con la experiencia.
Es más que probable que el problema desaparezca (por tres razones fundamentales, las mejoras en el scheduler, la gestión de la máquina virtual 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
Pero he aqui lo mejor de Android, y es que los propios ingenieros admiten esto y trabajan duro para mejorarlo. Tanto es asi que ha sido el foco de atención en su nueva versión ICS y de seguro que se pondra a la par (si no lo supera) en nivel de fluidez.
