Nova Arquitetura do React Native em 2026: Hermes V1, Modo Bridgeless e Perguntas de Entrevista

A Nova Arquitetura do React Native atingiu maturidade plena em 2026. Com o React Native 0.84 entregando o Hermes V1 como motor padrão e a versão 0.85 removendo todo vestígio da bridge legada, o framework agora entrega performance quase nativa sem exigir que os desenvolvedores se preocupem com flags de arquitetura ou camadas de compatibilidade.

O que mudou na pilha arquitetural do React Native

A arquitetura antiga do React Native dependia de uma bridge JSON assíncrona single-thread para transmitir mensagens entre JavaScript e o código nativo. Cada interação passava por esse gargalo: eventos de toque, cálculos de layout, chamadas de módulos. A Nova Arquitetura substitui cada camada desse pipeline por uma alternativa direta e síncrona.

| Camada | Arquitetura Antiga | Nova Arquitetura | |--------|-------------------|------------------| | Motor JS | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderização | Paper (bridge async) | Fabric (síncrono, C++ compartilhado) | | Módulos Nativos | Bridge Modules (serialização JSON) | TurboModules (JSI, chamadas diretas) | | Comunicação | Bridge JSON Async | JSI (JavaScript Interface) | | Inicialização | Init bridge + registro de módulos | Bridgeless (lazy, sob demanda) |

JSI (JavaScript Interface) é a base de tudo. Em vez de serializar cada chamada para JSON e passá-la por uma fila, o JSI expõe objetos host C++ diretamente ao JavaScript. Uma chamada TurboModule que antes exigia codificação JSON, enfileiramento na bridge e decodificação JSON agora se executa como uma invocação direta de função.

Hermes V1: o motor JavaScript padrão

O Hermes V1 tornou-se o motor padrão no React Native 0.84, lançado em fevereiro de 2026. Trata-se de uma reescrita completa do compilador e da VM, não apenas uma atualização incremental das versões anteriores do Hermes.

As melhorias abrangem quatro áreas: um compilador reescrito com novo formato de bytecode, um compilador JIT aprimorado, o coletor de lixo concorrente Hades e melhor suporte aos padrões JavaScript modernos utilizados pelo React 19.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

O Hades, o coletor de lixo concorrente, merece atenção especial. As versões anteriores do Hermes utilizavam um GC stop-the-world que ocasionalmente causava engasgos visíveis durante a rolagem de listas. O Hades executa a coleta de forma concorrente em uma thread de background, mantendo as pausas do GC abaixo de 12 ms. Para aplicações que renderizam listas longas com células complexas, isso elimina a última fonte de queda de frames no lado do JavaScript.

Fabric: renderização e layout síncronos

O Fabric substitui o renderizador Paper por um núcleo C++ compartilhado entre iOS e Android. A diferença fundamental: os cálculos de layout acontecem de forma síncrona na thread JavaScript em vez de assincronamente através da bridge.

Esse modelo síncrono habilita duas capacidades que eram impossíveis com o Paper:

1. Suporte a renderização concorrente: O Fabric se integra com os recursos concorrentes do React 19. Transitions, boundaries de Suspense e useTransition funcionam corretamente porque o Fabric pode interromper e retomar a renderização.

2. Layout C++ direto: O Yoga (motor de layout) executa no mesmo espaço de memória que o runtime JavaScript. Sem overhead de serialização para cálculos de flexbox.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

O hook useTransition neste exemplo demonstra por que o Fabric é essencial. Com o Paper, startTransition não tinha efeito porque o renderizador não podia interromper uma renderização em andamento. A integração do Fabric com o modo concorrente do React 19 permite que atualizações diferidas funcionem conforme projetado, mantendo o campo de texto responsivo enquanto filtra milhares de itens em segundo plano.

TurboModules e JSI: eliminação do overhead de serialização

