La lista es el producto

Las pantallas financieras viven o mueren por las listas largas: una lista de seguimiento de cientos de valores, un libro de órdenes que se actualiza sin cesar, un historial de operaciones que crece sin límite. Los datos del Web Almanac y de Lighthouse hacen el peligro concreto. La página móvil mediana lleva unos 594–616 elementos DOM, y el 10% más pesado llega a cerca de 1.700–1.900; Lighthouse empieza a advertir por encima de 800 nodos y marca error por encima de 1.400–1.500. Una sola lista de 1.000 filas renderizada a la manera web puede superar todos esos umbrales —y cada desplazamiento, hover y toque obliga al navegador a recalcular estilo y diseño para todo el árbol, que es exactamente cómo colapsa el INP (Interaction to Next Paint).

WebView renderiza cada fila como un nodo

Un WebView construye una lista larga a la manera del documento: cada fila es un nodo DOM, todos vivos en memoria a la vez. Al desplazar, el navegador debe maquetar y pintar miles de nodos, y el recálculo de estilo toca cientos de elementos por interacción. Pasadas unas pocas centenas de filas aparecen fotogramas caídos, aumento de memoria y, finalmente, pantallas blancas cuando la capa de render se queda atrás. La web tiene mitigaciones —content-visibility: auto, librerías de lista virtual como react-window— pero son parches opt-in sobre una arquitectura que nunca se diseñó para reciclar nodos, y añaden peso de framework y trampas de accesibilidad.

Un mini-programa recicla solo lo visible

Un runtime gobernado trata una lista larga como un widget nativo. El recycle-view de WeChat renderiza solo las filas actualmente en vista y recicla las instancias de nodo mientras el usuario se desplaza —los componentes se mantienen fijos y solo se mueven los datos. El scroll-view más nuevo con type="list" (bajo el renderizador Skyline) elimina el JSBridge lógica↔render por completo: el desplazamiento y el render corren en el mismo hilo con rasterización síncrona, así que no hay pantalla blanca al desplazar rápido y la memoria se mantiene baja. El antiguo scroll-view estilo WebView pagaba un costo de conversión JSBridge y usaba rasterización por bloques asíncrona, que mostraba pantalla blanca cuando no podía seguir. El reciclaje es el predeterminado, no una librería que acoplas después.

Cara a cara

DimensiónH5 / WebViewMini-Programa (recycle-view / Skyline)
Nodos en una lista de 1.000 filasMiles de nodos DOM vivosSolo filas en pantalla (~decenas)
Recálculo de estilo al desplazarTodo el árbol por interacciónReciclado, trabajo mínimo
Puente lógica↔renderCosto de conversión JSBridgeNinguno (mismo hilo, raster síncrono)
RasterizaciónAsíncrona; pantalla blanca al desplazar rápidoSíncrona; sin pantalla blanca
MemoriaAlta; riesgo de caídaBaja
Impacto en INPDOM grande → INP pobreDOM pequeño → INP bueno

Qué significa para tus listas

Para superficies densas en datos y de crecimiento continuo —valores, libros de órdenes, registros de transacciones— el reciclaje de nodos es la diferencia entre una sensación nativa y una presentación de diapositivas. Un runtime que recicla por construcción mantiene el ritmo de fotogramas predecible en Android de gama baja, donde vive la base instalada global y donde una lista de 1.000 filas es rutinaria. H5 sigue siendo la herramienta correcta para documentos y la web abierta; la superficie de datos dentro del host no debería tartamudear cuando se le dan mil filas.

Dónde encaja Cross Mini App

Cross Mini App es el runtime y el catálogo abierto para este modelo. Construyes un mini-programa sobre una superficie de API estándar y hereda una ruta de lista que recicla las filas en pantalla en cada host que lo embebe —no un WebView que instancia miles de nodos y se traba. Las listas fluidas se diseñan, no se esperan. H5 muestra las filas; el mini-programa te deja desplazarlas.

Fuentes