SwiftUI VS Flutter

Préface

Je pense que chaque développeur qui voit SwiftUI associera immédiatement ce nouveau cadre d'interface utilisateur à Flutter. Oui, ils ont trop de similitudes, une syntaxe de déclaration similaire, des mises à jour à chaud en temps réel, multiplateforme (SwiftUI ne traverse que les plates-formes Apple), etc., rendant également vivant le cercle du développement mobile qui envie l'explosion de la technologie frontale. . Alors, quelles sont les similitudes et les différences entre SwiftUI et Flutter? Quels sont leurs avantages et leurs inconvénients? Et enfin, en termes de direction technique uniquement, qui est le gagnant de la future solution multiplateforme?

Langue

Il est incontestable que les langages informatiques modernes se ressemblent de plus en plus, car les objectifs de base de chaque langage sont tout à fait les mêmes: simplicité, flexibilité, sécurité et hautes performances. Dans le même temps, les excellentes caractéristiques de diverses langues sont utilisées pour la référence mutuelle, ce qui réduit encore davantage l'écart entre les langues.

Swift et Dart sont respectivement les seules langues officielles de ces deux frameworks d'interface utilisateur.La différence de syntaxe est en fait très faible.Il y a aussi beaucoup d'articles sur Internet pour comparer les avantages et les inconvénients de ces deux langues. Mon expérience est similaire à celle de la plupart des gens. Pour l'instant, Swift et Dart ont leurs propres avantages et inconvénients.

Swift est plus concis que Dart. Swift lui-même est beaucoup plus concis que Dart en termes de syntaxe, par exemple, il n'est pas nécessaire d'ajouter un ;point - virgule à la fin des phrases . Ceci est particulièrement évident lors de l'écriture directe de SwiftUI et Flutter. Cependant, ce problème n'est pas entièrement causé par le niveau de langue, mais également lié à la conception de ces deux frameworks d'interface utilisateur.

ForEach(userData.landmarks) { landmark in
	NavigationButton( destination: LandmarkDetail(landmark: landmark)) {
    LandmarkRow(landmark: landmark)
  }
}
复制代码

SliverList(
  delegate: SliverChildBuilderDelegate(
    (context, index) {
      final landmark = landmarks[index];
      return LandmarkCell(
        landmark: landmark,
        onTap: () {
          Navigator.push(
            context,
            CupertinoPageRoute(
              builder: (context) => LandmarkDetail(
                landmark: landmark,
              ),
            ),
          );
        },
      );
    },
    childCount: landmarks.length,
  ),
),
复制代码

Les deux implémentent une page de liste cliquable et tous deux appellent une cellule personnalisée.

Swift est plus strict que Dart et sera plus sûr d'un certain point de vue. Bien sûr, cela dépend des gens pour trouver la racine de la sécurité.
Swift n'avait pas attendu / async dans la 5ème année de sa sortie. Bien qu'il y ait eu des propositions, elles n'ont pas été implémentées. Cependant, il n'y a pas d'options sur Dart. On peut seulement dire que l’absorption mutuelle des deux n’est pas suffisante.
Technologie noire de Dart: prend en charge à la fois AOT et JIT, qui confère également à Flutter des fonctionnalités de rechargement à chaud au niveau du Web, et est une arme puissante pour Flutter contre SwiftUI.
Swift et Dart sont des langages open source. Apple est ouvert à Swift sans précédent, maintenant Swift a peut-être manqué de macOS, il y en a aussi eu dans la communauté, comme le framework back-end pour Vaporune série de choses intéressantes, etc., il s'agit de devenir l' Tensorflowune des langues officielles. Tout cela élargit considérablement les scénarios d'utilisation de Swift. Cependant, Dart est évidemment plus rapide que Swift en termes de jouabilité. Le framework back-end développé avec celui-ci a été mis dans l'environnement de production par certaines entreprises, et le framework Web de Google AngularDart(et non Flutter Web) fonctionne également de manière stable sur certains services depuis longtemps. Sans parler de l'exécution d'iOS Android macOS Windows Web avec l'aide de Flutter, cela peut être décrit comme rapide.

La conception d'un langage affecte la popularité d'un framework.J'ai entendu d'innombrables développeurs Flutter se plaindre du problème de nidification sans fin de Dark. Bien que Dark soit plus jouable, en ce qui concerne un seul cadre d'interface utilisateur, je pense personnellement que Swift a une expérience nettement meilleure que Dart.

grammaire

