Yield return unity что это
Coroutines
A coroutine allows you to spread tasks across several frames. In Unity, a coroutine is a method that can pause execution and return control to Unity but then continue where it left off on the following frame.
In most situations, when you call a method, it runs to completion and then returns control to the calling method, plus any optional return values. This means that any action that takes place within a method must happen within a single frame update.
In situations where you would like to use a method call to contain a procedural animation or a sequence of events over time, you can use a coroutine.
However, it’s important to remember that coroutines aren’t threads. Synchronous operations that run within a coroutine still execute on the main thread. If you want to reduce the amount of CPU time spent on the main thread, it’s just as important to avoid blocking operations in coroutines as in any other script code. If you want to use multi-threaded code within Unity, consider the C# Job System.
It’s best to use coroutines if you need to deal with long asynchronous operations, such as waiting for HTTP transfers, asset loads, or file I/O to complete.
Coroutine example
As an example, consider the task of gradually reducing an object’s alpha (opacity) value until it becomes invisible:
In this example, the Fade method doesn’t have the effect you might expect. To make the fading visible, you must reduce the alpha of the fade must over a sequence of frames to display the intermediate values that Unity renders. However, this example method executes in its entirety within a single frame update. The intermediate values are never displayed, and the object disappears instantly.
To work around this situation, you could add code to the Update function that executes the fade on a frame-by-frame basis. However, it can be more convenient to use a coroutine for this kind of task.
In C#, you declare a coroutine like this:
A coroutine is a method that you declare with an IEnumerator return type and with a yield return statement included somewhere in the body. The yield return null line is the point where execution pauses and resumes in the following frame. To set a coroutine running, you need to use the StartCoroutine function:
The loop counter in the Fade function maintains its correct value over the lifetime of the coroutine, and any variable or parameter is preserved between yield statements.
Coroutine time delay
By default, Unity resumes a coroutine on the frame after a yield statement. If you want to introduce a time delay, use WaitForSeconds:
You can use WaitForSeconds to spread an effect over a period of time, and you can use it as an alternative to including the tasks in the Update method. Unity calls the Update method several times per second, so if you don’t need a task to be repeated quite so often, you can put it in a coroutine to get a regular update but not every single frame.
For example, you can might have an alarm in your application that warns the player if an enemy is nearby with the following code:
If there are a lot of enemies then calling this function every frame might introduce a significant overhead. However, you could use a coroutine to call it every tenth of a second:
This reduces the number of checks that Unity carries out without any noticeable effect on gameplay.
Stopping coroutines
To stop a coroutine, use StopCoroutine and StopAllCoroutines. A coroutine also stops if you’ve set SetActive to false to disable the GameObject The fundamental object in Unity scenes, which can represent characters, props, scenery, cameras, waypoints, and more. A GameObject’s functionality is defined by the Components attached to it. More info
See in Glossary the coroutine is attached to. Calling Destroy(example) (where example is a MonoBehaviour instance) immediately triggers OnDisable and Unity processes the coroutine, effectively stopping it. Finally, OnDestroy is invoked at the end of the frame.
Analyzing coroutines
Coroutines execute differently from other script code. Most script code in Unity appears within a performance trace in a single location, beneath a specific callback invocation. However, the CPU code of coroutines always appears in two places in a trace.
All the initial code in a coroutine, from the start of the coroutine method until the first yield statement, appears in the trace whenever Unity starts a coroutine. The initial code most often appears whenever the StartCoroutine method is called. Coroutines that Unity callbacks generate (such as Start callbacks that return an IEnumerator ) first appear within their respective Unity callback.
The rest of a coroutine’s code (from the first time it resumes until it finishes executing) appears within the DelayedCallManager line that’s inside Unity’s main loop.
This happens because of the way that Unity executes coroutines. The C# compiler auto generates an instance of a class that backs coroutines. Unity then uses this object to track the state of the coroutine across multiple invocations of a single method. Because local-scope variables within the coroutine must persist across yield calls, Unity hoists the local-scope variables into the generated class, which remain allocated on the heap during the coroutine. This object also tracks the internal state of the coroutine: it remembers at which point in the code the coroutine must resume after yielding.
Because of this, the memory pressure that happens when a coroutine starts is equal to a fixed overhead allocation plus the size of its local-scope variables.
You can use the Unity Profiler A window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating, or in your game logic. More info
See in Glossary to inspect and understand where Unity executes coroutines in your application. To do this, profile your application with Deep Profiling enabled, which profiles every part of your script code and records all function calls. You can then use the CPU Usage Profiler module to investigate the coroutines in your application.
Profiler session with a coroutine in a DelayedCall
It’s best practice to condense a series of operations down to the fewest number of individual coroutines possible. Nested coroutines are useful for code clarity and maintenance, but they impose a higher memory overhead because the coroutine tracks objects.
If a coroutine runs every frame and doesn’t yield on long-running operations, it’s more performant to replace it with an Update or LateUpdate callback. This is useful if you have long-running or infinitely looping coroutines.
Как сделать корутины в Unity немного удобнее
Каждый разработчик находит свои преимущества и недостатки использования корутин в Unity. И сам решает в каких сценариях их применить, а в каких отдать предпочтение альтернативам.
В повседневной практике я достаточно часто использую корутины для различных видов задач. Однажды, я понял, что именно меня в них раздражает и отторгает многих новичков.
Кошмарный интерфейс
Движок предоставляет всего пару методов и несколько их перегрузок для работы с корутинами:
Запуск (docs)
Остановка (docs)
Перегрузки со строковыми параметрами (не смотря на их обманчивое удобство) можно сразу отправить на помойку забыть как минимум по трем причинам.
С одной стороны, предоставленных методов вполне достаточно, чтобы покрыть базовые потребности. Но со временем я начал замечать, что при активном использовании приходится писать большое количество шаблонного кода — это утомляет, и ухудшает его читаемость.
Ближе к сути
В этой статье я хочу описать небольшую обертку, которую я применяю уже давно. Благодаря ей, с мыслями о корутинах у меня в голове больше не возникают фрагменты шаблонного кода, с которым приходилось вокруг них плясать. Кроме этого, всей команде стало проще читать и понимать компоненты, где используются корутины.
Допустим, перед нами стоит следующая задача — написать компонент, который позволяет перемещать объект к заданной точке.
В данным момент не играет роли, каким именно методом будет выполняться передвижение и в каких координатах. Мной будет выбран лишь один из множества вариантов — это интерполяция и глобальные координаты.
Стандартная реализация
Предлагаю следующий вариант реализации необходимого компонента:
В методе Move очень важно запускать корутину только в тому случае, когда она еще еще не запущена. Иначе их можно будет запустить сколько угодно и каждая из них будет перемещать объект.
threshold — допуск. Другими словами, расстояние к точке, приблизившись на которое мы будем считать, что достигли цели.
Для чего это нужно
Мы проверяем расстояние к цели на больше/меньше, что позволяет нам избежать данной проблемы.
Пока что это всё, наш компонент достаточно прост. И в текущий момент никаких проблем нет. Но, что это за компонент, позволяющий двигать объект к точке, но не предоставляющий возможность его остановить. Давайте исправим эту несправедливость.
Так как мы с вами решили не переходить на сторону зла, и не использовать перегрузки со строковыми параметрами, теперь нам нужно сохранить где-то ссылку на запущенную корутину. Иначе как потом остановить её?
Добавим метод остановки движения:
Совсем другое дело! Хоть к ране прикладывай.
Итак. Мы имеем небольшой компонент, который выполняет поставленную задачу. В чем же моё негодование?
Проблемы и их решение
Со временем, проект растёт, а вместе с ним и количество компонентов, в том числе использующих корутины. И с каждым разом мне всё больше не дают покоя вот какие вещи:
Один их вид заставляет мой глаз дергаться, да и читать такой код сомнительное удовольствие (согласен, бывает и хуже). Но ведь куда приятнее и нагляднее было бы иметь что-нибудь в таком роде:
Иначе, по причине отсутствия ссылки на корутину, вы попросту не сможете ее остановить.
Если забудете, то получите одноразовую корутину. После первого запуска в moveRoutine так и останется ссылка на корутину, и новую запустить уже не выйдет.
Точно так же нужно сделать и в случае принудительной остановки:
Давайте же наконец-то это сделаем!
Routine — делегат, с которым будет сообщен метод, выполняющий роль корутины.
IsProcessing — позволяет узнать, выполняется ли корутина в текущий момент.
Таким образом мы избавляемся от большого количества головной боли, а наш компонент приобретает совсем другой вид:
Осталась лишь сама корутина и несколько строчек кода для работы с ней. Значительно лучше.
Допустим, пришла новая задача — нужно добавить возможность выполнить любой код после того, как объект достиг цели.
В изначальном варианте нам пришлось бы в каждую корутину добавлять дополнительный параметр-делегат, который можно дернуть по ее завершении.
И вызывать следующим образом:
А если еще в качестве обработчика будет какая-нибудь лямбда, то смотрится еще страшнее.
С нашей же оберткой достаточно лишь один раз добавить в нее это событие.
А затем, при необходимости, подписаться.
Полагаю, вы уже обратили внимание на то, что текущий вариант обертки предоставляет возможность работать только с корутинами без параметров. Поэтому мы можем написать обобщенную обертку для корутин с одним параметром. Остальные делаются по аналогии.
Но, по хорошему, было бы неплохо сначала вынести код, который будет одинаковым для всех оберток, в какой-то базовый класс, чтобы не писать одно и то же. Мы ведь с этим и боремся.
И теперь, собственно говоря, обертка для корутин с одним параметром:
Как видим, код практически такой же. Лишь в некоторых местах добавились фрагменты, зависящие от количества аргументов.
Есть множество вариантов, как можно еще больше расширить функциональность этой обертки: добавить запуск с задержкой, события с параметрами, возможное отслеживание прогресса корутины и прочее. Но я предлагаю на этом этапе остановиться.
Цель данной статьи — желание поделиться насущными проблемами, с которыми я столкнулся и предложить вариант их решения, а не покрыть возможные потребности всех разработчиков.
Надеюсь, как новички, так и опытные товарищи почерпнут пользу из моего опыта. Возможно, поделятся своим в комментариях или укажут на ошибки, которые я мог допустить.
Зачем в Unity корутины?
Зачем в Unity корутины? Ведь, насколько я понял, они позволяют выполнять параллельно какие то действия, во время основной работы программы. Цикл ожидания подключения там крутить. В Unity в каждом скрипте мы можем завести Update,FixedUpdate,LateUpdate. При этом у нас есть такой отличный метод как InvokeRepeating, который тоже может
параллельно что то своё запускать, с нужной частотой, и не раз в каждом скрипте.
При том что самих скриптов может быть сколько угодно.
Есть ли какая то реальная необходимость сопрограмм в Unity? Может, они лучше с точки зрения производительности? Или могут применяться более точно?
1 ответ 1
Во-первых, сразу напишу, что не совсем корректно сравнивать корутину с Update,FixedUpdate,LateUpdate и InvokeRepeating. Ибо она может выполняться только один раз. Например
выведет Start game и через 3 секунды Coroutine is work. Всё. Никаких повторных вызовов.
Будет выведено «Test0», а через 1,5 секунды «Test00», «Test1» (т.к. программа продолжило выполнение с момента где остановилась и потом опять продолжила цикл). потом «Test11», «Test2» и т.д.
Таким образом корутина позволяет прерывать вычисления, отдавать ресурсы в основной поток, а потом возобновлять следующую часть вычислений.
Другой пример: нам нужно инстанциировать 10.000 объектов. Порциями по 10-100 или просто в цикле, неважно. Если мы воткнем это в методе Update, то пока цикл не отработает обновления экрана не будет, приложение «висит» все это время. У пользователя «бомбит». То есть корутину можно применять для длительных операций, которые можно «размазать» по кадрам. Причем (как написано выше) можно вызывать примерно следующую последовательно действий:
другой пример с пулями:
Такую работу проделать InvokeRepeating не позволит в принципе.
Еще пример. Мы хотим, чтобы до прогона действий и после что-то происходило, например логирование сообщений сделано что-то или нет. Как это делать в InvokeRepeating или Update? Вешать всякий флаги было сделано что-то или нет, зашел в метод или нет? Зачем, если можно сделать её в корутине
А еще корутина может дожидаться действий от ForFixedUpdate, т.е. прерывает выполнение до кадра, в котором обновляется физика (вызывается посредством WaitForFixedUpdate) или конца фрейма (WaitForEndOfFrame). Что бывает полезно сделать и для того же InvokreRepeating придется лепить что-то для этого.
В итоге. Как я описал выше: корутину можно применять для длительных операций, которые можно «размазать» по кадрам от которых главный поток не повиснет. Для некой отдельной микропрограммки, которая будет работать параллельно (пример с миганием спрайта, или запустить персонажа бродить в одну сторону и в другую «tween»), которую сложно зарепитить из-за разности действий.
Кастомные корутины в Unity с преферансом и куртизанками
Вы уже настолько круты, что вертите корутинами вокруг всех осей одновременно, от одного вашего взгляда они выполняют yield break и прячутся за полотно IDE. Простые обертки — давно пройденный этап.
Вы настолько хорошо умеете их готовить, что могли бы получить звезду Мишлена (а то и две), будь у вас свой ресторан. Конечно! Никто не останется равнодушным, отведав ваш Буйабес с корутинным соусом.
Уже целую неделю код в проде не падает! Обертки, callback ’и и методы Start/Stop Coroutine — удел холопов. Вам нужно больше контроля и свободы действий. Вы готовы подняться на следующую ступеньку (но не бросить корутины, конечно).
Если в этих строках вы узнали себя, — добро пожаловать под кат.
Пользуясь случаем, хочу передать привет одному из моих любимых паттернов — Command.
Введение
Для кастомных yield инструкций Unity предоставляет одноименный класс CustomYieldInstruction (docs).
Достаточно лишь наследоваться от него и реализовать свойство keepWaiting. Его логику мы уже обсудили выше. Оно должно возвращать true до тех пор, пока корутина должна выполняться.
Пример из документации:
Если вы работаете с кодом, в котором определенные вещи должны сработать в конкретный момент, и до сих пор не изучили вот эту страницу — настоятельно рекомендую решиться на сей подвиг.
Кастомные yield инструкции
Но мы же с вами сюда пришли не очередные обертки на подобие CustomYieldInstruction наследовать. За такое можно и без Мишлена остаться.
Потому курим дальше документацию и практически на дне всё той же страницы находим самый важный абзац.
To have more control and implement more complex yield instructions you can inherit directly from System.Collections.IEnumerator class. In this case, implement MoveNext() method the same way you would implement keepWaiting property. Additionally to that, you can also return an object in Current property, that will be processed by Unity’s coroutine scheduler after executing MoveNext() method. So for example if Current returned another object inheriting from IEnumerator , then current enumerator would be suspended until the returned one has completed.
Чтобы получить больше контроля и реализовать более комплексные yield инструкции, вы можете наследоваться непосредственно от интерфейса System.Collections.IEnumerator . В этом случае, реализуйте метод MoveNext() таким же образом, как свойство keepWaiting . Кроме этого, вы можете использовать объект в свойстве Current , который будет обработан планировщиком корутин Unity после выполнения метода MoveNext() . Например, если свойство Current возвращает другой объект реализующий интерфейс IEnumerator , выполнение текущего перечислителя будет отложено, пока не завершится выполнение нового.
Святые моллюски! Это же те контроль и свобода действий, которых так хотелось. Ну всё, теперь то вы так корутинами завертите, что никакой Gimbal Lock не страшен. Главное, от счастья, прод с вертухи не грохнуть.
Интерфейс
Что ж, было бы неплохо начать с того, чтобы определиться, какой интерфейс взаимодействия с нашей инструкцией мы хотим иметь. Некий минимальный набор.
Предлагаю следующий вариант
Хочу обратить ваше внимание, что здесь IsExecuting и IsPaused не противоположные вещи. Если выполнение корутины на паузе, она всё еще выполняется.
Пасьянс и куртизанки
Стоит учитывать, что есть как минимум два способа, которыми наша инструкция может быть запущена:
Метод StartCoroutine(IEnumerator routine) :
Также, методы для обработки событий в дочерних классах:
Они будут вызываться вручную непосредственно перед соответствующими событиями, чтобы предоставить дочерним классам приоритет их обработки.
Теперь оставшиеся методы.
Здесь всё просто. Инструкцию можно поставить на паузу только в том случае, если она выполняется и если ещё не приостановлена, и продолжить выполнение, только если оно приостановлено.
Основной метод запуска тоже крайне прост — запуск будет произведен только в том случае, если инструкция еще не запущена.
И самое интересное, но от этого не более сложное, — MoveNext :
if (!Update()) — метод Update в наших инструкциях будет работать точно так же, как keepWaiting в CustomYieldInstruction и должен быть реализованным в дочернем классе. В Instruction это просто абстрактный метод.
Примеры
Базовый класс готов. Для создания любых инструкций достаточно наследовать его и реализовать необходимые члены. Предлагаю взглянуть на несколько примеров.
Как шаблон StartCoroutine / yield return работает в Unity?
Я понимаю принцип сопрограмм. Я знаю, как заставить стандарт StartCoroutine / yield return шаблон работать на C # в Unity, например, вызвать метод, возвращающийся IEnumerator через, StartCoroutine и в этом методе что-то сделать, сделать, yield return new WaitForSeconds(1); чтобы подождать секунду, а затем сделать что-то еще.
У меня вопрос: что на самом деле происходит за кулисами? Что на StartCoroutine самом деле делает? Что IEnumerator это WaitForSeconds возвращение? Как StartCoroutine вернуть управление «чему-то еще» в вызываемом методе? Как все это взаимодействует с моделью параллелизма Unity (где множество вещей происходит одновременно без использования сопрограмм)?
Подробнее о сопрограммах Unity3D
Многие процессы в играх происходят в течение нескольких кадров. У вас есть «плотные» процессы, такие как поиск пути, которые усердно работают с каждым кадром, но разделяются на несколько кадров, чтобы не слишком сильно влиять на частоту кадров. У вас есть «разреженные» процессы, такие как триггеры игрового процесса, которые ничего не делают в большинстве кадров, но иногда требуются для выполнения важной работы. И у вас есть разные процессы между ними.
Было бы здорово, если бы вместо того, чтобы явно отслеживать все это состояние в нескольких фреймах и вместо многопоточности и управления синхронизацией, блокировкой и т. Д., Вы могли бы просто написать свою функцию как единый фрагмент кода, и отметить конкретные места, где функция должна «приостановиться» и продолжиться позже?
Как они выглядят? В «Unityscript» (Javascript):
Как они работают? Позвольте мне сразу сказать, что я не работаю в Unity Technologies. Я не видел исходного кода Unity. Я никогда не видел внутренностей движка сопрограмм Unity. Однако, если они реализовали это способом, радикально отличным от того, что я собираюсь описать, я буду очень удивлен. Если кто-нибудь из UT захочет вмешаться и поговорить о том, как это работает на самом деле, это было бы здорово.
Теперь вот трюк. Не имеет значения, каковы фактические значения, возвращаемые последовательностью. Вы можете повторно вызывать MoveNext () и игнорировать Current; вычисления по-прежнему будут выполняться. Каждый раз, когда вызывается MoveNext (), ваш блок итератора переходит к следующему оператору yield, независимо от того, какое выражение он фактически дает. Итак, вы можете написать что-то вроде:
Или, что более полезно, вы можете смешать это с другой работой:
Все зависит от времени. Как вы видели, каждый оператор yield return должен предоставлять выражение (например, null), чтобы блоку итератора было что-то присвоить IEnumerator.Current. Длинная последовательность нулей не совсем полезна, но нас больше интересуют побочные эффекты. Не так ли?
На самом деле, с этим выражением можно сделать что-то полезное. Что, если вместо того, чтобы просто выдавать значение null и игнорировать его, мы получили что-то, что указывало бы, когда мы ожидаем, что нам потребуется выполнить больше работы? Часто нам нужно будет сразу перейти к следующему кадру, конечно, но не всегда: будет много раз, когда мы захотим продолжить после того, как анимация или звук закончится, или по прошествии определенного времени. Те while (playsAnimation) yield return null; Конструкции немного утомительны, вам не кажется?
Unity объявляет базовый тип YieldInstruction и предоставляет несколько конкретных производных типов, указывающих на определенные виды ожидания. У вас есть WaitForSeconds, которая возобновляет работу сопрограммы по истечении заданного времени. У вас есть WaitForEndOfFrame, который возобновляет сопрограмму в определенной точке позже в том же кадре. У вас есть сам тип Coroutine, который, когда сопрограмма A дает сопрограмму B, приостанавливает сопрограмму A до завершения сопрограммы B.
На что это похоже с точки зрения времени выполнения? Как я уже сказал, я не работаю в Unity, поэтому я никогда не видел их кода; но я бы предположил, что это может выглядеть примерно так:
Пара неочевидных ответвлений Во всем этом есть пара полезных вещей, которые люди иногда упускают, и я подумал, что должен указать на них.
Конкретные строки yield return new WaitForSeconds (), yield return new WaitForEndOfFrame () и т. Д. Являются обычными, но сами по себе они не являются специальными формами.
В-третьих, тот факт, что вы можете уступать другим сопрограммам, может как бы позволить вам реализовать свои собственные YieldInstructions, хотя и не так эффективно, как если бы они были реализованы движком. Например: