A COMPARAÇÃO DE PERFORMANCE ENTRE REACT NATIVE E FLUTTER NO DESENVOLVIMENTO DE APLICATIVOS MÓVEIS

PERFORMANCE COMPARISON BETWEEN REACT NATIVE AND FLUTTER IN MOBILE APPLICATION DEVELOPMENT

REGISTRO DOI: 10.69849/revistaft/cl10202510211202


Darlan Kennedy Oliveira dos Santos1
Orientador: Wagner Palheta2


RESUMO

O presente trabalho vem abordar a comparação de performance entre React Native e Flutter no desenvolvimento de Aplicativos Móveis. O desenvolvimento de aplicativos móveis multiplataforma tem ganhado destaque devido à necessidade de soluções ágeis, eficientes e compatíveis com diferentes sistemas operacionais. Nesse contexto, frameworks como React Native e Flutter se consolidaram como alternativas relevantes, cada qual apresentando vantagens e limitações técnicas em termos de desempenho, usabilidade e escalabilidade. O principal objetivo deste trabalho é comparar a performance entre React Native e Flutter no desenvolvimento de aplicativos móveis, buscando identificar suas diferenças mais significativas e implicações práticas para desenvolvedores e empresas. A metodologia adotada consiste em uma revisão de literatura, com base em artigos científicos, livros e estudos técnicos que abordam métricas de eficiência, consumo de recursos, tempo de execução e experiência do usuário. Conclui-se que o Flutter, por compilar diretamente em código nativo e oferecer uma arquitetura mais unificada, tende a apresentar melhor performance em cenários que exigem maior responsividade e velocidade de execução. Já o React Native, embora apresente menor desempenho em alguns casos, destaca-se pela ampla comunidade, integração com bibliotecas externas e curva de aprendizado mais acessível para quem já domina JavaScript. Assim, ambos os frameworks demonstram potencial de aplicação, cabendo a escolha ao contexto do projeto e às necessidades específicas de cada solução.

Palavras-chave: React Native. Flutter. Aplicativos Móveis. Performance. Desenvolvimento Multiplataforma.

ABSTRACT

This paper addresses the performance comparison between React Native and Flutter in mobile application development. Cross-platform mobile application development has gained prominence due to the need for agile, efficient, and cross-platform solutions. In this context, frameworks such as React Native and Flutter have established themselves as relevant alternatives, each offering technical advantages and limitations in terms of performance, usability, and scalability. The main objective of this paper is to compare the performance of React Native and Flutter in mobile application development, seeking to identify their most significant differences and practical implications for developers and companies. The methodology adopted consists of a literature review, based on scientific articles, books, and technical studies that address metrics of efficiency, resource consumption, execution time, and user experience. The conclusion is that Flutter, because it compiles directly into native code and offers a more unified architecture, tends to perform better in scenarios that require greater responsiveness and execution speed. React Native, while offering lower performance in some cases, stands out for its broad community, integration with external libraries, and a more accessible learning curve for those already proficient in JavaScript. Thus, both frameworks demonstrate application potential, with the choice being determined by the project context and the specific needs of each solution.

Keywords: React Native. Flutter. Mobile Apps. Performance. Cross-platform Development.

1. INTRODUÇÃO

O avanço das tecnologias digitais e a popularização dos dispositivos móveis consolidaram os aplicativos como parte essencial do cotidiano, impactando áreas como comunicação, comércio, educação e entretenimento. Nesse cenário, o desenvolvimento de soluções multiplataforma tornou-se uma demanda crescente, visto que empresas e desenvolvedores buscam alternativas para reduzir custos, otimizar prazos e atender simultaneamente usuários de sistemas operacionais distintos, como Android e IOS. Assim, ferramentas como React Native e Flutter emergiram como opções de destaque no mercado (Beneveduto et al, 2022).