SwiftUI et Flutter utilisent la syntaxe déclarative et leurs DSL respectifs pour décrire l'interface utilisateur sans exception. Son avantage est que vous pouvez voir la structure réelle de l'interface utilisateur à partir de la structure du code en un coup d'œil, et éviter les codes logiques répétés. SwiftUI utilise la liaison de données et la gestion de l'état pour remplacer la logique de contrôle complexe d'origine, et DSL rend la structure du code très cohérente avec la hiérarchie de l'interface utilisateur.

VStack {
    MapView()
        .edgesIgnoringSafeArea(.top)
        .frame(height: 300)

    CircleImage()
        .offset(y: -130)
        .padding(.bottom, -130)

    VStack(alignment: .leading) {
        Text("Turtle Rock")
            .font(.title)
        HStack(alignment: .top) {
            Text("Joshua Tree National Park")
                .font(.subheadline)
            Spacer()
            Text("California")
                .font(.subheadline)
        }
    }
    .padding()

    Spacer()
}
复制代码

Ci-dessus, un LandMark de démonstration SwiftUI qui est apparu sur WWDC. Même si vous n'avez pas appris la syntaxe de SwiftUI, si vous lisez un peu le code ci-dessus, vous pouvez également constater qu'il correspond à l'interface utilisateur de l'image. C'est l'avantage de la syntaxe déclarative. Cependant, lors de l'écriture de code, les sentiments de Flutter et Swift sont trop différents.Le plus évident est: Flutter est beaucoup plus compliqué que SwiftUI. Combien de code dois-je écrire pour obtenir l'effet ci-dessus avec Flutter? Je ne peux pas trop le coller, sinon la moitié de mes articles seront du code Dart. Mais voici une personne qui a écrit une version Flutter de LandMarks imitant la Démo , vous pouvez vous y référer.

Pourquoi est-ce aussi une syntaxe déclarative, Fluter est tellement plus compliqué que SwiftUI. Cela reflète en fait les différentes idées d'Apple et de Google lors de la conception de ces deux cadres d'interface utilisateur, et représente même les différentes cultures des deux entreprises. Les développeurs qui ont un peu de connaissances sur iOS et Android savent que le développement iOS est beaucoup plus facile que le développement Android. En termes de configuration de l'environnement de développement seul, iOS peut commencer à écrire du code un jour plus tôt qu'Android. Sans parler des cadres compliqués, de la compatibilité des plates-formes chaotiques et des documents saccadés.

Apple traite les développeurs comme s'il s'agissait d'un novice, faisant de son mieux pour simplifier le processus de développement, réduire la charge de travail du développement et même faire du développement une chose élégante, de l'apparence et de la conception des fonctions de Xcode Cela est vrai de l'API système au langage Swift. Lorsque Google traite les développeurs, cela ressemble plus à un geek, donnant beaucoup de travail et de création aux développeurs, leur permettant de créer librement des choses intéressantes. Mais en conséquence, son seuil est également très élevé, et la fragmentation et l'incontrôlabilité induites par la liberté conduiront également à une diminution de l'efficacité du développement.

Lors de la conception de l'API SwiftUI, Apple cache de nombreux détails internes, permettant aux développeurs d'appeler le moins de code possible pour obtenir l'effet correspondant. Les développeurs n'ont pas besoin de réécrire la méthode d'initialisation ne nécessite pas l'utilisation return, n'ont pas besoin de se préoccuper du contextcontexte, il ne devrait pas être nécessaire de s'inquiéter StatefulWidgetencore StatelessWidgetplus de la conception matérielle ou du style iOS. Apple peut tout faire pour vous en interne. Tout ce que vous avez à faire est d'indiquer au compilateur les contrôles dont vous avez besoin, à quoi ils ressemblent, où ils devraient être, et rien de plus. Si la grammaire déclarative que Flutter apporte au développement mobile brille aux yeux de tous, alors l'émergence de SwiftUI consiste à dire à tout le monde (y compris Flutter) quelle est la vraie grammaire déclarative.

Mise à jour en direct

La caractéristique la plus importante de SwiftUI est le rechargement à chaud très attendu, qui est une mise à jour en temps réel. L'efficacité de développement ultra-élevée du Web a toujours été une compétence rêvée du terminal mobile.L'émergence du RN a fait voir cette possibilité à tous les développeurs mobiles pour la première fois, même si elle a maintenant ses propres problèmes. En tant qu'extension de la technologie Web, Flutter hérite d'un grand nombre de fonctionnalités de la technologie Web, et le rechargement à chaud semble être une compétence pratique. Cependant, si SwiftUI souhaite réaliser un rafraîchissement en temps réel similaire au Web, les difficultés auxquelles il doit faire face sont beaucoup plus compliquées. De mon expérience réelle, cela illustre pleinement ce point.

