EDICIóN GENERAL

Por qué iOS es más fluido que Android

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ó, 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: 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 (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?
#11 Si el equipo original de Android estaba pensado en táctil, ¿por qué su primer modelo fue una copia de blackberry? A ver si ahora la culpa va a ser de blackberry, o de palm o de windows mobile por ser muy malos y no poder copiarlos bien...
#16 ¿Copia de Blackberry?

Qué fácil que decís barbaridades, la arquitectura de Android no tiene nada que ver con la de BB, ni con casi ningún otro sistema operativo. Es una obra maestra de ingeniería.

No sé de dónde sacas que es "copia", no sé si has visto alguna demo previa al primer Android comercial (que no tiene nada que ver con la interfaz de BB), pero estás confundiendo "aspecto visual" con "copiar el sistema". O que se usen los dispositivos que hay en el mercado para demostrar tus prototipos (no puedes gastar tanto dinero en diseñar y fabricar el dispositivo de hardware desde el principio).

Insisto, decís muy fácil lo de "copiar", sin conocer nada de cómo está construido.
#22 Yo, desde luego, no entiendo de esto ni el 0,001% de lo que entiendes tú, pero hay una cosa que me sorprende. La gente que dice que Android es una copia de iOS solo por el aspecto gráfico (que ya es discutible).
Vamos que un SO se me antoja que son mil cosas y que el aspecto gráfico es solo la punta del iceberg. Que lo complejo está debajo y que no tiene porque tener nada que ver, incluso aunque el aspecto gráfico fuera una copia 100% igual.
#23 Está claro que en fluidez no es una copia :-P
#22 No quiero menospreciar las obras de ingeniería, pero en el contexto con el que se compara, android no es tan obra maestra de ingeniería en fluidez en comparación a iOS.

Por otro lado, ¿si en Android creían tanto en el táctil, y es tan obra maestra, porque su primera versión comercial no era táctil, y se ve claramente que estaban inspirados en blackberry?
Para mi una obra maestra de la ingeniería es aquella que mantiene sus ideas iniciales, fija y no distrae sus prioridades y da resultados excelentes. Android no entra en ninguna de las tres. Es buena ingeniería, pero no maestra. Los maestros en fluidez de interfaz gráfica está claro que son otros. Yo lo llamaría ingeniería discípula. No menosprecio, que ya sabemos que muchas veces el discípulo supera al maestro, pero no en esto.
#24 El primer móvil Android era el HTC G1, que era táctil con teclado deslizante. Lo del teléfono estilo blackberry era un prototipo que se mostró junto a otro prototipo de pantalla táctil.
#22 Eso fue un rumor que circuló por ciertos prototipos iniciales. www.osnews.com/story/25264
#16 Cuando presentaron por primera vez Android se hizo con dos móviles, uno como dices al estilo Blackberry y otro táctil para mostrar la versatilidad del nuevo sistema operativo Android para los diferentes tipos de móviles.

www.youtube.com/watch?v=1FJHYqE0RDg

Al final por cosas del mercado y evolución al final todos los Android llevan pantalla táctil pudiendo llevar o no teclado físico.
#11 Normalmente el planificador (scheduler) de procesos , hilos, etc, se encuentra en el kernel del SO. Esto es mejorable simplemente tratando de optimizar el código. De hecho, existen multitud de páginas web donde puedes descargarte varias versiones de kernel's de android, realizada por programadores informáticos, conocidos como "cocineros" porque además realizan ROM's personalizados de varias versiones de android.

Supongo que todo esto lo sabrá, ya que intuyo que ha estudiado informática. Yo también. Soy licenciado y no me apetece meterme ahora mismo en pleno debate porque estoy en la oficina programando para un banco en código COBOL (hágase una idea de como tengo la cabeza ahora). Aparte, que estoy de acuerdo con usted en un 95%. Por otra parte no considero que este diciendo una barbaridad. Es bastante lógico lo que afirma en su comentario.

Sin embargo no he podido evitar cuestionarme un comentario suyo. En concreto es el siguiente:
"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: en.wikipedia.org/wiki/Dalvik_virtual_machine"

Cabe decir, repito, que estoy de acuerdo con usted en casi todo. Y afirma bien diciendo que cada proceso en android es una máquina virtual de Java. Sin embargo, ¿realmente usted cree que esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché?. Yo considero que esto también beneficia también a las aplicaciones en Apple iOS. Por tanto es de suponer que Apple siempre estará un paso por delante en este aspecto, ya que como bien afirma, en iOS los programas son nativos en procesador y esto supone más "eficiencia y rapidez" que los programas cargados en una máquina virtual. Creo que mientras esto siga así, Apple siempre estará por delante, ¿no cree?.

Además esa máquina virtual es de Java. Y sí, una de las mejores cosas que tiene Java es su máquina virtual por cuestiones de su sencilla portabilidad. Sin embargo como lenguaje... quizás no es tan bueno como aparenta en un principio. Aunque este es otro tema de debate que ahora mismo no viene al caso.

Es evidente que, en lo que refiere al tema de portabilidad y tal, android sale ganando frente a Apple y por goleada. Pero Apple a esto no le importa mucho porque para ellos iOS siempre correrá en un iPhone y no en un HTC, Sambung, LG, etc. Obviamente, si un día esto tuviese que cambiar, Apple se vería en un serio aprieto. ¿Me equivoco?

Un saludo.
#30

> Supongo que todo esto lo sabrá, ya que intuyo que ha estudiado informática

No sé, quizás, sólo soy ingeniero y doctor en informática... lo que no asegura que lo sepa. Bueno, también uso firmwares alternativos en mis Androids (ahora tengo el Cyanogen 7 en uno, y uno más antiguo en el Magic)... supngo que esto da más credibilidad. Bueno, también que doy clases de sistemas operativos, y explico estos temas.

> ¿realmente usted cree que esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché?

Sí, será cada vez menor por las mejoras en hardware que están haciendo (como el multicore, supongo que vienen mejoras también en TLBs y caché). Por otro lado iOS tendrá que hacerse más complejo, lo que hará que las distancias sean cada vez más pequeñas. Cuando el usuario no perciba la diferencia, el problema ya no existirá (de hecho es casi imperceptible con el 4.0, diría yo).

Bueno, no me lío, que ya estoy escribiendo un apunte sobre este tema.
¡Upsss! Se me olvidó poner que el comentario #35 era en respuesta a #33 . Fallos de novato :-P

De nuevo, un saludo.
#30 Por tanto es de suponer que Apple siempre estará un paso por delante en este aspecto, ya que como bien afirma, en iOS los programas son nativos en procesador y esto supone más "eficiencia y rapidez"

Una cosa es la eficiencia en ejecución, y otra el problema de falta de respuesta que se plantea en el artículo. La primera no suele ser un problema en el mundo Java desde hace tiempo puesto que el término cache de #11, asociado a Java, hace referencia a los atajos y optimizaciones para la ejecución de bytecodes/optcodes. El cacheado sería, por decirlo de alguna manera, una versión binaria cuasinativa que evita muchos procesos de 'traducción' cuando se trabaja en modo JIT. Es decir, Java podría tener en memoria una imagen ejecutable nativa tan eficiente como la del compilado iOS; virtualmente, porque nunca será perfecta y siempre habrá más overheading al trabajar en dos capas. Hoy en día la diferencia es poco apreciable. Empieza a ser frecuente ver aplicaciones Java casi tan eficientes como otras realizadas en C++, esto tiene truco: una aplicación C++ será siempre más eficiente si está muy bien afinada, pero no todas lo están. Y aquí volvemos a iOS: viendo el nivel de muchas de sus aplicaciones, no creo que los que llegan ahora al mundo de Objective-C sean expertos 'pulidores' de aplicaciones.

De todos modos, y como solución futurible a favor de Java, está la posibilidad de incorporar una VM por hardware (algo que ya viene de la era de Sun). Aunque no creo que sea necesario con las CPUs cada vez más potentes y de 2/4 núcleos.

El asunto de la 'falta de respuesta' es otro, y en mi opinión está desvinculado de las VMs de Java. Puede que el artículo haya acertado, de casualidad, en una cosa. iOS puede despachar hardIRQs (lo que llama 'prioridad absoluta') directamente a las aplicaciones (convertidas en eventos listos para ser manejados). iOS se lo puede permitir porque podría (hipotéticamente; lo desconozco) incorporar por hardware el propio controlador gestual. En Android esto se convierte en una casacada de interrupciones que van desde el hardware, pasando por el controlador, relanzamiento de softIRQs, despachado en la VM con interrupción de su hilo(s) de ejecución y delegación de eventos al manejador de la app... ¿Y para qué sirve todo esto? Para que podamos elegir libremente el teléfono que te apetezca sin depender de un solo terminal (iPhone). Este es el coste a pagar y es algo que hereda del mundo GNU/Linux (modularidad y kernel desacoplado del hardware).
#43 Largo, pero... largo :-D
Gracias por el enlace y la exposición. Ahora mismo estaba comentando sobre el tema con un commiter de Lucene al hilo de Dalvik. Si saco algo en claro, lo comento en el blog.
#43 Muy buen artículo.

Gracias por tomarse la molestia y el tiempo en redactarlo. Me ha gustado especialmente el apartado de "El lenguaje y plataforma", en la que he podido encontrar respuesta a mi duda de "código nativo vs. máquina virtual". No conocía el mecanismo copy-on-write por el cual se sustenta la idea y el proceso inicial zygote (el cual tampoco tenía conocimiento). Eso respondió a mis anteriores dudas.

Entre otras conclusiones que he sacado al respecto, creo que hay que quitarse el sombrero ante la gente de Google por diseñar un sistema operativo a la altura del iOS de Apple y que además (a diferencia del iOS) Android corra con una máquina virtual por debajo.

¡Chapeau!

Un saludo.
#30 En qué cárnica trabajas? Accenture, everis, indra?
#11 Dices que:

En primer lugar afirma que Android fue diseñado para "joystick y teclado", lo que es falso.

Debes tener poca memoria porque cuando se empezaba a oir eso de "Android", los prototipos eran burdas copias de las balackberries de entonces:

gadgetsteria.com/wp-content/uploads/2009/11/google-phone.jpg

También hay que destacar que Android no lo empezó Google, sino Android Inc., una firma comprada por Google en 2005. Y ellos nunca pensaron en una pantalla táctil.
#11 Por comentarios como el suyo suelo pasar más tiempo leyendo opiniones de noticias que las propias noticias en sí.

Gracias. Ha comentado muchos detalles técnicos interesantes que desconocía.

menéame