Etiquetas
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, fundamentalmente para que se entiendan los problemas de arquitectura, y de cómo toda decisión que se tome en una arquitectura, lenguaje o programa tiene implicaciones positivas y negativas, siempre.
Lo básico
Apple tomó muchas decisiones técnicas con el objetivo de mejorar la «experiencia de usuario», pero por sí mismas serían inútiles -o más perjudiciales- si no van acompañadas de medidas de control estrictas. Es fundamental el papel de los controles de las aplicaciones en el App Store (¡ojo! no los justifico). Independientemente de otras consideraciones políticas, dado su simplicidad y soluciones ad hoc, el iOS sería muy fácil de «abusar» por los desarrolladores y aplicaciones.
Por el contrario, Android es una plataforma abierta que puede user cualquier fabricante, que permite la instalación de cualquier aplicación. El control de aplicaciones del Market por parte de Google es prácticamente inexistente. Esto hace que no valgan soluciones ad hoc, obliga a implementar en el sistema operativo medidas de seguridad y control «canónicas», en el sentido que mantenga las condiciones fundamentales de todo sistema operativo de propósito general: eficiencia, equidad (fairness) y seguridad.
Cualquiera que haya estudiado la teoría y arquitectura de sistemas operativos (o que haya leído sobre el tema) entiende perfectamente que la eficiencia, equidad y seguridad son objetivos contradictorios. Mayor equidad o seguridad afectan negativamente a la eficiencia, y viceversa.
Hay otro problema importante. Se desea que los sistemas operativos de teléfonos actúen como sistemas de tiempo real también para las aplicaciones (ya tienen que serlos en otros aspectos, como la «radio» a interacción con protocolos de red de telefonía). Es decir, con límites precisos de «tiempo de respuesta»: el tiempo que transcurre desde que ocurre un evento (como tocar la pantalla) hasta que se empieza a ejecutar al «gestor» de ese evento (la aplicación).
Los sistemas Unix (como Linux o Darwin) no son de tiempo real, su planificador de procesos (scheduler) es no-determinístico. No lo es por una sencilla razón: si se pretende una buena «multiprogramación» (llamada comunmente «multitarea») se deben cumplir los objetivos de equidad y otros más complejos, como evitar los tiempos de espera muy largos (starvation). Esos dos objetivos impiden asegurar (formalmente) que el sistema sea de tiempo real. Además, los sistemas de tiempo real exigen que el tiempo de ejecución de cada ráfaga de ejecución de las aplicaciones (CPU bursts) críticas sea lo suficientemente breve para poder asegurar «tiempo real» a las demás aplicaciones (recordad que el scheduler debe ser determinístico, por ende no puede asegurar equidad).
En pocas palabras, si deseas comportamientos próximos al tiempo real necesitas relajar los requerimientos de un sistema de propósito general, y aumentar el control de las aplicaciones que se ejecutan en ese sistema.
¿Se entiende el balance y decisiones contradictorias que hay que tomar? En un sistema de multiprogramación, con el hardware equivalente (los dispositivos iOS y Android lo son), si se desea disminuir las latencias se deben relajar otras condiciones del planificación de procesador (por lo que se obtiene una «peor multitarea») y aumentar el control de aplicaciones (lo que genera otros problemas polítics, éticos, sociales y de negocio). Si pretende más apertura y libertad, se debe ser muy estricto con equidad y seguridad, lo que genera efectos negativos sobre el tiempo de respuesta.
Al final el tema de fondo no es [sólo] técnico, sino de otros aspectos más filosóficos: control vs apertura.
Creo que ya expliqué la base del problema técnico-filosófico, ya puedes dejar de leer si te agobian los detalles técnicos. Pero si te interesan, intentaré resumirlos en las cuatro partes que tienen más responsabilidad en los «tiempos de respuesta» de un sistema: las aplicaciones, el lenguaje y plataforma, la gestión de memoria, y el scheduler.
Las aplicaciones
El tipo de programación para móviles es esencialmente «dirigida por eventos» . Cuando el usuario toca la pantalla se llama la función que debe responder a ese evento (en Android se llaman «actividades»). La recomendación es que la aplicación no necesite mucha CPU ni tiempo para generar la respuesta, especialmente en los menús principales. Por supuesto, a este nivel, todo depende de los programadores de la aplicación, y supongo que estos son los mayores culpables de la «reacción lenta» de los menús cuando se interactúa con una aplicación.
Las aplicaciones también pueden tener otros malos comportamientos, por ejemplo consumir mucha CPU (aún cuando están en background o como servicio), no sólo molesta a todos los demás procesos, también aumenta el consumo de batería y la temperatura.
¿Cómo solucionar este problema? O se hace un control estricto de cada aplicación, o se implanta un scheduler más sofisticado y genérico que puede tener algunas aristas.
Ya sabéis qué decisión se tomó en Apple, y cuál en Google.
El lenguaje y plataforma
iOS y Android difieren mucho en este aspecto.iOS usa el mismo lenguaje estándar del Mac OS X, el Objective-C. Los programas se compilan directamente en código ejecutable para el procesador. En cambio Android optó por usar Java, que se convierte a un lenguaje intermedio ejecutado por una máquina virtual optimizada (similar la máquina virtual de Java, pero es diferente), Dalvik.
Obviamente el rendimiento entre ambas es muy diferente, el código ejecutable siempre será más eficiente que otro se que no se ejecuta directamente en el procesador. Pero esto no significa que los diseñadores de Android sean unos imbéciles, de nuevo, fueron decisiones estratégicas que están muy por encima de temas técnicos, aunque terminan afectando dramáticamente a este último.
Si el sistema operativo se va a ejecutar siempre sobre una única arquitectura, como hizo históricamente Apple (aunque tuvo dos migraciones importantes, exitosas pero dolorosas y muy molestas para los desarrolladores), la opción natural es generar directamente el ejecutable. Además, Apple licenció el diseño de ARM [*] y compró una empresa de diseño de chips (Intrinsity) para que se encargue del diseño de sus procesadores y no depender ni de fabricantes externos (antes lo hacía Samsung).
Por otro lado, la intención de Android era entrar a competir en el mercado con un sistema libre/abierto y multiplataforma (después de varios intentos fallidos, como OpenMoko), por lo que era preferible un sistema que no obligase a compilar una aplicación para cada tipo de procesador. Si no, estaría condenada al fracaso. Para solucionar el problema de la eficiencia diseñaron desde cero el Dalvik, que al usar el lenguaje Java ya tenía a su disposición muchas herramientas (como Eclipse), librerías de desarrollo (como las clases estándar de Java), y una comunidad enorme de progamadores (me abstengo de opinar sobre Java, pero afortunadamente Android lo ha mejorado muchísimo con su API y framework de programación).
Aunque Java ya está preparado para multithreading, por cuestiones de seguridad los diseñadores de Android prefirieron, muy acertadamente, ejecutar cada aplicación como un proceso diferente y completamente aislado. Dejaron esta parte de la gestión de procesos al núcleo Linux, que es muy eficiente y está más que probado. Con esta arquitectura de máquinas virtuales replicadas en procesos independientes, se generan otras infeficiencias: cada proceso debe cargar su máquina virtual, y éste debe cargar después todas las clases estándar de Java que hacen falta para la aplicación. Esto haría que el tiempo de arranque de cada programa fuese inaceptable, y han recurrido a un truco muy guapo para solucionarlo (por eso digo que la arquitectura de Android es una obra impresionante de ingeniería informática): el zygote.
El kernel Linux implementa un mecanismo llamado copy-on-write ( COW) que permite que los procesos hijos (creados con el fork()) compartan memoria con el padre (por eso la creación de procesos es muy rápida de Linux). Cuando un proceso crea un hijo, éste reusa la misma memoria y tablas de páginas del padre, pero todas las páginas se marcan como «sólo lectura». El hijo puede comenzar a ejecutarse muy rápidamente. Cuando uno de los procesos intenta escribir sobre una página compartida, se genera una interrupción de error (trap), el sistema operativo coge el control, verifica que se trata de memoria COW, asigna una nueva página, copia el contenido de la página afectada, modifica la tabla de páginas de uno de los procesos para apuntar a esta nueva, y permite la continuación de ambos procesos. Además de la rapidez con que puede crear y ejecutar procesos, se ahorra mucha memoria RAM, por ejemplo, el código ejecutable y las librerías comunes siempre se comparten (nunca se modifican).
¿Cómo aprovecha Android este mecanismo? Crea un proceso inicial, el zygote, que carga la máquina virtual y las librerías estándares de Java y del API de Android. Cada nueva aplicación que se arranca es hija de este zygote, et voilà, ya ganaron eficiencia y se ahorra muchísima memoria (Chrome y Chromium usan la misma técnica para abrir pestañas y ventanas rápidamente).
¿Es o no es una obra maestra de ingeniería? Claro que sí, se han tomado todo ese trabajo para compensar el problema de eficiencia y seguridad de una máquina virtual. Por eso, cuando pienso que por debajo hay una máquina vrtual ejecutando el código, me maravillo con la velocidad de ejecución de las aplicaciones en Android.
Por supuesto, esta arquitectura con memoria virtual tiene otros efectos negativos a la hora de medir los tiempos de respuesta: en la gestión de memoria y cache, que trato más adelante.
[*] En la biografía de Steve Jobs cuentan como despuésde evaluar usar Intel para los iPad, Jobs le dijo muy cabreado a los ejecutivos de Intel algo así como: «son muy buenos para procesadores de alto rendimiento, pero sois unos inútiles para procesadores de bajo consumo».
La gestión de memoria del núcleo
Los procesadores que usan iOS y Android son similares en cuanto a su gestión de memoria (también similares a los ordenadores que usáis). Ambos gestionan memoria virtual con paginación. Los procesos no generan direcciones físicas de RAM, sino direcciones lógicas que son convertidas a direcciones físicas en cada ejecución por el módulo conocido como Memory Manager Unit (MMU). Cada proceso tiene sus propias tablas de página que mantienen la relación de número de página del proceso (es el índice a la tabla) a ubicación en la memoria RAM. Los procesadores ARM permiten páginas de 4KB a 64KB (lo usual son 4KB), así que cada aplicación tiene miles de páginas, y por lo tanto tablas de miles de entradas (en ARM hay tablas de dos niveles, en la arquitectura Intel o AMD, cuatro niveles).
Cada entrada de la tabla almacena propiedades de la página: lectura (r), escritura (w), ejecución (x), accedida (a, o acces bit), modificada (d, o dirty bit), cargada en memoria (p, present bit), etc. Por esta razón las tablas se mantienen en la memoria RAM, lo que genera otro problema ¿cómo hace el MMU para no tener que acceder dos veces a la memoria -primero a la tablas de página y luego a la dirección que se pretende acceder-? Sin un mecanismo que lo solucione, el tiempo efectivo de acceso a la memoria sería al menos el doble de lo que permite la memoria RAM (o sea, una patata de lento).
Para solucionar este problema se usan sistemas de cache que almacenan en registros del procesador un conjunto de entradas de las tablas: el translation-lookaside-buffer (TLB). El TLB de los ARM suelen tener 128 entradas, cada una de ellas es una copia idéntica de la entrada de la tabla de páginas. Se intenta tener en el TLB las entradas más usadas, así, cada vez que el MMU encuentra la entrada en el TLB puede acceder directamente a la memoria (hit), si no, tiene que descartar una entrada y cargar la que hace falta (fault). El hit ratio es una indicación de la velocidad de acceso efectivo a memoria, viene dado por el procesador y el algoritmo de sustitución que se use, a mayor número de entradas en el TLB, el hit ratio sube.
Cada vez que el scheduler selecciona otra aplicación para ejecutar se produce un cambio de contexto, entre otras cosas significa que las entradas del TLB deben ser invalidadas (ya no sirven para el nuevo proceso, por seguridad tampoco debe poder usar esos datos), además las entradas que han sido modificadas por el procesador (por ejemplo, que una una página fue accedida o modificada) deben ser copiadas a la tabla original en memoria (flush). Por eso se dice que los cambios de contexto son «caros», y es muy importante las decisiones que toma el scheduler para minimizar los cambios de contexto «inútiles» (¡pobre el scheduler!, las cosas que tiene que tener en cuenta para que lo usuarios no se quejen porque el audio pega saltos).
Un proceso con máquina virtual como Android mete mucha más presión al TLB (y por ende baja el hit ratio) que un proceso que ejecuta código nativo. Para ejecutar una función equivalente en máquina virtual se necesita más memoria, la del código del intérprete, la memoria usado por éste, más el código en lenguaje intermedio y la memoria que necesita el programa. No sólo eso, prácticamente cada ejecución del código intermedio implica cambios en las variables del propio programa, también en las de la máquina virtual, forzando a que en cada cambio de contexto sean más las entradas del TLB que deben ser copiadas a la RAM. O sea, los cambios de contexto son también más caros.
Lo mismo que pasa con el TLB (recordemos que es un tipo específico de cache), pasa con la memoria de cache de RAM en el procesador, la máquina virtual mete más presión, por lo que también bajan sus hit ratios.
De nuevo, una decisión de negocio (y política y filosófica), genera muchas complicaciones técnicas que hay que resolver. Si uno las tiene en cuenta, empieza a dejar de pensar en términos de fanboy y se cuestiona muchas cosas. Entre otras, lo eficiente que tiene que ser Linux para gestionar esta complejidad adicional sin que se note demasiado la diferencia.
El scheduler
Se llama scheduler al módulo del sistema operativo que selecciona cuál será el siguiente proceso a ejecutar. A cada proceso se le le asigna un tiempo máximo de ejecución: el cuanto (o quantum). Si al proceso se le acaba el cuanto, el sistema operativo se apropia de la CPU (por eso se llaman apropiativos o preemptive), y llama al scheduler para seleccionar el siguiente de la lista de procesos que esperan para ejecutar (este mecanismo se denomina round robin). El scheduler de Linux (como la gran mayoría) no son determinísticos, significa que a priori no se puede conocer la secuencia de ejecución de procesos, por lo que no se puede asegurar analítica o formalmente que los procesos se ejecuten en un tiempo máximo predeterminado (si éste es suficientemente pequeño).
No todos los procesos tienen los mismos requerimientos, aquellos interactivos, o de reproducción multimedia necesitan menores tiempo de respuesta que un servicio en background, o que consume mucha CPU. Para eso se usan las prioridades, cada proceso tiene una prioridad inicial (por ejemplo «multimedia», «normal», «de fondo», etc.), luego el scheduler la ajusta dinámicamente (prioridad dinámica) dependiendo del comportamiento del proceso y las necesidades de los otros. Por eso, el comportamiento de un sistema que use prioridades depende del comportamiento global de todos los procesos, estos no se pueden predecir, y de allí que sea no determinístico, y que se generen tiempos de respuesta variables.
El scheduler además tiene que tomar en cuenta muchos factores adicionales (p.e., minimizar los cambios de contexto), y evitar que se produzcan esperas muy largas (starvation) que se pueden producir porque procesos con mayor prioridad están cogiendo siempre la CPU y no dejan ejecutar a otros de menor prioridad. Imaginaros que tenéis el reproducto de música de fondo, y que estáis por sacar una foto. La aplicación de foto podría estar consumiendo el 100% de CPU para actualizar la imagen, por lo que produciría cortes en la música, insoportablemente molesto ¿no? Pues es el pobre scheduler el que tiene que evitar estos problemas, tomando decisiones muy rápidas, cientos de veces por segundo.
Para evitar estas esperas tan largas en los casos extremos (corner cases) como el que acabo de decir, el scheduler mantiene dos colas, la activa y la inactiva. Siempre asigna procesos desde la cola activa. A cada proceso se le asigna un tiempo máximo (además del cuanto) que puede estar en la cola activa (el timeslice, por ejemplo 500 mseg), cuando consume todo su tiempo se le mueve a la cola inactiva. Cuando ya no queda nadie en la cola activa, el scheduler cambia, la activa pasa a ser la inactiva, y viceversa. Esto aumenta aún más el efecto «no determinístico» del scheduler, y puede producir saltos o latencias elevadas si el procesador está temporalmente sobrecargado.
Para evitar estas latencias que molestan a la interactividad del usuario se pueden tomar varias medidas ad hoc, por ejemplo subir la prioridad al máximo a la aplicación que está activa (así hacía Windows), pero esto genera otros problemas: ¿si la aplicación activa abusa y no deja de usar la CPU? (un truco obvio de programador para que su aplicación parezca que es más rápida y eficiente ¿no?) ¿y si hay procesos en background que necesitan la CPU -por ejemplo un SMS, o responderá la red antes que pase el timeout- y esperan demasiado tiempo?
Pues es muy complicado, y cualquier «truco» que se ponga al scheduler deja la puerta abierta para que los programadores abusen… salvo que hagas un control exhaustivo de cada aplicación que se vaya instalar en el teléfono. ¿Se entiende por qué Apple puede recurrir a trucos ad hoc y evitar al mismo tiempo el abuso de las aplicaciones?
Si por el contrario renuncias a hacer ese control, no queda más remedio que el scheduler haga su trabajo, como en cualquier sistema operativo de uso genérico. Y que la solución adoptada sea lo suficientemente buena, simple, genérica y segura. ¿Se entiende por qué la solución en el Linux de Android es más difícil de encontrar? ¿o por qué le llamé una «solución canónica?
¿Como puede Android mejorar los tiempos de respuesta?
Evidentemente hay dos caminos obvios.
Por un lado, mejorar paulatinamente el scheduler (si es que allí reside el problema). No es una cuestión de un día, ni un año, en Linux se tardó años en encontrar un planificador que funcione tan bien como la actual para sistemas interactivos (el scheduler CFQ).
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 incluirán 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).
Tampoco me extrañaría que el código de los drivers de la pantalla sea de baja calidad (como suelen ser todos los drives, comparados con el núcleo del sistema operativo, se hacen bajo presión, y la prioridad es el hardware, no el SO) y encuentren big locks que no tocan.
De todas formas, los tiempos irán mejorando paulatinamente hasta que no podamos detectar diferencias en las latencias de la interactividad. Al mismo tiempo, iOS tendrá que ir incluyendo mejores capacidad de «multitarea» (como ya pasó desde que salió la primera versión de iOS, y seguramente irá reduciendo los controles de calidad que hace a cada aplicación).
Supongo que os dáis cuenta de la complejidad técnica de estos «cacharritos», y que las decisiones de negocio imponen muchas restricciones y problemas al desarrollo del software, lo que obliga a los ingenieros a aplicarse a fondo. No es que los ingenieros de iOS son unos genios, y los de Android unos inútiles, los requerimientos y grados de libertad son diferentes.
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.
PS: Si queréis saber más, justamente estas semanas estoy enseñando gestión de memoria en la asignatura. Si sois de Palma, estáis invitados de oyente, martes de 15:30 a 17:20, Aula 5, en el Anselm Turmeda. Me ofrezco a explicar más si me pagáis un café después de clase 😉
Ricardo Galli, de software 
Muchas gracias por la clase, he aprendido un montón con tu articulo :).
Pingback: Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos « Ricardo Galli, de software libre
Muy buen artículo. Debo reconocer que he aprendido mucho sobre sistemas operativos y sobre la guerra entre Android y iOS, cosas importantes a mi parecer.
¿Y para los que no somos de Palma? Mira a ver si pones tus clases en streaming, solo como un experimento a ver qué pasa 😉
Y bueno, dado el público que suele visitar este blog, creo que puedo preguntar esto:
¿Me recomendáis hacer grado de ingeniería informática? Sé que hay grados similares (sistemas, etc) pero no tengo muy claras las diferencias. Por lo que sé, creo que estoy más inclinado hacia ingeniería informática a secas (Inteligencia artificial, bases de datos, desarrollo de software (en lenguajes varios, supongo), desarrollo web (creo, porque no me parece haberlo visto en la lista de asignaturas)…) El caso es que estoy haciendo 2º de Bachillerato y nadie ha sabido explicarme bien en qué consiste cada grado informático exactamente, así que os lo agradecería 🙂
He disfrutado como un enano leyendo esta entrada.
Vaya parrafada, sintetizar no es lo tuyo eh? Excelente articulo por cierto.
En general, estoy de acuerdo con la explicacion… pero creo que dejas de lado uno de los puntos interesantes del articulo original (en ingles) que inició toda esta discusión, donde plantean que la principal diferencia es que en iOS (y BBX y WM7 y demas, excepto Android) el interfaz de usuario esta relegado a un thread con prioridad mas alta, mientras que en Android, las rutinas graficas se ejecutan en el mismo thread principal de la aplicacion.
Esta separación de responsabilidades en threads con prioridades diferentes no tiene ninguna dependencia con los «grados de libertad». Aunque no estoy seguro de si la escogencia de Linux como kernel y de Dalvik como VM tengan alguna implicacion en este sentido. Creo que fue una decision de arquitectura influenciada por la simplicidad en una epoca (pre 2007) en que el tiempo de reacción del interfaz no era la prioridad #1.
Y es que al tener un thread separado para interactuar con el usuario, y «marcado» con una prioridad especial, le haces mucho mas facil la tarea al Scheduler, y reduces el impacto de la calidad del programador sobre la «fluidez» del interfaz.
Muy buena explicación aunque tendre que darle otro repaso más tarde porque es mucha información la que asimilar
Deberías subir tus clases en streaming o archivos para descargar.
Espero mas artículos como este.
¿Cuando podremos ver tu nuevo libro?
Si viviera en Palma, seguro que te pagaba el café.
Como referencia:
El post que (creo) origino toda esta discusion es este:
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
Donde Andrew Munn (fue pasante («intern») en el equipo Android y ahora en Windows Phone) habla sobre el uso de threads separados para el «UI rendering».
Que fue inspirado a su vez por un post de Dianne Hackborn
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
Donde habla sobre los mitos de la aceleración por hardware, entre otras cosas.
Sólo puedo decir que muchas gracias por la explicación. Es curiosa «la guerra» entre ambos bandos por «fanboyismos». Estos «pequeños» artículos como el tuyo deberían ser leídos por más gente para que tuvieran una visión algo más amplia del tema. Un saludo 😉
@sd
Además de los problemas de aceleramiento por hardware (que los 60fps no afecta tanto a la hora a abrir un menú, me parece), la clave está en:
Es la prioridad lo que cambia las cosas, no sé cómo controla Apple (además de los que hacen antes de autorizar al Store) para evitar el abuso de la prioridad. Pero es lo mismo que hacía Windows 95 (por eso el Nero te decía «deje esta ventana activa para asegurar la grabación»).
Por supuesto, también cuenta lo que dicen, de la VM y el garbage collector (pero ya lo comenté, salvo lo del GC, que me olvidé completamente, cosas de usar lenguajes con «reference counters» 😉 )
Que gustazo aprender con entradas como esta, de verdad. Felicidades.
Entonces, para cuando la app de menéame en iOS??? 😛
yo solo se, y esta claro, ke el samsung galaxy s 2 va mas rapido, fluido ke cualkier iphone
Muy bueno, pero hay un punto que no entiendo: «era preferible un sistema que no obligase a compilar una aplicación para cada tipo de procesador. Si no, estaría condenada al fracaso.»
¿Cómo puede ser? Ya había y sigue habiendo kernel para montones de plataformas, librerías gráficas para otro montón y también herramientas de desarrollo.
¿De verdad piensas que un modelo «KDE Mobile» (por ejemplo) con un Kernel estándar que compilara contra muchas plataformas y QTDesigner + KDevelop (y otros) no habría funcionado? ¿Por qué? ¿Porqué fallaron otros como OpenMoko? Ninguna plataforma había tenido antes el impulso de una empresa como Google. De hecho IOS está usando su propio diseñador, herramientas y compilador.
Es la diferencia fundamental entre ambos: uno ejecuta programas virtualizados y otro no, pero justificas la decisión diciendo que para poder usar código nativo tuvieron que montar la App Store que ejerce un control férrero (no es tanto, ya se les colaron muchas cosas que no funcionaban o desobedecían las condiciones absurdas de la Store). Yo creo que usaron VMs porque querían llegar a la mayor cantidad posible de HW sin importar nada más (y por eso en Android se permite instalar programas fuera del Market)
En una cosa tienes razón: es un puto milagro que el Scheduler gestione tan bien los procesos y que casi ni se note que todo está virtualizado y aprovechar el copy-on-write era la solución obvia (yo no lo sabía, pero lo he pensado inmediatamente cuando explicabas que cada fork levanta una VM)
En resumen: Es verdad que en Android hay un trabajo cojonudo de ingeniería, pero dudo mucho que usar la VM Dalvik y virtualidad todos los programas de usuario haya sido la mejor decisión técnica. Tampoco creo que Apple controle todo lo que se sube a la Store y creo que hubieran podido copiar el modelo IOS completamente. Justificar la App Store por motivos técnicos con lo restrictiva que es me parece una estupidez por parte de Apple (seguro que lo hacen para ganar dinero)
En fin, es un tema muy interesante, no lo arreglaremos ahora. Gracias recordarnos todos esos detalles de implementación de SO que no recordamos todos los días.
La verdad que hoy en Fnac comparando Androids y iPhones la fluidez de este ultimo marcaba la diferencia.
Enviado desde mi iPhone.
Gran artículo, clase magistral! Enhorabuena, lo he disfrutado mucho! Muchísimas gracias de nuevo!
🙂
@paco:
“era preferible un sistema que no obligase a compilar una aplicación para cada tipo de procesador. »
No es problema del kernel, sino que cada aplicación debería ser compilada, probada y subida al Market para cada tipo de procesador diferente. Si no puedes controlas la aquitectura de hardware, lo tienes más complicado.
Yo no creo que haya sido la mejor decisión (y hubiese usa un Python, por ejemplo), pero si genera código nativo ¿qué lenguaje que sea popular hubieses usado? ¿C++?
Apple partía con le ventaja que el Objetive C ya era el estándar en Mac OS X. ¿Qué hubieses elegido tú? C++ es una pesadilla infumable.
Por otro lado, sí que se puede compilar código nativo si necesitas algo que sea CPU intensivo, pero tienes restricciones de en qué plataformas (soportan 3) se puede ejecutar: http://developer.android.com/sdk/ndk/overview.html
Gallir, podrías pasarte algún día por la Escuela de Informáticos de la Universidad de Sevilla…
¿No temés un overclock cerebral?
En general los defensores de la política de Apple se olvidan de los beneficios a largo plazo. Yo vengo de un origen C++, y aún hoy, después de mucho tiempo, sigo prefiriendo Java – como filosofía general, sin entrar en detalles -, porque tiene unos beneficios genéricos que no se ven claramente en la aplicación en sí. La latencia puede ser fastidiosa, pero se puede pulir. Una arquitectura no genérica, no abstracta, es un lastre en sí mismo. Como los lenguajes naturales, las arquitecturas hardware/software tienden a la regularidad, salvaguardando los casos irregulares por una cuestión de eficiencia: el uso intensivo. En definitiva trato de decir que un traje a medida sienta muy bien, pero que cada persona tenga un traje a medida es un despilfarro ingente. Apple es la hermosa caligrafía, a veces magistral, a veces sólo resultona, y otras ininteligible y falaz… Y Android es la imprenta.
@sd
Según he podido entender, no es tanto un problema de prioridad del thread dedicado de iOS (algo que ya acarreaba problemas en WIndows justamente porque disminuía la respuesta del resto del sistema), como del proceso de render en dos fases: a) la delegada a la aceleración gráfica que se hace componente por componente gráfico individual, y b) el paso para hacer el ‘compositing’ de todo el UI; la segunda fase es la que produce la sincronización pues la lleva a cabo el thread de la aplicación. En iOS la vista ‘compuesta’ se genera íntegramente por hardware y la aplicación sólo sufre la llamada del habitual ‘redraw’ para volcar el buffer en pantalla. Según explica uno de los ingenieros del UI de Android sería más -o también- un problema de diseño del toolkit gráfico.
Cita:
>> You are right, a lot of the work we have to do today is because of certain choices made years ago. I’m not sure I agree with your conclusions about View vs ViewGroup but 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.
Muchas gracias, he aprendido mucho y siento no estar en Palma para pagarte una docena de cafés
Como decía mi abuela: no te acostarás sin saber una cosa más.
Artículo muy interesante y entretenido. Ojala hubiese tenido profesores que explicasen
De nuevo felicitaciones por lo expuesto.
Dices:
«De nuevo, una decisión de negocio (y política y filosófica), genera mcuhas complicaciones técnicas que hay que resolver. Si uno las tiene en cuenta empieza a dejar de pensar en términos de fanboy y se cuestiona muchas cosas. Enre otras, lo eficiente que tiene que ser Linux para gestionar esta complejidad adicional sin que se note demasiado la diferencia.»
Pero realmente también tienes que tener en cuenta que los móviles tope de gama de Android vienen con el doble de RAM que el iPhone, con lo cual, ya no es que sea eficiente por gestionar algo tan complejo sin que se note la diferencia, es que usa el doble de RAM también.
¡Señor, señor! Cuanto tendríamos que aprender de los Sistemas Operativos propietarios.
Por ejemplo, Del EXEC de UNISYS: El sistemas de carga inicial, el dispatcher, el scheduler, el dynamic allocator de memoria, el sistema de interrupciones,…
Sic transit gloria mundi que Anibal no dijo.
No tengo ni idea de arquitectura de sistemas, pero lo he entendido y eso tiene merito. No recuerdo si fue carl sagan que dijo que si enseñaran a escribir a los científicos todos seríamos más listos… gracias creo que soy un poco más listo… o menos tonto.
Ya me gustaría que me dieras clase tú… Mi profesor de Sistemas Operativos por vocación no creo que esté ahí. En fin, muy interesante el artículo, siempre está bien saber más de lo que realmente pasa en nuestros cacharros
¿No recuerda todo esto un poco al bueno de Con Kolivas y su rama -ck con sus parches preemptive behavior?
Ricardo, ha sido una muy buena lectura técnica. Gracias.
Por cierto, ¿podrías bloguear algo similar sobre el HURD y sus problemas? (creo que esto vale algo más de un café).
Enhorabuena.
Buenísimo, yo aprobé Sistemas Operativos I y II hace un año, y me ha parecido ilustrativo y muy interesante éste artículo. Muchas gracias por enseñarme más sobre mi Androide y su archienemigo el de la manzana.
Ya me diste clase en el año 93 y veo que sigues haciendo las clases igual de entretenidas y formativas. En aquel entonces no usabamos Linux, usabamos una cosa infumable que era el Minix corriendo sobre mac… bffff
Disfrute cuando tuve la suerte de tenerte de profesor de la misma manera que he disfrutado hoy leyendo este articulo.
Gracias.
Excelente artículo !!!,
se agradece mucho el esfuerzo en redactar un artículo tan técnicamente fundado y que a la vez explica de forma sencilla las consecuencias que aspectos complejos tienen en la forma como el usuario percibe el funcionamiento general de un equipo informático.
Yo hace tiempo que dejé de intentar explicar a nadie porque prefería una plataforma u otra. Esta claro que con los teléfonos y los tablets ha acabado pasando como con los ordenadores personales, la famosa frase yo prefiero MAC …
Pero hay un aspecto que no mencionas y que creo ha confundido a mucha gente, el hardware.
El hardware de apple ha tenido poca evolución, no quiero decir que entre el primer dispositivo y el último no hayan habido muchas mejoras, a lo que me refiero es que han existido no más de seis dispositivos en teléfonos y dos o tres en tablets. Y además el primer modelo de cada tipo fué el más avanzado de su época.
Por otra parte con Android ha pasado todo lo contrario, los primeros dispositivos eran muy primitivos y la experiencia de usuario nefasta. Y después han surgido una infinidad de dispositivos que han ido mejorando, o a veces no, el uso final.
Pero lo relevante es que hemos llegado a un punto, en que, en función del dispositivo android escogido se puede superar a IOS+SU HARDWARE en el coste, en el coste + el uso o sólo el uso sin importar el coste. Sin olvidar que en muchos casos el uso será peor. Aqui tenemos el fracaso del año pasado con los tablets chinos a 100 euros.
Lo que no creo que pase nunca es que el uso sea peor y el coste menor o igual.
Saludos y enhorabuena por la labor de divulgación que llevas a cabo, paternidad de menéame incluida.
Hugo Berlinches.
Cada vez que leo las decisiones que hay que llevar a cabo para facilitar la usabilidad de una aplicación informática, especialmente en dispositivos móviles, me entran ganas de invadir Polonia o en su defecto rescribir todos los libros de introducción a la programación y mover la parte de algorítmica al tomo 2.
Porque mira que la vida es sencilla en un mundo de arquitectura Harvard y, como mucho, preemptive multiprogramming con prioridades….
Hace muchos años que aprobé SO I y SO II en otra universidad y con otro profesor. Como alabanza debo decir que parece que los profesores de Sistemas Operativos viven la asignatura y se la hacen vivir a sus alumnos.
Muy buena explicación (realmente muy poco técnica). Pena que me quede lejos asistir de oyente, pero de poder asistir las clases de planificación o ejecución multithread serían las más interesantes (debido a que en mi época, el planificador era el de System V R4 o el de BSD 4.3) y el multithreading se tocaba menos.
Buen artículo para empezar el día. Un buen resumen…
Pero en mi opinión te has dejado alguna cosa importante que influye en gran medida a la hora de diseñar el sistema.
La primera es las comunicaciones entre procesos. Android tiene el Binder, aunque desde el punto de vista del desarrollador de aplicaciones son los Intentents y los Activities. Sin embargo iOS no tiene ningun método de IPC real. Puede usar handlers y registrar tipos de URI pero poco más.
Una segunda muy relacionada con la anterior es la filosofía del sistema. Aquí ambos son bastante parecidos, pero como siempre iOS mucho más restrictivo. La filosofía es de aplicaciones completamente independientes, sin comunicación entre ellas. Lo cual simplifica de manera infinita el desarrollo del software. Android permite más interacción entre procesos, pero también bastante abstraído bajo el concepto de Activities.
Otro concepto muy distinto de SO para móvil es el difunto MeeGo. Que enfoca el problema de otra manera distinta, intenta llevar el SO del escritorio al móvil. Por supuesto haciendo numerosas concesiones y optimizaciones para obtener un buen resultado y batería. En este caso a la hora de manejar las prioridades se utilizan los cgroups del nucleo. Y no sólo para obtener CPU sino controlar el acceso IO, que en los móviles es casi más importante, porque la memoria flash es un gran cuello de botella.
De todas maneras ambos sistemas, sobre todo iOS, tienen un gran trabajo por delante. En mi opinión la convergencia entre móviles y escritorios está por llegar. Los sistemas que ganarán son los móviles, que irán evolucionando hacia el modelo PC. Y para eso a ambos les queda mucho por delante, pero mucho más a iOS que a Android. El concepto de MeeGo en mi opinión y con muchos peros, iba mejor encaminado.
Ricardo, ¿podemos decir entonces que la solución Apple es más KISS, dado que ha optado por la vía fácil vs una solución más elegante de Android? Probablemente unos tests de rendimiento en cada App y más prioridad a las tareas de cara al usuario.
que suerte tenerte de profe, un saludo!
Quizás en unos años en vez de Java tengamos Go en Android http://golang.org/ Ya hay un proyecto que sustituye java por limbo y Inferno http://mobile.slashdot.org/story/11/09/17/2050200/inferno-os-running-on-android-phones
Pingback: Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos “Ricardo Galli”, de software libre
Muchos recuerdos de la asignatura de Sistemas Operativos. Después de unos años todavía se recuerdan cosas, jeje.
Un saludo
No lo sé, ya me lo leeré mas adelante en profundidad.
No todo es hardware ni tampoco software, en muchas ocasiones el problema parte de la responsabilidad de los programadores, para que no carguen demasiado al sistema sin «unificar» requisitos, lo que produce software de mala calidad que tira a patadas en un hardware que hace 10 años en el mundo de los teléfonos no existía, pero en el mundo de los Pcs si. Y yo no recuerdo que uno de mis ordenadores de hace 10 años intentara cargarle tantas cosas de golpe…
Pingback: La razón de por qué la interfaz de Android es lenta | eConectados
Hombre, por fin averiguo que es el zygote. Por lo general, cuando estás depurando y aparece el señor zygote es que la app falla y no hay vuelta atrás.
Il bambino, precisamente los intents son una de las mejores cosas de Android, son potentes y pieza fundamental del sistema. De hecho, a nivel de desarrollar apps lo mejor es pensar en las actividades como procesos separados que se comunican por intents.
Comentaban por ahí el tema de que no hubiese sido un problema tener que compilar para diferentes plataformas. Aun recuerdo mi vieja cassiopea con windows mobile, que tenías que estar buscando si la app estaba para tu procesador o no, y era pesadisimo. Creo que eso hubiese sido un lastre muy, muy importante para el desarrollo del SO.
@gallir sí, Python habría sido muy buena elección. Incluso (a voluntad del fabricante) podría tener el código en el Market y compilarse en el momento de instalar. Fomentaría el uso de código abierto. En caso contrario, también hay maneras de ejecutar código nativo en python. El programador lo tendría complicado para tantas arquitecturas, pero si realmente considerara que es necesario tendría la opción como tiene ahora.
El motivo por el que la combinación de hw+sw de Apple funciona bien es el mismo por el que la XBox 360 mueve tan bien (comparado con los PCs de la época) un videojuego. Ya debiste ver en la bio de Jobs que el tío creía en un todo integrado y cerrado «por motivos de diseño» y yo añadiría «y de negocio».
Estoy de acuerdo en todo lo que dices, la explicación del Scheduler y cómo afecta a las apps de tiempo real con un S.O. que no es de tiempo real es fantástica y me ha encantado.
Sólo que sigo pensando que el motivo de que el IOS vaya un poco mejor es porque es una arquitectura dedicada, código compilado para unos pocos dispositivos y que la App Store y el Market poco han tenido que ver (puede que algún caso puntual; no lo sabemos). Eso es extensible al OS X Apenas tiene que funcionar en una o dos docenas de combinaciones de hardware y, aún así, la última versión se arrastra y consume memoria absurdamente.
También creo (como tú) que Java (aunque con el truco del copy-on-write) no era la mejor elección, pero esa opción tiene una característica que no tendría Python: se puede subir el código al Maket compilado y SIN código fuente y sigue funcionando en todas las arquitecturas con su VM. A Google le importó poco en ese momento que los programadores liberaran código; incluso se lo puso fácil.
La verdad es que podemos discutir sobre qué arquitectura habría sido la mejor (ya sabes, diseños de sofá), pero ellos con la solución Java fueron los únicos que de verdad lanzaron con éxito una plataforma para móviles universal y ámpliamente extendida que funciona muy muy bien con decisiones inteligentes para solucionar problemas complejos en un hw muy limitado inicialmente.
Brillante. Buen resumen.
Muy interesante, no parecía tan largo mintras lo leía
Gracias por esta entrada. Me gustaría si podrías analizar y comparar el Nokia N9 MeeGoo con Android e iOS. Un saludo atento y cordial desde Buenos Aires.
Muchas gracias por el artículo. Así da gusto aprender. Saludos desde Asturias 🙂
Muy interesante articulo y brillante gestión de eficiencia didáctica Vs entretenimiento de lectura.
Muy buen artículo, lástimas que Palma me pille un poco lejos. Te apunto los cafés para cuando vengas por Zaragoza 😉
Un saludo
No ho tinc tant clar: la gestió de codi nadiu té la seva complicació i hi ha molts de casos de grans llibreries (numpy → Fortran90+C) que ho necessitarien.
Muy bueno el artículo tengo un iPhone y un android, no son comparables en hardware (iphone 4 sony ericcson mini PRO) pero no llegaba a comprender la superioridad de la manzanita en dispositivos con un harwd similar.
Gracias!
Me ha venido bien el refresco.
Fantastico el articulo, tanto tecnica como pedagogicamente.
@Paco @gallir teniendo la jvm puede ejecutar cualquier lenguaje que compile bytecode para la jvm es decir, python con jython, scala, clojure, ruby con jruby, etc…
El problema es que como no es la misma maquina virtual, ni las mismas librerías, necesitan ser portados a android también.
Paco del #44, la selección de Java sobre otros lenguajes quizás tenga que ver más con la cantidad de programadores disponibles en el mercado que con alguna razón técnica.
Y si bien Java puede tener alguna limitación, creo que tener la market llena de aplicaciones (de calidad o no, es otra discusión) rapidamente de alguna manera compenso los problemas técnicos.
Como bien comenta el artículo al comienzo, hay razones de negocios que guían las decisiones técnicas … creo que la selección de Java es un ejemplo.
Creo que en esta ocasión, aunque con razón en el fondo, estas respondiendo a otra cuestión diferente de la planteada. No es que el sistema operativo sea mas o menos capaz, que lo es. El problema que tiene Android es la Fluidez, que es una sensación puramente subjetiva. En el par de links de google plus fijate que hablan principalmente de la arquitectura del sistema gráfico y la interfaz de usuario, iOS desde el principio uso aceleración gráfica, y todos los modelos de apple salen con los mejores chips graficos disponibles en ese momento.
Y es que la percepción de la fluidez no tiene nada que ver con el rendimiento total. Ejemplo claro es el navegador en ambos sistemas operativos, utiliza diferente arquitectura como bien indica el post de Dianne Hackborn, a cambio de una renderizacion mas precisa a la hora de hacer zoom o scroll, tiene la penalizacion de que a veces aparece como si la pagina no estuviese terminada de renderizar cuando haces scroll y te la va rellenando a trozos.
Un ejemplo claro de esto lo tenéis en muchas paginas web, comparar una como meneame, que prácticamente se muestra de forma instantánea, con otra con mucha publicidad que se carga a saltos. Es posible que el tamaño del html sea el mismo, que se lo haya descargado en el mismo tiempo etc, sin embargo las llamadas a publicidad de la segunda hacen que el renderizado de la pagina vaya a saltos, dando la impresión de que el sitio va mas lento.
@jokin
> El problema que tiene Android es la Fluidez, que es una sensación puramente subjetiva.
La «fluidez» tiene una medida fundamental, es el tiempo de respuesta (o «latencia»), que depende de muchos factores, entre los más importantes, el scheduler y los cambios de contextos.
> En el par de links de google plus fijate que hablan principalmente de la arquitectura del sistema gráfico y la interfaz de usuario,
Y explica una ingeniera de Google que sí se usa aceleración gráfico, y por qué no lo es todo (además, para «fluidez» de la interacción, no se necesitan 60fps).
> a cambio de una renderizacion mas precisa a la hora de hacer zoom o scroll
Eso lo que hace es reducir el tiempo de respuesta del scheduler + aplicación. Es lo que explico a lo largo del artículo. Si se tiene que hacer una lista muy larga, una app en bytecode consume más CPU que una en código nativa. También explicado.
> Un ejemplo claro de esto lo tenéis en muchas paginas web, comparar una como meneame, que prácticamente se muestra de forma instantánea,
Porque nos hemos currado mucho los tiempos de respuesta: https://gallir.wordpress.com/2010/08/27/piensa-un-poco-en-los-lectores-de-tu-sitio-web-optimiza-lo-fundamental-intercala-y-elimina/ (y retrasamos al máximo la carga de los javascript de publicidad o botones externos).
A ver si grabas las clases en vídeo, que Palma me pilla un poco a desmano. 🙂
Gracias por tu estupendos artículos, Ricardo.
Abrazos de tus incondicionales de Zaragoza.
Jodó, estos apuntes sí que molan, magnífico.
#55 Sí, tiene cierta lógica pensar eso, pero te pondré un contraejemplo que lo desmonta: Apple lanzó una «Store» para aplicaciones de móviles que necesitaban un kit de desarrollo propietario y privativo de Apple y que se programaba en un lenguaje que se llama Objective C (y que no se parece en casi nada al C de toda la vida).
Resulta que llenó la Store de «apps» en muy poco tiempo (http://www.androidpolice.com/2011/03/14/number-of-apps-in-android-market-rapidly-gaining-on-apples-app-store-but-android-tablets-arent-so-lucky/). Y ahora pregunto yo ¿Había más programadores de Objective-C que de Python (por ejemplo)? Parece que no (fuente http://langpop.com/)
Luego eso que comentas de que el número de programadores era relevante, aunque tiene sentido, no es cierto 🙂
Estamos especulando demasiado. Se eligió Java y no sabemos a ciencia cierta porqué. Estaría bien poder preguntarlo a uno de los diseñadores iniciales.
@gallir
>La “fluidez” tiene una medida fundamental, es el tiempo de respuesta (o “latencia”), que depende de muchos factores, entre los más importantes, el scheduler y los cambios de contextos.
No es tan sencillo, la vista funciona de una forma muy curiosa, se percibe como mas fluido una animación a 30 fps fijos, que una animación a 60 fps que ocasionalmente baja a 40 o 20, incluso una animación fija a 15fps puede parecer mas fluida que una a 30 que ocasionalmente baje a 20.
>Y explica una ingeniera de Google que sí se usa aceleración gráfico, y por qué no lo es todo (además, para “fluidez” de la interacción, no se necesitan 60fps).
Y hoy a actualizado también explicando que android esta basado en ventanas mientras que iOS no, permite widgets en la home screen mientras que iOS no, tiene ventajas (la funcionalidad que me ofrecen los widgets de la home la cambio por una pequeña perdida de fluidez sin dudarlo), tiene una api cerrada para soportar teclados alternativos, que por fuerza hace que este tenga que estar implementado en otro proceso, etc.
Android va actualizándose y mejorando, cada vez llevamos mas potencia en el bolsillo, pero ahora mismo el subsistema grafico va un paso por detras de iOS debido a los requerimientos y a que apple siempre mete lo mejor en chips gráficos en sus cacharros, mientras que en android tienes de todo.
Si nada de lo que explicas es incorrecto, lo que pasa es que respondes con un enfoque muy general de SO a algo muy particular como la interfaz de usuario y subsistema de renderizado grafico.
>Porque nos hemos currado mucho los tiempos de respuesta: https://gallir.wordpress.com/2010/08/27/piensa-un-poco-en-los-lectores-de-tu-sitio-web-optimiza-lo-fundamental-intercala-y-elimina/ (y retrasamos al máximo la carga de los javascript de publicidad o botones externos).
Lo se, por eso lo comentaba, y sobre todo porque quería dejar claro que no es lo mismo ser rápido, que parecerlo.
No, el problema es infinitamente mayor por que jython no es cpython: desde que no estan en la misma versión de librerías pasando por que no has arreglado el problema del código nativo (jython no puede ejecutar numpy ni PyQt).
Muy bueno el articulo.Seria genial leer este tipo de artículos mas seguido!.
Pingback: Lo mejor de mi RSS del 5 al 11 de diciembre | Linux Hispano
El problema de Android es que los usuarios pagan con tiempo perdido configurando, actualizando, … y que las apps no están controladas (hay mucho malware).
Encima como nada es gratuito, las apps gratuitas van llenas de publicidad que es lo que molesta mucho, tener que tragarte publicidad diaria en TU MOVIL.
Está claro que google gana dinero por publicidad y que no es el ángel que vanaglorian muchos.
¿Alguien estará seguro pagando con NFC en un futuro no lejano con sistemas Android?
Está muy bonito saber linux, android, … sobre todo a nivel académico (en la Universidad), pero para el resto de los mortales, elejir Android en vez de iOS o Windows es estar desnudo y poner en peligro tus datos.
Al final, google acabará mandando emails publicitarios a los android, puesto que sabe por dónde navegan, qué apps usan,… y dejarán este sistema como ya está youtube (inservible al bombardearte a publicidad).
Leyendo el post me ha recordado a mi profesor de sistemas operativos de la universidad.
Se nota la gran cantidad de conocimientos y la desmesurada pasión por el tema.
Pingback: Android, iOS y elecciones de diseño « Sobre el pingüino
Gracias por tu articulo, lo he disfrutado bastante. Lo compartire en mis redes sociales. Un abrazo!!!
Es lo mismo que usar una PC, al final la seguridad y el performance dependen del usuario y lo que se instale, asi como existen desarrolladores de malware para Android existen para apple; y ya se les han pasado apps que estan hechas con fines destructivos.
La diferencia principal entre estas plataformas es la filosofia, una es cerrada y te obligan a «casarte» y consumir lo que te den. La otra es abierta y usar el telefono bajo tu responsabilidad.
Si sientes que tu libertad y derechos no se restringen en una carcel de cristal, propongo la siguiente analogia: Compras un auto exclusivo de cierta marca, en cierta agencia, y para usarlo necesitas su permiso, solo podras comprar (aunque sean excesivamente caros) y usar refacciones, llantas y gasolina donde la marca te diga, no puedes compartirlo ni personalizarlo, si se descompone tampoco puedes repararlo. Ese es el modelo de apple.
Fui usuario de iphone 3gs y ahora soy mas que feliz con mi galaxy s2, la semana pasada actualice el firmware tomó menos de 20 mins y fue automatico 2 clicks y listo (el sw de sincronizacion lo hace por mi) la duracion de mi bateria se incremento y mi telefono sigue rapidisimo, yo se lo que instalo y lo que ejecuto, justo como una pc, solo se necesita ser un usuario responsable.
Pingback: El Ocio Digital » Blog Archive » Diferencias a nivel técnico de iOS y Android
¿Eso es todo? ¿iOS es más fluido porque además de fanaticos de la manzana, no es una máquina virtual?
No se por qué, me esperaba otra cosa.
Con la llegada del post-pc todo el aspecto técnico mostrado
al final será nada; los SO (móviles y desktops) se simplificarán al máximo haciendo innecesario el concepto de «Task Manager»
Muchas gracias por el artículo. Ya sospechaba que esto era aproximadamente así, pero era una intuición y no había tenido la valentía de investigarlo por mi cuenta.
Muchas gracias de nuevo por gastar tu tiempo para que otros podamos ahorrarlo.
Pingback: ¿Es Android menos fluido que iOS?: Appleweblog #Apps
Pingback: ¿Es Android menos fluido que iOS?: Appleweblog #iMAPAS — #iMAPAS
Me ha encantado el artículo, lo leeré más de una vez seguro. Muy interesante.
Un saludo de un exalumno tuyo al que le gustaría recibir tus clases hoy día ya que le encantan las plataformas móviles como Android (Con el que llevo 3 años desde mi Htc Magic) e iOS.
Y por cierto, dejando temas técnicos a un lado y las decisiones tomadas por unos y otros (tanto en google como en apple son ingenieros cojonudos) al final de todo lo que importa es conseguir que el usuario este contento con el producto que compra. En este sentido y a la espera de probar Ice Cream Sandwich (del que pienso es el inicio del camino correcto para evitar la fragmentación y animar a los desarrolladores) creo que a Android le queda un caminito por recorrer. Supongo que como dejas entender en el penúltimo párrafo antes de la ley informática tenderá a equipararse.
Pingback: ¿Es Android menos fluido que iOS? | Tenoch
Buen e interesante artículo. La verdad es que toda la teoría de sistemas operativos estudiada vuelve a estar en auge con la «computación movil», ya que el hecho de que estos computadores móviles llamen empieza a ser circustancial.
Por cierto, por poner una crítica, la traducción directa del inglés «determístico» no existe en castellano. 😉 es determinista.
Un abrazo!
Para empezar, «Enviado desde mi iPhone»: Ya de salida eres imparcial, y para seguir, ¿me puedes decir que aparatos Android eran, y que precio tenían?. Si comparabas Galaxy Tab con Ipad, pues es una comparación más o menos justa, Si comparabas, un android de 150 euros con un ipad de 500, pues es obvio cual va a «vencer».
En cualquier caso, ahora cuando llegue el más unificado/universal S.O. ICS (Ice Cream Sandwich) en su versión 4.1 (todos sabemos que las «.0» nunca son muy recomendables, sean de Android de Apple iOS, o de pastelitos de las Monjas del Albergue de San Nicolás).
Antes de que acribilleis, tengo tanto un iPad como un Galaxy Tab…
Perdón, me refiero obviamente a «Tablets», mientras el usuario a móviles, pero mis dudas con respecto a su «investigación» de campo son las mismas, insitio que si tiene ya un iPhone, no es parcial (parate de que ya sabe usarlo, versus un S.O. más nuevo para él, y en el que se verñia más perdido), y que hay que ver si comparó el móvil a un Galaxy SII, o a un simple movil android, que es posible que costase la mitad, y con hardware más simple…
Muy buen artículo. Me ha abierto los ojos con la información, a nivel de SO, referente a los dos grandes de los dispositivos móviles. Gracias
Lo de «y porque nada es gratis» es una afirmacion totalmente tendenciosa y detructiva en si para la informatica… apple fan. Después de eso ya se que todo lo que voy a leer es basura adoradora del diablo. Justificar la censura absurda y las políticas retrogradas con excusas banales y ridículas. Estas infectado.
Anda que ya te vale galli… que poco claro en cuanto a sistemas cerrados… los consoladores anales están muy bien pero resulta que no a todo el mundo le gusta sodomizarse el ano… anda que defender el sistema «anti-operativo porque lo que ejecuta lo -hace mejor-«… anda hombre mi mando a distancia tiene una genial velocidad, no te jode… y mi tostadora y si lo hago en ensamblador pues va mas rápido… pero a costa de que? es que es ridículo, esta gente va 10 años atrasados y encima le doras la pildora? que clase de sistema serio se tiene que «fiar de los programas» pero que estas diciendo…
¡te han comprao!
Ivan de la Jarai, creo que no te has enterado de nada.
@Ivan de la Jara
Mi postura sobre el tema de Apple es bien conocida, y el tiempo y dinero que invierto en activismo. Por ejemplo un caso de hace unos días:
https://gallir.wordpress.com/2011/11/29/del-kit-tecnologico-del-congreso-y-de-justificaciones-posmodernas/
http://blog.meneame.net/2011/11/28/un-netbook-con-software-libre-para-el-diputado-alberto-garzon/
https://gallir.wordpress.com/2011/12/15/de-etica/
Además no tengo nada de Apple, rechacé regalos de iPod e iPad (que también es conocido).
Sin embargo, en un artículo pura y estrictamente técnico sueltas burradas como las que acabas de soltar (y sin entender nada del «no es gratis»). Lo siento, sólo puedo decir una cosa: vaya gilipollez, idiotez, subnormalidad e imbecilidad que has escrito.
Hazte ver, que pensar en el bilis (como con la polla), anula las neuronas.
Lo he leído varias veces, pero sigo sin entender que demonios intentas decir.
¿Estaré perdiendo facultades?