Какие стратегии загрузки контента используются с Addressables в Unity

Что проверяют

Работали ли вы с Addressables на реальном проекте или знаете только LoadAssetAsync. Интервьюера интересует связка трёх вещей: как контент разложен по группам, когда он скачивается и когда выгружается из памяти. Следом почти всегда спрашивают, почему после Release память не освободилась.

Как отвечать

Разделите ответ на уровень сборки и уровень кода:

• локальные и удалённые группы: базовый контент едет в билде, остальное лежит на CDN и докачивается. Так уменьшают размер установки;
• упаковка бандлов: Pack Together, Pack Separately или по меткам. Мелкие бандлы дают точную выгрузку, но больше запросов и тяжелее каталог;
• загрузка по требованию: LoadAssetAsync<T> по адресу, LoadAssetsAsync по метке, LoadSceneAsync для сцен, InstantiateAsync для префабов;
• предзагрузка: GetDownloadSizeAsync показывает объём, DownloadDependenciesAsync качает бандлы заранее, например на экране загрузки с прогрессом;
• обновление без релиза: CheckForCatalogUpdates и UpdateCatalogs подтягивают новый каталог, и игрок получает изменённые ассеты без переустановки.

Отдельно скажите про память. Хэндлы считаются по ссылкам, и бандл выгружается, только когда отпущены все ассеты из него. Поэтому на каждый Load нужен парный Release, а на InstantiateAsync парный ReleaseInstance. Скачанные удалённые бандлы кэшируются на диске, и это не то же самое, что ассет в памяти.

Где спотыкаются

Забывают Release. Хэндлы копятся, счётчик ссылок не падает до нуля, и память растёт от сцены к сцене.

Складывают всё в один большой бандл. Тогда отпустить половину ассетов бесполезно: бандл держится целиком, пока жив хотя бы один из них.

Не следят за дублированием. Если общий материал не вынесен в свою группу, он копией попадает в несколько бандлов, и это видно только в отчёте сборки или в правилах Analyze. Рядом ещё одна ловушка: WaitForCompletion на удалённом ассете замораживает главный поток до конца скачивания.