Hace 11 años | Por Nights a appleweblog.com
Publicado hace 11 años por Nights a appleweblog.com

Hay una eterna discusión que aparece una vez tras otra en los debates de geeks. ¿Por qué un dispositivo con Android se siente menos fluido que uno con el sistema iOS? No se trata de simples conclusiones subjetivas, es algo que ocurre de verdad, un pequeño retardo entre el momento en que tocamos la pantalla para realizar una acción y el momento en que esta se realiza. Andrew Munn, estudiante universitario de software ha dado una respuesta satisfactoria en base a su etapa como interino en Google.

Comentarios

D

#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...

D

#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.

D

#23 Está claro que en fluidez no es una copia

D
editado

#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.

mondi

#22 Eso fue un rumor que circuló por ciertos prototipos iniciales. http://www.osnews.com/story/25264

Escapology

#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.



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.

Elric
editado

#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.

gallir
editado

#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.

Elric

¡Upsss! Se me olvidó poner que el comentario #35 era en respuesta a #33 . Fallos de novato

De nuevo, un saludo.

D

#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).

D

#43 Largo, pero... largo
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.

Elric
editado

#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.

D
editado

#30 En qué cárnica trabajas? Accenture, everis, indra?

D

#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:

http://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.

D

#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.

D

#6 En los dos ejemplos que he puesto en #5 no. Con el Samsung Galaxy mini puede que si. Pero vamos, es un hardware muy inferior al de un iPhone.

Robus
editado

#5 En mi iPhone 3GS, desde que le puse el iOS 5, la fluidez se ha ido a tomar viento...

g

#5
Tengo un SG2 y un iPad 2, y te aseguro que lo del SG2 no es "fluidez total"

bewog

#5 bonito ejemplo.. curiosamente tengo un asus transformer, y fluidez total lo que es fluidez total no tiene pese a los trucos que hacen para optimizar el display:

Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1280x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU

Elric
D

#4 Windows Phone no está hecho para un hardware concreto y es más fluido que android. En realidad cualquier cosa es más fluida que android. Y del malware mejor no hablamos.

Ihzan

#4 ¿ese extra de fluidez es realmente relevante?

Depende de para quien. Yo acabo de comprar un Xperia Neo con gingerbread y lo primero que he hecho es calzarme la mitad de los programas preinstalados en el smartphone puesto que tarda casi 1 min en arrancar.

Ahora va mucho mejor . Para mi, si es importante que el dispositivo sea rapido (tb aplicable a pc´s y demas), otra cosa es ¿cuanto estoy dispuesto a pagar de mas?

p

#14 ¿Cómo has echo eso? A mi tambien me arranca en un minuto y me gustaria reducirlo.

Ihzan

#31 Poco a poco, la verdad es que llevo muy poco con el, seguro que mas de uno aquí podrá ayudarte mas.

Yo saque el tlfno con Vodafone, así que venía muchas aplicaciones de fabrica con el. Utilice el Advanced Task Manager creo recordar para quitar muchas de ellas.

Ahora estoy intentando dar un paso mas, cuando tenga tiempo investigar en logearme como root y seguir calzandome cosas que no use.

Aun así, no creas que es la panacea. Yo me asuste puesto que al principio llego a sobrepasar el minuto. Ahora no llega pero sigue siendo lento en mi opinión y por eso voy a seguir investigando.

