El presupuesto de frame son 16 milisegundos
En una pantalla de 60 Hz el navegador tiene unos 16 ms para ejecutar JavaScript, calcular estilos, disponer y pintar cada frame. Si falla, el frame se cae — la animación tartamudea, la lista da tirones, el toque se siente tarde. El Web Almanac y web.dev muestran repetidamente que el hilo principal móvil es el cuello de botella: una tarea de más de 50 ms es una "long task" (W3C Long Tasks API) que bloquea la entrada y daña directamente Interaction to Next Paint (INP, métrica web central desde marzo de 2024, "bueno" por debajo de 200 ms). En los teléfonos, procesar un scroll o un evento de entrada puede tardar cientos de milisegundos, durante los cuales la animación se detiene por completo. Eso lo llaman jank.
WebView pone todo en un hilo
Un WebView renderiza la página a la manera del navegador: un hilo principal hace JS, estilos, layout y pintado. Una animación dirigida por script — incluso una simple actualización tipo setData — debe cruzar del hilo lógico al de render mediante un puente serializado: corre la lógica, serializa JSON, reenvía Native, deserializa el lado de render, pinta y recién dibuja el frame. En un dispositivo de gama baja, ese viaje de ida y vuelta supera fácilmente 16 ms, que es exactamente por qué los gestos de arrastre y el scroll se sienten desconectados del dedo. La arquitectura tiene un tope duro: el hilo principal solo puede hacer una de "correr JS / disponer / pintar" a la vez.
Skyline ejecuta la animación en el hilo de render
El renderizador Skyline de WeChat (autodesarrollado, basado en Skia, tipo Flutter, disponible desde la base library 3.0.0 en 2023) saca el cálculo de estilos, el layout, el dibujo y la animación del WebView y los lleva a una tubería de render nativa. El cambio decisivo es el worklet: el código de animación y gesto corre directamente en el hilo de render, leyendo y escribiendo valores compartidos sin serialización entre hilos. No hay viaje de ida y vuelta por el puente, así que las animaciones siguen el dedo a hasta 120 fps en lugar de trabarse en 16 ms. Los componentes nativos — cámara, mapa, video — se renderizan en la misma capa que los componentes comunes (sin trucos de z-index) y las transiciones de elemento compartido vienen integradas.
El renderizador decide el techo
Esto no es una diferencia de ajuste; es estructural. Una página WebView puede mitigar el jank con animaciones CSS, Web Workers y fragmentación cuidadosa, pero sigue peleando contra un hilo principal que también debe analizar, compilar y ejecutar JavaScript. Skyline elimina el WebView de la ruta de render por completo y deja al hilo de render dueño de la animación y los gestos. El resultado es un ritmo de frames predecible en hardware de gama baja, donde el jank daña más la adquisición.
Cara a cara
| Dimensión | H5 / WebView | Mini-Programa (Skyline) |
|---|---|---|
| Backend de render | WebView del sistema (WKWebView / X5) | Tubería Skia autodesarrollada |
| Hilo de animación | Hilo principal (JS + layout + pintado) | Hilo de render vía worklet |
| Costo entre hilos | Serializar → Native → deserializar | Cero (valores compartidos en hilo) |
| Techo de frame | Pierde frames tras 16 ms | Hasta 120 fps, sigue el dedo |
| Componentes nativos | Trucos de capa / z-index | Misma capa, apilado correcto |
| Animación de elemento compartido | No nativa | Integrada |
| Sistema de gestos | Sin competencia nativa | Gestos declarativos en competencia |
Qué significa para tu UI
Si tus pantallas viven o mueren por la sensación de scroll, las interacciones de arrastre o las transiciones de elemento compartido — escaparates, galerías, carruseles de onboarding — la ruta de render es el producto. Un runtime gobernado con renderizador nativo te da esa fluidez por construcción, especialmente en los Android de gama baja que forman la mayor parte de la base instalada global. H5 sigue siendo la herramienta correcta para contenido y la web abierta; la superficie interactiva dentro del host no debería tartamudear cuando no es necesario.
Dónde encaja Cross Mini App
Cross Mini App es el runtime y el catálogo abierto para el modelo de render fluido. Construyes un mini-programa contra una superficie de API estándar y hereda una ruta de render donde la animación y el gesto viven en el hilo de render, en cada host que lo incrusta — no un WebView peleando con un hilo principal. Fluido se diseña, no se espera. H5 cuenta la historia; el mini-programa deja al usuario sentirla.
