Así que ya sabes de dónde vengo, no solo hice desarrollo móvil en AIR, sino que también envié un juego en cocos2d-x y construí varios prototipos en Objective-C. Entonces mi respuesta no es de investigación sino de experiencia del mundo real.
Lo más importante que debe saber es que AIR tiene dos formas de renderizado, modo software y modo GPU. Muchas personas que probaron AIR hace un tiempo no tenían acceso al modo GPU, por lo que se vieron obligados a renderizar a través del software. Como resultado de eso, AIR obtuvo la reputación de ser lento. Una vez que llegó el acceso a la GPU, y salió Starling, las cosas cambiaron, y AIR ahora es tan rápido en el renderizado como cualquier solución nativa.
1) Los mayores obstáculos que enfrenta en este momento son:
- ¿Qué lenguaje y / o marco me recomendaría usar si necesito desarrollar una aplicación? ¿Por qué?
- Cómo agregar espacios entre las celdas de la vista de tabla de forma rápida en el guión gráfico
- Cómo crear un medidor de nivel estéreo para iOS usando solo Swift
- Cómo llamar a funciones nativas de iOS desde Unity
- ¿Cómo se comunican las partes MVC entre sí?
a) El tamaño del paquete es de aproximadamente 7-8 MB más grande que un equivalente nativo
b) Si bien el simulador de escritorio es increíblemente rápido, llevar una compilación de calidad de lanzamiento a un dispositivo iOS lleva varios minutos. Sin embargo, el modo “empaquetador rápido”, que tiene problemas de rendimiento, es muy rápido de implementar. En mi experiencia
c) Problemas de rendimiento marginal. La mayoría de los cuellos de botella en el desarrollo de juegos están en la capa de renderizado, y ahora que AIR tiene soporte Stage3D para iOS y Droid, es tan rápido como el desarrollo nativo.
2) Ninguno que yo sepa. Se cubren casos de uso comunes como conexiones de socket y http / https.
3) Diría que el 80% del código es reutilizable, donde el 15% puede ser cubierto por Native Extensions. La buena noticia es que la mayoría de las extensiones nativas que posiblemente pueda desear (Facebook, compras en la aplicación, notificaciones push) se han convertido en código abierto por muchos desarrolladores virtuosos de AIR. Solo google para ellos. El 5% restante es la posibilidad de que tenga que escribir su propia extensión nativa para un dispositivo específico, lo cual es una probabilidad baja.
4) AIR tiene un marco más sofisticado para manejar inconsistencias entre dispositivos que otros marcos, como Cocos2D-X. Todavía tengo que ver algo equivalente a Adobe Native Extensions, donde otros marcos requieren que intente por su cuenta cada solución específica del dispositivo (notificaciones, compras en la aplicación, etc.). El más cercano son los complementos de Unity, pero su kilometraje puede variar. Las extensiones nativas le permiten abstraer características comunes que tienen implementaciones específicas del dispositivo y acceder a ellas a través de una API unificada. Y el hecho de que haya tantos gratuitos que cubren todos los casos de uso principales lo convierte en una propuesta muy atractiva.
