Unity Addressables: Lade- und Freigabe-Lebensdauern explizit entwerfen

Ein Ladevorgang begründet eine Verpflichtung

Eine Asset-Anfrage kann den Bildschirm überdauern, der sie ausgelöst hat. Ein Porträt wird möglicherweise erst fertig geladen, nachdem das zugehörige Charakter-Panel geschlossen wurde, oder eine Vorschau wird ersetzt, bevor ihre Textur eintrifft. Diese Lebensdauer ist zu entwerfen, bevor ein Ladeindikator ergänzt wird. Festzulegen sind der Besitzer, die Konsumenten und das genaue Ereignis, das den Besitz beendet. Die hier genannten Referenzen beziehen sich auf die Dokumentation von Addressables 2.7.

Abschluss und Besitz trennen

LoadAssetAsync liefert ein Operation-Handle zurück. Dieses Handle ist aufzubewahren, solange das Ergebnis genutzt wird, und danach freizugeben; mit der Freigabe wird das Handle ungültig. Auch fehlgeschlagene Operationen erfordern das Aufräumen des Handles. [1] Der Abschluss beantwortet, ob ein Ergebnis bereitsteht. Der Besitz beantwortet, wer es am Leben halten muss. In der Anwendung sind beide als getrennte Entscheidungen zu modellieren.

Verpflichtungen zählen, nicht Variablen

Addressables arbeitet mit Referenzzählern. Explizite Ladevorgänge sind mit Freigaben auszugleichen; erreicht ein Asset null Referenzen, wird sein Speicher nicht zwingend sofort freigegeben, weil auch die Lebensdauer der Bundles eine Rolle spielt. [2] Ein praxistauglicher Wrapper kann pro Anfrage genau eine Freigabepflicht erfassen, mit Zuständen wie pending, usable, obsolete und released. Das Aufräumen ist in diesem Wrapper idempotent zu gestalten, damit das Schliessen des Panels und der Abschluss der Anfrage nicht beide dieselbe Pflicht freigeben. Eine kopierte Variable sollte nie als Besitznachweis dienen.

Beispiel: ein Karussell zur Charakterauswahl

Angenommen, die Auswahl von Pilot A startet die Porträtanfrage 21. Noch vor deren Abschluss wählt der Spieler Pilot B aus, wodurch Anfrage 22 entsteht. Anfrage 21 bleibt erfasst, ihr Ergebnis wird aber als obsolete markiert. Sobald 21 abgeschlossen ist, wird ihr Ausgang geprüft, ihr Porträt nicht zugewiesen und ihr einziger Aufräumpfad ausgeführt. Wenn 22 erfolgreich abgeschlossen ist, wird deren Porträt angezeigt, und der Besitz bleibt bestehen, bis das Panel es ersetzt oder geschlossen wird. Ein Request-Identifier verhindert, dass ein alter Callback die neue Auswahl überschreibt. Das Schliessen des Panels sollte den Zugriff der Darstellung sofort ungültig machen, während die ausstehende Anfrage so lange erfasst bleibt, bis das Aufräumen abgeschlossen werden kann. Diese Regelung beschreibt das Verhalten der Anwendung; sie setzt nicht voraus, dass das Ausblenden eines Panels einen Download abbricht.

Grenzen und aussagekräftige Belege

Einzeln geladene Addressable-Assets werden nicht automatisch freigegeben, nur weil eine Szene entladen wird. [3] Szenenwechsel gehören deshalb in denselben Besitzplan. Zu testen sind fehlgeschlagene Ladevorgänge, schnelle Auswahlwechsel, wiederholte Öffnen-Schliessen-Zyklen und ein Schliessen unmittelbar vor dem Abschluss. Request-Identifier, Besitzwechsel und Freigabezähler sind zu protokollieren. Nach mehreren Zyklen sind die verbleibenden Assets und Bundles zu vergleichen, statt bei jeder Freigabe einen sinkenden Prozessspeicher zu erwarten. Ein bewusst geteilter Cache ist nur dann beizubehalten, wenn er eine definierte Verdrängungsstrategie und ein Speicherbudget hat.

Quellen

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