SwiftUI Series 09｜Introduction à SwiftUI Animation : utilisation de l'animation et de withAnimation

L’animation SwiftUI est plus susceptible de donner aux gens un sentiment « d’apparence simple » :

• Ajouter .animation
• Ou pack withAnimation

La page commence à bouger.

Mais dans les projets réels, le problème le plus courant avec l’animation est exactement là :

• Ça bouge ici aussi.
• Les choses ont bougé là où elles n’auraient pas dû bouger.
• Il n’y a pas d’animation pour un certain changement d’état
• L’animation est particulièrement bizarre lorsque la liste est rafraîchie

Cela montre que bien souvent, nous ne comprenons pas en premier :

Cette animation doit-elle être attachée à un certain changement d’état, ou doit-elle seulement résumer un processus de changement spécifique ?

1. Le cœur de l’animation SwiftUI est de « laisser les changements d’état être interpolés et présentés »

Ceci est particulièrement important.

Si vous utilisez toujours les idées UIKit pour comprendre l’animation, il est facile de choisir par défaut :

• Je veux faire un certain mouvement de contrôle

SwiftUI ressemble plus à faire :

• Lorsque l’état passe de A à B, utilisez l’animation pour exprimer le processus de changement

Cela signifie que les animations dépendent naturellement des changements d’état. Ce qu’il faut vraiment juger, c’est donc :

• Quels changements d’état méritent d’être animés ?
• Quelle doit être la portée de l’animation ?

2. La différence entre .animation et withAnimation n’est pas seulement la méthode d’écriture, mais la granularité du contrôle.

Une compréhension plus pratique est la suivante :

• .animation revient davantage à attacher une animation à certains types de changements d’état.
• withAnimation revient plus à encapsuler explicitement une modification d’état spécifique

Ainsi, lorsque vous utilisez .animation, cela revient plutôt à dire :

Cette vue devrait avoir des réactions d’animation par défaut pour certains changements d’état.

Et withAnimation revient plutôt à dire :

Je vais faire ce changement d’état maintenant, et je souhaite que ce changement soit animé.

Cette distinction est essentielle car elle affecte directement la contrôlabilité de l’animation.

3. De nombreuses animations de pages “se déplaceront ensemble inexplicablement”

La raison la plus courante est que le champ d’action n’est pas fermé.

Par exemple, je voulais à l’origine qu’un bloc étendu soit animé, mais le résultat est :

• Les autres textes sur le même calque se déplacent également en conséquence
• Le changement de hauteur du conteneur parent provoque l’animation de toute la zone
• Certaines mises en page non pertinentes ont également commencé à faire la transition

Cela se produit généralement lorsque l’animation est attachée à un changement d’état ou à une hiérarchie de vues trop grande.

Ainsi, lorsque l’animation est gâchée, ce que je vérifie le plus souvent est :

• De quels changements cette couche est-elle actuellement responsable ?
• L’animation est-elle liée à une vue trop grande ?
• Le changement de statut affecte-t-il trop de résultats de mise en page en même temps ?

4. De nombreuses “animations ne sont pas belles” car la modélisation de l’état n’est pas claire.

Certaines animations semblent gênantes et sont :

• L’État lui-même n’est pas clairement conçu
• Un changement modifie trop de valeurs en même temps
• Le niveau de mise en page est instable

Par exemple, un clic déclenche à la fois :

• Développer
• Changement de rédaction
• Changements d’altitude
• Réarrangement de la liste

Cela finit par paraître compliqué, souvent avec trop de changements sémantiques différents intégrés dans la même transition d’état.

5. Quand est-il plus approprié d’utiliser withAnimation

Je préfère l’utiliser dans ces scénarios :

• Une action utilisateur déclenche un changement d’état explicite
• Je veux juste que le changement d’état soit animé cette fois
• Je souhaite contrôler explicitement “si ce changement doit être déplacé ou non”

Par exemple :

• Développer/Réduire
• Insérer/supprimer un bloc partiel
• Changer un certain état de présentation après avoir cliqué

L’avantage est que la sémantique est plus claire : Sachez que l’animation est directement liée à cette action.

6. Quand le .animation est-il susceptible d’être plus dangereux ?

.animation est particulièrement facile à faire “bouger un peu partout” lorsque la portée de l’influence du statut n’est pas clairement réfléchie au préalable.

Surtout dans les mises en page complexes, si un changement d’état affecte :

-Dimensions

• Alignement
• rédaction
• Hiérarchie des conteneurs

Accrocher l’animation directement dessus peut facilement provoquer une transition de toute la zone.

Le .animation est donc plus adapté à ceux :

• Le champ d’influence est relativement clair
• Sémantique simple des changements d’état
• Stabilité de la zone locale

scène.

7. Un jugement plus pratique : Cette animation exprime-t-elle « une action » ou modifie « un type de changement » par défaut ?

Si vous exprimez une action explicite :

• Cliquez pour ouvrir
• fermer
• Insérer
• Supprimer

Ensuite, je considère généralement withAnimation en premier.

Si vous modifiez un changement d’état local stable, il est plus facile de considérer .animation.

Ce jugement est très utile car il permet de ne pas se concentrer uniquement sur le nom de l’API, mais de véritablement revenir à la « sémantique de l’animation » elle-même.

8. Conclusion : Ce qui doit vraiment être distingué dans l’animation SwiftUI, c’est la limite des changements d’état et la limite des effets d’animation.

Pour le dire sous une forme plus courte, je dirais :

La chose la plus importante à propos de l’animation SwiftUI est d’abord de distinguer : si cette animation exprime une action spécifique ou si elle ajoute un effet de transition à un certain type de changement d’état local.

Une fois ces deux limites claires, l’animation sera plus contrôlable ; Si les limites ne sont pas claires, la page peut facilement devenir « qui bouge partout, mais aucun endroit ne bouge particulièrement à droite ».