Descripción general de los marcos de desarrollo móvil multiplataforma

Introduccion


En el trabajo, tuve que lidiar repetidamente con la elección de la tecnología adecuada para el desarrollo móvil. A continuación traté de recopilar y clasificar los marcos principales de acuerdo con los enfoques utilizados, las ventajas y desventajas.


Si parte de mi información es incorrecta o no está actualizada, los comentarios son bienvenidos.


Desventajas comunes del desarrollo multiplataforma


Soporte limitado de plataforma


Cualquier marco multiplataforma es una capa de abstracción por encima de la plataforma nativa y le permite acceder solo a las funciones que son directamente compatibles con el marco.


En la mayoría de los casos, es posible ampliar el soporte para la plataforma escribiendo complementos nativos para el marco, pero en algunos casos esto puede complicar significativamente el desarrollo. Un nuevo ejemplo del sensacional artículo de AirBnb es React Native, que por el momento no sabe cómo trabajar de inmediato con las bibliotecas de Android de 64 bits.


También debe prestar atención a que los complementos nativos y el código principal de una aplicación multiplataforma, como regla, se ejecutan en diferentes procesos y la interacción entre ellos puede causar problemas de rendimiento. Para trabajar con sensores o SQLite, esto generalmente no es un problema, pero si usa, por ejemplo, la biblioteca OpenCV como un complemento nativo y comienza a lanzar un video entre esta y la aplicación principal, la desaceleración puede ser significativa.


Oferta limitada en el mercado laboral


En primer lugar, la presencia misma de los desarrolladores depende de la prevalencia del marco. Encontrar personas en React Native puede ser incluso más fácil que los desarrolladores nativos, pero, por ejemplo, con Flutter es mucho más difícil.


Cuánto debe tenerse en cuenta este factor depende de las tareas. Es posible que la mayoría de las nuevas empresas no le presten atención, ya que aprender una nueva tecnología es más probable que sea una bonificación para los empleados existentes y potenciales. Por otro lado, las grandes empresas se ven obligadas a tener en cuenta el mercado laboral.


Riesgos de apoyo


Se cree que la probabilidad de que finalice el soporte para el marco multiplataforma es mucho mayor que la probabilidad del mismo evento con respecto al sistema operativo móvil.


De hecho, la pregunta es bastante complicada. El sistema operativo se puede cerrar al igual que los marcos (el ejemplo de Windows Phone es completamente nuevo). Además, dentro del desarrollo nativo, ciertas tecnologías también pueden cerrarse y, a veces, el código en los marcos multiplataforma es más resistente.


Un ejemplo de esto es en el campo de los juegos y multimedia: Apple enviará la tecnología OpenGL para que descanse en su sistema operativo y todos los que escribieron aplicaciones 3D nativas tendrán que reescribirlas por completo para lanzar nuevas versiones. Al mismo tiempo, para aquellos que usaron motores de juegos multiplataforma (por ejemplo, Unity), la actualización no requerirá ningún esfuerzo adicional.


Las direcciones principales


Desarrollo Híbrido, HTML + JavaScript


Técnicamente, las aplicaciones de tipo híbrido son páginas HTML que se muestran en un navegador integrado. En general, el marco no es necesario para este enfoque, pero Cordova proporciona un conjunto de complementos para acceder a las funciones de la plataforma, por lo que generalmente se usan.


Principales ventajas


Costo mínimo de desarrollo.


El enfoque híbrido le permite reutilizar no solo las habilidades de los desarrolladores, sino también el código escrito para los sitios web.


Capacidad para integrar elementos web.


El número de bibliotecas para HTML / JS excede significativamente el número de bibliotecas para aplicaciones nativas. De lo interesante, esto incluye, por ejemplo, Google Analytics, o una amplia selección de redes publicitarias.


Contras clave


Baja productividad


El JavaScript moderno en sí usa la compilación JIT, está bien optimizado y funciona rápidamente, pero construir una interfaz basada en el árbol DOM no es un proceso muy eficiente. El uso de marcos JS modernos proporciona un nivel adicional de carga. Para teléfonos débiles y / o con el uso activo de elementos interactivos, esto puede ser un problema.


"Sentimiento nativo"


Este es un punto bastante informal, pero muy importante. El sitio en el navegador responde a los gestos y muestra un poco diferente a una aplicación móvil. El elemento más notable de este sentimiento, un retraso de 300 ms cuando se presiona, decide Córdoba, pero quedan muchos otros detalles.


Problema de compatibilidad del navegador


En versiones anteriores de Android (anteriores a la versión 5), WebView era parte de la plataforma y no se actualizaba automáticamente. En consecuencia, no será posible utilizar las capacidades modernas del navegador en aplicaciones híbridas en estos dispositivos.


