Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos "Ricardo Galli", de software libre

Hace unas pocas horas escribí esta respuesta sobre Por qué iOS es más fluido que Android (con buen criterio, eliminaron la entrada). Obviamente, por cuestiones de longitud y la “respuesta rápida” que requiere un comentario, no me quedó todo lo completo que requiere el tema. Lo que me gustaría explicar daría para muchas horas de charlas. De hecho, enseño estos temas en mi asignatura de Sistemas Operativos (II), dedico al menos unas 12 hs de clase, y aún así no entramos en muchos detalles importantes. Pero intentaré resumirlo en este apunte....

[#8 Desactivado]

En resumen:
Ios es más rápido porque corre en un hardware específico.
Android está diseñado para correr bien en cualquier cualquier arquitectura.

El precio de temer libertad a la hora de escoger arquitectura es no estar tan optimizado para una concreta.

Lo que no me gusta es el título, porque quien sólo se quede con el título, puede interpretar que lo bueno se paga, que el software libre es peor, etc.

[#63 K-M]

#8 en realidad el artículo no le da tanta importancia al tema del hardware específico, sino al hecho de que en Android se puede meter cualquier programa hecho por cualquiera, por lo que el SO tiene que estar más preparado para cualquier situación, mientras que para iOS los programas han de pasar un "control de calidad" forzosamente por parte de Apple, por lo que el SO puede ser mucho más relajado.

[#71 rafaLin]

#8 No es por el hardware, es porque Android es suficientemente robusto como para ejecutar programas mal hechos, en cambio si en iPhone metes un programa mal hecho, peta, por eso está tan capado y es tan difícil que aprueben un programa para meterlo en el market.

Es cuestión de política, Android ha empezado haciendo un sistema operativo robusto, y poco a poco lo va optimizando para que sea más fluido, en cambio Mac ha hecho un sistema fluido pero muy vulnerable, y poco a poco lo irá haciendo más robusto, pero mientras tanto tiene que controlar muy bien qué deja que se ejecute.

[#98 uzolaik]

#71 Me ha gustado tu simplificación, sí señor.

[#53 Graffin]

Voy a hacer una prueba, no me tengáis en cuenta el comentario.
Así se desvanecerán los argumentos de Slayertanic con el nuevo gobierno del PP:
SOCIALISMO ES CORRUPCIO_OOOOOOOON

[#1 kaidohmaru]

¿En 4 minutos os ha dado tiempo a leer la noticia completa? Menuda velocidad lectora

[#2 ADLR0]

#1 yo lo he leído antes de que alguien lo meneara. Quizás el resto de los que han meneado pronto hicieron lo mismo, o eso espero.

[#3 kaidohmaru]

#2 Es que me he quedado un pelín impresionada, porque es bastante largo Luego me he dado cuenta de que está en Apuntes de Blog así que a lo mejor por ahí vienen los meneos "precoces".

[#6 kaidohmaru]

#5 En 4 minutos lees más bien poquito si quieres quedarte con algo de información. En lo de que es de buena calidad, te doy totalmente la razón. Luego, como ya he comentado en #3, me he fijado que estaba en Apuntes de Blog por lo que es normal que haya gente que lo haya votado nada más verlo subir a "Pendientes"

[#4 Desactivado]

#1 No se, yo la leí antes de menearla y supongo que otros también ya que antes de yo menearla salió en el nótame.

[#5 Gonzi]

#1 Con haber leído una parte razonable del post, ya te das cuenta que como divulgación tiene una buena calidad. Sin ánimo de pelotear...

[#14 Desactivado]

#1

¿ Tu sabes lo que son los "pelotillas" ? Pues eso ...

[#21 Desactivado]

#1 Leer textos largos en la web es fácil. Dás "scroll" al final del artículo y lees la conclusión. Por lo general todo lo demás es paja.

"Ley informática: optar por la apertura tiene costes técnicos iniciales, optar por el software libre tiene costes técnicos iniciales, pero producir una plataforma totalmente bajo control también tiene costes (sociales), y a más largo plazo."

[#95 Aitortxu]

Del reciente post¹ en G+ de Andrew Munn al respecto:

"[...]

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and started from scratch. Android is the only mobile OS left that existed pre-iPhone.

So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.”

Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:

- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed

However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely unacceptable. It should be priority #1 for the Android team.

[...]"

Las negrillas son mías, y las racionalizaciones del que las compre.
_______
¹ https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

[#97 Aitortxu]

Del post¹ en G+ de Andrew Munn:

"[...] Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and started from scratch. Android is the only mobile OS left that existed pre-iPhone.

So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.”

Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:

- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed

However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely unacceptable. It should be priority #1 for the Android team [...]"

Las negrillas son mías, y las racionalizaciones del que las compre.

PD: Me ha encantado lo de que las migraciones de arquitectura han sido muy costosas para los desarrolladores de iOS/OSX sobretodo por que no es en absoluto cierto sino precisamente al contrario. Pero claro, si la gente hablase sólo de lo que conoce esto no sería meneame.
_______
¹ https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

[#26 Desactivado]

Qué bueno, suelta un rollo que te cagas y la gente se queda con que iOS es más rápido porque está pensado para hardware específico.

Nada más lejos de la realidad. Además, se deberían de echar un vistazo a los tests de velocidad de teléfonos con ICS y con iOS. ICS ha mejorado su velocidad como anteriores releases y además han añadido aceleración por hardware a la interfaz, cosa que antes el render se hacía por software y que yo sepa sólo la interfaz personalizada TouchWiz de Samsung utilizaba aceleración hardware.

Código nativo sobre Android es igual de rápido que código nativo sobre iOS. Otra cosa es comparar apps que utilizan Dalvik contra las apps de iOS que son nativas.

[#52 jacintorodriguez]

Joder, con lo bueno que es el post y estos comentarios...

[#60 JanSmite]

#52 El post es muy bueno, me ha recordado tiempos mozos, pero todo ello para justificar lo que afirmaba la noticia que se votó como errónea a tutiplén: que iOS es más fluido que Android. Que sí, que si el software libre vs software propietario, que si las decisiones políticas y de diseño, que si tal y que si cual, pero todas esas argumentaciones no van a cambiar la realidad. Ojo, no digo que una solución sea mejor que otra, y cada uno es libre de escoger una u otra por sus propios motivos y razones, pero la realidad es tozuda.

Y lo mejor del caso es que 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

[#19 Bedel_roolmo]

Qué gozada de post. Para los que disfrutamos con la teoría de Sistemas Operativos (Tannenbaum, Stallings...) leer esto es un placer.

[#20 Desactivado]

#19 el post está bien pero a mi parecer no descubre nada explica lo obvio... pero está bien, supongo que hay gente que lo necesita.

[#24 kahun]

#18 #20 Ni entiendes nada del post y lo que es peor ni te molestas en intentar entenderlo. No eres más que un fanboy disfrazado de troll que echaba pestes de Android por el tema del CarrierIQ y que prometió tragarse sus palabras si se encontraba en iOS y resulta que no viene en Android (no en las versiones oficiales de Google ni en las versiones libres) y sí viene en iOS pero en lugar de admitir tu error y rectificar, sigues salpicando.

El artículo explica las diferencias entre ambos sistemas, las ventajas e inconvenientes de cada uno y tu sólo te quedas con lo más básico y eres incapaz de ver que Android es una maravilla y además es libre. Espero que Apple te pague, porque si no me das mucha pena.

[#99 kadmon]

#24 Lo cierto es que hasta sus propios (ex)empleados se quejan de la mala respuesta de Android: http://www.genbeta.com/movil/un-ex-empleado-de-google-describe-los-motivos-por-los-que-las-animaciones-son-menos-fluidas-en-android

Y para ser una maravilla, el malware para Android ha aumentado un 472%: http://www.europapress.es/portaltic/internet/noticia-malware-android-aumentado-472-20111118115211.html

Mientras que en IOS... http://www.google.es/search?q=malware+ios

Si hasta el impacto de carrier fue menor en IOS

No te confundas, mi próximo teléfono será android y yo también considero que Android es una maravilla... cierto es que también considero que windows es una maravilla a pesar de tener más malwarez... pero ya sabes, Windows está preparado para que lo ejecute el 90% de la población, canis incluídos (Especialmente canis incluídos)

[#102 Desactivado]

#99 Probablemente (lo digo por suposición) tiene algo que ver en el malware el que tenga que ser cada fabricante el que dé las actualizaciones, con lo que igual algunos agujeros que ya están reparados en la rama principal no se reparan hasta meses después en algunas versiones de algunos fabricantes.

Encuentro que sería más lógico que Android tuviera un repositorio central independiente de los fabricantes para las actualizaciones y un repositorio propio de cada fabricante para las paridas propias (fondos de pantalla, colocación de los botones, ...).

[#103 kahun]

#99 iOS tiene menos malware porque Apple impone más control sobre las aplicaciones que Google, no porque el sistema sea mejor y el impacto de Carrier fue nulo en los Android oficiales.

Windows está preparado para que lo ejecute el 90% de la población pero sólo para que lo usen un 5% y el que un sistema tenga o no más malware responde al control que se ejerce sobre las aplicaciones más que a la seguridad que pueda implementar dicho sistema.

[#69 joffer]

#20 Esta claro que tu nivel de obviedad es distinto al mio

[#70 yan_frank]

En conclusión, a dia de hoy, iOS es un poco más rápido en lo que respecta a interface de usuario, pero no tiene un buen soporte para multitarea, ya que no fue diseñado en principio así. Android llegará mas temprano que tarde a igualar y superar la velocidad en la interface de usuario (para que se vea más fluido, bonito, natural, etc.) que iOS y se soluciona el problema.

La gran ventaja es que Android tendrá la misma o mayor velocidad de interface de usuario que iOS y una multitarea muchisimo mejor implementada que iOS (Se diseñó así desde el principio, apple sólo parchea su multitarea).

Los beneficiarios serán los desarrolladores que podrán aprovechar la multitarea en sus aplicaciones y nosotros tendremos interfaces de usuario bonitas y rápidas además de correr 10 aplicaciones a la vez, 50 servicios y 100 gadgets, todo a la vez, como en la PC.

Definitivamente, los smartphones llegaron para reemplazar a los PCs, tomen nota.

Muchos _{Saludos a todos.}

[#23 majestad]

#22 así_asíasíasí?

[#25 Desactivado]

#23 ¿Qué clase de brujería es esa?

[#27 majestad]

#25 Es una recurrencia

[#29 CapitanObvio]

#25 Un vistazo al código fuente te aclarará las dudas.

[#31 kastromudarra]

#29 ¿y eso a un no-infórmatico le ayuda?

[#32 Desactivado]

#31
Debería ayudarte, _{¿no crees amigo? jojojojojo}

[#33 sangaroth]

#31 No hace falta ser informático!!
que deduces de esto?:
texto
Que la palabra 'texto' enmarcada como subindice se mostrará en tu browser (firefox,chomre,...) como subindice
Por tanto:
texto1 texto2
Que pasaría?

[#43 kastromudarra]

#33 gracias por la ayuda da gusto ver como algo aparentemente tan complicado puede ser muy sencillo ¿qué he hecho mal?
pd - no lo borro para que se vea lo lerdo que soy

[#44 dominicanopuro]

#43 no es "subindice" es "sub"

[#47 kastromudarra]

#44 #45 ah joder, ya lo entiendo, no edito #43 que quede como recordatorio. No había visto los nuevos botones del cuadro de texto!! gracias _{os estoy muy agradecido de todos modos}

[#36 dominicanopuro]

#31 _sisisisi

[#50 Señor_Mandarina]

¡Gallir que te violan menéame!

#12#23 #39 #36

[#77 Desactivado]

#25 HA-HA!_{HA-HA!HA-HA!HA-HA!HA-HA!HA-HA!HA-HA!HA-HA!HA-HA!HA-HA!HA-HA!}

[#35 alfonferdez]

Mi clase de sistemas operativos es muuucho más aburrida si hicieran ese tipo de referencias como la del Windows 95 y el Nero estaría más atento, seguro.
Hay profesores que solo se limitan a leer diapositivas, relacionar los conceptos con ejemplos reales es mucho más estimulante. Es lo que mola del artículo, ahora si entras para leer la conclusión, eso ya lo sabíamos o intuíamos desde hace tiempo.

[#38 sangaroth]

#35 No tengo ni idea de como es la educación Americana(USA) pero por algún vídeo que he visto parece que se estila la educación en cosas 'punteras'.
Por contra aquí se parte de las bases teóricas pura y duras, normalmente un poco obsoletas, pero que aportan unas buenas bases para mayor flexibilidad / adaptación.
Si bien la primera opción es mas estimulante y atractiva , y te adaptas a un mercado directamente y de manera 'competitiva', no tengo tan claro que es mejor.

[#58 Desactivado]

#0 Optar por plataformas abiertas beneficia la venta de dispositivos, optar por plataformas cerradas beneficia la venta de contenido.

[#89 Desactivado]

#58 Y he aquí un gran comentario que ha pasado totalmente desapercibido...
Es el modelo de Sony de toda la vida, o del Kindle, pero ya sabemos que aquí, en menéame, las decisiones de negocio se confunden con decisiones éticas, sobre todo si se trata de Apple.

[#28 zorion]

Deberían _{poner un sandbox para gente como #22 ^{y otros}}

[#40 JanSmite]

A ver si he entendido bien el artículo: ¿iOS es más fluido que Android?

[#84 Desactivado]

#40 La conclusión es que iOS es más fluido que Android, porque Android hace muchísimas más cosas que iOS y es infinitamente más flexible, aparte de se una maravilla de la ingeniería informática.

[#107 JanSmite]

#84 Sin animo de polemizar o molestar, el artículo al que se fundió a negativos decía exactamente eso, que iOS es más fluido que Android. Los motivos serán estos o aquellos, pero matar al mensajero porque no te gusta el mensaje que te trae es comportarse como un fanboy/hateboy.

[#92 ElPerroDeLosCinco]

¡Qué recuerdos de la Uni me ha traído este post!
Y también el comportamiento de la peña en los comentarios me ha recordado a la que teníamos los alumnos durante la clase: unos atendiendo al tema, y otros distraídos con paridas, como en este caso con los subíndices.

Yo meneo.

[#11 Desactivado]

El otro dia lei algo parecido https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

[#12 Desactivado]

#11 Acabas de crear un bluce infinito. _{Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.Acabas de crear un bluce infinito.}

[#22 ColaKO]

#12 coño ¿Cómo has hecho eso?

[#80 australia]

#22 < sub>"Texto"< /sub>

Elimina los espacios entre "sub" y "

[#100 NeoJordan]

#12 que es un "bluce"?

[#17 paLitroke]

#11 Otra relacionada http://necedades.com/sobre-la-fluidez-de-android

[#30 sangaroth]

Generalizando un poco mas:
Toda libertad tiene un precio
Desde asumir las consecuencias de tus acciones, diversidad y flexibilidad vs intereses específicos y 'eficacia',...

[#7 zorion]

He leído hasta aquí:
Creo que ya expliqué la base del problema técnico-filosófico, ya puedes dejar de leer si te agobian los detalles técnicos.

He meneado (me parece interesante) y ahora voy a ver si pillo algo de los detalles técnicos

[#39 JanSmite]

Si vamos ^{a empezar a hacer trucos de magia, esto va a ser el despiporre…}

[#41 Darkdog]

Pues yo tenía entendido que todo el renderizado de la interfaz en IOS se hace en un hilo en tiempo real. Y eso es lo que realmente marca la diferencia.

Todas las demas historias de paginaciones, bytecode, hardware específico, etc. Son secundarias, como mínimo, en cuanto a "fluidez" de la interfaz.

[#87 jacarepagua]

Me ha encantado leer el artículo a pesar de no tener ni idea de informática a ese nivel. Se intuye por donde van los tiros de unos y de otros y también de la razones de que cada uno haya seguido un camino distinto. También se agradece la voluntad de escribirlo de manera objetiva, sin menosprecio ni vanagloria para nadie.
A mí al menos me ha servido para resolver la duda de por qué la interfaz en los terminales Android parecen siempre ir menos fluida que en iOS. Lo de la virtualización a priori parece un berenjenal en el que no se habrían metido de no ser por prioridades de mercado. Desde luego tiene mérito lo que han logrado.

Por otra parte creo que el planteamiento de Apple siempre irá por delante en cuanto a rendimiento. Es un desarrollo específico y mucho más involucrado en el hardware, como los procesadores, que se diseñan y fabrican sólo para terminales iOS.
Dando por sentado que los programadores de ambos tendrán un nivel similar (de hecho a menudo son los mismos que cambian de empresa) la diferencia fundamental será el planteamiento inicial de cada proyecto.

[#76 Desactivado]

No hace falta ser ingeniero para ver que Android está diseñado para multitarea e iOS para fluidez en una sola tarea, por eso dan prioridad a sus animaciones de tiempo real, y las demás tareas se van añadiendo a la cola poco a poco.

Siendo pro software libre, veo un poco mal el funcionamiento de un planificador como el de Linux en un dispositivo que poco uso va a hacer de la multitarea.

¿Cómo es que no meten el planificador -rt en Android por defecto?

[#86 Desactivado]

#76 ¿Que no se usa la multitarea? Mira ayer mi mujer fue a casa de una amiga. Ella se fu a pie, pero quedamos que yo la pasaría a buscar con el coche. Yo llegaba de viaje y dejé aparcado el coche en la estación de tren de Barcelona (a unos 30km del destino).

Al llegar le envío un whatsapp, le digo que para que vea por donde voy, le envío un glympse, con lo cual puede ver un mapa mi recorrido. Al mimo tiempo, como no había ido nunca a casa de la amiga me envía un Whatsapp con la dirección, abro el Google Navigation y le digo que me lleve a casa de la amiga. Con lo cual ya tengo dos programas funcionando simultanea e intensivamente y, además, ambos usando el GPS.
Además me apetecía oir música. Así que conecte mediante bluetooth el móvil al coche y puse el reproductor de este. Finalmente hay que decir que llevaba conmigo un tablet que, aunque no lo usaba obviamente, estaba encendido. Lo llevo todo el día encendido, porque la batería dura todo el día (un transformer). Este tablet solo tiene WiFi y lo conecto mediante el tethering de mi móvil que estaba activado.
Todo esto, tendiendo en cuenta que hay multitud de funciones que, no serán tan intensivas, pero que también estaban funcionando.

Pues la multitarea se usa. Lo que si es cierto, es que es bastante absurdo comprarte un móvil así, si no vas a hacer uso de estas cosas. Y no es un caso puntual. Por la mañana mientras escuchaba música en el tren y enviaba emails, el cliente me preguntó que cuanto me faltaba por, y también le envié un Gympse. Para mi, en todos los casos, con un Samsung Galaxy SII, a pesar de la caña que le pego, es perfecta.

Y, por cierto, antes que lo digais, por razones obvias, nunca salgo de casa sin dos baterías cargadas (la del móvil y una adicional). Si se acaba la batería a mitad del día, se pone la otra y ya está.

[#91 Black_Phillip]

#86 Espero que no hicieras todas esas cosas mientras conducías.

[#94 Desactivado]

#91 Sali del parking, paré, arranqué todo y seguí conduciendo. No, no lo hice en marcha.

Vamos, pienso que lo que hago yo será normal, porque sino no tiene sentido tener estos móviles tan potentes.

[#93 jacarepagua]

Se me ha olvidado mencionar un punto en el que no estoy nada de acuerdo:
La otra parte, la gestión de memoria, depende en gran medida del apoyo del hardware. Un procesador con más capacidad de cache y TLB mejoraría mucho, pero también tiene su coste: más transistores, más consumo, más temperatura, mayor tamaño. A medida que se mejore el proceso de fabricación (más transistores en el mismo chip), seguramente incluiran TLB y cache con más capacidad. Lo mismo ocurre con el aumento de la potencia bruta y el aumento de cores (aunque creo que afectan en mejnor medida a los tiempos de respuesta de la interfaz)

Eso de mejorar el sistema operativo a base de potencia bruta ya sabemos a lo que conduce.

[#110 Desactivado]

#93 Un rendimiento desastroso de Windows 98/Me en los primeros Pentium IV y Athlon , sobre todo al tener múltiples programas abiertos. Aún recuerdo lo mucho que se ralentizaba mi98 en el Athlon con 4 aplicaciones y 256MB de RAM, mientras que Suse 8 volaba.

[#42 Flkn]

"Los sistemas Unix (como Linux o Darwin) no son de tiempo real"

Sistemas Unix como Darwin, sí, pero Linux será en todo caso un "clon de..." o un "sistema similar a..." Unix pero que yo sepa Linux no es Unix.

Por ejemplo, ni siquiera es 100% POSIX Compliant => http://en.wikipedia.org/wiki/POSIX#Mostly_POSIX-compliant

[#46 Desactivado]

#42
Sí bueno, pero si no es 100% POSIX es por voluntad propia, como por ejemplo los retornos de algunas funciones en caso de error pueden estar a la inversa. En general son pequeñas tonterías, que ciertamente preferiría que fueran según POSIX para evitar divergencias chorras propensas a descuidos.

[#57 centelleante]

Después de que mi madre me tirara el samsung galaxy 3 a la cabeza diciendo con razón que iba como el culo, le he pasado este artículo y ha entrado en razón

[#81 Desactivado]

Toda la lógica de openess versus control cae por su peso con jailbteaking. Hay programas fuera del control de Apple que funcionan bien en iOS. Creo que el profe se columpia un poco en sus razonamientos... Si no que nos explique por que un sistema micronueo como osx es muuuucho mas fluido en ui que otro como Linux.

[#34 blid]

Bueno, pero la moraleja es que iOS responde mejor y más rápido.

[#45 sangaroth]

editado

[#37 Desactivado]

Vamos, lo que decía yo, que IOS no es un SO, es poco más que un firmware, y se mantiene sólo a base de control exhaustivo.

Personalmente quiero un SO de verdad, no un gadget que sólo funciona para lo que ha sido pensado.

Eso si, Android no me gusta por Java.

[#78 Desactivado]

me imagino a w.stallings escuchando una pelea de fan-trolls... seguramente moriria de 'inanición'

[#51 Graffin]

Joe, parece que finalmente si me sirvió de algo la clase de Sistemas Operativos II. He entendido y recordado la mayoría de las cosas que dice el artículo. ^_^^_{^_^^_^^_^^_^}

[#54 sangaroth]

#51 jejeje! a mi lo de Round Robin,políticas de cache me ha recordado exámenes llenos de tablas y tablas y mas tablas. Nos dejaban apuntes y todo, ya que si no tenias el culo pelado no tenias tiempo de hacer los problemas

[#56 Desactivado]

#54
Políticas de caché, TLB, memoria virtual se da debidamente en la rama de estructura de computadores. En sistemas operativos se da debidamente la parte más relacionada con el software.

[#61 sangaroth]

#56 Tienes toda la razón del mundo!

[#59 Desactivado]

#55
No, no es código nativo, es bytecode que se ejecuta nativamente con todo lo que acompaña a una máquina virtual, entre otras cosas la recolección de basura aunque no es exclusivo de máquinas virtuales dado que es un mecanismo de tener en cuenta qué áreas de memoria están referenciadas y cuáles no, C++11 por ejemplo incorpora recolección de basura opcional estandarizada, algo previamente implementado con los smart pointers.

La recolección de basura no tiene nada que ver con si es Android o iOS, ya que en Android puedes programar de forma nativa, aunque cojea en cuanto a facilidad para ello y utilerías.

[#65 Desactivado]

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

[#66 Desactivado]

#65
En ningún momento te estoy diciendo que Dalvik no sea en el momento. Claramente te estoy diciendo que es bytecode ejecutado de forma nativa con todo lo que ello conlleva, ya que es Java y por tanto arrastra todo lo de Java.

Esas optimizaciones de las que hablas como ya he dicho no son comparables a las optimizaciones que se pueden hacer a mano con C y C++.

[#67 Desactivado]

#c-66" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1462296/order/66">#66 nos estamos desviando un poco del tema por que esto iva de c# en ios y java con dalvik pero bueno, esas optimizaciones de c y c++ estarian en el codigo escritas en esos lenguajes lógicamente, no en ensamblador ni nada parecido por lo tanto tambien se podrian aplicar con jit.En .net puedes programar en c++ y c y tienes jit.

Lo importante es la optimizacion que haga el compilador ya sea estatico o dinamico.

Sería interesante ver una comparativa de un mismo código ejecutado en la misma maquina con el mismo SO y el mismo compilador una version compilada estaticamente y otra con jit para ver las diferencias, así saldriamos de dudas.

[#68 Desactivado]

#67
De lo que te estoy hablando no se puede hacer ni con JIT ni con .NET, que por cierto en .NET no puedes programar con C++ y C. No confundas utilizar Visual Studio .NET con utilizar el runtime .NET o enlazar a librerías programadas con lenguajes .NET.

Aunque el compilador haga una parte del trabajo, no la hace toda y hay cosas que simplemente no puede hacer. Compilador estático o dinámico...

[#73 Desactivado]

#68 pero esas cosas que dices que no se pueden hacer tampoco se podrán hacer entonces programando aplicaciones para ios ya que tienes que utilizar el compilador da apple. Te doy la razón en que cuanto más bajo nivel programes más podrás optimizar el código pero es que tampoco puedes programar en ensamblador para ios, curiosamente para android como bien dices tu si que puedes pero no para el market

yo siempre he pensado que lo de la compilación dinamica era peor que un programa compilado una vez y ya está pero es que con jit se aplican optimizaciones casi imposibles de otra forma y recalco lo del casi por ejemplo si tienes un bucle for y cuando estas ejecutando el programa resulta que llegas hasta el con un valor de contador bajo el compilador podria quitar ese bucle y ponerlo en linea con lo cual te ahorras incrementar la i a cambio de gastar un poco más de memoria tambien puede poner funciones en linea dinamicamente segun convenga ahorrar ram o cpu en cada preciso momento y si no usas jit lo de ahorrar ram o cpu lo tienes que decidir tú al compilar el programa y ya no se puede cambiar sin volver a compilar y mucho menos en tiempo de ejecucion.También es verdad que la maquina virtual no esta ahí gratis optimizando estas cosas y consume recursos

y ojo que yo no estoy diciendo que android sea más rápido que ios solo digo que usar una maquina virtual no tiene porque ser necesariamente la razon de que sea mas lento

[#105 Desactivado]

#73
Sí, sí que las puedes hacer con iOS. El problema de los compiladores es que hay situaciones en las que no saben qué valores contienen las variables por ejemplo. Tampoco son conscientes de la arquitectura sobre la que trabajan para aprovechar mejor los buses de datos.

El inlining de bucles lo pueden hacer pero en muchos casos es mejorable a mano por el propio programador. Además existe el uso de las intrínsecas y la posibilidad de meter ensamblador en línea mezclado con el propio código C.

Muchas veces optimizaciones que aplica el compilador no son adecuadas para un momento determinado, aunque evidentemente si se equivocaran muy a menudo no se dejaría optimizar a los compiladores.

Todo se reduce a una cuestión muy simple: los compiladores no tienen información de ejecución del programa.

Tener una máquina virtual siempre será más lento: recolección de basura, más memoria utilizada, control de límites de los índices de acceso, etc. Una cosa es marcar las áreas de memoria disponibles para un proceso y otra distinta es andar controlando la memoria de cada objeto y los accesos que realiza. Todo eso tiene un coste alto.

Poner funciones en línea dinámicamente y desenrollar bucles al vuelo...

JIT fundamentalmente lo único que añade es que el código Java deja de ser interpretado para ser ejecutado de forma nativa ya que lo compila a código nativo, pero obviamente sigue utilizando la máquina virtual java y los intérpretes o JITs nunca han hecho optimizaciones avanzadas porque los compiladores no son capaces de hacerlas.

[#83 Desactivado]

#68 ¿Por qué no compilar antes-de-tiempo (ahead of time) las aplicaciones al instalarlas en el teléfono, utilizando un compilador con optimizaciones para el hardware particular?
Si la lentitud no es por la compilación JIT, sino por la VM de Java, que no está diseñada para poder ser fuertemente optimizada... ¿Por qué no liarse la manta a la cabeza como hizo MS con .NET y partir de algo nuevo, diseñado desde cero para ser optimizable, aunque con sabor a Java?

[#72 Desactivado]

Es obvio que iOS esta diseñado con el fin de ser lo mas atractivo para el usuario común (pura pinta como todo producto mac, pero poca eficiencia). En el primer párrafo se resume todo, los S.O. de apple siempre tuvieron enormes carencias en seguridad y en redes. Nada tiene que ver si iOS o Android soportan el antiguo objective-C eifel lisp o el lenguaje monguito, las aplicaciones de Android se pueden escribir en C++ que es mucho mejor que objective-C pero eso es irrelevante, lo que si es importante es que tan escalable son y ahí sale perdiendo iOS. Creo que el único punto a favor del iOS es la velocidad, pero recuerdan windows98 o windows95 era mucho mas rapido que windows NT XP 2000 vista o 7, pero eso carecia de una cantidad enorme de funcionalidades y tenia serios problemas de seguridad, lo mismo pasa con iOS

[#90 kittenfukker]

Artículo típico que demuestra la arrogancia del profesorado en la universidad española. Todo se pega. No puede ser que el problema se deba en ningún caso a lo que explica el becario (técnica de composición de las vistas por SW en lugar de por GPU), que ha trabajado en el equipo de Google y que conoce el SW a fondo. La culpa tiene que ser de java y el scheduler... En fin, veo que la uni sigue igual, nada nuevo bajo el sol.

Gallir, tu artículo es arrogante.

[#74 Merkstw]

Por eso siempre he preferido IOS a Android....

[#15 zorion]

#13 Oshtrash, que lo he mirado bien y pone Grohe.
Disculpa las molestias ^-^

[#88 daveruiz]

Menos mal _{que no se admiten etiquetas HTML}
Edito: Ah, si. No vi los botones de la derecha

[#79 Desactivado]

A veeeer, que iOs minimiza el numero de programas que el usuario puede ejecutar cada vez... y creo que mas por la bateria que por nada mas. Solo en espacio de usuario y en sandbox. Pero de monotarea nada de nada. Es heredero de BSD...
Vamos que los desarrollos sobre iOS tiran de interrupciones del timer de la placa para sus rutinas y han tenido que crearse un gestor de memoria protegida...
Que Apple se basa en pensar en que si fabrico hardware y de configuracion cerrada, puedo ofrecer, a priori, un producto diferenciado no en apps si no en duracion de bateria, asistencia tecnica, garantias etc... y una serie de equilibrios que marcan en su ideario la diferencia. Aunque nada es para siempre, esa es la filosofia detras de ellos.
Que, tambien a priori, es dificil competir contra especificaciones abiertas en producción de apps ni que sea por volumen. Ni con los intermedios de microsoft que cuando se pusieron a hacer el plan estrategico ya les jabia rebentado el negocio de ordenadores personales y con un produto peor y sin hardware propietario detras...
El mismo ejercicio que hizo google cuando se lió la manta a la cabeza. No soy fabricante de hardware y si lo quiero ser no tengo oa potencia como empresa en ese sector como para no hundirme, como otros, en los primeros meses. Pensar en como quitar cuota de mercado disputando se lo a soluciones anteriores con un nivel de implantación real casi unica y muy dominante. Hacerlo en igualdad de condiciones es un suicidio y de hecho, como hemos visto, no es necesario para copar algo del mercado. Y mas teniendo en cuenta que el negocio principal de ambos es la store y es donde realmente compiten. No directamente en numero de apps si no en hacer atractiva la plataforma a los desarrollos y a empresas que paguen por ello. Tanto es así que nokia symbian (que no tenia store antes), samsung bada o webos o el bqnx que han intentado cosas a medio camino no se sabe ni que quieren ser de mayores. Yo que me gano el alpiste con esto, voy a publicar alli donde hayan compradores... y estos a su manera me plantean 2 opciones complementarias. En el fondo han acabado con el desierto productivo fuera de empresas muy grandes, que era una idea como windows para pcs. Pagar por un sdk una millonada para no hacer un adobe algo o un juego? Esa capacidad empresarial la tienen 4.

[#64 ankra]

modulo de xenomai y ya tienes un android en tiempo real

[#16 Desactivado]

"parecido"

[#82 Desactivado]

Tema interesante, pero pésimamente redactado, siento decirlo por muy gallir que sea.

[#85 loborobert]

Sip

[#96 screeno]

Está claro que un código ejecutable siempre será más rápido que uno intermedio como JAVA, en el que se basa Android. Pero la diferencia de respuesta no justifica la diferencia de precio. Yo uso Android porque es la mejor en relación precio-calidad.

[#48 Desactivado]

no estoy muy seguro de esto pero ¿la maquina virtual de java de android no usa jit? Microsoft si lo usa en .net y creo que android tambien asi que todo eso de que android pierde rendimiento por la maquina virtual solo es cierto la primera vez que ejecutas una aplicacion.

[#49 Desactivado]

#48
Una máquina virtual por mucha compilación en el momento que tenga nunca será igual de rápida que código nativo, y menos aún que código nativo al que se le ha dado un repaso manual.

[#55 Desactivado]

#49 una vez se ejecuta ya es código nativo y lo del repaso manual no entiendo muy bien a que te refieres, los programadores de java tambien podran repasar sus programas ¿no?

yo creo que si ios es mas rapido pueden ir mas los tiros por lo del recolector de basura que en ios no lo tienes y en java si y
Es mucho mas eficiente que gestione la memoria el programador

[#75 patosin]

Ah sí, por eso este lumbreras deja que invadan toda su privacidad, ya que puede usar dos dedos, no dos neuronas.
Y este elemento ¿da clases?. Da miedo. O es un inutil que solo sabe usar las cosas como un niño pequeño, sin criterio, o es un vendido al sistema. Informático? Ja.

¿A que te han regalado un Ipad?.

Vaya defensor de la privacidad, seguridad, etc.

[#9 Desactivado]

No da ni una

[#10 zorion]

#9 Te llamas como mi inodoro.

[#13 Desactivado]

#10

Es que zurullo estaba cogido, Supongo que a ti te pasó lo mismo, al elegir zorion. Siempre están cogidos los mejores nombres ...cachis

[#18 Desactivado]

Vaya si lo dice el jefe está bien, si lo dice laurita es una idiota, va así?

[#62 AurkA]

#18 me parece que necesitas salir un poco de fiesta o unos all brands, de esos con mucha fibra