Анализ сопутствующих программ
Корутины выполняются по-разному, чем другие коды скриптов. Большинство кодов скриптов в Unity появляются в трассировке производительности в одном месте, под конкретным вызовом обратного вызова. Однако код CPU корутины всегда появляются в двух местах в трассировке:
Весь начальный код в коррутине, от начала метода коррутины до первого инструкции
yield, появляется в трее всякий раз, когда Unity запускает коррутину. Начальный код чаще всего появляется всякий раз, когда вызывается методStartCoroutine. Коррутины, которые генерируются обратными вызовами Unity (такие как обратные вызоваStart, возвращающиеIEnumerator) впервые появляются в их соответствующих обратных вызовах Unity.Остальная часть кода коррутины (с первого раза, когда она возобновляется, до завершения выполнения) появляется в
DelayedCallManagerстрока в основном цикле Unity. Это связано с тем, как Unity выполняет сопутствующие программы. Компилятор C# автоматически создаёт экземпляр класса, обслуживающего корутины. По этому объекту Unity отслеживает состояние корутины между несколькими вызовами одного метода. Поскольку локальные переменные внутри корутины должны сохраняться междуyieldвызовами, Unity поднимает локальные переменные в сформированный класс, и они остаются в куче на всё время работы корутины. Этот же объект отслеживает внутреннее состояние корутины: он помнит, с какого места кода корутина должна продолжиться после yield.
По этим причинам память, выделяемая при запуске сопутствующей программы, равна фиксированному выделению накладных расходов плюс размер переменных локальной области.
Код, запускающий сопроцесс, конструирует и вызывает объект, а затем DelayedCallManager Unity вызывает его снова, когда выполняется условие yield сопроцесса. Поскольку сопроцессы обычно начинаются вне других сопроцессов, это разделяет их исполнение между вызовами yield и DelayedCallManager.
Мониторинг и улучшение результатов работы
Вы можете использовать Unity Profiler, чтобы проверить и понять, где Unity выполняет сопутствующие процедуры в вашем приложении. Для этого профилируйте ваше приложение с включенным Deep Profiling, который профилирует каждую часть кода вашего скрипта и записывает все вызова функций. Затем вы можете использовать CPU Usage Profiler модуль, чтобы исследовать сопутствующие процедуры в вашем приложении.
Наилучшей практикой является конденсировать серию операций до наименьшего количества индивидуальных сопутствующих процедур, насколько это возможно. Вложенные сопутствующие процедуры полезны для ясности кода и обслуживания, но они налагают более высокую нагрузку на память, потому что сопутствующая процедура отслеживает объекты.
Если сопутствующая программа запускает каждый кадр и не запускает yield при долгосрочных операциях, более эффективно заменить ее обратным вызовом Update или LateUpdate. Это полезно, если у вас есть долгосрочные или бесконечно повторяющиеся сопутствующие программы.