Melhor Formula Para Rn

Como decidir quando useMemo e useCallback valem a pena no React Native

A gente ouve muita coisa sobre performance em RN, mas a maioria dos artigos repete o mesmo conselho sem mostrar como aplicar na prática. Eu passei seis meses tentando otimizar um app de logística com mais de quarenta telas e cerca de trezentos mil usuários ativos por mês. O problema era simples: algumas listas de entregas travavam em dispositivos Android mais antigos enquanto o resto do app rodava liso. A causa raiz não era o JavaScript principal — era re-renderização desnecessária de componentes que nem sabiam que tinham mudado. Antes de entrar nas fórmulas, é preciso entender o que realmente acontece noRN quando um componente é renderizado. O bridge entre JavaScript e native não é de graça. Cada call de NativeModules tem overhead. Se você manda atualizar um FlatList duas vezes quando só precisa uma, o custo já está aí. O primeiro erro que cometi foi achar que bastava envolver tudo em React.memo e resolver. Quase quebrei a fila de dados de um modal de configuração porque o memo estava escondendo uma dependência de props que eu não via. Aprenda isso antes de seguir qualquer receita pronta: memoizaçãotrabalha, mas só quando você sabe exatamente o quê e por quê.

A melhor formula para rn que realmente funciona na prática

A regra básica é simples. Usememoquando você calcula algo pesado a partir de props ou state, e esse cálculo não precisa rodar em cada render. Usecallbackquando você passa funções como props para filhos memoizados ou como dependência de outros hooks. E useReact.menopara evitar re-renderizações inteiras de subárvores que não mudaram. Aí vem a parte chata: essas decisões não são binárias. Elas dependem do seu fluxo de dados. No meu projeto, eu criei uma planilha simples. Cada componente da tela recebia uma nota de um a cinco baseada em três coisas: frequência de renderização, custo do cálculo interno e valor das dependências. Se o componente renderizava mais de dez vezes por minuto e tinha um mapeamento de array grande sem memoização, eu entrava com useCallback. Isso me deu uma visão concreta de onde estavam os gargalos, em vez de adivinhar. O que pouca gente fala é que useMemo e useCallback têm custo próprio. Memória a mais, closures adicionais, referência instável se as dependências mudarem a cada render. Eu vi gente colocar useMemoem cálculos de uma soma de dois números só porque achou que era boa prática. Virou pior. O resultado era mais CPU gastando com comparação de referências do que ganhando com cache. A linha entre otimização e overengineeringé tênue. Meus critérios foram: sempre que o cálculo leva mais de dez milissegundos no device mais lento que eu testei, ou quando o resultado é usado como dependência crítica de outro hook, aí eu memoizo.

Outro ponto que eu aprendi na marra foi com FlatList. Você pode memoizar itens individuais com React.memo, mas se o renderItemreceber uma função nova a cada render da lista, o memo perde o efeito. A solução foi usaruseCallbackno próprio renderItem e passar esse callback como propriedade estabilizada. Eu fiz um teste com mil itens na lista. Antes, a animação de scroll travava em devices de entrada depois de vinte linhas de rolagem. Depois de estabilizar a função, rolou suave em todos os três dispositivos que eu tinha. O ganho real foi entre quinze e vinte por cento de FPS médio na média dos testes, mas o importante era a consistência. Tem situação em que memoização não ajuda. Se o componente recebe props que mudam todo frame — como coordenadas de swipe, animações ou estado global que dispara frequentemente —, React.memo só aumenta o trabalho de comparação sem evitar renderizações. Nesses casos, vale mais a pena repensar a arquitetura. Eu tive um caso assim com um overlay de mapa. O state de posição atualizava em cada movimento do sensor, e todo componente filho era obrigado a renderizar. Memoizar não resolvia. A solução foi separar a lógica de posicionamento do componente de exibição, criando um wrapper que só passava a prop que precisava mudar.

Quando ignorar as regras e simplesmente deixar o RN fazer o que ele faz

Não adianta transformar tudo em memo. O React Native já otimiza renders de forma razoável. A maioria dos apps perde tempo com re-renderizações em partes irrelevantes da árvore. Foque nos pontos quentes. Se seu app tem trinta componentes e apenas três causam problemas de performance, gaste energia nesses três. Teste com Flipper ou React DevTools antes de otimizar. Eu vi gente memoizar dezenas de componentes e ainda assim o app continuar lento. O problema real era um contexto global sendo consumido por muitos componentes ao mesmo tempo. Uma técnica que eu uso agora é deixar o componente renderizar normalmente por padrão e só memoizar quando o profiling mostra um ganho real. Eu medi o tempo de render com um cronômetro simples em dispositivos de baixo custo. Se a diferença entre memoizado e não memoizado era menor que cinco milissegundos, eu não memoizava. O código ficava mais limpo, mais fácil de manter, e o performance não sofreria. Às vezes, a melhor decisão é não decidir nada. O que eu posso afirmar com certeza é que a abordagem mais eficaz depende do seu contexto. Em apps com listas enormes e dados dinâmicos, memoização estratégica faz diferença. Em apps com interfaces estáticas e poucos estados, otimizações prematuras só atrapalham. Eu recomendo começar pelo profiling, identificar os gargalos reais, e só então aplicar memoização nos pontos que realmente precisam. Depois disso, teste em dispositivos de entrada. A maioria dos problemas de performance em RN aparece lá, não em emuladores modernos.

Se você tiver dúvidas específicas sobre como aplicar essas técnicas no seu projeto, comenta aí. Eu já passei por vários cenários parecidos e posso ajudar a ajustar a abordagem certa para o seu caso.