O orçamento de frame são 16 milissegundos
Numa tela de 60 Hz o navegador tem cerca de 16 ms para executar JavaScript, calcular estilos, dispor e pintar cada frame. Errar e o frame cai — a animação gagueja, a lista dá solavancos, o toque parece atrasado. O Web Almanac e o web.dev mostram repetidamente que o thread principal móvel é o gargalo: uma tarefa acima de 50 ms é uma "long task" (W3C Long Tasks API) que bloqueia a entrada e prejudica diretamente o Interaction to Next Paint (INP, métrica web central desde março de 2024, "bom" abaixo de 200 ms). Nos celulares, processar um scroll ou evento de entrada pode levar centenas de milissegundos, durante os quais a animação para completamente. Isso eles chamam de jank.
WebView coloca tudo num thread
Um WebView renderiza a página do jeito do navegador: um thread principal faz JS, estilos, layout e pintura. Uma animação dirigida por script — mesmo uma simples atualização tipo setData — precisa cruzar da camada lógica para a de render por uma ponte serializada: roda a lógica, serializa JSON, encaminha Native, desserializa o lado de render, pinta e só então desenha o frame. Num dispositivo de entrada, essa ida e volta ultrapassa facilmente 16 ms, que é exatamente por que gestos de arrasto e scroll parecem desconectados do dedo. A arquitetura tem um teto duro: o thread principal só pode fazer um de "rodar JS / dispor / pintar" por vez.
Skyline executa a animação no thread de render
O renderizador Skyline da WeChat (autodesenvolvido, baseado em Skia, tipo Flutter, disponível desde a base library 3.0.0 em 2023) tira o cálculo de estilos, o layout, o desenho e a animação do WebView e os leva para um pipeline de render nativo. A mudança decisiva é o worklet: o código de animação e gesto roda direto no thread de render, lendo e escrevendo valores compartilhados sem serialização entre threads. Não há ida e volta pela ponte, então as animações acompanham o dedo a até 120 fps em vez de travar em 16 ms. Componentes nativos — câmera, mapa, vídeo — renderizam na mesma camada dos componentes comuns (sem truques de z-index) e transições de elemento compartilhado vêm embutidas.
O renderizador decide o teto
Isso não é diferença de ajuste; é estrutural. Uma página WebView pode mitigar o jank com animações CSS, Web Workers e fragmentação cuidadosa, mas ainda briga com um thread principal que também precisa analisar, compilar e executar JavaScript. O Skyline remove o WebView do caminho de render por completo e deixa o thread de render dono da animação e dos gestos. O resultado é um ritmo de frames previsível em hardware de entrada, onde o jank prejudica mais a aquisição.
Lado a lado
| Dimensão | H5 / WebView | Mini-Programa (Skyline) |
|---|---|---|
| Backend de render | WebView do sistema (WKWebView / X5) | Pipeline Skia autodesenvolvido |
| Thread de animação | Thread principal (JS + layout + pintura) | Thread de render via worklet |
| Custo entre threads | Serializar → Native → desserializar | Zero (valores compartilhados no thread) |
| Teto de frame | Perde frames após 16 ms | Até 120 fps, acompanha o dedo |
| Componentes nativos | Truques de camada / z-index | Mesma camada, empilhamento correto |
| Animação de elemento compartilhado | Não nativa | Embutida |
| Sistema de gestos | Sem competição nativa | Gestos declarativos em competição |
O que isso significa para a sua UI
Se as suas telas vivem ou morrem pela sensação de scroll, interações de arrasto ou transições de elemento compartilhado — vitrines, galerias, carrosséis de onboarding — o caminho de render é o produto. Um runtime governado com renderizador nativo lhe dá essa fluidez por construção, especialmente nos Android de entrada que formam a maior parte da base instalada global. H5 segue sendo a ferramenta certa para conteúdo e a web aberta; a superfície interativa dentro do host não deveria gaguejar quando não precisa.
Onde o Cross Mini App se encaixa
O Cross Mini App é o runtime e o catálogo aberto para o modelo de render fluido. Você constrói um mini-programa contra uma superfície de API padrão e herda um caminho de render onde a animação e o gesto vivem no thread de render, em cada host que o incorpora — não um WebView brigando com um thread principal. Fluido se projeta, não se espera. H5 conta a história; o mini-programa deixa o usuário senti-la.
