SwiftUI Series 09｜Introdução à animação SwiftUI: uso de animação e withAnimation

É mais provável que a animação SwiftUI dê às pessoas uma sensação “aparentemente simples”:

• Adicionar .animation
• Ou embale withAnimation

A página começa a se mover.

Mas em projetos reais, o problema mais comum com animação está exatamente aqui:

• Está se mudando para cá também.
• As coisas mudaram para onde não deveriam.
• Não há animação para uma determinada mudança de estado
• A animação fica particularmente estranha quando a lista é atualizada

Isso mostra que muitas vezes não descobrimos primeiro:

Esta animação deveria ser anexada a uma determinada mudança de estado ou deveria apenas encerrar um processo de mudança específico?

1. O núcleo da animação SwiftUI é “permitir que as mudanças de estado sejam interpoladas e apresentadas”

Isto é particularmente importante.

Se você ainda usa ideias do UIKit para entender a animação, é fácil definir como padrão:

• Quero fazer um certo movimento de controle

SwiftUI é mais parecido com fazer:

• Quando o estado muda de A para B, use animação para expressar o processo de mudança

Isso significa que as animações dependem naturalmente de mudanças de estado. Então o que realmente precisa ser julgado é:

• Quais mudanças de estado merecem ser animadas?
• Qual deve ser o tamanho do escopo da animação?

2. A diferença entre .animation e withAnimation não é apenas o método de escrita, mas a granularidade do controle.

Uma compreensão mais prática é:

• .animation é mais como anexar animação a certos tipos de mudanças de estado.
• withAnimation é mais como envolver explicitamente uma modificação de estado específica

Então, ao usar .animation, é mais como dizer:

Esta visualização deve ter reações de animação por padrão para determinadas mudanças de estado.

E withAnimation é mais como dizer:

Vou fazer essa mudança de estado agora e quero que essa mudança seja animada.

Esta distinção é crítica porque afeta diretamente a controlabilidade da animação.

3. Muitas animações de página “se moverão juntas inexplicavelmente”

A razão mais comum é que o âmbito de ação não está fechado.

Por exemplo, originalmente eu queria apenas um bloco expandido para animar, mas o resultado é:

• Outros textos na mesma camada também se movem de acordo
• A mudança de altura do contêiner pai faz com que toda a área seja animada
• Alguns layouts irrelevantes também começaram a transitar

Geralmente, isso ocorre quando a animação está anexada a uma mudança de estado ou hierarquia de visualização muito grande.

Então, quando a animação está bagunçada, o que eu mais volto para verificar é:

• Por quais mudanças esta camada é atualmente responsável?
• A animação está vinculada a uma visualização muito grande?
• A alteração do status afeta muitos resultados de layout ao mesmo tempo?

4. Muitas “animações não são bonitas” porque a modelagem do estado não é clara.

Algumas animações parecem estranhas e são:

• O estado em si não está claramente concebido
• Uma alteração altera muitos valores ao mesmo tempo
• O nível de layout da página está instável

Por exemplo, um clique aciona ao mesmo tempo:

• Expandir
• Troca de redação
• Mudanças de altitude
• Reorganização da lista

Isso acaba parecendo confuso, muitas vezes com muitas mudanças semânticas diferentes espremidas na mesma transição de estado.

5. Quando é mais adequado usar withAnimation

Eu prefiro usá-lo nestes cenários:

• Uma ação do usuário aciona uma mudança de estado explícita
• Eu só quero que a mudança de estado seja animada desta vez
• Quero controlar explicitamente “se esta alteração deve ser movida ou não”

Por exemplo:

• Expandir/Recolher
• Inserir/excluir um bloco parcial
• Mude um determinado estado de apresentação após clicar

A vantagem é que a semântica é mais clara: Saiba que a animação está diretamente ligada a esta ação.

6. Quando é provável que .animation seja mais perigoso?

.animation é particularmente fácil de fazer com que a página “se mova ligeiramente para qualquer lugar” quando o escopo de influência do status não é claramente pensado primeiro.

Especialmente em layouts complexos, se uma mudança de estado afetar:

• Dimensões
• Alinhamento
• redação
• Hierarquia de contêineres

Pendurar a animação diretamente nele pode facilmente causar a transição de toda a área.

Portanto, .animation é mais adequado para aqueles:

• O escopo de influência é relativamente claro
• Semântica simples de mudanças de estado
• Estabilidade da área local

cena.

7. Um julgamento mais prático: esta animação está expressando “uma ação” ou modificando “um tipo de mudança” por padrão?

Se você estiver expressando uma ação explícita:

• Clique para abrir
• fechar
• Inserir
• Excluir

Então geralmente considero withAnimation primeiro.

Se você estiver modificando uma mudança de estado local estável, será mais fácil considerar .animation.

Este julgamento é muito útil porque permite que você não se concentre apenas no nome da API, mas realmente retorne à própria “semântica da animação”.

8. Conclusão: O que realmente precisa ser diferenciado na animação SwiftUI é o limite das mudanças de estado e o limite dos efeitos de animação.

Para resumir, eu diria:

O mais importante sobre a animação SwiftUI é primeiro distinguir: se esta animação está expressando uma ação específica ou se está adicionando um efeito de transição a algum tipo de mudança de estado local.

Uma vez claros esses dois limites, a animação será mais controlável; Se os limites não forem claros, a página pode facilmente “se mover para todos os lugares, mas nenhum lugar está se movendo particularmente certo”.