Польза Addressables в Unity3D и варианты использования

В Unity3D есть новый инструмент Addressables, для чего он нужен и в чём сложности его использования читайте в этой статье.

Польза Addressables в Unity3D и варианты использования
5353

Я бы ещё добавил, что разные пакеты работают избыточно, в т.ч. пакуя скипты. Т.е. каждый пакет(бандл по сути) собирает достаточные данные для запуска. Это не было бы проблемой, если бы при загрузке ресурс переиспользовали с других бандлов, а не загружали новый.

И если какой-то объект есть в 2 пакетах, то будет отдельно грузиться для каждого. Что решается очередным пакетом, который содержит объединённые данные этих 2 пакетов. На деле это не работает, т.к. для 3 пакетов так уже не получится сделать. А сами объекты можно загружать максимум на 2 уровня, бандл, и, скажем, префаб или сцену. А вот уже их содержимое загрузить отдельно нельзя.

Для хорошего контроля памяти, на коммерческом проекте, нужно будет подгонять всё под систему. Либо забить на перфекционизм и мириться с тем, что загружаем, по сути, один и тот же объект, из разных мест, т.к. этот объект находится на 3 уровне вложенности в разных бандлах. Ну и ещё вариант, гипотетический - делаем тысячи пакетов, грузим каждый ассет вручную, а уже десятки тысяч объектов как-то там выстроят взаимосвязь, может и пол года не пройдёт.

PS: Может в новой версии это работает лучше, давно не проверял. Мне интересно, как это работает со скриптами и рефлексией, если кто знает, опишите.
PPS: Что им мешало сделать общее хранилище по идентификатору(со счётчиком)? Почему нельзя было сделать автоматический подхват ссылок и автопрогрузку только требуемых для сцены объектов, при загрузке оной? Почему Опять контроль памяти ручками? Если систему закачки и формирование бандлов затронуть, то там ещё больше вопросов будет.

Ответить

Если я правильно понимаю принцип работы бандлов, то они вообще не грузят скрипты, только данные, никакого кода. Что будет со стриппингом тоже интересный для меня вопрос. 
"Почему нельзя было сделать автоматический подхват ссылок и автопрогрузку только требуемых для сцены объектов, при загрузке оной?" 
Сейчас так и есть без всяких Addressables, вместе со сценой грузится только то, что нужно для этой сцены, если же мы используем Addressables, то можно делать InstantiateAsync для каждого объекта. Весь смысл Addressables в том чтобы отделить загрузку лёгких ассетов от тяжёлых, например, сцена может грузиться лоупольная стандартной механикой без Addressables, а после загрузки появляются хайполи модельки там где это нужно в первую очередь уже через асинхронную подгрузку.
"Почему Опять контроль памяти ручками?"
В самом конце статьи говорится о том что не нужен контроль ручками, не забываем только загружать и выгружать, это единственное условие.
На каждый InstantiateAsync нужен свой ReleaseInstance, дальше память будет сама за собой следить.

1
Ответить