O React Native, desenvolvido pelo Facebook em 2015, possibilita a criação de aplicativos utilizando JavaScript e a reutilização de componentes, oferecendo integração com bibliotecas já consolidadas e ampla comunidade de suporte. O Flutter, lançado pelo Google em 2017, utiliza a linguagem Dart e apresenta uma arquitetura mais unificada, compilando diretamente em código nativo, o que promete maior desempenho e fluidez. Ambos os frameworks ganharam popularidade e se tornaram objeto de estudo em pesquisas acadêmicas e práticas profissionais (Lecheta, 2022).

A relevância do tema justifica-se pela crescente competitividade do mercado de aplicativos móveis, no qual a performance influencia diretamente a experiência do usuário, a fidelização e até mesmo a viabilidade comercial do produto. Para desenvolvedores e empresas, compreender as diferenças de desempenho entre React Native e Flutter é fundamental para embasar escolhas estratégicas, evitando retrabalho, desperdício de recursos e falhas de usabilidade.

Emerge a problemática central deste estudo: Qual framework, entre React Native e Flutter, apresenta melhor performance no desenvolvimento de aplicativos móveis e em quais aspectos essa diferença se torna mais significativa? A resposta a essa questão contribui para o avanço do conhecimento acadêmico e oferece subsídios práticos a profissionais da área.

O principal objetivo deste trabalho é comparar a performance entre React Native e Flutter no desenvolvimento de aplicativos móveis, analisando métricas de eficiência, tempo de execução, consumo de recursos e impacto na experiência do usuário. Para tanto, a metodologia adotada será a revisão de literatura, pautada em artigos científicos, relatórios técnicos, estudos de caso e materiais de referência que tratam das características e resultados obtidos por cada framework em diferentes contextos.

Ao investigar a performance entre React Native e Flutter, este trabalho propõe-se a contribuir tanto para o meio acadêmico quanto para o mercado profissional, oferecendo elementos comparativos que auxiliem na tomada de decisão sobre o uso das ferramentas. A análise fundamentada em revisão de literatura permitirá evidenciar não apenas os pontos fortes de cada framework, mas também suas limitações, delineando um panorama crítico e atualizado sobre o desenvolvimento multiplataforma. A partir desse ponto, inicia-se o desenvolvimento do estudo, voltado à exposição teórica e à comparação dos resultados discutidos por diferentes autores.

2. DESENVOLVIMENTO NATIVO

Um aplicativo é dito nativo quando ele é desenvolvido especificamente para uma única plataforma, utilizando seu próprio kit de desenvolvimento de software (SDK). Aplicativos desenvolvidos dessa forma ficam linkados ao sistema operacional e não podem ser reaproveitados em diferentes ambientes. Os dois maiores sistemas operacionais de dispositivos móveis, atualmente, possuem ferramentas próprias especializadas para o desenvolvimento nativo. Utilizando o SDK nativo, o desenvolvedor possui total acesso a todas as funcionalidades do dispositivo, como câmera, sensores, GPS e outros, sem nenhuma restrição. Além disso, um aplicativo nativo é capaz de aproveitar melhor os recursos, como bateria, memória e CPU, usufruindo ao máximo os recursos do dispositivo (Matilda, 2023).

Cada plataforma possui suas próprias especificidades para desenvolver um aplicativo. O desenvolvedor deve desenvolver o aplicativo em uma linguagem específica, utilizando o conjunto de ferramentas disponibilizadas pela plataforma. O código, então, será compilado para a linguagem de máquina reconhecida pelo sistema em questão. Finalmente, o aplicativo pode ser distribuído nas respectivas lojas virtuais. A tabela 1 indica as especificidades das plataformas Android e IOS (Lecheta, 2022).

Tabela 1- Especificidades de desenvolvimento para as plataformas Android e IOS

Fonte: Próprio autor, 2025.

Com o mercado de mobile crescendo gradativamente nos últimos anos, a demanda de aplicativos para dispositivos móveis aumentou consideravelmente. A fim de evitar a replicação de código e facilitar o desenvolvimento mobile, ao longo dos anos surgiram diferentes formas de desenvolver um aplicativo para várias plataformas sem escrever múltiplos códigos. Competindo com os aplicativos nativos, esses são chamados de aplicativos multiplataforma. Existem diferentes formas de desenvolver aplicativos multiplataformas, que podem ser classificadas quanto ao procedimento de desenvolvimento (Neves e Junior, 2020).