Como resultado, las aplicaciones híbridas limitan la versión mínima de Android (dejando cerca del 13% de los dispositivos en este momento) o incluyen WebView en el código de la aplicación (proyecto CrossWalk), aumentando el tamaño de la aplicación en varias decenas de megabytes.


Destino


Cree rápidamente aplicaciones únicas. Si hay un presupuesto de desarrollo sustancial, un enfoque híbrido suele ser desdeñoso.


Marcos básicos


El núcleo de todos los principales marcos híbridos es Cordova, que proporciona acceso a complementos nativos. PhoneGap proporciona herramientas para construir sobre Cordova, mientras que Ionic es un marco y un conjunto de componentes para construir interfaces de usuario en él.


IU nativa, código común


Es importante tener en cuenta que con este enfoque, la interfaz de usuario y la lógica empresarial se ejecutan en diferentes procesos que interactúan a través de un puente. Una serie de desventajas del enfoque están asociadas con esto.


Este enfoque tiene varias opciones de implementación.


Clasificación del código ejecutable.


Código compilado


Xamarin usa el lenguaje C #, compilándolo en código de plataforma nativo. En general, este enfoque proporciona un tamaño de aplicación bastante pequeño y una velocidad bastante alta.


Lenguaje interpretado con compilación JIT


La mayoría de los marcos en este enfoque utilizan JavaScript para procesar la lógica empresarial.


Clasificación por método de descripción de interfaz


Herramientas nativas


Xamarin no solo utiliza componentes de interfaz nativos, sino que también los describe en el formato aceptado para cada plataforma.


Elementos de interfaz universales


Xamarin Forms y Appcelerator usan su propio conjunto de widgets, que se convierte en los componentes de interfaz apropiados de cada plataforma.


Interfaz diferente para diferentes plataformas, pero un enfoque común.


React Native utiliza contenedores alrededor de los componentes de la interfaz nativa. En consecuencia, la interfaz se describe para cada plataforma por separado, pero el método de descripción es el mismo.


Principales ventajas


Interfaz completamente nativa


En primer lugar, la apariencia y la "sensación" de la aplicación coinciden completamente con las aplicaciones nativas.


En segundo lugar, permite el uso de bibliotecas de interfaz nativas en las aplicaciones. El uso de anuncios nativos (Native Ads), enfocados en aplicaciones móviles, en otros enfoques no funcionará. Es cierto que para este enfoque, el conjunto de bibliotecas relevantes es muy limitado. Solo sé sobre el soporte de Facebook Native Ads en React Native.


Capacidad para reutilizar habilidades de desarrollador


Muchos marcos de este grupo están diseñados para que los desarrolladores de otras áreas puedan aprender cómo crear aplicaciones móviles con costos mínimos. Para React, Native es React, para Xamarin, .NET, etc.


Contras clave


Limitación de las capacidades de la interfaz o costos adicionales para el desarrollo por separado.


El formato de este signo negativo depende de la clasificación del marco de acuerdo con la forma en que se describe la interfaz:


Xamarin le permite utilizar casi todas las funciones de las plataformas, pero debe dedicar mucho tiempo a las interfaces de cada plataforma. Como resultado, los costos laborales no son mucho menores que con el desarrollo nativo.


Xamarin Forms y Appcelerator le permiten describir las interfaces solo una vez, pero funcionan con un subconjunto muy limitado de funcionalidad nativa (no más que la intersección mínima de los conjuntos de características de cada plataforma, para ser formal).


React Native está en el medio, combinando ambas deficiencias, pero en una forma menos pronunciada.
Rendimiento de interacción de interfaz
Aquí entra en juego el factor de la ejecución de interfaces y lógica de negocios en diferentes procesos. Cuando es necesario intercambiar grandes volúmenes de información a través de un puente a alta velocidad (animación compleja con alta frecuencia), pueden surgir dificultades en este enfoque.


Fugas de memoria


Las pérdidas de memoria pueden ocurrir en cualquier aplicación, pero la mayoría de las situaciones estándar son manejadas por recolectores de basura.


El problema con las aplicaciones multiplataforma con una interfaz nativa es nuevamente que se ejecutan en dos procesos que tienen recolectores de basura separados. Si el objeto de lógica de negocios se refiere a un objeto de interfaz, este objeto de interfaz no es basura, porque Hay un enlace desde el puente. Si el objeto de interfaz hace referencia al objeto de lógica de negocios, no se considerarán basura incluso si no hay más referencias a ellos.


Las posibilidades de encontrar un problema y su escala dependen directamente de la aplicación. Si los objetos asociados con la interfaz se crean y eliminan activamente (como en el desplazamiento sin fin), la probabilidad de una fuga aumenta. Si estos objetos son grandes (por ejemplo, imágenes), aumenta el efecto de la fuga.


