Precarga de Assets

Para qué sirve este sistema

Addressables resuelve cómo cargar un asset por clave; no resuelve cuándo cargarlo ni cuánta memoria está dispuesto a gastar un proyecto en mantener assets a mano. Sin una capa de caché deliberada, los juegos o recargan los mismos assets una y otra vez — pagando un tirón de carga cada vez — o lo retienen todo en memoria indefinidamente hasta que el presupuesto de una plataforma se agota.

La Precarga de Assets de Serenity se sitúa entre el código del juego y Addressables como una caché en memoria de runtime con un presupuesto de bytes configurable. Los assets se precargan por clave o se precalientan por etiqueta en el arranque, se mantienen en memoria hasta el presupuesto y se expulsan por menos-usado-recientemente cuando un asset nuevo empujaría la caché por encima — sin más código que un asset de configuración y un puñado de llamadas a casos de uso.

El problema en Unity

Cargar un Addressable la primera vez que se necesita es simple, pero produce un tirón visible justo cuando el jugador está mirando la pantalla — un menú que se abre, un nivel que empieza, un arquetipo de enemigo que aparece por primera vez. Precalentarlo todo por adelantado evita el tirón pero no tiene límite natural: el uso de memoria crece con el proyecto hasta que alguien poda a mano.

Incluso una caché escrita a mano suele saltarse la parte difícil — decidir qué expulsar cuando se supera el presupuesto, y hacerlo de forma consistente en lugar de con llamadas de limpieza ad hoc dispersas por las transiciones de escena. Sin una caché compartida, dos sistemas que quieren mantener caliente el mismo asset acaban cargándolo y descargándolo a espaldas el uno del otro.

Cómo lo aborda Serenity

Un PrefetchPolicyProfile define el presupuesto y la política de la caché — un presupuesto de bytes, un tope de elementos previsto y una estrategia y política de expulsión con nombre — agrupados por un PrefetchPolicyRegistry que resuelve perfiles por id. IAssetPrefetcherService es la caché de runtime: precarga un asset por clave, precalienta un lote, consulta el estado de la caché y deja que el servicio expulse automáticamente las entradas menos usadas recientemente cuando se supera el presupuesto de bytes.

PrewarmAssetsByLabelsTask corre durante el arranque, resolviendo una lista de etiquetas de Addressables a claves y precargando cada una antes de que el jugador llegue al contenido que las necesita — una tarea, dirigida por datos, en lugar de una lista de assets a calentar mantenida a mano y dispersa por el código de inicialización.

Cómo encaja en Serenity

La política impuesta hoy es el presupuesto de tamaño con expulsión LRU: MaxSizeMB es el mando que soporta la carga, acotado a un mínimo para que un proyecto nunca pueda configurar la caché a la nada, y el servicio expulsa la entrada menos usada recientemente cuando un asset nuevo empujaría los bytes cacheados por encima del presupuesto. Los campos de estrategia y expulsión del perfil se llevan al runtime por compatibilidad futura, pero de momento no cambian el comportamiento del servicio más allá de eso.

El servicio compone con el Pipeline de Inicialización como instalador de arranque y con PrewarmAssetsByLabelsTask para el calentado dirigido por etiquetas, y con cualquier agregado que cargue Addressables — personajes, oleadas, audio, prefabs de UI — a través de la misma lista de precalentado por etiqueta, sin acoplamiento por agregado con la propia caché.

Flujo de trabajo práctico

1. Crea un PrefetchPolicyProfile con un presupuesto de bytes (MaxSizeMB) y añádelo a un PrefetchPolicyRegistry para que pueda resolverse por id en el arranque.
2. Conecta el registry al instalador de la Precarga de Assets como parte de tu pipeline de inicialización para que la caché exista antes de que el gameplay la necesite.
3. Añade PrewarmAssetsByLabelsTask a la secuencia de arranque con las etiquetas de Addressables que quieres calientes antes de que el jugador llegue a ese contenido.
4. Llama a IAssetPrefetcherService.PrefetchAsync para cargas bajo demanda, o a PrewarmContextAsync para un lote, desde cualquier sistema de gameplay que necesite un asset caliente.
5. Abre el Cache Inspector de runtime sobre el servicio en vivo para ver el contenido de la caché por asset, agrupado por categoría — Animations, Audio, Textures — junto a los diagnósticos de la caché.
6. Usa las acciones Refresh y Clear del Cache Inspector durante el desarrollo para confirmar el presupuesto y el comportamiento de expulsión antes de dar por buenos los números del perfil.

Qué incluye

• Caché de runtime IAssetPrefetcherService con precarga por clave, precalentado por lotes y consultas de estado de caché
• ScriptableObjects PrefetchPolicyProfile y PrefetchPolicyRegistry definiendo un presupuesto de bytes y una política con nombre
• Presupuesto de bytes configurable con expulsión LRU automática cuando los bytes cacheados superan el presupuesto
• PrewarmAssetsByLabelsTask para precalentar en el arranque cada asset que lleve una etiqueta de Addressables elegida
• Cache Inspector en vivo sobre el servicio de runtime — contenido por asset agrupado por categoría (Animations, Audio, Textures)
• Diagnósticos de caché y controles Refresh/Clear en el inspector para iterar rápido durante el desarrollo
• Compone con cualquier agregado que cargue Addressables mediante precalentado por etiqueta, sin acoplamiento por agregado
• Alcance honesto: la política impuesta hoy es el presupuesto de tamaño con expulsión LRU, por delante de cualquier soporte futuro de estrategias

Cuándo usarlo

• Proyectos que ven tirones de carga cuando los assets de Addressables se cargan por primera vez justo cuando el jugador está mirando la pantalla.
• Juegos que quieren un techo de memoria para los assets cacheados en lugar de recargar constantemente o retenerlo todo indefinidamente.
• Equipos que quieren un precalentado de arranque dirigido por etiquetas de Addressables en lugar de una lista de assets a calentar mantenida a mano en código.
• Bases de código que necesitan visibilidad de qué está cacheado ahora mismo y por qué se expulsó algo, sin bucear por reflexión en las tripas de Addressables.

Sistemas relacionados

• Workflow de Addressables Asset prefetcher basado en servicio con contextos, etiquetas, políticas de caché y tareas de prewarm para Unity Addressables.
• Pipeline de Inicialización Una pipeline asíncrona y ordenada que ejecuta las tareas de arranque de tu proyecto Unity con niveles de criticidad, progreso ponderado y telemetría transmitida a cualquier pantalla de carga.
• Sistema de Ajustes de Gráficos Un servicio de gráficos que persiste el nivel de calidad, la resolución y el estado de pantalla completa a través de Game Settings y difunde cada cambio mediante el Event Dispatcher.
• Capa de Persistencia de Datos Una jerarquía de puertos que desacopla los contratos de guardado de los backends de Unity para que el almacenamiento en ficheros, PlayerPrefs y el cifrado puedan cambiar sin tocar el código del juego.