2.1 DESENVOLVIMENTO WEB

Atualmente, a Web está desenvolvida o suficiente para suportar diferentes resoluções de tela. Assim, um simples site, desenvolvido com HTML, CSS e JavaScript, é capaz de ser acessado por qualquer dispositivo móvel. Existem, ainda, múltiplas ferramentas para auxiliar no desenvolvimento de um aplicativo Web, como Bootstrap, para garantir melhor responsividade e até frameworks mais robustas, como Angular (Matilda, 2023).

Nesse caso, o aplicativo roda integralmente dentro do browser do dispositivo, sem necessidade de instalação. Portanto, qualquer atualização necessária no aplicativo será feita diretamente no servidor, sem a necessidade de atualizações locais. Como o aplicativo não pode ser instalado, não é possível disponibilizá-lo nas respectivas lojas virtuais dos sistemas em questão. O acesso, porém, é bastante trivial, por meio de uma URL. Devido ao amplo uso da Web no mercado e sua padronização, o código pode ser reutilizado em diferentes plataformas (Beneveduto et al, 2022).

Apesar das facilidades descritas acima, o desenvolvimento web também possui grandes desvantagens. Obviamente, o aplicativo requer conexão com a Internet para funcionar corretamente. Conexões ruins podem afetar drasticamente seu desempenho. O único componente nativo, nessa abordagem, é o browser instalado no dispositivo. Assim, o desenvolvedor não é capaz de acessar quaisquer funcionalidades nativas do dispositivo, como sensores, câmeras, etc.. Em se tratando de aspectos visuais, os aplicativos web têm dificuldade de se assemelharem aos aplicativos nativos, o que pode causar certo desconforto ao usuário. Por fim, todos os detalhes do desenvolvimento web também devem ser levados em consideração, como suportar diferentes tamanhos de telas e diferentes versões de browsers (Lecheta, 2022).

2.2 DESENVOLVIMENTO HÍBRIDO

O desenvolvimento híbrido é uma combinação entre nativo e web. O aplicativo continua sendo desenvolvido com técnicas web, mas ele não é mais acessado diretamente pelo browser. Agora, um componente nativo é utilizado como um container para acessar o HTML. Em vez de utilizar um browser comum, como Chrome ou Firefox, o usuário deve instalar o aplicativo. Basicamente, o aplicativo é apenas um encapsulador, que possui um visualizador web incorporado. Por exemplo, no caso do Android, o visualizador em questão é o WebView, enquanto no IOS é o WKWebView (Lima, 2023).

Diferentemente do desenvolvimento web, os aplicativos híbridos podem ser distribuídos nas lojas virtuais como um aplicativo nativo. Outra vantagem em relação ao aplicativo web é a capacidade de acessar funcionalidades nativas do dispositivo, que são expostas via APIs em JavaScript por uma camada de abstração, tanto no iOS quanto no Android (Neves e Junior, 2020).

Apesar de corrigir desvantagens do desenvolvimento web e compartilhar das mesmas vantagens, o desenvolvimento híbrido possui alguns desafios. O desempenho ainda não é o ideal, pois o aplicativo continua sendo executado dentro de um mecanismo de browser. Visualmente, assim como anteriormente, o aplicativo dificilmente será equiparado a um aplicativo nativo. A comunicação com o hardware do dispositivo, que não acontecia antes, é feita via JavaScript e está sujeita a vulnerabilidades (Matilda, 2023).

Atualmente, a ferramenta multiplataforma mais consolidada que opta pela abordagem híbrida é o framework Ionic. Para usufruir de funcionalidades nativas, como bateria, notificações e armazenamento, Ionic utiliza plugins do Apache Cordova (Beneveduto et al, 2022).

2.3 DESENVOLVIMENTO INTERPRETADO