L'aperçu en temps réel de SwiftUI est divisé en aperçu statique et aperçu dynamique. L'aperçu statique est affiché par défaut, ce qui est rapide et prend en charge les méthodes d'écriture de code et de visualisation. Cependant, il ne répond à aucun événement et ne peut pas faire défiler et sauter des pages. Si vous avez besoin d'un débogage dynamique, vous devez passer à l'aperçu dynamique. L'aperçu dynamique doit passer une période de temps de compilation, puis il peut répondre aux modifications de l'interface utilisateur en temps réel sous une forme entièrement dynamique, et il peut être débogué en temps réel sur une machine réelle. Cependant, il existe encore de nombreuses restrictions sur l'aperçu dynamique et il est impossible d'obtenir le type de Flutter qui ne doit être compilé qu'une seule fois, puis l'ensemble de l'application peut être mis à jour dynamiquement.

Pourquoi existe-t-il un aperçu statique et un aperçu dynamique? Je pense qu'Apple ne compliquerait certainement pas ce problème s'il n'y avait pas de problèmes (problèmes de performances, bogues difficiles). On peut seulement dire que le rechargement à chaud actuel de la version désactivée est le meilleur effet qu'Apple puisse nous donner. Pour cette raison, le rafraîchissement dit en temps réel de SwiftUI est toujours en pédiatrie à partir du Web et de Flutter. Le débogage statique de l'interface utilisateur peut en fait être réalisé via StoryBoard, mais l'aperçu dynamique vraiment pratique présente certaines limites. Cependant, SwiftUI est encore en phase de test et il n'est pas encore possible de tirer une conclusion définitive sur ses performances.

performance

