Используют ли загружаемые во время выполнения ресурсы память / ресурсы, если они не используются? Больше, чем скомпилированные активы?

Question

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

1. Если я загружу эти ресурсы и сохраню их в памяти для последующего использования в игре, будут ли они потреблять системные ресурсы, просто скрытые в AssetLoader? Повлияет ли это на производительность?
2. Если я встраиваю эти ресурсы, будут ли они потреблять системные ресурсы, просто будучи скрытыми в скомпилированном SWF-файле?
3. Есть ли разница в производительности между этими двумя методами?

Answer 1

1. Они будут потреблять оперативную память, но не циклы процессора.На производительность в игре влияет только то, что используется вся ОЗУ, и программе необходимо использовать виртуальную память на жестком диске.

2. Встроенные ресурсы располагаются в ОЗУ, как и ресурсы, загруженные во время выполнения.описано выше.Однако они, вероятно, будут использовать меньше оперативной памяти, поскольку при компиляции в байт-код SWF при компиляции их размер файла, вероятно, будет уменьшаться.

3. Единственное снижение производительности ЦП происходит из-за загрузкии процессы создания экземпляров.

   • При загрузке активов во время выполнения объект Loader, используемый для получения активов, будет использовать циклы ЦП при сборе внешних данных.Скомпилированные ресурсы уже загружены, поэтому они выигрывают эту битву.
   • Во время построения скомпилированные активы создаются с использованием процесса, немного отличающегося от загруженных во время выполнения активов.Они занимают различное количество времени, чтобы построить.Я не уверен, насколько эти процессы различаются, но я думаю, что это довольно незначительно.Если загрузка выполняется более одного раза, я считаю, что загруженные во время выполнения ресурсы извлекаются из системного кэша, тогда как скомпилированные ресурсы существуют в SWF.Загруженные во время выполнения ресурсы также могут быть символами в SWF, которые экспортируются для совместного использования во время выполнения как часть общей библиотеки времени выполнения.

Answer 2

1. Да, может быть (в зависимости от доступной оперативной памяти, на современном компьютере, на котором не работает 3D Studio Max, я бы не подумал, что это будет серьезной проблемой, память дешевая).
2. Да, с точки зренияпамяти, см. выше с точки зрения производительности.
3. Это зависит, но в примере, который я пробовал со всем локальным Embed vs нагрузка во время выполнения, разница была незначительной, я думаю, что я собираюсь пойти с run-загрузка по времени, потому что я хочу загружать наборы изображений для анимации в стиле флипбук.

См. пример здесь (просмотр исходного кода включен, ссылки ниже, по-видимому, в «чистых AS3» проектах не устанавливаются правой кнопкой мышиПравильное меню при установке флажка для представления исходного кода в сборке выпуска):

http://www.shaunhusain.com/DrawTextRandomly/

http://www.shaunhusain.com/DrawTextRandomly/srcview/

Некоторые сведения, которые следует учитывать в приведенном выше примере, каждыйизображение размером ~ 1,5 КБ загружает 90 изображений для анимации взрыва.Используя 1 загрузчик снова и снова, для запуска локально потребовалось около 4 секунд. Я увеличил его до 90 загрузчиков, чтобы все они происходили одновременно, и это снизило скорость до 500 мс, что, на мой взгляд, разумно.Встраивание потребовало бы, чтобы я записал Embeds для каждого отдельного изображения (я использовал трассировку в цикле, чтобы выполнить это, чтобы проверить его, но производительность использования изображений во время выполнения была нулевой, чего, я полагаю, следовало ожидать)Как и вы, я не слишком озабочен наличием панели загрузки в течение нескольких секунд во время запуска, но не хочу продолжать добавлять Embeds, поскольку это просто делает код беспорядочным, поэтому я собираюсь выполнить загрузку во время выполнения(по крайней мере, пока).