Andriod e iOs

Android, iOS, tiempos de respuestas y por qué nada es gratis en
sistemas informáticos
Diciembre 7, 2011

-Ricardo Galli-

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 eltema. 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 horas de clase, y aun 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 unaarquitectura, 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 losjustifico).
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 usar cualquier fabricante, que permite la
instalación de cualquier aplicación. El control de aplicaciones del Market por parte de Google esprá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ídosobre 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” ainteracció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 unasencilla razón: si se pretende una buena “multiprogramación”
(llamada comúnmente “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 deejecució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 lasaplicaciones 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...