La ventaja oculta de Apple, por Sergio Martínez-Losa

26/11/2012 por Carlos Burges

Mucho se ha dicho de lo cerrado del ecosistema de Apple y de como la compañía de Cupertino se ha aprovechado de este ecosistema para dejar cautivos a sus usuarios de sus productos y dispositivos, pero también esta es una ventaja competitiva que a la postre, le va a permitir en un momento determinado triunfar a la larga frente a Android o incluso frente a Windows, al menos cuando rendimiento y estabilidad sean una característica clave más allá del uso para consumo.

Esta ventaja intrínseca le permite a Apple el ejecutar aplicaciones mucho más rápidamente que otros dispositivos con hardware similar o alternativamente, consumir menos potencia en procesos a la misma velocidad. Esto no es precisamente trivial para Apple, cuando el rendimiento y el consumo de energía en dispositivos móviles es una característica de primer orden en los ecosistemas móviles: tan importante que todos los fabricantes han iniciado una carrera por tratar de equilibrar potencia y autonomía. Precisamente por estas circunstancias, Apple ha tomado la decisión de crear una arquitectura y un entorno que será inmutable a lo largo de mucho tiempo, lo que le ofrece una ventaja (si la decisión ha sido adecuada) que a la larga le permitirá, si no es la victoria sobre sus competidores, establecerse como una opción sólida en cuanto a rendimiento, estabilidad y autonomía.

Hoy en día existe una gran posibilidad de dispositivos a la hora de desarrollar aplicaciones y juegos para móviles, de igual manera hay muchas opciones para desarrollarlo, desde aplicaciones de código nativo, HTML5, aplicaciones que utilizar herramientas que intentan imitar la metodología de una aplicación flash, etc.

Podemos ver una diferencia sustancial en cuanto al desarrollo nativo o no, en dispositivos nativos la aplicación puede funcionar sin necesidad de ser interpretada/traducida por elementos intermedios, lo cual hace que de por sí sea aparentemente una ventaja, la eliminación de procesos intermedios hace que las operaciones ganen en rapidez de ejecución, una claro caso son las aplicaciones en código nativo de iPhone, esto y el hecho de que la segmentación todavía no supone un problema real hace que muchos desarrolladores den el paso hacia Objective-C, en su favor hay que decir que el lenguaje de programación puede resultar algo atípico pero quizás las carencias del lenguaje se complementen con la ayuda disponible en el Apple Developer Center.

En contraposición tenemos las aplicaciones que generan el archivo ejecutable con interpretaciones intermedias del código, como por ejemplo WindowsPhone o Android, por suerte, en WindowsPhone 8 tenemos la posibilidad de usar una lenguaje de programación nativo como C++ para crear nuestras aplicaciones.

En Android utilizamos Java, se trata de una lenguaje que debe ser interpretado por un programa intermedio que ejecuta dicho código en máquinas distintas (Mac, PC, Android), visto de primeras es una ventaja, se puede ejecutar una mismo código en varias plataformas, esto es lo que suele llamar multiplataforma. Bien es cierto que dichos programa que interpretan el código (llamadas máquinas virtuales) suelen estar optimizadas para la plataforma en la que se ejecuta y en caso particular de Android, la llamada máquina virtual sólo ejecuta código compilado específicamente para ésa plataforma, por lo que el concepto de multiplataforma en éste caso queda ligado a los dispositivos Android (teléfonos, tablets, etc), además el amplio rango de dispositivos hace que las características del hardware de cada uno puedan impactar en el rendimiento de la aplicación, no todos los dispositivos tienen la misma memoria, por ejemplo. Adicionalmente, se requieren muchas más llamadas al procesador lo que implica también, para un mismo rendimiento, procesadores mayores y mayores consumos de energía.

No obstante Google quiso dar una poco de mejora a la plataforma y por ello liberó, para disfrute de los desarrolladores, el llamado NDK (Native Development Kit), el cual se centra en la posibilidad de crear las operaciones más costosas de la aplicación en código nativo del teléfono, con lo que conlleva. Pero de igual manera si se desea usar éste tipo de código deberemos crear una aplicación Java en la cual se incruste el código nativo, lo que resulta es una aplicación que igualmente debe ser interpretada por el programa intermedio (máquina virtual) pero sólo una parte, porque la otra parte generada con el lenguaje nativo simplemente se ejecuta de forma inherente en el dispositivo.

