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....
|
etiquetas: android , ios , por que nada es gratis , gallir 
…...
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
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.
Disculpa las molestias ^-^
"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."
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.
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.
Toda libertad tiene un precio
Desde asumir las consecuencias de tus acciones, diversidad y flexibilidad vs intereses específicos y 'eficacia',...
Debería ayudarte, ¿no crees amigo? jojojojojo
que deduces de esto?:
<subindice> texto </subindice>
Que la palabra 'texto' enmarcada como subindice se mostrará en tu browser (firefox,chomre,...) como subindice
Por tanto:
<subindice> texto1 <subindice> texto2 </subindice></subindice>
Que pasaría?
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.
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.
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.
Todas las demas historias de paginaciones, bytecode, hardware específico, etc. Son secundarias, como mínimo, en cuanto a "fluidez" de la interfaz.
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 => en.wikipedia.org/wiki/POSIX#Mostly_POSIX-compliant
pd - no lo borro para que se vea lo lerdo que soy
editadoSí 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.
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.
#12#23 #39 #36
Así se desvanecerán los argumentos de Slayertanic con el nuevo gobierno del PP:
SOCIALISMO ES CORRUPCIOOOOOOOOON
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
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.
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.
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 www.genbeta.com/movil/un-ex-empleado-de-google-describe-los-motivos-po
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.
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.
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++.
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.
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...
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.
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.
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
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.
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?
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.
Elimina los espacios entre "sub" y "<".
Ejemplo: Texto
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á.
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.
Edito: Ah, si. No vi los botones de la derecha
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.
Gallir, tu artículo es arrogante.
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.
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.
Vamos, pienso que lo que hago yo será normal, porque sino no tiene sentido tener estos móviles tan potentes.
"[...]
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.
_______
¹ plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
"[...] 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.
_______
¹ plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
Y para ser una maravilla, el malware para Android ha aumentado un 472%: www.europapress.es/portaltic/internet/noticia-malware-android-aumentad
Mientras que en IOS... 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)