Boas Práticas de Performance
Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção.
Meça primeiro em Android de gama média: Classe Pixel 6a expõe travamentos, pressão de memória e armazenamento lento que o iPhone Pro esconde - se passar no Android de referência, o iOS geralmente está bem; o inverso é falso.
Defina TTI antes de otimizar: Inicialização fria → aba principal interativa (não apenas esconder splash) - documente o portão em docs/performance-budgets.md com um dispositivo de referência.
Publique orçamentos com proprietários nomeados: MBs de Bundle, segundos de TTI, pisos de FPS e tetos de memória - orçamentos anônimos são ignorados na semana de aperto; veja Regras de Orçamento de Performance.
Analise builds semelhantes a release: Tempos do Expo Go e do cliente de desenvolvimento não são de produção - use variantes preview ou de release da EAS para pontuações de TTI, bundle e Flashlight.
Separe FPS do JS do FPS da UI: JS a 0 significa que toques são enfileirados mesmo quando o FPS da UI parece bom - travamentos de scroll em feeds frequentemente envolvem ambas as threads.
Instrumente TTI com marcas: performance.now() no layout raiz e na tela principal interativa - envie eventos de análise em produção, não apenas console.info.
Mantenha imports mínimos no _layout raiz: SDKs pesados, gráficos e editores pertencem a rotas lazy - cada import raiz está no caminho crítico da inicialização fria.
Aguarde o splash até o primeiro frame significativo: Evite esconder splash → spinner em tela cheia → conteúdo; carregue uma fonte do corpo para TTI, adie o resto.
Adie o trabalho pós-TTI com InteractionManager: Análises, migrações, configuração remota e pré-busca secundária rodam após animações - cancele tarefas ao desmontar.
Analise o tamanho do bundle no CI: react-native-bundle-visualizer em bundles com --dev false - falhe PRs acima do orçamento sem exceção ADR.
Carregue telas pesadas do Expo Router de forma lazy: React.lazy + Suspense para relatórios, mapas e editores - confirme que os blocos do treemap saem do bundle principal.
Use imports estreitos de pacotes: Caminhos por ícone e por função - lodash completo e re-exports de barril dominam treemaps.
Grave o Profiler do React DevTools na navegação: Troca de aba, push/pop de pilha, abertura de modal - corrija contexto instável e screenOptions antes de memoizar leaves.
Estabilize pais de listas antes do memo de linhas: useCallback renderItem, keyExtractor no escopo do módulo, e extraData para seleção - veja Boas Práticas de Listas.
Use FlatList por padrão para feeds crescentes: ScrollView monta cada filho - mude em ~20 linhas ou qualquer paginação; avalie FlashList quando a análise provar o custo de montagem.
Execute amostragem Hermes em cenários quentes: Fling rápido, troca de aba, inicialização fria - exporte .cpuprofile para speedscope quando a CPU do JS disparar sem commits React óbvios.
Pontue o cenário de scroll principal com Flashlight: Pontuação agregada BAM no Android de referência - compare iterações entre releases, não uma demo em um flagship.
Construa uma matriz de dois dispositivos: Gate de gama média + dispositivo de piso de orçamento - pontuações de flagship são apenas informativas.
Limite a memória da lista e pagine com descarte: Arrays data ilimitados são o principal vazamento de RAM da sessão - buffer circular ou itens máximos com cursor persistido.
Limpe listeners em cada useEffect: AppState, NetInfo, addListener de navegação, intervalos - a falta de limpeza duplica o trabalho e retém closures.
Limpe caches no logout: TanStack Query clear(), escopo de usuário MMKV, mapas de imagem globais - cache obsoleto é um defeito de memória e segurança.
Teste de imersão de memória por 10 minutos: Scroll realista, navegação de pilha, background/foreground - vazamentos aparecem tarde, não em testes de fumaça de 30 segundos.
Ajuste windowSize apenas após a higiene: Menor reduz a memória; muito baixo causa linhas em branco - analise com Flashlight antes de alterar os padrões.
Vincule regressões à política de rollback: TTI > 15%, queda de pontuação > 10 pontos, ou estouro de bundle aciona revisão de release - documente em Regras de Orçamento de Performance.
Corrija a medição antes de micro-otimizações: Script de reprodução → commits do DevTools → hotspots do Hermes → treemap do bundle - não useMemo aleatório em chips de apresentação.
Orçamentos escritos + dispositivo Android de referência + builds preview de release + React DevTools Profiler para navegação + amostragem Hermes para hotspots de JS + Flashlight para pontuações de scroll + visualizador Metro no CI.
Boas Práticas de Listas primeiro - chaves, memo, renderItem. Depois React DevTools Profiler. Depois Hermes Sampling Profiler se a CPU do JS permanecer alta.
Não - shell nativo, grafo de módulos e sobrecarga de desenvolvimento diferem. Envie a aprovação de performance apenas em artefatos EAS preview/production.
Regras de Orçamento de Performance possui os limiares, gates de CI e proprietários. Esta seção possui as ferramentas de medição e padrões de correção.
FlatList para feeds curtos e médios com higiene correta. FlashList quando a análise mostra que a reciclagem/custo de montagem domina - benchmark com Flashlight antes de migrar.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026