An asset loaded from an AssetBundle cannot be released from memory until both its reference count and all other asset reference counts in the same AssetBundle are at 0. The AssetBundle itself can be released from memory only when all asset reference counts in the AssetBundle are at 0.
As I understand it, Addressables keep a reference count of all assets in memory. When you use LoadAssetAsync, or any such method, the loaded asset’s reference count goes up by 1, and when you use Release, the reference count goes down. From the above quote, it sounds as if it stays in memory, taking up space until all other asset’s from the bundle are unloaded. Then, and only then, can it be unloaded by the Addressable’s system. Is that right?
I’m confused on this point: Say I have an assetbundle that contains like, idk, a ton of assets (ballpark estimate: 500), and I load a single asset from that bundle, the rest of the bundle isn’t loaded into memory, right? I guess my confusion is, what’s the difference between an asset and the bundle it belongs to? How are asset bundles released, are they just automatically released when all assets reference counts are released?
Keeping in mind this tight relationship between Addressables and AssetBundles, the most important rule when organizing your Addressables content is to create AssetBundles that contain discrete sets of assets that you expect to be loaded and unloaded together .
so not “ton of assets” but “discrete” set of assets which in math means “separated” groups of entities that have some logic behind.
How you group these assets depends of your game.
For example you have a fighting game like Tekken or Street Fighter:
You don’t create one huge asset bundle that has ALL the fighters packed together. You may create a bundle for each fighter, so if the game is a One vs One mode then you just load two asset bundles. If you want to replace a fighter mid game you load that fighter asset bundle and get unload the asset bundle of the fighter that will be replaced.
Just take a piece of paper and a pen and spend an afternoon thinking on how your game is structured and what data you need at some point in time, and try to group it together in the most efficient way possible.