Overview
This post summarizes what I analyzed through my own experience. If anything is incorrect, I’d really appreciate a correction!
Addressables was created to make the legacy AssetBundle package easier for developers to use.
When I only introduced AssetBundles into the project and measured the resource build time, it was certainly faster than Addressables… but AssetBundle required loading all dependencies alongside a single prefab by default, which meant writing all that raw logic yourself.
So after wandering around trying to figure out how to handle things, I decided to dig into Addressables.
How It Works
- Inject an address into existing resources to register them as Addressables assets
- Build the checked Addressables resources (you can see what assets exist via step 3 in the Setup section)
- After building, a
catalog.jsonfile is generated, which records all assets and their versions - At runtime, calling
Addressables.InitializeAsyncreads thecatalog.jsonand caches bundle metadata in memory - Then, referencing that metadata,
Addressables.LoadAssetAsyncloads the resource into memory, followed byObject.Instantiate - The
AsyncOperationHandlereturned byAddressables.LoadAssetAsynchas aReleasemethod to unload from memory — I cached these in a Dictionary and called Release + Remove when the asset was no longer needed - Not using Resources seems to result in significantly less memory allocation!
Versions Used
- Unity 6000.3.9f1
- Addressables 2.7.2
Setup
- After installing Addressables, designate a specific folder and mark all resources inside as Addressables assets
- Run the build
- If there are script errors, the build won’t proceed
- Each platform needs to be built separately
- In
Window/Asset Management/Addressables/Groups, set PlayMode toUse Existing Build
Usage
I actually tried two approaches here.
Cache All Resources on Initialize
After calling
Addressables.InitializeAsync, load all resources in the folder viaLoadAssetsAsyncand cache them in memory upfront.
Not having to worry about allocating and releasing individual resources was nice, but the timing of “cache everything” became a problem.
In the Editor, caching was nearly instant — no issues at all. But on Android and iOS, it took 15 seconds… sometimes up to 20 seconds. (Based on a project with ~1,500 files and ~250 MB.)
So…
Cache Resources On Demand
Just call the recommended
LoadAssetAsyncwhen you need a resource.
Clean and simple. There’s a reason this is the recommended approach. Since we’re doing it this way, make sure to handle the AssetHandle properly when you’re done with it.
Comments