Os TurboModules substituem o antigo sistema NativeModules. A diferença de performance vem da eliminação total da serialização JSON. Uma chamada via bridge seguia este caminho: objeto JS -> JSON.stringify -> fila da bridge -> JSON.parse -> chamada nativa -> JSON.stringify -> fila da bridge -> JSON.parse -> callback JS. Uma chamada TurboModule é uma invocação direta de função C++ através do JSI.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo')

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

O detalhe fundamental: getDeviceModel(), getOSVersion() e getBatteryLevel() são síncronos. A thread JavaScript chama diretamente o código nativo e recebe o valor de retorno no mesmo tick. Sem promises, sem callbacks, sem ida e volta pela bridge. Isso só é possível através do JSI.

Modo Bridgeless: o que ele remove e por que importa

O Modo Bridgeless, introduzido no React Native 0.73 e tornado padrão na 0.74, completa a migração arquitetural ao eliminar inteiramente a inicialização da bridge. Mesmo após a adoção do Fabric e dos TurboModules, a bridge antiga ainda inicializava no startup para gerenciar emissores de eventos globais, timers e tratamento de erros. O Modo Bridgeless migra esses sistemas remanescentes para implementações baseadas em JSI.

O impacto prático:

• Startup mais rápido: sem overhead de inicialização da bridge. O runtime inicializa apenas o que a aplicação realmente utiliza através de carregamento preguiçoso.
• Menor consumo de memória: sem estruturas de dados da bridge alocadas no startup.
• Tratamento de erros mais limpo: error boundaries e handlers de erro globais funcionam pela nova arquitetura sem fallbacks da bridge.

O React Native 0.82 desabilitou permanentemente a bridge antiga. O React Native 0.85, lançado em abril de 2026, removeu todo o código restante relacionado à bridge da base de código. Não existe caminho de retorno.

Migração em produção: benchmarks de performance reais

As migrações em produção da arquitetura antiga para a Nova Arquitetura mostram melhorias consistentes nas métricas chave:

| Métrica | Arquitetura Antiga | Nova Arquitetura | Melhoria | |---------|-------------------|------------------|----------| | Cold start (TTI) | 1,4s | 0,8s | 43% mais rápido | | Transição de tela | 180ms | 110ms | 39% mais rápido | | Memória base | 89MB | 66MB | 26% menor | | Chamada JS-para-nativo | ~5ms (async) | ~0,1ms (sync) | 40x mais rápido | | Pausa GC máxima | 45ms | 12ms | 73% mais curta | | Scroll FlatList (1000 itens) | Engasgos ocasionais | 60fps fluido | Sem frames perdidos |

A melhoria mais significativa para a qualidade percebida pelo usuário é a redução das pausas do GC. O Hades mantém as pausas de coleta abaixo do orçamento de um frame (16,6 ms a 60 fps), eliminando a fonte mais comum de engasgos visíveis em aplicações React Native complexas.

Compatibilidade do ecossistema em 2026

O ecossistema convergiu completamente para a Nova Arquitetura. O Expo SDK 55 e versões posteriores funcionam exclusivamente com a Nova Arquitetura, sem opção para desativá-la. Pontos chave de compatibilidade:

• React Navigation 7.2+: suporte completo ao Fabric com telas native-stack
• Reanimated 3.5+: backend de animação compartilhado com React Native 0.85
• Gesture Handler 2.16+: reconhecimento de gestos direto baseado em JSI
• Vision Camera 4.0+: processamento de frames via JSI
• Detox: testes E2E compatíveis com a Nova Arquitetura

Para equipes que usam Expo, npx create-expo-app gera um projeto com a Nova Arquitetura habilitada por padrão. Nenhuma configuração necessária.

Perguntas de entrevista: Nova Arquitetura do React Native

Estas perguntas aparecem frequentemente em entrevistas de React Native de nível sênior em 2026. Cada resposta cobre a profundidade esperada em nível staff/sênior.

P1: Explicar a diferença entre a Bridge antiga e o JSI. Por que o JSI permite chamadas nativas síncronas?

