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

> A Nova Arquitetura do React Native é agora o padrão em 2026 com Hermes V1, Modo Bridgeless, TurboModules e Fabric. Análise aprofundada dos ganhos de performance, padrões de migração e perguntas essenciais de entrevista.

- Published: 2026-05-09
- Updated: 2026-05-09
- Author: SharpSkill
- Tags: react-native, hermes, new-architecture, bridgeless, turbomodules, fabric, mobile-development, deep-dive
- Reading time: 10 min

---

A Nova Arquitetura do React Native atingiu maturidade plena em 2026. Com o React Native 0.84 entregando o [Hermes V1](https://reactnative.dev/blog/2026/02/11/react-native-0.84) 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.

> **Ponto Chave**
>
> A Nova Arquitetura (Fabric + TurboModules + Modo Bridgeless + Hermes V1) não é mais opcional. Todo projeto React Native 0.84+ a utiliza por padrão. O código relacionado à bridge legada deve ser removido das bases de código existentes.

## 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](https://reactnative.dev/blog/2026/02/11/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.

```javascript
// HermesV1Benchmarks.js
// 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.

> **Suporte a WebAssembly**
>
> O Hermes V1 também introduz suporte a WebAssembly no React Native 0.84. Código de alta performance escrito em Rust, C ou C++ pode ser compilado para WASM e executado dentro da aplicação, possibilitando inferência de IA on-device, computação numérica pesada ou reutilização de bibliotecas nativas existentes sem escrever bindings específicos de plataforma.

## 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.

```typescript
// FabricConcurrentExample.tsx
// 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.

```typescript
// NativeDeviceInfo.ts
// 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')
```

```kotlin
// DeviceInfoModule.kt
// 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](https://docs.expo.dev/guides/new-architecture/) 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.

> **Requisito de Migração**
>
> Aplicações ainda no React Native 0.75 ou anterior precisam migrar. A bridge antiga está permanentemente removida na 0.82+. Bibliotecas de terceiros que dependem da bridge (aquelas que usam `NativeModules` diretamente sem especificações TurboModule) precisam de atualizações. O [React Native Upgrade Helper](https://react-native-community.github.io/upgrade-helper/) e o [guia de migração oficial](https://reactnative.dev/architecture/landing-page) cobrem o processo passo a passo.

## 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](/technologies/react-native/interview-questions/rn-new-architecture) 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/pt/blog/react-native/react-native-new-architecture-hermes-v1-bridgeless