Présentation
Au travail, j'ai dû à plusieurs reprises faire face au choix d'une technologie adaptée au développement mobile. Ci-dessous, j'ai essayé de collecter et de classer les principaux cadres en fonction des approches utilisées, des avantages et des inconvénients.
Si certaines de mes informations sont incorrectes ou obsolètes, les commentaires sont les bienvenus.
Tout framework multiplateforme est une couche d'abstraction au-dessus de la plateforme native et vous permet d'accéder uniquement à ses fonctionnalités qui sont directement prises en charge par le framework.
Dans la plupart des cas, il est possible d'étendre la prise en charge de la plate-forme en écrivant des plugins natifs pour le framework, mais dans certains cas, cela peut compliquer considérablement le développement. Un nouvel exemple de l'article sensationnel d'AirBnb est React Native, qui pour le moment ne sait pas comment travailler avec les bibliothèques Android 64 bits prêtes à l'emploi.
Vous devez également faire attention au fait que les plug-ins natifs et le code principal d'une application multiplateforme, en règle générale, sont exécutés dans différents processus et l'interaction entre eux peut entraîner des problèmes de performances. Pour travailler avec des capteurs ou SQLite, ce n'est généralement pas un problème, mais si vous utilisez, par exemple, la bibliothèque OpenCV en tant que plugin natif et commencez à lancer une vidéo entre celle-ci et l'application principale, le ralentissement peut être important.
Offre limitée sur le marché du travail
Premièrement, la présence même des développeurs dépend de la prévalence du framework. Trouver des personnes sous React Native peut être encore plus facile que les développeurs natifs, mais, par exemple, avec Flutter, c'est beaucoup plus difficile.
La mesure dans laquelle ce facteur doit être pris en compte dépend des tâches. La plupart des startups peuvent ne pas y prêter attention, car l'apprentissage d'une nouvelle technologie est plus un avantage pour les employés existants et potentiels. En revanche, les grandes entreprises sont obligées de prendre en compte le marché du travail.
Risques liés au support
On pense que la probabilité que la prise en charge du cadre multiplateforme se termine soit beaucoup plus élevée que la probabilité du même événement par rapport au système d'exploitation mobile.
En fait, la question est assez compliquée. Le système d'exploitation peut être fermé comme les frameworks (l'exemple de Windows Phone est complètement nouveau). De plus, au sein du développement natif, certaines technologies peuvent également être fermées, et parfois le code sur les frameworks multiplateformes est plus survivable.
Un exemple en est dans le domaine des jeux et du multimédia - Apple va envoyer la technologie OpenGL au repos dans son système d'exploitation et tous ceux qui ont écrit des applications 3D natives devront les réécrire complètement pour publier de nouvelles versions. Dans le même temps, pour ceux qui ont utilisé des moteurs de jeux multiplateformes (par exemple, Unity), la mise à jour ne nécessitera aucun effort supplémentaire.
Les directions principales
Développement hybride, HTML + JavaScript
Techniquement, les applications de type hybride sont des pages HTML affichées dans un navigateur intégré. En général, le cadre n'est pas requis pour cette approche, mais Cordova fournit un ensemble de plugins pour accéder aux fonctionnalités de la plate-forme, c'est pourquoi ils sont généralement utilisés.
Avantages principaux
Coût de développement minimal
L'approche hybride vous permet de réutiliser non seulement les compétences des développeurs, mais aussi le code écrit pour les sites Web.
Capacité à intégrer des éléments Web
Le nombre de bibliothèques pour HTML / JS dépasse considérablement le nombre de bibliothèques pour les applications natives. Parmi les éléments intéressants, cela inclut, par exemple, Google Analytics ou une large sélection de réseaux publicitaires.
Inconvénients clés
Faible productivité
Le JavaScript moderne lui-même utilise la compilation JIT, est bien optimisé et fonctionne rapidement, mais la construction d'une interface basée sur l'arborescence DOM n'est pas un processus très efficace. L'utilisation de frameworks JS modernes offre un niveau de charge supplémentaire. Pour les téléphones faibles et / ou avec l'utilisation active d'éléments interactifs, cela peut être un problème.
«Sentiment indigène»
Il s'agit d'un point plutôt informel, mais très important. Le site du navigateur répond aux gestes et s'affiche un peu différemment d'une application mobile. L'élément le plus notable de cette sensation, un retard de 300 ms lorsqu'il est pressé, décide Cordova, mais de nombreux autres détails restent.
Problème de compatibilité du navigateur
Sur les anciennes versions d'Android (avant la version 5), WebView faisait partie de la plateforme et ne se mettait pas à jour automatiquement. Par conséquent, il ne sera pas possible d'utiliser des capacités de navigateur modernes dans des applications hybrides sur ces appareils.
En conséquence, les applications hybrides limitent la version minimale d'Android (laissant environ 13% des appareils derrière pour le moment) ou incluent WebView dans le code d'application (projet CrossWalk), augmentant la taille de l'application de plusieurs dizaines de mégaoctets.
Destination
Créez rapidement des applications uniques. S'il y a un budget de développement substantiel, une approche hybride est généralement dédaigneuse.
Cadres de base
Le cœur de tous les principaux cadres hybrides est Cordova, qui donne accès aux plugins natifs. PhoneGap fournit des outils pour construire au-dessus de Cordova, tandis que Ionic est un cadre et un ensemble de composants pour y construire des interfaces utilisateur.
Interface native, code commun
Il est important de noter qu'avec cette approche, l'interface utilisateur et la logique métier sont exécutées dans différents processus interagissant via un pont. Un certain nombre d'inconvénients de l'approche y sont associés.
Cette approche a plusieurs options de mise en œuvre.
Classification du code exécutable
Code compilé
Xamarin utilise le langage C #, le compilant en code de plateforme natif. En général, cette approche fournit une taille d'application assez petite et une vitesse assez élevée.
Langage interprété avec compilation JIT
La plupart des cadres de cette approche utilisent JavaScript pour traiter la logique métier.
Classification par méthode de description d'interface
Outils natifs
Xamarin utilise non seulement des composants d'interface natifs, mais les décrit également dans le format accepté pour chaque plate-forme.
Éléments d'interface universels
Xamarin Forms et Appcelerator utilisent leur propre ensemble de widgets, qui est converti en composants d'interface appropriés de chaque plate-forme.
React Native utilise des wrappers autour des composants d'interface natifs. En conséquence, l'interface est décrite pour chaque plate-forme séparément, mais la méthode de description est la même.
Avantages principaux
Interface entièrement native
Premièrement, l'apparence et la «sensation» de l'application coïncident complètement avec les applications natives.
Deuxièmement, il permet d'utiliser des bibliothèques d'interface natives dans les applications. L'utilisation d'annonces natives (Native Ads), axées sur les applications mobiles, dans d'autres approches ne fonctionnera pas. Certes, pour cette approche, l'ensemble des bibliothèques pertinentes est très limité. Je ne connais que le support de Facebook Native Ads dans React Native.
Capacité à réutiliser les compétences des développeurs
De nombreux cadres de ce groupe sont conçus pour que les développeurs d'autres domaines puissent apprendre à créer des applications mobiles avec des coûts minimes. Pour React, Native est React, pour Xamarin, .NET, etc.
Inconvénients clés
Limitation des capacités d'interface ou coûts supplémentaires pour un développement séparé
Le format de ce moins dépend de la classification du framework selon la façon dont l'interface est décrite:
Xamarin vous permet d'utiliser presque toutes les fonctionnalités des plates-formes, mais vous devez passer beaucoup de temps sur les interfaces de chaque plate-forme. En conséquence, les coûts de main-d'œuvre ne sont pas beaucoup moins élevés qu'avec le développement indigène.
Xamarin Forms et Appcelerator vous permettent de décrire les interfaces une seule fois, mais elles fonctionnent avec un sous-ensemble très limité de fonctionnalités natives (pas plus que l'intersection minimale des ensembles de fonctionnalités de chaque plate-forme, pour être formelle).
React Native est au milieu, combinant les deux lacunes, mais sous une forme moins prononcée.
Performances d'interaction de l'interface
Ici entre en jeu le facteur d'exécution des interfaces et de la logique métier dans différents processus. Lorsqu'il est nécessaire d'échanger de grands volumes d'informations à travers un pont à grande vitesse (animation complexe à haute fréquence), des difficultés peuvent survenir dans cette approche.
Fuites de mémoire
Des fuites de mémoire peuvent se produire dans n'importe quelle application, mais la plupart des situations standard sont gérées par des garbage collector.
Le problème avec les applications multiplates-formes avec une interface native est à nouveau qu'elles s'exécutent dans deux processus qui ont des récupérateurs de place distincts. Si l'objet de logique métier fait référence à un objet d'interface, cet objet d'interface n'est pas une ordure, car il y a un lien depuis le pont. Si l'objet d'interface fait référence à l'objet de logique métier, ils ne seront pas considérés comme des ordures même s'il n'y a plus de références à eux.
Les chances de rencontrer un problème et son ampleur dépendent directement de l'application. Si des objets associés à l'interface y sont activement créés et supprimés (comme dans le défilement sans fin), la probabilité d'une fuite augmente. Si ces objets sont volumineux (par exemple, des images), l'effet des fuites augmente.
En fait, ce problème est également présent lorsque vous travaillez avec des plugins natifs, qui sont également exécutés dans un processus distinct. Mais là, dans la plupart des cas, soit il n'y a pas une telle manipulation intensive des gros objets, soit l'interaction se déroule dans une approche strictement procédurale, sans références croisées.
Destination
Applications avec une interface entièrement native, surtout s'il existe des spécialistes des technologies connexes.
Cadres de base
React native
Il a un support Facebook et utilise l'approche du framework React JS le plus populaire, grâce auquel il est très populaire. Un article récent sur l'abandon par AirBnb de React Native a fait beaucoup de bruit, mais s'il est conscient des risques, il peut être une solution très efficace.
Xamarin
En plus de l'approche principale, il possède la bibliothèque Xamarin.Forms, qui vous permet de concevoir des interfaces simples de manière efficace et multiplateforme. Supporté activement par Microsoft. Lorsque vous travaillez avec ASP.NET sur le serveur, il vous permet également d'enregistrer une certaine quantité de travail grâce à l'utilisation de classes de logique métier communes sur le serveur et dans l'application mobile.
Nativecript
Il est calqué sur React Native pour les développeurs qui possèdent d'autres frameworks JS (Angular et Vue.js). Moins populaire, mais propose un certain nombre de solutions plus modernes en architecture.
Interface native, code commun
Presque tous les moteurs de jeux utilisent cette approche, mais ils dépassent le cadre de cet article.
Le principe de cette approche est que l'application utilise son propre code et son propre rendu d'interface utilisateur.
Avantages principaux
Interfaces hautes performances
En fait, une application qui dessine sa propre interface seule effectue les mêmes opérations que le système d'exploitation dans l'interface native. En théorie, cela peut être encore plus rapide, car il n'y a pas de commutation entre le processus et le noyau, mais en pratique, d'autres facteurs affectent la vitesse de rendu d'une interface particulière, jouent un rôle beaucoup plus important.
«Design Interfaces»
Les applications natives utilisent des composants d'interface prêts à l'emploi et ont certaines limitations sur ce qui peut être fait avec eux. À leur tour, les applications qui dessinent elles-mêmes leur propre interface n'ont pas de telles restrictions et peuvent mélanger librement des éléments prêts à l'emploi avec un rendu individuel.
Inconvénients clés
Ces inconvénients ne sont pertinents que pour les applications qui imitent l'interface standard du système d'exploitation. Comme déjà mentionné, pour les interfaces de conception et les jeux, cette approche est optimale.
Taille de l'application
Les applications avec cette approche sont obligées de transporter du code pour le rendu de tous les éléments d'interface, y compris les éléments conditionnellement standard. Cela affecte à la fois la taille de l'application pendant l'installation et la RAM pendant le fonctionnement.
Si le premier problème peut être minimisé par un tremblement d'arbre efficace (comme le font les dernières versions de Flutter), alors ces applications perdent de manière stable leur mémoire native en RAM. Cependant, ce problème est également caractéristique d'autres cadres multiplateformes.
Interface native
Par défaut, l'application est identique sur toutes les plateformes, ce qui peut créer un inconfort pour les utilisateurs. Les thèmes sont utilisés pour résoudre ces problèmes, mais ils ne peuvent pas créer le sentiment d'une application entièrement native.
Mais il y a un inconvénient plus important - avec cette approche, il est plus difficile d'utiliser des éléments d'interface tiers créés pour des applications natives (y compris les annonces natives mentionnées précédemment).
Destination
Applications publiques, notamment avec une interface de conception.
Cadres de base
Flutter
Flutter est promu par Google comme cadre de développement multiplateforme et interface de base pour leur futur système d'exploitation Fuscia. Bien que le cadre soit très jeune (au stade de la prévisualisation des versions) et peu courant, il gagne rapidement en popularité. Utilise le langage Dart (avec compilation en code natif).
Il a tous les avantages et les inconvénients de la jeunesse - une architecture bien pensée, tenant compte des erreurs de ses prédécesseurs, mais un écosystème plutôt limité.
QT Mobile
Il est populaire parmi les développeurs de PC de bureau. JavaScript peut être utilisé dans le développement. Sans le soutien des grandes entreprises, ce n'est pas très populaire.
Kivy
Un autre framework pas très populaire qui est intéressant, principalement parce que c'est le seul framework de la liste qui utilise Python. Pour les développeurs qui ne connaissent que ce langage (et ils sont nombreux dans certains domaines des technologies de l'information), cela peut être crucial.
Matériel connexe
Sur la mémoire dans Xamarin et les cadres similaires
Comparaison des performances des applications natives, Flutter et React Native