Caso de estudio 01 / 21JS Front-End
Mapas 3D sin conexión por cliente, recortados al corredor del ducto
El build de cada cliente lleva solo sus mapas 3D, recortados al corredor de cada línea: de 17.1 GB a 45 MB para un cliente con dos sistemas.
Stack
- CesiumJS
- WebGL
- Leaflet
- nginx
- Node.js
- Next.js
- TypeScript
- WebP
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Los mapas 3D en vivo con los que los operadores siguen alarmas y fugas funcionan sin conexión en los sitios de los clientes, en equipos modestos con unos 8 GB de RAM y solo un navegador. Rehice cómo se empaquetan y cómo arrancan: el build de cada cliente lleva solo sus sistemas, recortados al corredor de cada línea; cada fila del tablero muestra su mapa como imagen antes de que el 3D esté listo, y un sistema cuyo mapa era solo un dibujo ganó las mismas funciones en vivo que los demás.
6 conexiones· elige un componente para ver su recorrido
- Perfil del cliente a Build por cliente: lista sus sistemas
- Build por cliente a Paquete sin conexión: sus mapas y el corredor
- Paquete sin conexión a Fila del tablero: imagen de inicio enseguidamodificado
- Paquete sin conexión a Motor de mapas 3D: terreno y teselas de suelo
- Motor de mapas 3D a Fila del tablero: entra el 3D en vivo
- Fila del tablero a Operador: imagen y luego mapa vivo
02Resultados
- R01Cuanto más bajo, mejor
Datos de mapas enviados a un cliente con dos sistemas
Antes 17,132 MB, después 45 MB, 381× menor. Cuanto más bajo, mejor.AntesDespués - R02Cuanto más bajo, mejor
Tablero, primera visita: imagen del mapa en cada fila
Antes 9.3 s, después 2.5 s, 3.7× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más alto, mejor
Funciones en vivo del mapa que era solo un dibujo (de 8)
Antes 0, después 8, desde 0. Cuanto más alto, mejor.AntesDespués
Qué logró
- Datos de mapas para un cliente con dos sistemas: 17.1 GB, todos los mapas para todos los clientes → 45 MB: sus propios mapas y estilo de suelo, con el terreno recortado a sus corredores
- Clientes sin mapas: 17.1 GB de teselas → ninguna; la app muestra solo el gráfico y la página de salud marca gris, nunca rojo
- El mapa que era solo un dibujo: 0 de 8 funciones en vivo → 8 de 8, sobre todo con datos y configuración, sin ningún nombre de sistema en el código
- Estilos de suelo: foto y mapas de calles → dos más, curvas de nivel y relieve, en claro y oscuro en todos los mapas, con 0 cambios en lo que se dibuja encima
Leer más
- Tablero en la primera visita: el cuarto mapa en pantalla a los 9.3 s → una imagen de inicio en cada fila a los 2.5 s, generada en el build, sobre la que entra el 3D en vivo con un fundido
- Filas del tablero en 2D, probadas en A/B y guardadas en una rama aparte (el 3D sigue por defecto): 2.3–2.7 s de espera por los programas de la GPU → 0, la última fila en vivo un 86–93 % antes, 94 % menos peticiones de mapa
El desafío
Cada instalación recibía los 19 juegos de teselas de mapas, 17.1 GB, aunque sus sistemas estuvieran en una sola región, y el 40 % cubría regiones sin ningún sistema. Dentro de la carpeta de cada mapa, una copia del terreno base del mundo entero pesaba más que el terreno propio del mapa. Con cualquier estilo de suelo, un mapa sin conexión ocupaba 1.3–1.9 GB de RAM del navegador, casi la mitad en memoria de GPU.
Leer más
En el tablero los mapas arrancaban uno detrás de otro: en una primera visita el cuarto aparecía a los 9.3 s, con el hilo principal ocupado 8.3 s, de los cuales 2.4 s se iban en esperar a que la GPU compilara sus programas de sombreado. Y el mapa de un sistema era solo un dibujo de color fijo, sin ninguna de las 8 funciones en vivo de los demás mapas, aunque el backend ya consultaba sus datos.
Qué aprendí
El peso no estaba donde parecía. El motor, no las imágenes, definía la memoria de cada mapa: un modo ligero que bajaba 24–36 % la RAM de un mapa se perdía en el ruido con cuatro mapas en el tablero. Tampoco la red era el cuello de botella: nginx delante y un paquete de arranque por mapa bajaron 20 % las peticiones y 12 % el tiempo del tablero, pero el hilo principal seguía ocupado.
Leer más
Por eso descarté un solo motor 3D para los cuatro mapas, porque arrancar sus marcos costaba solo 0.45 s, y un build a medida del motor que ahorraría menos de 0.1 s por mapa. Además, un control por hash no vio 88 teselas de aviso en pantalla, cada una con otro trozo de una marca de agua; ahora se detectan por su brillo.
Stack
- CesiumJS
- WebGL
- Leaflet
- nginx
- Node.js
- Next.js
- TypeScript
- WebP
Habilidades
- Empaquetado de mapas sin conexión
- Renderizado 3D en la web
- Perfilado de rendimiento
- Medición con pruebas A/B
- Herramientas de build
