O motor que você não pediu

Abra um WebView e você abre um navegador. A própria documentação do Android chama o WebView de essencialmente um motor de navegador de todas as funções (Chromium) com uma pegada de memória significativa e uma arquitetura multiprocesso complexa. Você não pediu um segundo navegador dentro do seu app; pediu para mostrar uma tela. Ainda assim o custo é inevitável: o motor, seu runtime de JavaScript, seu renderizador e seus caches carregam antes de aparecer o primeiro pixel do seu conteúdo.

O que custa o motor completo

Os números não são sutis. O guia de WebView do Android nota que o processo de render está isolado e que sua memória é contabilizada separadamente do seu app — o que significa que o número de destaque no seu profiler subestima o custo real. Medições de engenharia independentes colocam uma única instância de WebView em 60–150 MB para páginas simples e mais de 200 MB para páginas complexas no Android, com o WKWebView no iOS em cerca de 60–100 MB para uma lista simples e 150–200 MB para uma página com muita mídia. Uma página em branco custa sozinha 60–80 MB no Android e 50–70 MB no iOS antes de rodar seu código.

Multiplique isso por abas, por páginas em segundo plano, pelos pesados frameworks de JavaScript que muitas páginas H5 empacotam, e o orçamento de um dispositivo de gama média — aquele que a maioria dos usuários de mercados emergentes realmente carrega — acaba. A pressão de memória dispara o OOM killer do sistema ou o limite duro por processo do iOS, e a página, ou o app, morre. Nenhuma dessas memórias está fazendo o trabalho que seu programa pediu; é o motor em marcha lenta.

A alternativa leve

Um runtime de mini-programas inverte o modelo. A plataforma mantém um motor compartilhado e pré-aquecido e gera apenas o que cada programa precisa: uma camada lógica, uma camada de visão leve e as páginas concretas em uso. Não há um segundo navegador completo por tela, não há um renderizador pesado separado que você deva destruir à mão, nem uma pilha V8 ou JIT ligada do zero a cada inicialização. Como o runtime é genérico e pré-carregado pelo host, um programa chega já quente — o imposto de inicialização a frio que o WebView paga a cada início é absorvido em grande parte pela plataforma.

A divisão de duplo encadeamento multiplica a economia: a lógica de negócio e a renderização estão separadas, de modo que um cálculo longo não bloqueia o orçamento de quadros, e apenas os dados alterados atravessam a ponte. O resultado é um invólucro de memória menor e mais previsível por programa do que uma tela WebView equivalente.

A bateria é a gêmea silenciosa da memória

A memória é apenas metade da história. Um motor completo executando compilação JIT, layout e pintura em um processo separado mantém ocupadas a CPU e a GPU, e uma CPU ocupada é uma bateria que se esgota. Páginas H5 baseadas em WebView que buscam, re-analisam e re-renderizam de novo a cada visita mantêm o dispositivo trabalhando muito depois de uma superfície nativa ou de runtime já ter se assentado. Um mini-programa, em contrapartida, mantém sua camada local e só re-renderiza deltas, então o dispositivo faz menos e fica mais fresco.

Para usuários com dispositivos de armazenamento livre limitado e bateria restrita — exatamente o perfil de mercados emergentes — essa diferença é a linha entre uma sessão que dura e uma que o usuário abandona. Menos memória, menos consumo, sessões mais longas no mesmo hardware.

O que isso significa para as sessões

A conclusão prática: um runtime permite a um host executar muitos programas pequenos sem empilhar um navegador pesado sobre outro, então o app se mantém responsivo e a bateria dura. O Cross Mini App é esse runtime genérico e pré-aquecido — um motor compartilhado em todo o catálogo, cada programa leve por design. Você entrega amplitude sem empilhar motores.

Fontes