En realidad, este problema también está presente cuando se trabaja con complementos nativos, que también se ejecutan en un proceso separado. Pero allí, en la mayoría de los casos, o no existe una manipulación tan intensa de objetos grandes, o la interacción se lleva a cabo en un enfoque estrictamente procesal, sin referencias cruzadas.


Destino


Aplicaciones con una interfaz totalmente nativa, especialmente si hay especialistas en tecnologías relacionadas.


Marcos básicos


Reaccionar nativo


Tiene soporte de Facebook y utiliza el enfoque del marco React JS más popular, por lo que es muy popular. Un artículo reciente sobre el abandono de React Native por parte de AirBnb hizo mucho ruido, pero si conoce los riesgos, puede ser una solución muy efectiva.


Xamarin


Además del enfoque principal, tiene la biblioteca Xamarin.Forms, que le permite diseñar de manera eficiente y multiplataforma interfaces simples. Activamente apoyado por Microsoft. Al trabajar con ASP.NET en el servidor, le permite guardar adicionalmente una cierta cantidad de trabajo mediante el uso de clases comunes de lógica de negocios en el servidor y en la aplicación móvil.


Nativecript


Está modelado en React Native para desarrolladores que poseen otros frameworks JS (Angular y Vue.js). Menos popular, pero tiene una serie de soluciones más modernas en arquitectura.


IU nativa, código común


Casi todos los motores de juego usan este enfoque, pero están más allá del alcance de este artículo.


El principio de este enfoque es que la aplicación utiliza su propio código y su propia representación de interfaz de usuario.


Principales ventajas


Interfaces de alto rendimiento


De hecho, una aplicación que dibuja su propia interfaz realiza las mismas operaciones que el sistema operativo en la interfaz nativa. En teoría, puede ser aún más rápido, porque no hay cambio entre el proceso y el kernel, pero en la práctica, otros factores afectan la velocidad de representación de una interfaz en particular, juegan un papel mucho más importante.


"Interfaces de diseño"


Las aplicaciones nativas usan componentes de interfaz listos para usar y tienen algunas limitaciones sobre lo que se puede hacer con ellos. A su vez, las aplicaciones que dibujan su propia interfaz no tienen tales restricciones y pueden mezclar libremente elementos preparados con renderizado individual.


Contras clave


Estas desventajas son relevantes solo para aplicaciones que imitan la interfaz estándar del sistema operativo. Como ya se mencionó, para las interfaces de diseño y juegos, este enfoque es óptimo.


Tamaño de la aplicación


Las aplicaciones con este enfoque se ven obligadas a llevar código para representar todos los elementos de la interfaz, incluidos los condicionalmente estándar. Esto afecta tanto el tamaño de la aplicación durante la instalación como la RAM durante la operación.


Si el primer problema puede ser minimizado por el Tree Shaking efectivo (como lo hacen las últimas versiones de Flutter), entonces estas aplicaciones pierden de manera estable su memoria nativa por RAM. Sin embargo, este problema también es característico de otros marcos multiplataforma.


Interfaz nativa


Por defecto, la aplicación se ve igual en todas las plataformas, lo que puede crear molestias para los usuarios. Los temas se utilizan para resolver estos problemas, pero no pueden crear la sensación de una aplicación totalmente nativa.


Pero hay un inconveniente mayor: con este enfoque, es más difícil usar elementos de interfaz de terceros creados para aplicaciones nativas (incluidos los anuncios nativos mencionados anteriormente).


Destino


Aplicaciones públicas, especialmente con una interfaz de diseño.


Marcos básicos


Aleteo


Flutter está siendo promovido por Google como el marco de desarrollo e interfaz multiplataforma para su futuro sistema operativo Fuscia. Si bien el marco es muy joven (en la etapa de Vista previa de lanzamiento) y no es muy común, está ganando popularidad rápidamente. Utiliza el lenguaje Dart (con compilación en código nativo).


Tiene todos los pros y los contras de la juventud: una arquitectura bien pensada, teniendo en cuenta los errores de sus predecesores, pero un ecosistema bastante limitado.


QT Mobile


Es popular entre los desarrolladores de escritorio QT. JavaScript puede usarse en el desarrollo. Sin el apoyo de grandes empresas no es muy popular.


Kivy


Otro marco no muy popular que es interesante, principalmente porque es el único marco en la lista que usa Python. Para los desarrolladores que solo están familiarizados con este lenguaje (y hay muchos en algunas áreas de la tecnología de la información), esto puede ser crucial.


Materiales relacionados


En memoria en Xamarin y marcos similares
Comparación de rendimiento de aplicaciones nativas, Flutter y React Native

Source: https://habr.com/ru/post/es421227/


All Articles