Algumas abordagens de desenvolvimento multiplataforma utilizam, de certa forma, componentes do desenvolvimento nativo. É o caso do desenvolvimento interpretado. A ideia central aqui é, com apenas um código, requisitar e utilizar os componentes nativos de cada plataforma, sem a necessidade de códigos diferentes. O código é escrito em alguma linguagem interpretada, como JavaScript ou TypeScript. As funcionalidades nativas, assim como os elementos de UI nativos, serão expostas por uma camada de abstração. Posteriormente, em tempo de execução, o código será interpretado em diferentes plataformas. Nessa abordagem, o aplicativo não está rodando dentro de um mecanismo web. Os elementos presentes na tela são, de fato, os elementos nativos do dispositivo. Isso é possível pois o interpretador interpreta o código fonte e, durante a execução, providencia os elementos requisitados (Neves e Junior, 2020).

Assim como um aplicativo híbrido, um aplicativo interpretado também pode ser distribuído nas lojas virtuais e instalado normalmente. Evidentemente, sua instalação é necessária. Agora, pela primeira vez, o visual alcançado é totalmente equiparável ao visual de um aplicativo nativo, visto que os elementos nativos de UI são invocados pelo interpretador. As funcionalidades nativas do dispositivo estão disponíveis para serem acessadas via API, assim como no aplicativo híbrido (Nawrocki et al, 2021).

Apesar de não rodar em um mecanismo web, problemas de desempenho ainda existem nessa abordagem. Mesmo que os elementos e funcionalidades sejam nativos, o fato de ser uma linguagem interpretada traz problemas de desempenho. A espécie de ponte, feita pelo interpretador em tempo de execução, entre o código fonte e o sistema operacional pode ser bastante problemática (Stender, 2020).

Além do React Native, outros frameworks também utilizam a abordagem interpretada. Alguns exemplos são o Native Script e Smartface App Studio, poucos utilizados atualmente, ambos tendo JavaScript como principal linguagem (Danielsson, 2022).

2.4 DESENVOLVIMENTO CROSS-COMPILED

Similar ao desenvolvimento interpretado, o código é escrito somente uma vez e aplicativos diferentes serão gerados para cada plataforma. A diferença principal é que, nessa abordagem, o código é compilado para a plataforma em questão, em vez de ser interpretado. O aplicativo, assim como nas duas abordagens anteriores, será distribuído e instalado como um aplicativo nativo. Porém, em vez de ser interpretado em tempo real, todo o aplicativo é compilado para código de máquina que será executado nativamente no dispositivo (Lima, 2023).

É evidente o ganho de desempenho ao substituir uma linguagem interpretada por uma compilada. O maior benefício esperado nessa abordagem é a possibilidade de alcançar o mesmo desempenho oferecido por um aplicativo nativo. Por mais que seja possível utilizar os elementos nativos de UI com essa abordagem, alguns frameworks optam por montar a interface de outra forma. A comunicação com as funcionalidades nativas do dispositivo não é feita através de API em JavaScript, o que pode corrigir problemas de vulnerabilidade (Nawrocki et al, 2021).

Flutter e Xamarin são frameworks consolidadas que trabalham na abordagem cross-compiled. Entretanto, existem grandes diferenças entre ambas que resultam em diferentes desvantagens. Diferentemente de Flutter, Xamarin permite utilizar os componentes nativos de UI do dispositivo. Assim, é possível se beneficiar do visual nativo oferecido pelas plataformas, com o qual o usuário já está acostumado. Porém, não é trivial usufruir dessa funcionalidade e pode ser custoso lidar com a UI nativa, podendo haver a necessidade de escrever código específico para cada plataforma (Danielsson, 2022).

3. RESULTADOS E DISCUSSÃO

Durante os experimentos, todos os aplicativos foram executados em um dispositivo físico com o sistema operacional Android. É importante não utilizar emuladores para executar os experimentos, pois eles utilizam o hardware do computador e podem apresentar resultados destoantes com a realidade. O dispositivo utilizado foi um Xiaomi Mi A1 com 4GB de RAM e um processador Snapdragon 625 com oito núcleos (Nawrocki et al, 2021).