A bridge serializava cada mensagem JS-para-nativo como JSON, a colocava em uma fila assíncrona e a desserializava no lado nativo. O JSI (JavaScript Interface) expõe objetos host C++ diretamente na VM JavaScript. Funções nativas registradas através do JSI aparecem como funções JavaScript comuns que executam código nativo inline, sem serialização ou enfileiramento. Chamadas síncronas são possíveis porque o JSI opera no mesmo contexto de thread sem uma fila de mensagens intermediária.

P2: Qual problema o renderizador Fabric resolve que o Paper não conseguia?

O Paper renderizava assincronamente pela bridge, tornando impossível o suporte aos recursos concorrentes do React. Uma chamada a startTransition não tinha efeito porque o Paper não podia interromper uma árvore de renderização em progresso. O Fabric implementa a renderização em código C++ compartilhado, se integra diretamente com o reconciliador do React 19 e suporta renderização concorrente, Suspense e transitions. Os cálculos de layout via Yoga também ocorrem sincronamente no mesmo espaço de memória, eliminando a latência da bridge.

P3: Por que o Hermes é necessário para a Nova Arquitetura? Outro motor poderia ser usado?

A Nova Arquitetura depende do JSI, que requer que o motor JavaScript suporte o registro de objetos host C++. O Hermes foi projetado desde o início com integração JSI. O JavaScriptCore poderia teoricamente suportar JSI, mas a implementação oficial e os testes são construídos em torno do Hermes. O Hermes V1 fornece adicionalmente pré-compilação para bytecode (eliminando parsing em runtime), o GC concorrente Hades (pausas abaixo de 12 ms) e suporte a WebAssembly, nenhum dos quais está disponível pela integração JSC do React Native.

P4: Como os TurboModules diferem da antiga API NativeModules na perspectiva do desenvolvedor?

Os TurboModules requerem uma especificação Codegen (uma interface TypeScript que estende TurboModule) que gera bindings nativos tipados em tempo de build. O antigo NativeModules usava reflexão em runtime sem verificação de tipos. Os TurboModules suportam valores de retorno síncronos (não apenas promises), inicialização lazy (módulos carregam apenas no primeiro acesso) e chamadas JSI diretas sem serialização JSON. O desenvolvedor escreve uma especificação TypeScript, executa o Codegen e implementa a interface nativa gerada.

P5: Descrever o Modo Bridgeless e o que ele remove em comparação com usar apenas Fabric e TurboModules.

Mesmo após a adoção do Fabric e dos TurboModules, a bridge antiga ainda inicializava no startup para gerenciar emissores de eventos globais, timers, tratamento de erros e outra infraestrutura de runtime. O Modo Bridgeless substitui esses sistemas residuais dependentes da bridge por implementações baseadas em JSI. Ele elimina o overhead de inicialização da bridge, reduz o consumo de memória base e garante que todo o runtime opere via JSI. Desde o React Native 0.85, o Modo Bridgeless é o único modo operacional.

Praticar essas perguntas com exemplos de código funcionais fortalece tanto a compreensão conceitual quanto a memória prática. O módulo Nova Arquitetura do React Native do SharpSkill cobre mais de 40 perguntas adicionais sobre Fabric, TurboModules, internos do Hermes e estratégias de migração.

Conclusão

• O Hermes V1 entrega cold starts 29% mais rápidos, 38% menos uso de memória e pausas de GC abaixo de 12 ms desde o React Native 0.84+
• O Fabric habilita os recursos concorrentes do React 19 (transitions, Suspense) que o Paper nunca pôde suportar
• Os TurboModules eliminam a serialização JSON, tornando as chamadas JS-para-nativo 40x mais rápidas através de invocação direta via JSI
• O Modo Bridgeless remove as últimas dependências da bridge; o React Native 0.85 não contém nenhum código bridge restante
• O ecossistema é totalmente compatível: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ e todas as bibliotecas principais suportam exclusivamente a Nova Arquitetura
• A preparação para entrevistas deve focar na mecânica do JSI, nas diferenças entre Fabric e Paper, no fluxo de trabalho Codegen dos TurboModules e nas mudanças de runtime do Modo Bridgeless