Middle React Native Developer — Perguntas de entrevista React Native

Explique o que realmente acontece quando o JS chama um método nativo — arquitetura antiga vs. nova.

No bridge antigo, a chamada é serializada para JSON, entra numa fila, é agrupada em lote, enviada de forma assíncrona para o lado nativo, executada, e o resultado é serializado de volta — cada salto custa tempo, e nada é síncrono. Com o JSI, um TurboModule é um objeto C++ real ao qual o JS mantém uma referência direta; chamar um método passa por um binding em C++ sem serialização JSON e sem fila, e pode ser síncrono quando é isso que se precisa. O custo é a complexidade — escrever um TurboModule direito significa lidar com codegen e C++, enquanto um módulo no estilo bridge antigo era mais parecido com código cola comum próximo do JS.

Uma `FlatList` com algumas centenas de linhas está travando no scroll — como você aborda isso?

Primeiro faça o profiling — o profiler do Flipper/React DevTools ou o perf monitor embutido mostra se o custo está no JS (re-renders, renderItem pesado) ou na thread nativa (layout, imagens). Depois verifique o básico: keyExtractor estável, React.memo na linha para que uma mudança de state do pai não se propague para cada linha, e nada de funções arrow ou literais de objeto inline passados como props da linha. Se o thrashing de layout é o problema, getItemLayout evita uma passagem de medição por item, e se a própria lista é o gargalo em grande escala, trocar para FlashList costuma ser o ajuste mais pragmático do que continuar afinando o FlatList na mão.

Uma feature precisa de uma capacidade que o React Native não expõe — como você chega ao código nativo, e o que precisa ser duplicado?

Você escreve um módulo nativo — uma implementação em Swift/Objective-C para iOS e outra em Kotlin/Java para Android — expondo a mesma assinatura de método dos dois lados, porque o JS chama uma única API voltada para JS, que precisa se resolver numa implementação real na plataforma em que estiver rodando. Pular uma plataforma significa que o app trava ou fica silenciosamente sem efeito ali, então as duas implementações precisam genuinamente fazer a mesma coisa, não só compartilhar o nome. Testar significa rodar num dispositivo real ou simulador de cada plataforma, não só confiar que "compilou".

Como você lida com deep links de forma confiável, incluindo a partir de um cold start?

Registre o esquema de URL ou o universal link/app link na config nativa (Info.plist / AndroidManifest.xml) e na config linking do navigator, mapeando padrões de URL para telas e parâmetros. A parte difícil é o cold start — se o app não estava rodando, Linking.getInitialURL() precisa ser checado ao iniciar e usado para definir o estado inicial de navegação, porque o listener de evento do Linking sozinho só captura links que chegam enquanto o app já está aberto. Universal links também precisam dos arquivos associated-domains / assetlinks.json hospedados no seu domínio, para que o SO confie que o app deve tratar aquela URL em vez de abrir um navegador.

Qual é a diferença entre uma atualização OTA e um release de store, e quando usar cada uma?

Uma atualização OTA (CodePush, Expo Updates) envia um novo bundle JS direto para os apps instalados, sem revisão da store, e os usuários a recebem no próximo início do app ou numa checagem em background — boa para bugfixes só de JS e mudanças de conteúdo. Qualquer coisa que toque código nativo — um novo módulo nativo, uma permissão adicionada, um bump de dependência nativa — nem está no bundle JS, então OTA não consegue entregar isso; precisa de um build de verdade e um envio à store. As diretrizes da Apple restringem explicitamente que OTA não pode "mudar significativamente o propósito principal do app", então um time que depende de OTA além de fixes rápidos arrisca a conta na store, não só a atualização.