Para garantir uma alta confiabilidade nos resultados, os experimentos foram executados várias vezes. Cada aplicativo foi executado 50 vezes. Durante os experimentos, não temos total controle sobre o sistema operacional e não é possível garantir que não há outros processos em execução utilizando recursos do dispositivo, afetando o desempenho do aplicativo. Dessa forma, para minimizar possíveis interferências, os experimentos foram executados em diferentes dias. Para minimizar processos em segundo plano, o modo avião foi ativado e as notificações foram desativadas (Lima, 2023).

3.1 QUANTIDADE DE JANKY FRAMES

Apresenta-se a média, a mediana e o desvio padrão da quantidade de janky frames (em porcentagem) encontrados nas 50 execuções de cada um dos 5 aplicativos. É importante medir a quantidade média de janky frames para analisar o desempenho do aplicativo de modo geral. Enquanto isso, o desvio padrão é uma boa métrica para verificar instabilidades.

3.1.1 Aplicativo 1 – Stopwatch

O aplicativo 1 apresenta apenas um contador, incrementado automaticamente. Em uma execução limpa de janky frames o contador é incrementado 60 vezes em um segundo. A presença janky frames ocasiona uma demora na atualização do contador, fazendo com que ele seja incrementado menos vezes, demorando mais para chegar em determinado número. Interessante ressaltar que esse contador não é de fato um stopwatch, cuja integridade não pode depender de janky frames (Danielsson, 2022).

Como pode-se ver na tabela 2, o React Native não apresentou nenhum janky frame em nenhuma das 50 execuções. O Flutter apresentou alguns janky frames, porém com média e mediana extremamente baixas e certa consistência, sem grandes picos.

Tabela 2- Quantidade de janky frames no aplicativo 1

Fonte: Próprio autor, 2025.

Analisando cada uma das execuções, como pode ser visto no gráfico apresentado pela figura 1, é possível confirmar que a porcentagem de janky frames variou pouco entre as execuções no Flutter. Algumas execuções chegaram a apresentar nenhum janky frame, enquanto outras alcançaram um pico de aproximadamente 1,4%.

Figura 1- Porcentagem de janky frames por execução do aplicativo 1

Fonte: Próprio autor, 2025.

3.1.2 Aplicativo 2 – Multi Stopwatch

O aplicativo 2 também é composto apenas por contadores. Dessa vez, são apresentados seis contadores simultâneos. Assim como no aplicativo 1, a presença de janky frames impactará na quantidade de vezes que os contadores serão incrementados.

Novamente, como podemos ver na tabela 3, o React Native não apresentou janky frames. Enquanto isso, o Flutter apresentou uma média um pouco pior que o aplicativo anterior. Já era esperado que os resultados fossem iguais ou piores, pois a complexidade do aplicativo aumentou.

Tabela 3- Quantidade de janky frames no aplicativo 2

Fonte: Próprio autor, 2025.

Analisando o gráfico que representa o Flutter na figura 2, pode-se notar algumas semelhanças com o gráfico do aplicativo 1. Apesar da média e mediana serem levemente maiores, os picos continuam acontecendo por volta de 1,4%. Dessa vez, apenas uma execução apresentou nenhum janky frame.

Figura 2- Porcentagem de janky frames por execução do aplicativo 2

Fonte: Próprio autor, 2025.

3.1.3 Aplicativo 3 – Counter

O aplicativo 3 é o primeiro aplicativo a lidar com interação do usuário. Ao tocar no botão, o contador é incrementado em uma unidade. Importante ressaltar que a incrementação do número não é a única atualização efetuada a partir do toque no botão. O botão, ao ser tocado, emite uma animação para que o usuário receba um feedback de que o botão foi, de fato, tocado. A presença de janky frames pode causar animações mais lentas ou travadas, impactando na sua suavidez. Por ser um aplicativo bastante simples, espera-se que a quantidade de janky frames seja extremamente baixa, a ponto de não afetar negativamente a experiência do usuário.

