#59 ya pero la maquina virtual de android no es como la de java, los bycodes se interpretan solo una vez, despues se guardan en la cache, efectivamente la maquima virtual sigue estando ahi pero no interpreta cada instruccion como en java. Esto no se menciona en el articulo y es importante.
Ademas con la compilacion jit se pueden aplicar algunas optimizaciones en tiempo de ejecucion que son imposibles en un programa compilado estaticamente sobretodo con el tema de poner funciones en linea segun el tamaño del argumento con el que se hace la llamada.
http://en.wikipedia.org/wiki/Just-in-time_compilation
ojo no digo que sea mas rapido que la compilacion tradicional pero segun que casos puede ser mas rapido, mas lento o mas o menos lo mismo.
Portada
mis comunidades
otras secciones
Lo siento, pero vaya tonterías que dice, se nota que no entiende ni lo que es un scheduler o un thread (que traduce del original en inglés como "código principal").
En primer lugar afirma que Android fue diseñado para "joystick y teclado", lo que es falso. Desde que empezaron con Android (que no fue Google, sino la empresa que compró, http://en.wikipedia.org/wiki/Android_(operating_system) ) se pensó en pantalla táctil, y no tiene que vr con eso. El iOS es un derivado del Mac OS X/Darwin, que además de no estar pensado originalmente para pantallas táctil está basado en Unix, que tampoco estuvo diseñado para pantallas táctiles.
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: http://en.wikipedia.org/wiki/Dalvik_virtual_machine
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é.
Lo peor, acaba con:
El verdadero problema viene cuando nos enteramos que esto va a seguir siendo así por algún tiempo más.
¿De dónde saca eso? En Linux hubo el mismo problema durante años, porque Linus Torvalds no aceptaba chapuzas en el scheduler (cosas que sí hacía Windows, como dar mayor prioridad a la "aplicación activa"), pero se solucionó hace años con el scheduler de Ingo Molnar, el Completely Fair Scheduler (http://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
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. ¿Es que no leyó nada de la historia reciente de la informática?