Unity Addressables: designing explicit load and release lifetimes

A load creates a responsibility

An asset request can outlive the screen that requested it. A portrait may finish loading after its character panel has closed, or a preview may be replaced before its texture arrives. Design this lifetime before adding a loading spinner. Name the owner, the consumers and the exact event that ends ownership. The references here use Addressables 2.7 documentation.

Separate completion from ownership

LoadAssetAsync returns an operation handle. Preserve that handle while using its result, then release it; releasing invalidates the handle. Failed operations also need handle cleanup. [1] Completion answers whether a result is ready. Ownership answers who must keep it alive. Model those as separate decisions in your application.

Count obligations, not variables

Addressables uses reference counts. Balance explicit loads with releases; an asset reaching zero references does not necessarily free its memory immediately because bundle lifetimes matter. [2] A practical wrapper can record one release obligation per request, with states such as pending, usable, obsolete and released. Make cleanup idempotent within that wrapper so panel closure and completion cannot both release the same obligation. A copied variable should never be your ownership ledger.

Example: a character selection carousel

Suppose selecting pilot A starts portrait request 21. Before it completes, the player selects pilot B, creating request 22. Keep request 21 tracked but mark its result obsolete. When 21 completes, inspect its outcome, avoid assigning its portrait and perform its one cleanup path. When 22 completes successfully, show its portrait and retain ownership until the panel replaces it or closes. A request identifier prevents an old callback from overwriting the new selection. Closing the panel should invalidate presentation access immediately, while the outstanding request remains tracked until cleanup can complete. This policy describes application behaviour; it does not assume that hiding a panel cancels a download.

Limits and useful evidence

Separately loaded Addressable assets are not automatically released just because a scene unloads. [3] Include scene transitions in the same ownership plan. Test failed loads, rapid selection changes, repeated open-close cycles and a close that happens just before completion. Record request identifiers, ownership transitions and release counts. Compare retained assets and bundles after several cycles rather than expecting process memory to drop at every release. Keep an intentional shared cache only when it has a defined eviction policy and a memory budget.

Sources

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