Оптимизация скриптов

Простое объяснение понятия “автоматическое управление памятью”

Дело в том, что частое использование Instantiate и Destroy подкидывает сборщику мусора прилично работы, что может привести к рывкам во время игры. Как рассказано на странице про автоматическое управление памятью, существуют другие способы обойти основные проблемы с производительностью, окружающие Instantiate и Destroy, такие как ручной запуск сборщика мусора пока на экране ничего не происходит, или очень частый его запуск для предотвращения накапливания большого количества работы для сборщика.

Во введении в методы оптимизированного скриптинга в качестве примера пересечения игрового процесса и хорошего дизайна кода мы привели пулинг объектов. Использование пулинга объектов для недолговечных объектов быстрее, чем их создание и уничтожение, т.к. пулинг упрощает процесс выделения памяти, исключает динамическое выделение памяти и сборку мусора (Garbage Collection или GC).

Существует бесплатное расширение для редактора Sprite Packer, которое позволят создавать системы частиц из анимированных спрайтов. Оно отрисовывает кадры вашего объекта в текстуру, которая затем может использоваться в качестве атласа анимированных спрайтов для системы частиц. В нашем случае, мы могли бы использовать его для вращения монетки.

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

Другая причина в том, что иногда в память должны прогрузиться дополнительные вещи при создании первого экземпляра определённого префаба, либо в GPU должны загрузиться текстуры и меши. Это также может вызвать рывок, а при использовании пулинга объектов это произойдёт при загрузке уровня, а не во время игры.

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

Почему пулинг объектов быстрее

то MyFunction получит копию foo. Память для foo никогда не выделяется из кучи и никогда не подвергается сборке мусора. Если MyFunction изменяет свою копию foo, то это не влияет на остальные foo.

Игровой пример O(n 2 ) операции — 100 врагов, где ИИ каждого врага учитывает передвижения всех остальных врагов. Возможно будет быстрее разбить карту на ячейки, записать передвижение каждого врага в соседнюю ячейку и затем заставить каждого из врагов проверять несколько ближайших ячеек. Тогда это была бы O(n) операция.

Это может работать медленно, если среди них достаточно много бегущих одновременно. Небольшой известный факт: все поля для доступа к компонентам в MonoBehaviour, такие как transform, renderer, и audio, эквивалентны соответствующим вызовам GetComponent(Transform), и потому они работают немного медленно. Метод GameObject.FindWithTag был оптимизирован, но в некоторых случаях, например, во вложенных циклах, или в скриптах, которые запущены на большом количестве экземпляров, оно тоже может работать немного медленно.

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

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

Предположим, что алгоритм будет работать с самым худшим случаем: входящие числа отсортированы, но в обратном порядке. В таком случае, вложенный цикл выполнится j раз. В среднем, когда i меняется от 1 до arr.Length–1, j будет arr.Length/2. С точки зрения O(n), arr.Length — это наше n, так что, в итоге вложенный цикл выполнится n*n/2 раз, или n 2 /2 раз. Но в рамках O(n) мы выбрасываем все постоянные вроде 1/2, т.к. мы желаем говорить о том, как увеличивается количество операций, а не о самом количестве операций. Так что алгоритм будет таким: O(n 2 ). Порядок операций имеет большое значение при работе с большим набором данных, т.к. количество операций может стремительно расти по экспоненциальной кривой.