Yo estoy trasteando por aquí (http://www.htcmania.com/foro.php)

Espero que te ayude

p

#32 Gracias, miraré por ahí.

oconel

#14 Es de coña que las operadoras nos metan tantas tonterías en el móvil que tengamos que rootearlo para poder utilizarlo a nuestro gusto.

Lo que me recuerda que tengo que rootear mi HTC...

Lobazo

#4 Hombre, un jailbreak y te va igual de fluido con la parte de software "liberada" al menos.

R
editado

#4 No. El sistema de prioridades para los hilos es dinámico y en tiempo real en iOS y Windows Phone7 mientrás que en Android la gestión de hilos se realiza mediante un sistema estático de prioridades similar al de los PCs.

b
editado

Si le adjuntas una power balance, la fluided, la agilidad y los reflejos aumentan de forma exponencial

D

El artículo tiene su interés pero no se, no prefiero una pantalla más fluida (que tampoco es tanto más) a costa de no poder, por ejemplo, usar el bluetooth en el coche y muchas cosas más. Me quedo con mi HTC.

JanSmite

#8 ¿No poder usar el bluetooth en el coche? Que yo sepa, sí se puede.

D

#40 Pues yo tengo amigos fanboys appeleros y no hubo narices de conectar el iphone al bluetooth para oir canciones o recibir llamadas, en cambio mi htc a la primera. Yo tengo entendido que el BT está capado, pero eso sólo lo ponía como ejemplo.De todos modos tTe hablo de hace un par de años, supongo que ya se haya solucionado según tu comentario.

JanSmite

#50 Tengo un auricular manos libres por bluetooth y no tuve que hacer nada especial para conectarme. Lo mismo con el bluetooth del coche, uno que va a la toma del mechero, y lo mismo con el Astra de un amigo, que tiene el bluetooth incorporado.

D

" ¿Por qué un dispositivo con Android se siente menos fluido que uno con el sistema iOS?"

O sea, no es que sea resultado de una medición producto de una comparativa, ni de ningún análisis serio. Simplemente se siente, como el que dice que con un Peugeot se siente más seguro que con un Renault.

Pero bueno, será por el puente, sera porque se siente la navidad, pero me ahorro el negativo de sensacionalista por ver otro flame navideño.

p

Yo tengo un sony ericson xperia neo V para uso particular y del trabajo tengo un iphone 4.
Tienen un harware similar, mismo tamaño de pantalla, misma velocidad procesador y misma memoria, uno usa android 3.2 y el iphone ios 5.
La velocidad de respuesta del iphone le saca años luz de ventaja en cualquier tarea, y en dictados y traducciones y navegación...también.
Yo creo que android abarca muchisimo hardware, de todas formas cada cosa es para lo que es.

D
editado

#9 " harware similar, mismo tamaño de pantalla, misma velocidad procesador y misma memoria"

No te lo crees tú ni harto de vino, chaval. Anda, anda. El iphone tiene dos núcleos y el xperia uno.

Que manía de hablar sin tener ni puta idea.

p

#55 Hola accorn, el que demuestra que no tiene ni puta idea eres tu.
Yo he nombrado el iphone 4, que, si miras es sus especificaciones, tiene un procesaror A4 de un solo nucleo a 800mhz,512 megas de ram y pantalla de 3.5 pulgadas.
El sony xperia neo V tiene un procesador arm a 1ghz, 512 mb ram y pantalla de 3.5 pulgadas,¿Por qué no los voy a comparar si tengo los dos?

D

Cuando iOS recibe una pulsación del usuario, detiene cualquier otro proceso que estuviera realizando para “escuchar” e interpretar lo que la persona está haciendo sobre la pantalla, la interfaz de usuario tiene prioridad absoluta. En cambio cuando un tablet o smartphone del robot verde reciben un toque por pantalla el procedimiento a seguir es distinto. Se entiende que la acción es una más como cualquier otra en el código principal que se está ejecutando con lo que la interfaz de usuario sufre ciertos retardos, en especial cuantos más procesos se estén llevando a cabo en ese momento.
O sea, que no es más fluido, solo parece que es más fluido. En iOS tocas el teléfono y ves como te responde en el acto, pero lo que no ves el atasque de aplicaciones en segundo plano que has provocado.

D
editado

Bueno, es otra de las ventajas de ser un sistema abierto, no espera.
#18 Algo que es fluido, además de parecerlo lo es, si no dejaría de ser fluido.

D

"No se trata de simples conclusiones subjetivas, es algo que ocurre de verdad"

Ah claro, si ocurre de verdad entonces vale.

Alguien puede decir si es así?

palitroque

Flame ON

ramores

Por si alguno no lo noto aun, el articulo cuestionador del rendimiento de ANDROID esta en un blog que se llama APPLEweblog.com.

D

#19 Si que lo vieron, pero eso no importa, un fanboy siempre lo vera objetivo o sensacionalista.

vtomasr5

Al parecer aqui (https://plus.google.com/100838276097451809262/posts) hay una mejor respuesta de un ex-ingeniero de Google del equipo Android

JanSmite
editado

Por cierto, ¿por qué es errónea esta noticia, si incluso un ingeniero de Android lo reconoce?:

"Roman Guy, un ingeniero de software del equipo de Android, ha admitido estos problemas pero también ha dicho que estén trabajando en nuevos modos de implementar las animaciones para solucionar los problemas de la respuesta. De todos modos, también ha comentado que no son pocos los inconvenientes para crear un nuevo kit de interfaz gráfica para los desarrolladores."

Sacado de http://www.genbeta.com/movil/un-ex-empleado-de-google-describe-los-motivos-por-los-que-las-animaciones-son-menos-fluidas-en-android

PD: El enlace del meneo ya no existe, por lo que parece.

llamamepanete
editado

Lo que dice el artículo en inglés, del cual la traducción al español es pésima es bastante cierto.

No obstante, se puede mejorar bastante la respuesta de cualquier Android rooteado, usando comandos básicos de UNIX sobre los procesos que queremos optimizar. Un ejemplo: renice 5 `pidof com.google.process.gapps` && renice -15 `pidof com.android.phone` && renice -15 `pidof com.android.inputmethod.latin` && renice -18 `busybox pidof com.android.systemui`

bewog

estoy mezclando un par de todas las cosas que he leido ultimamente sobre este tema, pero hay una cosa que leí que me parece que da en el clavo, a mi me ha pasado, que si estoy instalando alguna aplicación en background, el teclado deja de responder y lo mismo tarda medio segundo en registrar la pulsación de la tecla, quedando una experiencia de usuario desastrosa. En cambio comentaban que en iOS detenia la instalación en segundo plano mientras estuvieses interactuando en la pantalla.

Bien.. ¿que es mas optimo? por supuesto en android la instalación de la aplicación terminara antes, porque no la detienes.

Francamente, me importa 0 que la instalación que he dejado en segundo plano para hacer otra cosa termine 1s o 10s despues, yo quiero que el teclado reaccione al instante de apretar la pantalla y muestre en el textbox la tecla pulsada de manera inmediata. Eso es fluidez, y no hay que mezclarlo con el rendimiento.

Elric

> 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.

Por favor, no me malinterprete. En ningún momento he puesto en duda su posible conocimiento sobre el tema. Únicamente lo he supuesto a juzgar que escribía con cierta propiedad sobre el tema. Ser ingeniero y doctorado en informática sí le asegura conocer "algo" sobre el tema. Por tanto no me equivocaba suponiendo que ha estudiado informática . Y sobre firmwares, yo actualmente estoy usando el CyanogenMod 9 con ICS en un Nexus S y un kernel alternativo al que venía de stock.

> 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).

Buena observación. Y francamente, eso espero. Una mejora en las TLB's y por tanto en el manejo de las tablas de paginación, así como en las cachés, mejorarían considerablemente el SO. Sin embargo creo que hasta que no este bien afianzado Ice Cream Sandwich en nuestros android's no podremos estar plenamente seguro de ello. Aún no ha salido la versión para Nexus S (aunque está a punto de salir) y únicamente lleva poco tiempo en el mercado con el Galaxy Nexus. No obstante he de admitir que actualmente la versión alpha que tengo instalado en mi Nexus S va bastante bien y fluido.

Un saludo. Espero ansiosamente su apunte sobre este tema.

D

¿Qué hace en pendientes un enlace a una noticia que ya no existe?

Miyata
editado

He llegado tarde

La página que estás buscando no se ha encontrado

Puede que la página cambiase de dirección o nunca existiera. Si crees que se trata de un problema ponte en contacto con nosotros o revisa el archivo.

¿ Alguien me puede decir de cuantos segundos de diferencia estamos hablando para asumir que uno es mas fluido que otro ? Vamos, un dato concreto para situarme y saber de que estamos discutiendo.

D

Porque salió de la mente de un genio. Porque es mejor en todo a Android: más capacidad de memoria, más versatilidad, mejor diseño, con ABS y elevaluna eléctrica. Además, si compras dos, te regalan un imán para la nevera. ¿Qué más se puede pedir?

D

AMÉN maese Gallir!