Auditoria de Performance do SwiftUI

Início Rápido

Use esta habilidade para diagnosticar problemas de performance do SwiftUI, começando pelo código e, em seguida, solicitando evidências de profiling quando a revisão de código sozinha não puder explicar os sintomas.

Quando Usar

• Quando o usuário relata renderização lenta, rolagem travada, "layout thrash" (recalculo excessivo de layout) ou alto uso de CPU no SwiftUI.
• Quando você precisa de uma auditoria focada no código, mais orientação sobre o Instruments caso evidências de profiling sejam necessárias.

Fluxo de Trabalho

1. Classifique o sintoma: renderização lenta, rolagem travada, alto uso de CPU, crescimento de memória, travamentos ou atualizações excessivas de views.
2. Se o código estiver disponível, comece com uma revisão focada no código usando references/code-smells.md.
3. Se o código não estiver disponível, peça a menor parte útil: view alvo, fluxo de dados, passos de reprodução e target de deployment.
4. Se a revisão de código for inconclusiva ou evidências de runtime forem necessárias, guie o usuário através do profiling com references/profiling-intake.md.
5. Resuma as causas prováveis, evidências, remediação e passos de validação usando references/report-template.md.

1. Coleta de Informações

Colete:

• Código da view ou funcionalidade alvo.
• Sintomas e passos exatos para reproduzir.
• Fluxo de dados: @State, @Binding, dependências de ambiente e modelos observáveis.
• Se o problema aparece no dispositivo ou simulador, e se foi observado em Debug ou Release.

Peça ao usuário para classificar o problema, se possível:

• Pico de CPU ou consumo de bateria
• Rolagem travada ou frames perdidos
• Alta pressão de memória ou de imagem
• Travamentos ou interações sem resposta
• Atualizações de view excessivas ou inesperadamente amplas

Para a lista completa de verificação de coleta de profiling, leia references/profiling-intake.md.

2. Revisão Focada no Código

Concentre-se em:

• Tempestades de invalidação de observações amplas ou leituras de ambiente.
• Identidade instável em listas e ForEach.
• Trabalho derivado pesado em body ou view builders.
• "Layout thrash" de hierarquias complexas, GeometryReader ou cadeias de preferências.
• Grande trabalho de decodificação ou redimensionamento de imagem na thread principal.
• Trabalho de animação ou transição aplicado de forma muito ampla.

Use references/code-smells.md para o catálogo detalhado de "cheiros" (problemas comuns) e orientação para correção.

Forneça:

• Causas raiz prováveis com referências de código.
• Sugestões de correções e refatorações.
• Se necessário, uma sugestão de reprodução mínima ou instrumentação.

3. Guie o Usuário para o Profiling

Se a revisão de código não explicar o problema, peça evidências de runtime:

• Um export de trace ou screenshots da timeline do SwiftUI e da árvore de chamadas do Time Profiler.
• Configuração do dispositivo/OS/build.
• A interação exata que está sendo perfilada.
• Métricas antes/depois se o usuário estiver comparando uma mudança.

Use references/profiling-intake.md para a lista de verificação exata e passos de coleta.

4. Analisar e Diagnosticar

• Mapeie as evidências para a categoria mais provável: invalidação, "churn" de identidade, "layout thrash", trabalho na thread principal, custo de imagem ou custo de animação.
• Priorize problemas pelo impacto, não pela facilidade de explicá-los.
• Distinga suspeitas em nível de código de evidências comprovadas por trace.
• Indique quando o profiling ainda é insuficiente e que evidências adicionais reduziriam a incerteza.

5. Remediar

Aplique correções direcionadas:

• Restrinja o escopo do estado e reduza a propagação ampla de observações.
• Estabilize identidades para ForEach e listas.
• Mova trabalho pesado para fora de body para estados derivados atualizados a partir de inputs, pré-computação na camada de modelo, helpers com memoização ou pré-processamento em background. Use @State apenas para estado de propriedade da view, não como um cache ad hoc para computação arbitrária.
• Use equatable() apenas quando a igualdade for mais barata do que recomputar a subárvore e os inputs forem verdadeiramente semânticos em valor.
• Redimensione imagens antes de renderizar.
• Reduza a complexidade do layout ou use dimensionamento fixo onde for possível.

Use references/code-smells.md para exemplos, orientação sobre propagação específica de Observation e padrões de remediação.

6. Verificar

Peça ao usuário para executar novamente a mesma captura e comparar com as métricas de base. Resuma a diferença (CPU, quedas de frames, pico de memória) se fornecida.

Saídas

Forneça:

• Uma tabela curta de métricas (antes/depois, se disponível).
• Principais problemas (ordenados por impacto).
• Correções propostas com esforço estimado.

Use references/report-template.md ao formatar a auditoria final.

Referências

• Lista de verificação de coleta e informações de profiling: references/profiling-intake.md
• Cheiros de código comuns e padrões de remediação: references/code-smells.md
• Modelo de saída de auditoria: references/report-template.md
• Adicione documentação da Apple e recursos do WWDC sob references/ conforme forem fornecidos pelo usuário.

…