WindowsPhone, en la actualidad, con WIndows 8 para dispositivos móviles ofrece una solución intermedia que de momento parece tener una acogida cálida pero que no termina de consolidarse, ofrece la posibilidad de crear aplicaciones con código nativo (mediante el lenguaje de programación C++) y código interpretado (mediante el lenguaje C#), personalmente me parece una acierto la posibilidad de poder manejar código nativo al igual que con Objective-C en el iPhone, es más, podemos tener un cierto tipo de multiplataforma en cuanto al desarrollo de juegos (en cuanto a aplicaciones puede ser un poco más complicado puesto que en cada plataforma tiene su propia política de usabilidad), por ejemplo, existen kilts de desarrollo de juegos que se encuentran disponibles tanto en iPhone y WindowsPhone, como por ejemplo cocos2d-x. Es muy interesante éste tipo de entornos puesto que facilita la posible monetización del juego al poder alcanzar varias plataformas tan heterogéneas.

Personalmente he conocido desarrolladores de videojuegos que programaban sus creaciones para PC en Windows en código nativo de ésa plataforma (C++) y que con el mismo código generaban el juego para iPhone y versiones antiguas de Windows CE, con el mínimo esfuerzo obtenían el mismo videojuego para dispositivos antiguos y más modernos.

Por último tenemos la solución que mas de moda se está poniendo hoy en día entre muchos profesionales: HTML5 y derivados de ésta tecnología, disponemos de varias plataformas en cuanto a aplicaciones y juegos: Corona, GameSalad, Appcelerator, Phonegap, etc. Suponen un desarrollo rápido de aplicaciones y juegos pero a veces están limitados por las características de acceso al hardware de los terminales o por la falta de dicho hardware, aunque las aplicaciones que se suelen desarrollar bajo éstas plataformas no suelen necesitar la interacción con mucho hardware. Luego tenemos otras plataformas que realizan juegos de manera muy visual, las cuales permiten realizar casi todas las operaciones de manera más sencilla.

A dispositivos móviles HTML5 (como tecnología web) se comporta de manera diferente en función del navegador sobre el que se este ejecutando, por lo tanto el rendimiento viene muy condicionado por el motor del navegador. Un ejemplo claro de que HTML5 no está a la altura de ciertas misiones ha sido el abandono de este estándar por Facebook en busca de código nativo para ser ejecutado, ya que el rendimiento que estaba obteniendo de sus desarrollos no estaban a la altura de las expectativas de sus usuarios (y clientes).

Llegados a este punto,  esta es la ventaja que ofrece Apple en su "entorno cerrado": la ejecución de código nativo, no interpretado, le facilita la posibilidad de crear dispositivos mucho más rápidos con velocidades de procesador más lentas que las de su competencia, menor consumo de energía y en general, hardware más ajustado. Es precisamente por esto por lo que Apple está apostando muy seriamente por el diseño a medida, la personalización de los componentes y en general, lo que se podría llamar "tunning" de forma que su código compilado puede ejecutarse en hardware menos potente, pero también mucho más barato de producir y que consume mucha menos energía.

Generalmente esto es algo que a la gente no le importa, pero tiene una importancia muy grande en una carrera tecnológica a la larga entre diferentes empresas.

En conclusión, y bajo mi opinión personal, no se puede comparar el rendimiento que se puede obtener con el código nativo con respecto a otras soluciones, y en concreto para aplicaciones el usuario puede notar la diferencia dependiendo del dispositivo que se compare: por ejemplo,  en cuanto a juegos complejos el código nativo mejora sustancialmente el rendimiento final del mismo pero cuando los dispositivos móviles saltan del consumo a la empresa, que es muchas veces donde está el Big Business, las ventajas en cuanto a rendimiento y estabilidad que el código nativo ofrece superan con mucho a los problemas del código interpretado en misiones críticas.

Sergio Martinez-Losa es desarrollador de aplicaciones y videojuegos para iOS en Double Equal. Double Equal es un estudio independiente dónde se desarrollan videojuegos y apps para móviles, entre sus creaciones destacan Quares y Think'N'Link, para mas información no dudes en visitar su web.

 

0
Comentarios
  • #1 por yules el 26/11/2012
    Esa ventaja también la tenía Nokia con Symbian. A la larga, no fue suficiente.

    Es cierto que Apple en los primeros modelos de iPhone se las arregló con procesadores inferiores a los de la competencia, pero los actuales están a su altura, si no los superan. Aún así, seguían arreglándoselas con menos RAM y baterías de bastante menos capacidad. Sin embargo, lo de la RAM ya no está tan claro con iOS6. Al menos la información de desempeño de mi 4S está llena de logs de "low memory" y cuando he abierto alguna aplicación de gestión de memoria, con mucha frecuencia me he encontrado con cantidades ridículas de memoria libre, en comparación con iOS 5 donde, con las mismas aplicaciones abiertas (puesto que cierro las que no voy a usar en breve), era raro que bajase de los 100 MB.

    Lo peor de todo es que alguna vez alguna aplicación ha acaparado la memoria de mala manera y si abría alguna después, se cerraba sola al pasarla a segundo plano. Si abría alguna aplicación de gestión de memoria, ésta petaba, por lo que la única solución era reiniciar el teléfono. La última vez que me ocurrió, después de ver que me había cerrado por su cuenta un par de veces la aplicación "Endomondo" que tenía en segundo plano, pude comprobar por los logs que el proceso acaparador era "LOTAppleDeviceAs", es decir un proceso interno. De ese mismo día tengo logs con warnings de Low Memory de la AppStore y de Mail.

    En fin, que la siguiente versión de iOS tiene mucho que arreglar todavía.
  • #2 por digitalmaxima el 26/11/2012
    Gran artículo. Muchas gracias, Sergio. Pena de que no haya más comentarios, es un tema interesantísimo para que los legos como yo aprendamos.