L'année dernière, j'ai quand même écrit des applications Flutter pour iOS et Android. Avant cela, j'avais et j'ai 5 ans d'expérience avec Xamarin. Cela a été un merveilleux 5 ans. Grâce à Xamarin et à mon amour pour ce framework, j'ai, en principe, déménagé dans le camp des développeurs, cet outil m'a permis de gagner beaucoup d'argent, de connaissances et de trouver de merveilleux collègues. Alors pourquoi j'écris sur Flutter maintenant? Réponse courte, car Flutter couvre tous les besoins du développement multiplateforme.Un peu d'histoire
Corrigez-moi si je me trompe, mais 2009 a été à bien des égards la clé du développement mobile en général et du développement multiplateforme en particulier. En 2009, l'iPhone 3gs est sorti, ce qui vous permettait d'exécuter des applications tierces depuis l'AppStore. Pour la première fois, cette opportunité est apparue un an plus tôt dans l'iPhone 3g, mais le 3gs est devenu un iPhone véritablement massif et «populaire». Encore une fois, un an plus tôt, en septembre 2008, Android a été présenté au public et en 2009, de nombreux fabricants de téléphones ont commencé à essayer Android pour leurs nouveaux modèles de téléphones. Au printemps 2009, Nitobi a présenté PhoneGap, un nouveau cadre pour créer des applications multiplateformes basées sur HTML5, CSS et JS. La même année, en septembreXimian a publié MonoTouch, qui vous permettait d'écrire des applications iOS en utilisant Mono et C #. Dans le même 2009, en décembre, Rovio Entertainment a sorti un jeu pour iOS et, pendant un moment, Maemo, qui à bien des égards a marqué le début de l'industrie du jeu mobile - Angry Birds. Le dernier exemple ici n'est pas accidentel.Le premier framework multiplateforme "pour le peuple" peut être considéré comme PhoneGap (développeurs Qt, ne jetez pas de pierres). C'était une idée merveilleuse et très évidente: faire entrer le Web dans le monde du développement mobile. En 2009, les capacités du Web avaient déjà commencé à s'étendre au-delà du navigateur ( bonjour node.js), tandis que l'écriture d'applications Web dans JS était assez simple. Le deuxième point, non moins important, est le rendu de l'interface utilisateur. La façon dont le rendu se produit réside dans le moteur du navigateur et tous ces moteurs suivent plus ou moins les normes W3C pour HTML, CSS et DOM. Tout développeur Web qui a créé un site s'attend à ce que son site soit presqueidentique dans n'importe quel navigateur, sur n'importe quelle plateforme. C'est, à mon avis, l'aspect le plus important du Web en tant que plate-forme ouverte. Pourquoi devrais-je apprendre un nouveau langage / cadre pour dessiner l'interface utilisateur pour chaque plate-forme, si pendant longtemps il existe une norme de modélisation de l'interface utilisateur pour différents navigateurs.Après cela, Cordova s'est éloignée de PhoneGap et d'Ionic. Il semblerait que ce soit un cadre idéal, mais il y avait 2 points: les performances et l'intégration du système d'exploitation. L'un des principaux objectifs ou, si vous le souhaitez, des repères d'application, écrits sur des solutions multiplates-formes, était leur «nativité». Ceux. Idéalement, 100% des utilisateurs devraient considérer que votre application multiplateforme est native. Et cela signifie qu'il devrait ressembler à natif, fonctionner comme natif et avoir toutes les intégrations possibles avec le système d'exploitation. Au début, tous ces points pour PhoneGap étaient inaccessibles, les capacités des smartphones il y a 10 ans n'étaient pas suffisantes pour le rendu de l'interface utilisateur à 60 ips, l'intégration avec le système d'exploitation était minime. Maintenant, il existe un certain nombre d'applications sur Ionic qui sont difficiles à distinguer des applications natives, mais imiter une application native est toujours une tâche.et non donné comme tel. Résumons un peu. L'écriture d'applications Web, ou plutôt d'applications hybrides sur iOS et Android, est possible et pratique. C'est pratique car le mécanisme de rendu de l'interface utilisateur repose entièrement sur la plate-forme WebView, et il existe une couche de programmeurs déjà formés qui connaissent bien le Web.Cependant, dans les applications hybrides, les performances et l'intégration du système d'exploitation peuvent être boiteuses.En même temps que PhoneGap, MonoTouch est né en 2009, qui a ensuite été renommé Xamarin.iOS. De plus, la même année, Titanium est sorti, ce qui a également permis d'écrire des applications iOS sur javascript. Au début, Titanium fonctionnait exactement dans le même paradigme que PhoneGap - en s'appuyant sur WebView. Mais ils ont ensuite adopté l'approche Xamarin. Quelle est cette approche? Il peut être vu comme quelque chose au milieu. L'approche de Xamarin / Titanium / React.Native est qu'au lieu d'essayer de créer / migrer votre rendu d'interface utilisateur / existant, le cadre s'intègre simplement avec l'existant natif.Au lieu de dessiner un formulaire en HTML, Xamarin appelle pour cela un élément d'interface utilisateur natif (UITextField, TextEdit, etc.). En effet, pourquoi réinventer la roue? Tous les éléments d'interface utilisateur nécessaires existent dans les SDK natifs et les runtimes, il vous suffit d'apprendre à communiquer avec eux depuis vos machines virtuelles (mono, v8, etc.). En même temps, comme vous l'avez déjà deviné, vous pouvez utiliser vos C #, JS, TS, F #, Kotlin, etc. préférés et, en même temps, le code qui n'interagit pas directement avec l'interface utilisateur est 100% multiplateforme. Vous pouvez aller encore plus loin. Les mêmes UITextField et TextEdit sont des entités conceptuellement identiques, ils ont plusieurs propriétés et interfaces d'interaction similaires, et donc, vous pouvez créer une entrée abstraite (bonjour Xamarin.Forms) et travailler uniquement avec elle, pour rare ( pas très) exception allant jusqu'à l'élément d'interface utilisateur de la plate-forme. Je ne mentionne pas que si votre VM peut fonctionner avec l'interface utilisateur de manière native, votre VM peut très probablement appeler n'importe quelle API de plateforme. Cela semble être l'option parfaite. Interface utilisateur native, performances natives (Hi Bridges dans React.Native), intégration à 100% du système d'exploitation. Est-ce vraiment parfait? Très probablement - non, et le problème est qu'en réalité, ces solutions ne résolvent pas le problème du développement multiplateforme - une interface utilisateur unique. Ils la déguisent. Je veux écrire une fois, courir partout. C'est loin d'être la meilleure devise pour tous les types de programmes et de problèmes, mais cela correspond bien à l'interface utilisateur. Je veux écrire la même interface utilisateur pour tout le monde, quelle que soit la plate-forme. Pourquoi un développeur Web peut-il se permettre d'utiliser HTML et CSS pour écrire un site qui sera ensuite affiché de la même manière dans Safari sur iOS et Chrome sur Android, mais pas de développeur natif?En fait, les programmeurs ont depuis longtemps écrit une interface utilisateur haute performance avec une base de code commune pour iOS et Android. Ces programmeurs sont appelés développeurs de jeux. Angry Birds a été écrit sur le moteur Cocos2d-x, Cuphead sur Unity et Fortnite sur Unreal Engine. Si les moteurs de jeu peuvent montrer des scènes à couper le souffle sur votre téléphone, les boutons et les listes avec une animation fluide seront certainement en mesure de le faire. Alors pourquoi personne ne les utilise dans cette veine? La réponse est simple et banale, ils ne sont pas destinés à cela. Lorsque vous ouvrez le jeu, c'est à la lampe de poche de voir à quel point l'interface utilisateur ressemble à une interface native, vous n'avez presque jamais besoin d'interagir avec la géolocalisation, les boutons-poussoirs, une caméra vidéo, etc. Pendant que vous jouez, vous vivez une vie différente dans votre petit monde qui est rendue via Canvas dans votre UIViewController / Activity. par conséquentles moteurs de jeu ont une intégration relativement médiocre avec le système d'exploitation , il n'y a donc pas (ou je n'ai pas vu) imitant le moteur supérieur de l'interface utilisateur native.Sous-totaux
Pour un cadre multiplateforme idéal, nous avons besoin de:- Mappage de l'interface utilisateur native
- Performances de l'interface utilisateur native
- 100% capacité d'appeler n'importe quelle API de système d'exploitation, comme s'il s'agissait d'une application native
Vous pensez maintenant que je vais commencer à échouer sous Flutter, mais j'entends déjà des commentaires en colère: «Où est Qt!? Il peut faire tout ça! » En effet, Qt à un degré ou à un autre correspond à ces critères. Bien que je doute fortement du premier d'entre eux. Mais le principal problème de Qt n'est pas la difficulté d'écrire une interface utilisateur native, le problème principal est C ++. Ensuite, j'essuie déjà mon visage de la salive de codeurs de travail sur les avantages. Pros est un couteau suisse pour les stéroïdes anabolisants, pour les pros vous pouvez tout faire. Mais moi, en tant que développeur frontend, je n'ai pas besoin de tout cela. J'ai besoin d'un langage simple et compréhensible qui fonctionne avec l'interface utilisateur et les E / S. Ainsi, à nos trois points ci-dessus a été ajouté:- Langue facile à apprendre et assez expressive
- Rantime qui s'intègre bien dans le paradigme de développement frontend
Eh bien, maintenant que nous avons mis en évidence certaines mesures d'un bon outil multiplateforme pour développer des applications mobiles, nous pouvons passer en revue chacune d'entre elles et voir comment elle est implémentée dans Flutter.Mappage de l'interface utilisateur native
Comme nous l'avons découvert plus tôt, il existe deux approches opposées pour travailler avec l'interface utilisateur dans des cadres multiplateformes. Il s'agit d'un rendu d'interface utilisateur utilisant WebView ou des appels d'éléments d'interface utilisateur natifs sur chaque plate-forme. Chaque approche a ses avantages et ses inconvénients. Mais ils ne couvrent pas la gamme complète des besoins des développeurs: ne se distinguent pas de l'interface native + des performances natives. Flutter couvre tous ces besoins avec une tête. L'équipe Flutter a dépensé une certaine quantité de ressources pour créer des éléments «natifs» dans le framework lui-même. Tous les widgets de Flutter sont divisés en trois grandes catégories:Si vous allez dans la section cupertino, vous verrez que ces widgets ne se distinguent pas des éléments iOS natifs. En tant que développeur qui utilise Flutter depuis un certain temps, je peux confirmer qu'il est impossible de les distinguer. Si vous utilisez CupertinoDatePicker, par exemple, lors du défilement, vous ressentirez exactement la même chose, de bons commentaires du moteur Taptic / Haptic sur votre iPhone comme s'il s'agissait d'un élément natif de l'application native. J'en dirai plus, périodiquement j'ouvre l'application du site realtor.com sur mon iPhone et jusqu'à récemment je n'avais aucune idée qu'il était écrit en Flutter (ou sur quelque chose de non natif).Flutter vous permet non seulement d'utiliser des widgets "natifs" pour 2 plateformes, mais aussi de créer les vôtres, et c'est très simple! Le paradigme est que tout fonctionne avec un widget. Vous pouvez créer des éléments d'interface utilisateur et des animations incroyablement complexes en peu de temps. Les charmes et la sagesse de l'approche de travailler avec l'interface utilisateur dans Flutter ont récemment été décrits dans cet article sur Habr, je recommande la lecture. Parce que tout cela fonctionne sur un seul moteur graphique qui rend tout cela directement pour chaque plate-forme (nous en reparlerons plus tard), vous pouvez être sûr que tout sera affiché comme prévu.Un autre point assez étonnant. Flutter prend en charge les plates-formes commençant par iOS 8 et Android API v16. Du point de vue du rendu de l'interface utilisateur, Flutter n'a pas vraiment d'importance quelles API sont disponibles sur une plate-forme particulière. Il aurait l'opportunité de travailler avec Canvas et une sorte d'interaction avec le sous-système graphique. Et cela signifie que nous pouvons dessiner les derniers éléments d'interface utilisateur d'AndroidX, par exemple, sur un téléphone de 8 ans. Il y a certainement une question de performance de cette approche sur les plus anciennes plateformes supportées, mais c'est une autre question.Performances de l'interface utilisateur native
Comme vous pouvez le voir, l'approche de Flutter pour le rendu de l'interface utilisateur est plus proche de celle des applications hybrides comme Ionic. Nous avons un moteur unique pour le rendu de l'interface utilisateur sur toutes les plates-formes, c'est la bibliothèque graphique Skia . Google a acheté Skia en tant que produit en 2005 et l'a transformé en projet Open Source. Cela suggère au moins qu'il s'agit d'un produit assez mature. Certaines fonctionnalités de performance de Skia:- Copie sur écriture pour les éléments graphiques et autres types de données
- Utilisation de la mémoire de pile dans la mesure du possible pour réduire la fragmentation
- Sécurité des fils, pour une meilleure parallélisation
Je n'ai pas trouvé de tests de performances Skia convaincants par rapport à des bibliothèques similaires (voir Le Caire ), mais certains tests montrent un gain de performances de 50% en moyenne, sauf dans certaines situations spécifiques. Oui, ce n'est pas particulièrement important, car ces tests sont basés sur l'utilisation d'OpenGL sur les postes de travail, et ...Skia peut interagir avec de nombreux backends GPU. Depuis récemmentsur iOS, depuis la version 11, Flutter utilise Metal comme GPU backend par défaut. Sur Android, à partir de l'API 24 - Vulkan. Pour les versions ci-dessous - OpenGL. Tout cela nous donne un gain évident de productivité. Sur d'autres plates-formes "matérielles", si je comprends bien, Skia / Flutter utilise OpenGL, ce qui ne nous empêche pas en principe d'écrire des applications avec des performances graphiques suffisantes.Le Web se distingue. Pour le moment, l'intégralité du rendu de l'interface utilisateur repose toujours sur le bundle Canvas / HTML. Par conséquent, Skia n'est aucunement impliqué dans ce processus. De plus, la machine virtuelle Dart n'interagit pas directement avec le DOM. Vient d'abord la conversion en js. Tout cela n'a pas le meilleur effet sur la productivité et cela se remarque directement à l'œil nu. Cependant, des travaux sont en cours pour implémenter CanvasKitdans Flutter, qui à son tour permettra à Skia d'être utilisé dans les navigateurs via WebGL.Enfin, les programmeurs C # utilisent SkiaSharp depuis relativement longtemps - un wrapper sur Skia pour Mono / .Net x. Et la communauté Xamarin utilise cette bibliothèque pour dessiner des éléments d'interface utilisateur personnalisés et c'est une bibliothèque très populaire. Si ce n'est pas une victoire, alors je ne sais pas ce que c'est.100% capacité d'appeler n'importe quel système d'exploitation API
Dans Flutter, il existe 2 principes d'interaction avec le monde "extérieur":Les canaux de plate-forme vous permettent d'interagir avec le runtime / API natif via un système de messagerie. D'un point de vue architectural, cela peut être vu comme suit. Visuellement, Flutter n'est qu'un canevas, qui est étiré en plein écran dans le seul Activity / UIViewController de votre application native. C'est exactement la même approche que j'utilise pour les développeurs de jeux (moteurs de jeux). Ceux. Vous pouvez ouvrir le projet iOS / Android de votre application et ajouter toute autre fonctionnalité à Swift / Kotlin / etc. Le problème est que le runtime natif et la machine virtuelle Dart ne savent rien l'un de l'autre (en plus du fait que le runtime natif saura que l'application a Canvas et que quelque chose y est affiché). De plus, si vous, par exemple, ouvrez le fichier MainActivity.kt de votre projet Android, vous verrez quelque chose comme ceci:class MainActivity: FlutterActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
GeneratedPluginRegistrant.registerWith(this)
}
}
Avez-vous remarqué que votre activité hérite de FlutterActivity? Cela nous donne la possibilité de configurer le mécanisme d'envoi des messages directement à Flutter / DartVM. Pour ce faire, nous devons remplacer la méthode configureFlutterEngineet il déterminera le nom de la méthode appelée et le nom du canal d'envoi de messages asynchrones. Tout. Cela permet de nous écrire n'importe quel code natif et d'appeler n'importe quelle API native! Dans le même temps, il existe déjà un grand nombre de plugins (packages) qui vous évitent d'écrire du code natif, vous ne pouvez utiliser que Dart. C'est tout simplement merveilleux! Vous écrivez l'interface utilisateur séparément et une fois pour n'importe quelle plate-forme, utilisez DartVM pour travailler avec l'interface utilisateur, les E / S et tout comme un composant informatique, utilisez des plugins qui implémentent des fonctionnalités natives et qui couvrent 99% de toutes les fonctionnalités. Et si cela ne suffit pas, vous écrivez en natif et communiquez via le mécanisme de message. Récit.Le deuxième mécanisme est une interface de fonction étrangère ou FFI. Il s'agit d'un terme assez courant pour désigner le mécanisme itérope avec d'autres langues, principalement C. Dans le monde .Net, ce mécanisme est appelé P / Invoke, pour la JVM c'est JNI. En bref, c'est la possibilité d'interagir avec des bibliothèques écrites en C / C ++ / etc. À l'époque du .Net Framework, par exemple, aucun logiciel n'était écrit en C # et la grande majorité des logiciels étaient écrits en C / C ++, donc un mécanisme était nécessaire pour travailler avec ces bibliothèques. La même chose s'applique à JVM, Python, vous l'appelez. FFI est utilisé d'une manière ou d'une autre dans tous les cadres mobiles multiplateformes. Plus récemment, DartVM a également commencé à prendre en charge FFI pour l'interopérabilité avec C et JavaScript! Bien que cette fonctionnalité soit dans une branche bêta, elle est déjà disponible pour utilisation (à vos risques et périls).Comme vous pouvez le voir, Flutter et DartVM couvrent 100% des possibilités sur les plateformes natives, et bien plus encore.Langue facile à apprendre et assez expressive
J'avoue honnêtement, alors que Dart pour moi ne reste pas la meilleure langue du monde. Il n'y a pas de système de type strict, il n'y a pas de petits pains fonctionnels, tels que les fonctionnalités de correspondance de modèle ou d'immuabilité (comme ils seront bientôt livrés), etc. Concernant le système de types, Dart a été conçu à l'origine comme un langage "sans langage typique", ala JS, mais pour un support normal de la compilation AOT, il était néanmoins nécessaire de rendre le système de types plus strict, mais pas complètement, je dirais. Cela m'ennuie encore de travailler avec des signatures de méthode, notamment avec des arguments. Tous ces supports, @requiredpour une raison quelconque , sont en colère . Mais le dart est une langue très facile à apprendre. En syntaxe, c'est un croisement entre Java et JS pour moi. Dart pardonne beaucoup, comme JS. En général, c'est une langue assez facile à apprendre, je n'ai pas rencontré de problèmes importants.Rantime qui s'intègre bien dans le paradigme de développement frontend
Parlons maintenant de Dart VM. En général, Dart VM comprend beaucoup de choses, du GC au Profiler et à l'Observatoire. Ici, je veux parler uniquement du GC et de l'exécution conditionnelle. Vous pouvez vous familiariser avec le fonctionnement du runtime et sa composition ici . Je ne suis pas un expert dans ce domaine, mais pour ma part, j'ai noté certains des avantages de Dart VM, que je vais essayer de décrire. Avant cela, je voudrais noter que Dart et la machine virtuelle correspondante ont été initialement développés en remplacement de JS, ce qui, pour ainsi dire, met l'accent sur le développement du frontend.Les isolats
Sommaire
Si vous lisez cette ligne, alors, premièrement, félicitations, et deuxièmement, je dois dire que je n'ai aucune expérience dans la rédaction d'articles, donc je ne comprends pas très bien si j'ai réussi à faire passer mon message. Et l'idée est simple, lorsque vous écrivez une application mobile avec Flutter, elle s'avère native. Et sous forme de bonus, vous obtenez une vitesse de développement d'application très décente. Le rechargement / redémarrage à chaud est tout simplement indispensable dans le développement Frontend. Pouvez-vous imaginer un typographe qui aurait besoin de construire / compiler l'ensemble du projet pour chaque navigateur, par exemple, à chaque changement de couleur d'un bouton? Bien sûr que non. En général, Hot Reload / Restart mérite un article séparé. Mais j'étais distrait.Mon expérience avec Flutter me dit que ce cadre sera dominant dans un avenir proche. Périodiquement, je passe des entretiens pour un poste de développeur Flutter et dans la moitié des cas, les entreprises qui recherchent un développeur Flutter ont en fait une équipe de développeurs natifs mobiles. Ils ont juste essayé Flutter sur des projets intérieurs / latéraux, étaient satisfaits / ravis et se déplaçaient lentement vers Flutter. C'est une vraie victoire, il me semble. Ce que l'on ne peut malheureusement pas dire de Xamarin. Très souvent, la décision de choisir Xamarin est simplement due au fait que le reste de la pile est écrit en .Net, et c'est une pente glissante.Pour résumer, je tiens à dire que si vous pensez de quel côté aborder lors du développement de votre nouvelle application mobile, regardez Flutter.