Unity Addressables : concevoir des durées de vie explicites pour le chargement et la libération

Un chargement crée une responsabilité

Une requête d'asset peut survivre à l'écran qui l'a émise. Un portrait peut finir de se charger après la fermeture du panneau de son personnage, ou un aperçu peut être remplacé avant l'arrivée de sa texture. Concevez cette durée de vie avant d'ajouter un indicateur de chargement. Nommez le propriétaire, les consommateurs et l'événement précis qui met fin à la propriété. Les références citées ici s'appuient sur la documentation d'Addressables 2.7.

Dissocier l'achèvement de la propriété

LoadAssetAsync renvoie un handle d'opération. Conservez ce handle tant que vous utilisez son résultat, puis libérez-le ; la libération invalide le handle. Les opérations en échec exigent elles aussi un nettoyage de leur handle. [1] L'achèvement répond à la question « le résultat est-il prêt ? ». La propriété répond à la question « qui doit le maintenir en vie ? ». Modélisez ces deux aspects comme des décisions distinctes dans votre application.

Compter les obligations, pas les variables

Addressables repose sur des compteurs de références. Équilibrez chaque chargement explicite par une libération ; un asset dont le compteur retombe à zéro ne libère pas forcément sa mémoire immédiatement, car la durée de vie des bundles entre en jeu. [2] Un wrapper pragmatique peut enregistrer une obligation de libération par requête, avec des états tels que « en attente », « utilisable », « obsolète » et « libérée ». Rendez le nettoyage idempotent au sein de ce wrapper, afin que la fermeture du panneau et l'achèvement du chargement ne puissent pas libérer deux fois la même obligation. Une variable copiée ne doit jamais tenir lieu de registre de propriété.

Exemple : un carrousel de sélection de personnage

Imaginons que la sélection du pilote A lance la requête de portrait 21. Avant qu'elle ne se termine, le joueur sélectionne le pilote B, ce qui crée la requête 22. Conservez le suivi de la requête 21, mais marquez son résultat comme obsolète. Lorsque la 21 se termine, examinez son issue, n'affectez pas son portrait et exécutez son unique chemin de nettoyage. Lorsque la 22 se termine avec succès, affichez son portrait et conservez la propriété jusqu'à ce que le panneau le remplace ou se ferme. Un identifiant de requête empêche un ancien callback d'écraser la nouvelle sélection. La fermeture du panneau doit invalider immédiatement l'accès à l'affichage, tandis que la requête en cours reste suivie jusqu'à ce que le nettoyage puisse s'achever. Cette politique décrit un comportement applicatif ; elle ne suppose pas que masquer un panneau annule un téléchargement.

Limites et preuves utiles

Les assets Addressables chargés séparément ne sont pas libérés automatiquement du simple fait du déchargement d'une scène. [3] Intégrez les transitions de scène dans le même plan de propriété. Testez les chargements en échec, les changements rapides de sélection, les cycles répétés d'ouverture et de fermeture, ainsi qu'une fermeture intervenant juste avant l'achèvement. Consignez les identifiants de requête, les transitions de propriété et le nombre de libérations. Comparez les assets et les bundles conservés après plusieurs cycles, plutôt que d'attendre une baisse de la mémoire du processus à chaque libération. Ne gardez un cache partagé volontaire que s'il dispose d'une politique d'éviction définie et d'un budget mémoire.

Sources

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