Porque Android siempre sera mas lento que iOS

Este artículo trata de demostrar por qué en su rendimiento, Android siempre va por detrás de iOS, hecho constatado y no basado en una opinión. Son infinidad los estudios de renta que demuestran que el nuevo iPhone 4S da un renta de CPU y gráficos de 2 a 4 veces superior que cualquiera de los últimos modelos Android del mercado. Pero, ¿por qué un procesador A5 de Apple a 800Mhz. supera en casi 4 veces el renta de un procesador casi igual, a 1,5Ghz.? ¿Cuál es el motivo?

Pues este se basa en la infraestructura sobre la que se soportan ambos sistemas. Tanto iOS como Android tienen una base similar, basado en un foco de regla activo Unix. En el ocasión de iOS se basa en el desarrollo Darwin que da foco también al propio OS X, y en el ocasión de Android se basa en el foco Linux que usan sistemas como Ubuntu o cualquier otro. Hasta ese punto, el foco base es igual de bueno.

Pero si avanzamos un nivel nos encontramos con algo que es efectivo y se deriva de una de las máximas que Steve Jobs aprendió en sus primeros años de carrera: “para obtener un máximo rendimiento, todo el que hace software debería fabricar su propio hardware para él”. Partiendo de esta premisa, todos sabemos que los modelos de iPhone que hay en el mercado se pueden contar con los dedos de la mano: tenemos 5 modelos de iPhone, 2 modelos de iPad y 5 de iPod Touch. Nada más. Estamos hablando de un regla operativo, iOS, que está diseñado para ceder servicio a 12 dispositivos que han aparecido en los últimos 5 años. Y si tenemos en cuenta que la última traducción no es soportada por todos ellos, cerramos aun más el número. En total, iOS 5 es soportado por 3 iPhones, 2 iPad y 3 iPod Touch, total 8 dispositivos.

Partiendo de esa base, y que Apple controla el hardware que fabrica, el regla activo puede acarrear a niveles más cercanos al foco porque ellos siempre controlan las configuraciones de hardware. Es algo muy análogo a lo que sucede con los ordenadores Mac. Es Apple quien se encarga de cerrar las configuraciones de cada único de sus modelos y ceder soporte de controladores a cada configuración. Por lo tanto, teniendo un hardware comprobado y certificado, los problemas de compatibilidad desaparecen prácticamente en su totalidad.

Por ese motivo, programar para iOS (de manera oficial) es práctica obligada usando las librerías públicas que Apple pone al servicio de los desarrolladores en su kit de desarrollo, y no las partes privadas del mismo que Apple cambia libremente de traducción a traducción y que provocarían (como pasa con infinidad de aplicaciones jailbreak) que dejaran de funcionar en actualizaciones del sistema. Por eso Apple ha de aprobar las aplicaciones antes de publicarlas, y crea un modelo cerrado como el que usa Microsoft en Windows Phone 7 o en el venidero Windows 8.

Pero si miramos al mundo Android es totalmente diferente. En esto, Android se parece más a los PCs. Es decir, hay, literalmente cientos de terminales, cada mes salen más, infinidad de marcas fabrican para este regla libre… desde marcas conocidas a fabricantes chinos de nombres desconocidos. Y para poner un regla Android cada fabricante elige el procesador que quiere, la configuración, memoria, placas, procesadores gráficos… cada terminal Android puede y es cada único como quiere el fabricante, lo que implica que no hay una configuración cerrada o certificación de componentes. Solo han de cumplir una catálogo de normas básicas de compatibilidad con sets de instrucciones y poco más.

Lo que esto implica es obvio: hacer un regla activo que garantice la total compatibilidad con configuraciones tan variadas no es tarea fácil. Para ello, Android ha tenido que incorporar a su regla una capa de ejecución en software, que se coloca por encima del hardware, y que garantiza la compatibilidad. Una capa creada en Java. Y ahí es donde empieza el problema, porque el propio regla no se ejecuta (porque no puede ya que no podría garantizar el correcto funcionamiento del mismo en todos los dispositivos) sobre el hardware del equipo como hace iOS, con un regla activo colocado junto al foco del sistema. En el ocasión Android, tenemos una máquina sobrentendido Java que garantiza la compatibilidad y que es la que ejecuta el propio sistema. Y azar máquina virtual, es un programa.

Por lo tanto, la diferencia está encima de la mesa: iOS ejecuta el regla activo directamente sobre el hardware del dispositivo (ya que dicho hardware está controlado) y el código que se genera para él (programado normalmente en lenguaje Objective-C) genera en sus compilados código máquina que se ejecuta contra el dispositivo sin ninguna capa intermedia. Pero Android, que en su delantera ejecuta aplicaciones Java, lo que ejecuta es un código intermedio que es ejecutado por una máquina sobrentendido software (un programa) que se está ejecutando contra la capa del sistema.

De hecho, es una realidad del mundo Android, que muchas de sus aplicaciones o juegos no funcionan con todos los dispositivos (a pesar de practicar el “manual de desarrollo”). Muchas compañías y desarrolladores pierden más tiempo haciendo que sus aplicaciones funcionen para todos los dispositivos, que en la propia programación del mismo. Aunque este problema se va solucionando con el tiempo pues Google va optimizando el código de su sistema, este sigue siendo una realidad. Por este motivo, Windows Phone 7 (el tercero en discordia) exige una certificación de componentes hardware a los fabricantes para certificarlos en su regla operativo. WP7 no se instala en cualquier móvil, solo en los que tenga una combinación de componentes certificados por Microsoft, para que así este se ejecute como hace iOS y no como hace Android.

Cierto es que existe la posibilidad de emplear el Kit de Desarrollo Nativo (NDK) de Android, que permite programar directamente aplicaciones por debajo de la máquina sobrentendido de Java, pero las posibilidades de obtener divergencia en los desarrollos es bastante más alta. Por lo tanto, azar NDK es principalmente usada por fabricantes que hacen sus propios desarrollos para sus propios terminales (como Samsung, por ejemplo), conociendo cada único de estos los componentes que monta y por lo tanto, puede sacar el máximo rendimiento.

Por lo tanto, y a grosso modo, un dispositivo Android necesitará al menos el doble o triple de posibilidad que un iOS para alcanzar rendimientos similares, y aun así puede que no los consiga. De hecho, las posibilidades que dan entornos de desarrollo de juegos 3D como Unreal Engine en los nuevos iPhone 4S o iPad 2, con efectos de luces o de hojas y polvo en el viento, han etapa hasta ahora reservados a ordenadores y consolas de última generación. Pero ahora también están disponibles por primera vez para entorno móvil, sobre iOS.

A ese respecto, y esto es una realidad constatada, no una opinión, Android todavía está muy lejos. De hecho, y para muestra un botón, la nueva consola Sony PS Vita que tiene una capa de juegos basada en Android, ofrecerá una tienda de aplicaciones para juegos independientes, con menores rendimientos y con aprobación previa (tipo Apple). Los juegos que realmente saquen renta al poderoso hardware, estarán basados en el propio regla de la consola y no en su compatibilidad Android, por razones obvias.

Eso son los dos sistemas, ni mejor ni peor: diferentes. No quiero que este artículo se interprete como único más que dice qué bonito es Apple y qué feo es Android, porque no lo son. Android es un gran regla activo móvil que da un excelente servicio a millones de usuarios en el mundo y que tiene infinidad de grandes dispositivos, al igual que iOS es otro magnífico regla con grandes terminales y dispositivos.