Arquitetura Antiga: O que é a Bridge?
Para entendermos a Bridge, precisamos entender como funciona uma aplicação React Native, até porque, sem entender isso, não é possível entender a Bridge.
O que acontece? Temos um aplicativo desenvolvido com RN, dentro do repositório, temos vários arquivos JS (contexts, components, routes etc). Assim como ocorre na web, esses arquivos são reunidos em um único bundle. No React Native, é semelhante, no final temos um bundle, mas diferente da web que utilizamos o WebPack para isso, no React Native utilizamos uma ferramenta chamada Metro.
Claro, diferente da web, em que temos um bundle JS com tudo (html, css, lógica etc), em aplicativos mobile com RN isso não ocorre.
O motivo é que aplicações em RN renderizam a interface nativamente (sim, no final vira UIView, AndroidView e outros componentes nativos). Logo, não temos apenas o JS, vamos ter implementações nativas e consequentemente códigos nativos. Então, iremos ter código JS e código nativo (Objective-C, Java ou Kotlin, dependendo da versão, e Swift).
Logo, temos uma JavaScript VM (é uma engine responsável por interpretar nosso JS, semelhante ao motor V8 do Node.js). Antes, era o JavaScript Core (mesmo motor do Safari). Mas, hoje, nas últimas versões foi criado um novo motor: Hermes (específico para React Native, mais leve, mais performático).
Ok, agora você entendeu coisas importantes:
- Metro: bundler do React Native
- Hermes: motor JavaScript otimizado para RN
- Renderização nativa: a UI é renderizada com componentes nativos
Agora, sabendo que de um lado temos Hermes (motor JS) e do outro lado temos o código nativo (Java/Kotlin e Objective-C/Swift), cabe a dúvida: o que cada um fica responsável?
A camada de JavaScript fica responsável pela lógica, ou seja, funções, hooks, renderização, tudo que a gente escreve fica dentro do JavaScript.
Já o lado nativo: responsável por renderizar e exibir a interface do usuário. Ou seja, montar os elementos na tela (UIView, AndroidView etc), isso é renderizado e executado pelo lado nativo. Eventos, scrolls, etc.
Agora, um questionamento: como o lado nativo, que é feito em linguagem totalmente diferente, vai se comunicar com JavaScript? Como o Hermes se comunica com a parte responsável por gerar a interface (camada nativa)?
Isso só é possível por causa de um carinha chamado Bridge (ponte, em português). Ou seja, a Bridge faz a ponte entre o JS e o Nativo.
Em termos simples, a Bridge faz a comunicação entre o lado nativo e o JavaScript (e vice-versa).
Agora, outro questionamento: como essa Bridge é? Em qual linguagem é desenvolvida? É baixo nível, né?
A verdade é que ela é tão simples quanto parece. A Bridge realiza a comunicação de forma assíncrona, enfileirando mensagens entre threads, e os dados são serializados em JSON para padronizar a troca.
Por exemplo: pressionei um button (camada nativa) -> enviado o evento de toque para o JS. Como é enviado? Através da Bridge. E em qual formato chega para o JavaScript? Em JSON. Simples. E vice-versa (o caminho contrário).
Resumindo, essa é a arquitetura:
- JavaScript Thread: executa o código JS, incluindo lógica, renderização e interações.
- Bridge (assíncrona): realiza a comunicação entre o código JS e o código nativo usando JSON.
- Main/UI Thread (Nativa): responsável por atualizar a interface do usuário e lidar com eventos de toque e animações.
- Shadow Thread (Yoga): executa cálculos de layout usando a Shadow Tree, uma representação virtual da UI. A biblioteca Yoga, escrita em C++, é usada para calcular o layout baseado em Flexbox.
Nova Arquitetura do React Native: Conheça o Fabric
Nos últimos anos, o time do React Native tem trabalhado intensamente para resolver uma dor de longa data na plataforma: a performance em cenários complexos. Foi assim que surgiu o Fabric, a nova arquitetura que promete mais fluidez, menos gargalos e uma comunicação mais eficiente entre o JavaScript e os módulos nativos.
Por que mudar?
A arquitetura anterior do React Native se baseava em uma ponte chamada Bridge (conforme explicamos anteriormente), que fazia a comunicação entre o código JavaScript e o lado nativo do sistema (Android/iOS).
Esse modelo funcionava bem - e ainda funciona - na maioria dos casos. Porém, em situações específicas, ele apresentava sérios gargalos de performance.
A causa? A Bridge era assíncrona e precisava serializar e desserializar objetos JSON para trafegar dados entre o JS e o nativo. Isso se tornava um problema em cenários como:
- Listas grandes (ex: FlatLists com muitos itens)
- Animações pesadas
- Atualizações frequentes na interface
Nesses casos, o app podia "engasgar" - e isso tem um nome carinhoso dentro do time do RN: "gagueira".
Na arquitetura tradicional, o React Native operava com três threads principais:
- JavaScript Thread: executa a lógica da aplicação.
- UI Thread: responsável pela renderização dos elementos visuais.
- Module Thread: usada para comunicação com os módulos nativos.
O problema é que, como a ponte precisava trafegar dados entre essas camadas de forma assíncrona e serializada, a UI Thread acabava esperando demais e apresentava lentidão perceptível pelo usuário.
O efeito visual? Aquela sensação de que a interface tenta renderizar e… trava por um instante: "ga-ga-ga… renderizou".
O que é o Fabric?
O Fabric é a nova arquitetura que substitui o uso da Bridge por um novo modelo baseado no JSI (JavaScript Interface).
- Adeus Bridge: não há mais a necessidade de enviar JSONs para lá e para cá.
- Olá JSI: uma interface em C++ que permite ao JavaScript acessar diretamente os módulos nativos - de forma síncrona.
- Comunicação mais direta: isso elimina a "gagueira" e melhora a performance em UIs pesadas.
A nova arquitetura é baseada em três tecnologias centrais:
JSI (JavaScript Interface)
Uma camada em C++ que permite chamadas diretas entre o JavaScript e o código nativo, eliminando a dependência da Bridge.
Codegen
Gera automaticamente código nativo (Java, Objective-C, C++) e código JavaScript com base em interfaces declaradas em arquivos TypeScript/Flow.
TurboModules
Substituem os NativeModules antigos. Agora escritos em C++ e acessíveis via JSI, são carregados sob demanda (lazy loading) e possuem performance muito superior.
Fabric
Um novo sistema de renderização, também em C++, que substitui a árvore de layout anterior. Trabalha de forma mais eficiente com a reconciliação do React, proporcionando UI renderizada com menor latência.
Uma jornada de 6 anos
O desenvolvimento do Fabric começou em 2018. Durante esse tempo, ele foi sendo testado, validado e refinado. Chegou pela primeira vez como opcional na versão 0.68 do React Native.
Somente em 2024, ele passou a ser habilitado por padrão ao criar um novo projeto.
Todo app precisa disso?
Não. A verdade é que a arquitetura antiga (com Bridge) ainda funciona perfeitamente em 99% dos casos.
O Fabric é mais útil em cenários específicos, como:
- Apps com interfaces ricas e animações complexas
- Uso intenso de FlatLists
- Manipulação de grandes volumes de dados na interface
Se seu app é simples, provavelmente você nem perceberá diferença. Mas para apps mais robustos, o Fabric pode representar uma melhoria significativa em performance e fluidez.
Comparativo visual das arquiteturas
Para facilitar o entendimento, veja abaixo as animações que mostram o fluxo de comunicação em cada arquitetura:
Arquitetura antiga (Bridge)
Nova arquitetura (JSI/Fabric)
Considerações finais
O Fabric é um passo importante na evolução do React Native. Ele traz uma arquitetura mais moderna, baseada em C++, e resolve problemas históricos relacionados à renderização e comunicação com o nativo.
Com ele, o React Native fica ainda mais próximo de entregar uma performance realmente nativa - sem abrir mão da produtividade do ecossistema JavaScript.
Agora que ele já vem ativado por padrão, vale a pena entender como funciona e explorar seus benefícios, principalmente se estiver começando um projeto novo ou lidando com interfaces mais exigentes.