Google affirme que l'un des objectifs de Flutter est la fluidité (60 Hz). Jusqu'à présent, il y parvient dans la plupart des scénarios. Cependant, selon mon test (c'est actuellement en version bêta), des scènes comme les transitions de page et les animations de contrôle ont toujours une certaine pression pour fonctionner à 60 Hz. J'ai suivi le projet Flutter, et nous essayons également de réécrire certains modules avec Flutter en interne. Mais ce que j'ai vécu jusqu'à présent, le Flutter actuel, ne peut être dit que très proche de la fluidité de la plate-forme native. Cependant, même si Flutter peut atteindre la fluidité native du système, il ne peut toujours pas éviter le problème de la perte de performances. Les frameworks d'interface utilisateur natifs d'iOS (y compris SwiftUI) sont construits sur Metal, et Metal utilise les GPU beaucoup plus efficacement qu'OpenGL. Les résultats apportés par celui-ci ont également montré dans mon test que le même rendu de page et la même animation, l'utilisation du processeur et du GPU par Flutter sont plus élevés que le cadre d'interface utilisateur natif iOS. Une consommation haute performance signifie une production de chaleur élevée et une faible autonomie de la batterie pour l'équipement. Ceci est particulièrement grave sur les appareils mobiles.

Contrairement à SwiftIU, Apple semble avoir copié tous les contrôles natifs du système. En principe, il n'y aura pas d'amélioration des performances, mais ne vous laissez pas berner par vos yeux. Apple a joué un gros jeu où vous ne pouvez pas le voir.

Les deux images ci-dessus sont les étiquettes SwiftUI et iOS rendues nativement. Elles fonctionnent toutes les deux sur la plate-forme iOS et se ressemblent exactement, mais derrière elles se trouvent deux choses complètement différentes. Nous avons constaté que le texte dans SwiftUI n'est plus un contrôle natif du système iOS, mais un nouveau type nommé Text. Il s'agit en fait d'un nouveau contrôle hérité de UIView, le nom complet est DisplayList.ViewUpdater.Platform.CGDrawingView. Observez la fenêtre des propriétés sur la droite et constatez que les deux contrôles ont des propriétés complètement différentes. UILabelIl possède des attributs complexes pour contrôler les styles, les interactions, etc. Et Textaura un beaucoup plus simplifié.

Il y a des rumeurs selon lesquelles certains des contrôles de SwiftUI ont abandonné le cadre d'interface utilisateur natif du système, et utilisent à la place directement le niveau inférieur, et sont également rendus dans les plus courants Core Animation, Core Graphics et Core Text de l'écosystème Apple. Je ne sais toujours pas si le cadre sous-jacent est directement utilisé pour un rendu efficace, mais ce qui est certain, c'est qu'Apple supprime SwiftUI du cadre d'interface utilisateur d'origine, perdant ainsi le lourd fardeau historique. Cela apportera nécessairement de nombreux avantages, tels que des degrés de liberté plus élevés, de meilleures performances et, dans le vrai sens du terme: multiplate-forme.

Multiplateforme?

Beaucoup de gens peuvent dire que SwiftUI et Flutter ne peuvent pas être comparés ensemble, et SwiftUI n'est pas vraiment multiplateforme. C'est vrai, SwiftUI ne couvre actuellement que le propre écosystème d'Apple, y compris iOS (iPadOS) macOS watchOS tvOS, et à côté, Flutter s'est déjà fatigué du terminal mobile et a commencé à passer à Windows macOS et le Web. Cependant, vous ne pouvez pas nier que SwiftUI a effectivement réalisé Write once, utilisez n'importe où sur une plate-forme système complètement différente. De plus, l'idée derrière cela est complètement différente.

SwiftUI ne construit pas essentiellement l'interface utilisateur, mais décrit l'interface utilisateur. Quelle est la différence entre les deux? Lors de la création de l'interface utilisateur, vous serez clair sur le type de chaque contrôle, même sur la plate-forme. Par exemple, dans un cadre d'interface utilisateur natif, si vous avez besoin d'une zone de saisie, vous devez choisir d'utiliser UITextFiled (iOS) ou NSTextFiled (macOS) selon différentes plates-formes, et ces deux zones de saisie ont des attributs, apparences et caractéristiques différents. Dans Flutter, vous n'avez pas besoin de prendre en compte les types de contrôles sur différentes plates-formes, mais vous devez prendre en compte le style des contrôles. Les contrôles Android officiels conformes à Material Design et les contrôles iOS conformes au style iOS sont fournis. Beaucoup de leurs fonctionnalités sont également incohérentes, ce qui donne tous la construction de l'interface utilisateur Apporte une logique et une charge de travail plus complexes.

Et SwiftUI ressemble plus à un modèle Web, il décrit uniquement l'interface utilisateur, à quoi ressemble le contrôle et les fonctionnalités dont il dispose seront implémentés en fonction des conditions locales en fonction de la plate-forme compilée, et c'est automatique. C'est comme mettre un modèle, un thème sur le Web.

Code gauche décrit une forme qui contient des contrôles simples, y compris Picker, Toggle, Stepper, Button. Si nous mettons le code intact dans le projet macOS, il ressemblera à ce qui suit.

Vous constaterez qu'avec le même code, l'interface utilisateur affichée est complètement différente, mais le contenu exprimé par l'interface utilisateur est en effet exactement le même. Ce qui est encore plus contemplatif, c'est que Pickerce contrôle de "sélection de liste d'éléments uniques" est traduit en une page de sélection sur iOS. Cliquer sur la cellule fera sortir toutes les options sélectionnables, et cliquer sur l'option retournera à la page précédente et la sélectionnera. Le contenu est affiché dans la cellule correspondante. Sur macOS, Pickeril sera traduit en une liste déroulante commune sur notre système d'exploitation de bureau. Ce genre de transformation est incroyable, je ne peux que le décrire comme Wow, Awesome et Amazing. Parce qu'il est parfaitement conforme au langage de conception de la plateforme et aux habitudes des utilisateurs, et en même temps réduit considérablement la difficulté de développement et d'adaptation. Cependant, SwiftUI peut faire bien plus que cela.

C'est vrai, non seulement iOS et macOS, mais aussi sur tvOS et watchOS, SwiftUI affichera également chaque contrôle de la manière qui correspond le mieux au langage de conception et à l'interaction de la plate-forme. De plus, vous obtiendrez automatiquement un grand nombre de fonctionnalités système, telles que le type dynamique, le modèle sombre et la direction de lecture adaptative.

De ce point de vue, SwiftUI et React Native ont des idées et des technologies plus similaires. C'est juste que Facebook n'a presque pas son mot à dire sur iOS ou Android, donc il y a certains problèmes de compatibilité et de cohérence. Pour atteindre cette compatibilité, non seulement React Native lui-même a besoin de beaucoup de travail, mais les développeurs doivent également être fatigués de traiter divers problèmes, qui peuvent être considérés comme une technologie intermédiaire délicate.

SwiftUI et React Native sont fondamentalement différents de la réflexion sur la plate-forme inter-UI de Flutter. Flutter abandonne complètement le cadre d'interface utilisateur natif de la plate-forme en cours d'exécution, similaire au «dessin» de chaque contrôle pixel par pixel sur une toile, similaire à un moteur de jeu 2D. Son objectif est également très clair: s'assurer que le même code affiche exactement la même interface utilisateur sous différents systèmes d'exploitation, périphériques matériels et tailles d'écran. Cela semble être ce que veulent les développeurs, car nous en avons assez des différences incontrôlables que RN montre sur différentes plates-formes. Mais même si les différences dans le langage de conception des différents systèmes d'exploitation sont ignorées, l'interface utilisateur sous différentes tailles d'écran devrait au moins être très différente. L'interface utilisateur de la plate-forme de bureau et celle de la plate-forme mobile, et même l'interface utilisateur de la montre, devraient avoir des interfaces utilisateur et des interactions complètement différentes en fonction des habitudes d'utilisation et des méthodes de manipulation de l'utilisateur. Si vous souhaitez implémenter une adaptation multi-plateforme sur Flutter, le résultat peut être un cauchemar pour tout programmeur. Vous devez faire beaucoup de jugements, et vous devrez peut-être utiliser plusieurs contrôles pour réaliser une seule fonction, et vous devrez éventuellement faire face à de nombreux tests et bogues.

Mais il y a des avantages et des inconvénients. La solution multiplateforme presque parfaite de SwiftUI est basée sur un faible degré de liberté. Grâce à l'exemple ci-dessus, vous avez également constaté que tous les styles de contrôle natifs du système sont utilisés dans la démo. Cela ne veut pas dire que nous ne pouvons pas le personnaliser, mais:

Nous ne pouvons pas personnaliser assez d'articles
Plus nous personnalisons de contenu, plus les fonctionnalités que le système nous ajoute automatiquement perdront

Par exemple, si nous voulons modifier la couleur d'arrière-plan de la liste, nous perdrons certaines des fonctionnalités du modèle sombre que le système a automatiquement ajoutées pour nous. Vous devez effectuer un travail supplémentaire pour indiquer à l'application la couleur que l'arrière-plan doit afficher en mode noir / blanc.

Mais heureusement, Apple a commencé à essayer de rompre avec le cadre d'interface utilisateur d'origine du système, ce qui nous permet plutôt de personnaliser une partie de l'interface utilisateur. Dans le passé, nous devions implémenter le style du Button ci-dessous, ce qui nécessitait de nombreux ajustements des paramètres de l'UIButton, car l'UIButton par défaut a le texte à gauche et l'image à droite. Maintenant que SwiftUI est séparé du cadre d'interface utilisateur du système, nous pouvons implémenter des styles d'interface utilisateur complexes grâce à des codes extrêmement simples.

Cependant, il y a encore un certain écart entre cela et le fier "précis au pixel" de Flutter. Nous ne pourrons peut-être pas contrôler entièrement tous les détails des contrôles de l'interface utilisateur comme Flutter. Mais tout comme le dessin, vous perdez une certaine liberté en échange d'un développement plus rapide et plus efficace, ce qui reflète exactement le style d'entreprise d'Apple.

Mais l'histoire de SwiftUI multiplateforme est-elle terminée? Je pense que ce n'est que le début. SwiftUI, un cadre d'interface utilisateur purement descriptif qui n'a rien à voir avec les plates-formes et les appareils, est précisément la bonne direction pour les solutions multiplateformes. SwiftUI peut être utilisé pour décrire l'interface utilisateur d'iOS macOS tvOS et même watchOS. Pourquoi ne peut-il pas être utilisé pour décrire Android ou le Web? SwiftUI dispose déjà d'une série de fonctionnalités telles que la mise en page Flex, combiner la liaison de données, le rechargement à chaud, etc. Il suffit de suivre cette idée et d'appliquer le modèle Android ou Web à SwiftUI, et nous pouvons également obtenir une interface utilisateur conforme au langage de conception et aux spécifications de la plate-forme. . Bien sûr, c'est loin d'être aussi simple que je l'ai dit, mais n'oubliez pas que Swift est open source et que le fonctionnement multiplateforme n'est pas un problème. Tant que les conditions existent, tout est possible.

Mais alors, à quoi ressemblera Flutter? Au moins pour le moment, Flutter deviendra toujours l'une des principales solutions multiplateformes pour la plupart des entreprises, et SwiftUI sera utilisé à grande échelle au moins deux à trois ans plus tard.