Dessa vez, como mostra a tabela 4, o React Native saiu do zero e apresentou alguns janky frames, porém com uma média extremamente baixa — próxima de zero — e mediana igual a zero. O Flutter apresentou resultados melhores que os dois primeiros aplicativos, com uma mediana também igual a zero, mas ainda obteve resultado pior que o React Native, com média mais alta e mais instabilidade.

Tabela 4- Quantidade de janky frames no aplicativo 3

Fonte: Próprio autor, 2025.

Figura 3 – Porcentagem de janky frames por execução do aplicativo 3

Fonte: Próprio autor, 2025.

Apesar de o React Native possuir uma média maior que zero, analisando o gráfico da figura 3, pode-se perceber que apenas uma execução apresentou janky frames. Por outro lado, o Flutter apresentou uma porcentagem aproximada de 0,8% de janky frames em aproximadamente metade das execuções. Enquanto isso, a outra metade apresentou 0%, com apenas uma exceção, apresentando cerca de 1,6%. A mediana igual a zero significa que mais da metade das execuções apresentou 0%. Analisando os resultados mais profundamente, é possível ver que o Flutter renderizou uma média de 129,5 frames por execução, com um desvio padrão de apenas 1,5. Dessa forma, as porcentagens 0,8% e 1,6% representam, respectivamente, apenas 1 e 2 frames do total.

3.1.4 Aplicativo 4 – Navigations

O aplicativo 4 é consideravelmente mais complexo que os anteriores. Além de lidar com toques do usuário, este aplicativo também é responsável por efetuar navegação entre telas. Então, além da animação do toque do botão em si, dessa vez também ocorrem animações de transição de telas. Assim como no aplicativo anterior, a presença de janky frames pode causar problemas nas animações, impactando na experiência do usuário. Por ser um aplicativo mais complexo, apresentando múltiplas animações, é natural que a quantidade de janky frames seja maior que no aplicativo anterior.

Com os resultados da tabela 5, pode-se ver que o React Native teve mais dificuldade para lidar com o aumento de complexidade e apresentou números piores que o Flutter.

Tabela 5- Quantidade de janky frames no aplicativo 4

Fonte: Próprio autor, 2025.

Figura 4 – Porcentagem de janky frames por execução do aplicativo 4

Fonte: Próprio autor, 2025.

3.1.5 Aplicativo 5 – List

O aplicativo 5 lida com a interação do usuário com uma lista. Ao rolar uma lista, os itens presentes na tela devem ser movidos para cima ou para baixo, dando lugar a novos itens. A presença de janky frames pode, novamente, causar problemas nas animações de rolagem da lista. Uma alta quantidade de janky frames pode impactar negativamente a experiência do usuário, pois, dependendo da velocidade da rolagem, o usuário pode ter a impressão de que a lista está “travando”.

Como pode-se ver na tabela 6, o último aplicativo é o que possui maiores problemas de desempenho. Apesar de ambos os frameworks apresentarem seus piores resultados nesse aplicativo, o React Native alcançou uma média drasticamente alta de 21,34%. Além disso, o desvio padrão também é extremamente alto, mostrando que o aplicativo apresentou boas e péssimas execuções. O Flutter foi mais consistente, apresentando um desvio padrão menor que 1% e uma média relativamente baixa.

Tabela 6- Quantidade de janky frames no aplicativo 5

Fonte: Próprio autor, 2025.

Como mostra a figura 5, o React Native oscilou bastante, chegando a apresentar uma porcentagem perto de zero em alguns momentos e alcançando quase 70% em outros. Apesar de poucas execuções possuírem uma porcentagem tão elevada, podemos notar que muitas apresentam uma porcentagem entre 20% e 40%, o que é extremamente alto e, certamente, impacta na experiência do usuário. O Flutter, além de apresentar maior regularidade, não ultrapassa 10% em nenhuma execução, alcançando um desempenho melhor nessa situação.

