Disseram que uma WebView é «só uma view». Não é. É um motor de navegador Chromium completo — o mesmo por trás do Chrome — rodando por cima do seu app nativo. Num topo de linha com 12 GB de RAM, talvez você nunca note. Nos dispositivos de 3–4 GB que são a maioria da sua audiência de app de tráfego em mercados emergentes, esse segundo motor é um imposto silencioso que você paga em cada tela: RAM que rouba, bateria que drena, quadros que caem.
WebView é um navegador multiprocesso, não um widget. A própria documentação do Android é direta: «porque é essencialmente um motor de navegador completo (Chromium), tem uma pegada de memória significativa e uma arquitetura multiprocesso complexa». Uma WebView divide o trabalho entre o processo navegador do seu app e um processo renderizador isolado em sandbox; a maior parte da memória dela — a árvore DOM, o runtime de JavaScript, os gráficos renderizados — vive em memória nativa que «pode crescer em silêncio até gigabytes» e nem aparece em um heap dump de Java. Pior, a memória nativa não tem teto como o heap de Java; ao encher a RAM, o Low Memory Killer do Android começa a encerrar processos em segundo plano e pode acabar matando o app em primeiro plano. Os documentos alertam que deixar instâncias de WebView sem gestão «pode causar vazamentos de memória, falhas por OOM e desempenho degradado», e que você deve chamar explicitamente destroy() ou os recursos nativos podem ficar muito mais tempo do que o esperado.
A diferença medida é grande. Benchmarks independentes de 2026 em dispositivos de média gama colocam um contêiner WebView em 85–320 MB de memória contra 12–65 MB de uma implementação nativa equivalente; início a frio de 1,2–2,8 segundos contra 0,18–0,28 segundos; taxa de quadros sustentada de 30–45 fps (caindo para 15–20 fps em aparelhos antigos) contra um estável 60 fps; e consumo de bateria de 120–180 mAh/h contra 45–65 mAh/h em uso ativo. Nada disso é arredondamento quando a tela é a que o usuário toca mais.
Sua audiência vive na entrada. O Android Go — a edição leve do Google para hardware limitado — move mais de 16.000 modelos de dispositivos em 180+ países, e desde o Android 16 (Go edition, fim de 2025) cobre aparelhos com até 4 GB de RAM. Em mercados sensíveis a preço dominam os handsets de 3–4 GB de RAM. Nesse dispositivo, uma WebView de 140 MB não fica parada — compete com seu app e com o sistema pela pouca RAM disponível, empurra o Low Memory Killer a recuperar memória e pode custar ao usuário seu estado dentro do app. Os mercados onde um app de tráfego precisa vencer são justo onde o imposto WebView é cobrado com mais força.
Um runtime renderiza nativamente, então paga a tarifa nativa. Um runtime próprio do host não sobe um segundo motor de navegador. Ele renderiza com o próprio kit de UI da plataforma, então memória, bateria e ritmo de quadros seguem o orçamento nativo do dispositivo: 60 fps no hardware que realmente está nas mãos dos usuários, sem um segundo motor comendo RAM, sem crescimento nativo silencioso esperando provocar um OOM. O imposto some porque o segundo motor nunca iniciou.
O segundo motor da WebView vs um runtime próprio do host
| Dimensão | WebView (Chromium sobre nativo) | Runtime próprio do host |
|---|---|---|
| Modelo de motor | Segundo motor de navegador sobre nativo | Só kit de UI nativo |
| Memória (média gama) | 85–320 MB | 12–65 MB |
| Início a frio | 1,2–2,8 s | 0,18–0,28 s |
| Quadros | 30–45 fps (15–20 em antigos) | Estável 60 fps |
| Bateria (ativo) | 120–180 mAh/h | 45–65 mAh/h |
| Risco na entrada | LMK mata estado, OOM | Orçamento nativo, sem segundo motor |
Fontes
- Android Developers — WebView e memória (Chromium multiprocesso, risco OOM nativo)
- Android Developers — Gerenciar e diagnosticar memória de WebView
- Conferbot — Benchmark nativo vs WebView (RAM, início, fps, bateria), 2026
- Appilix — WebView vs Hybrid vs Native: memória 100–200 MB, engasgos em listas longas
- Android Go — 16.000+ modelos, 180+ países, até 4 GB RAM (Android 16 Go, 2025)
