Unity Addressables: diseñar ciclos de vida explícitos de carga y liberación

Una carga genera una responsabilidad

Una solicitud de asset puede sobrevivir a la pantalla que la originó. Un retrato puede terminar de cargarse cuando el panel de su personaje ya se cerró, o una vista previa puede reemplazarse antes de que llegue su textura. Diseña este ciclo de vida antes de añadir un indicador de carga. Define quién es el propietario, quiénes son los consumidores y cuál es el evento exacto que pone fin a la propiedad. Las referencias de este artículo se basan en la documentación de Addressables 2.7.

Separar la finalización de la propiedad

LoadAssetAsync devuelve un handle de operación. Conserva ese handle mientras uses su resultado y luego libéralo; al liberarlo, el handle deja de ser válido. Las operaciones fallidas también requieren liberar su handle. [1] La finalización responde a la pregunta de si el resultado está listo. La propiedad responde a quién debe mantenerlo vivo. Modela ambas cosas como decisiones independientes en tu aplicación.

Contar obligaciones, no variables

Addressables usa conteo de referencias. Equilibra cada carga explícita con su liberación; que un asset llegue a cero referencias no implica necesariamente que su memoria se libere de inmediato, porque influye el ciclo de vida de los bundles. [2] Un wrapper práctico puede registrar una obligación de liberación por solicitud, con estados como pending, usable, obsolete y released. Haz que la limpieza sea idempotente dentro de ese wrapper, de modo que el cierre del panel y la finalización de la carga no puedan liberar la misma obligación dos veces. Una variable copiada nunca debería ser tu registro de propiedad.

Ejemplo: un carrusel de selección de personajes

Supón que al seleccionar al piloto A se inicia la solicitud de retrato 21. Antes de que termine, el jugador selecciona al piloto B, lo que crea la solicitud 22. Mantén la solicitud 21 en seguimiento, pero marca su resultado como obsoleto. Cuando la 21 termine, revisa su resultado, evita asignar su retrato y ejecuta su única ruta de limpieza. Cuando la 22 termine con éxito, muestra su retrato y conserva la propiedad hasta que el panel lo reemplace o se cierre. Un identificador de solicitud impide que un callback antiguo sobrescriba la selección nueva. Al cerrar el panel debe invalidarse de inmediato el acceso de presentación, mientras que la solicitud pendiente sigue en seguimiento hasta que pueda completarse su limpieza. Esta política describe el comportamiento de la aplicación; no presupone que ocultar un panel cancele una descarga.

Límites y evidencia útil

Los assets de Addressables cargados por separado no se liberan automáticamente solo porque se descargue una escena. [3] Incluye las transiciones de escena en el mismo plan de propiedad. Prueba cargas fallidas, cambios rápidos de selección, ciclos repetidos de apertura y cierre, y un cierre que ocurra justo antes de que termine la carga. Registra los identificadores de solicitud, las transiciones de propiedad y los conteos de liberación. Compara los assets y bundles retenidos tras varios ciclos, en lugar de esperar que la memoria del proceso baje con cada liberación. Mantén una cache compartida intencional solo si tiene una política de expulsión definida y un presupuesto de memoria.

Fuentes

1. Addressables 2.7: asynchronous operation handles — Unity Technologies.
2. Managing Addressable asset memory — Unity Technologies.
3. Unload Addressable assets — Unity Technologies.