Figura 5- Porcentagem de janky frames por execução do aplicativo 5

Fonte: Próprio autor, 2025.

3.2 ESPAÇO EM BRANCO NAS LISTAS

Discute-se os resultados obtidos a partir da medição da quantidade de espaço em branco encontrado no aplicativo 5 (List) durante a execução dos experimentos. O experimento consiste em 6 rolagens de tela, como se o usuário estivesse rolando a tela de cima para baixo seguidamente. A primeira rolagem é a maior de todas e antecede outras 5 rolagens de tamanhos iguais. Todas as 6 rolagens são executadas uma após a outra. Apesar de todas as interações serem simuladas via ADB, alguns atrasos de milissegundos podem ocorrer entre a execução de dois comandos. Dessa forma, não é possível garantir que todas as execuções terão, no geral, exatamente a mesma rolagem de tela.

Foram analisadas as gravações de telas de 50 execuções. O gráfico representado pelas figuras 6 e 7 mostram a porcentagem de espaço em branco da lista de cada um dos frames analisados da gravação. A linha mais escura representa a quantidade média de espaço em branco no frame de número x nas 50 execuções, enquanto a região mais clara delimita o intervalo de 95% de confiança.

3.2.1 Flutter

Diferentemente do React Native, que possui uma seção em sua documentação oficial exclusivamente sobre os problemas de desempenhos presentes em grandes listas, o Flutter não apresentou nenhum espaço em branco durante a execução dos experimentos. Os itens são, assim como no React Native, criados sob demanda, então apenas os itens visíveis são de fato construídos para serem renderizados na tela.

O gráfico representado pela figura 6 mostra a porcentagem de espaço em branco na lista, em média, em cada um dos frames renderizados.

Figura 6- Porcentagem de espaço em branco por frame no aplicativo 5 em Flutter

Fonte: Próprio autor, 2025.

Na tabela 7, pode-se visualizar, em média, quantos frames (em porcentagem) de uma execução possuem a lista com uma porcentagem de branco maior que o valor determinado.

Tabela 7- Quantidade de espaço em branco na lista do aplicativo 5 em Flutter

Fonte: Próprio autor, 2025.

Apesar da criação de itens sob demanda, o Flutter consegue gerenciar muito bem a criação de novos itens a serem renderizados enquanto o usuário realiza a rolagem na tela. Durante a execução dos experimentos, todos os itens foram renderizados corretamente, sem nenhum tipo de atraso, não apresentando espaços em branco.

3.2.2 React Native

O React Native apresentou problemas recorrentes de renderização de itens. Muitas vezes, vários itens não foram renderizados a tempo, causando a aparição de espaços em branco na lista durante a rolagem de tela.

Pode-se perceber, analisando o gráfico da figura 7, que o resultado é bastante consistente. Os espaços em branco começam a aparecer, de forma sutil, por volta do frame 200, no fim da terceira rolagem. Durante a quarta rolagem, por volta do frame 240, o espaço em branco aumenta consideravelmente, extremamente rápido, alcançando cerca de 90% da lista. Durante a quinta e a sexta rolagem, podemos observar outros dois picos, por volta dos frames 270 e 310, respectivamente. Nesse segundo pico, a lista chega a ficar quase completamente branca, com nenhum item sendo renderizado. A lista continua com bastante espaço em branco até o fim da sexta rolagem, quando a interação com o usuário acaba e nenhum novo item precisa ser renderizado. Nesse momento, conforme a rolagem vai chegando ao fim, o espaço em branco vai diminuindo, até que nenhum item esteja faltando na tela.

Figura 7-Porcentagem de espaço em branco por frame no aplicativo 5

Fonte: Próprio autor, 2025.

Na tabela 8, pode-se visualizar, em média, quantos frames (em porcentagem) de uma execução possuem a lista com uma porcentagem de branco maior que o valor determinado.

Tabela 8- Quantidade de espaço em branco na lista do aplicativo 5 (React Native)

Fonte: Próprio autor, 2025.

Em média, 28,13% dos frames apresentam pelo menos um item faltante na lista. Mais de 20% apresentam mais da metade da lista em branco. Outro fato que chama bastante atenção é que, em média, 11,87% — com um desvio padrão de apenas 4,03% — dos frames possuem mais de 99% da lista em branco. Isso significa que mais de um décimo dos frames apresenta a lista praticamente toda em branco, uma quantidade extremamente alta.

4. CONSIDERAÇÕES FINAIS

O trabalho buscou analisar a performance entre os frameworks React Native e Flutter no desenvolvimento de aplicativos móveis, considerando aspectos relacionados à eficiência, consumo de recursos, tempo de execução e impacto na experiência do usuário. A pesquisa, realizada a partir de revisão de literatura, demonstrou que ambos os frameworks apresentam relevância e aplicabilidade, cada qual com características próprias que influenciam diretamente na escolha por parte de desenvolvedores e empresas.

Constatou-se que o Flutter, por compilar diretamente em código nativo e oferecer uma arquitetura mais unificada, tende a apresentar melhor desempenho em aplicações que exigem maior responsividade e fluidez. Além disso, sua interface consistente, aliada à linguagem Dart, contribui para resultados mais estáveis em diferentes sistemas operacionais, tornando-se uma opção atrativa em projetos que priorizam performance e uniformidade visual.

O React Native, embora apresente algumas limitações de desempenho, destaca-se pela ampla comunidade de suporte, integração facilitada com bibliotecas externas e pela curva de aprendizado acessível, sobretudo para desenvolvedores já familiarizados com JavaScript. Esse conjunto de fatores assegura ao framework uma posição de destaque em projetos que exigem flexibilidade, rapidez no desenvolvimento e suporte técnico diversificado.

A problemática levantada, identificar qual framework apresenta melhor performance e em quais aspectos essas diferenças se manifestam, foi respondida ao demonstrar que não existe uma solução única ou definitiva. A escolha deve considerar o contexto do projeto, os recursos disponíveis e as prioridades de cada aplicação, visto que tanto React Native quanto Flutter podem oferecer resultados satisfatórios, desde que empregados de forma estratégica.

Conclui-se, portanto, que ambos os frameworks possuem potencial significativo no cenário do desenvolvimento multiplataforma, cabendo à análise crítica do desenvolvedor ou da equipe técnica a decisão sobre sua adoção. A partir desta pesquisa, espera-se contribuir com o debate acadêmico e profissional, fornecendo subsídios para escolhas mais conscientes e alinhadas às demandas de um mercado cada vez mais competitivo e exigente.

REFERÊNCIAS

BENEVENUTO, F; et al. Métodos para análise de sentimentos em mídias sociais. 19th Brazilian symposium on Multimedia and the web, 2022.

DANIELSSON, W. React native application development: A comparison between native android and react native. Human-Centered systems, 2022.

LECHETA. Google Android: Aprenda a criar aplicações para dispositivos móveis com o android sdk. Novatec Editora; 5ª edição, 2022.

LIMA, F. F. Avaliação de frameworks para o desenvolvimento de aplicações híbridas. Universidade Federal Do Pampa, 2023.

MATILDA, O. A comparison of performance and looks between flutter and native applications. Sinú University, 2023.

NAWROCKI, P; et al. A comparison of native and cross-platform frameworks for mobile applications. Computer, n.54, 2021.

NEVES, J; JUNIOR, V. M. Uma análise comparativa entre flutter e react native como frameworks para desenvolvimento híbrido de aplicativos mobile: Estudo de caso visando produtividade. Ciência da Computação – Tubarão, 2020.

STENDER, S; Akesson, H. Cross-platform framework comparison: Flutter e react native. Blekinge Institute of Technology, 2020.


1Darlan Kennedy Oliveira dos Santos – Curso de Engenharia da Computação – Fundação Centro de Análise, Pesquisa e Inovação Tecnológica – Manaus-AM. E-mail: darlankennedy2@gmail.com
2Wagner Palheta – Professor e Orientador.