часто ссылается Unity3D coroutines подробно ссылка мертвая. Поскольку это упоминается в комментариях и ответах, я собираюсь опубликовать содержание статьи здесь. Это содержание происходит от это зеркало.

Unity3D coroutines подробно

многие процессы в игре происходят в течение нескольких кадров. У вас есть "плотные" процессы, такие как pathfinding, которые усердно работают каждый кадр, но получают разделить на несколько кадров, чтобы не слишком сильно влиять на частоту кадров. У вас есть "разреженные" процессы, такие как триггеры геймплея, которые ничего не делают большинство кадров, но иногда призваны выполнять критическую работу. И у вас есть разные процессы между ними.

всякий раз, когда вы создаете процесс, который будет проходить через несколько кадров – без многопоточности – вам нужно найти способ разбить работу на куски, которые могут быть запущены по одному кадру. Для любого алгоритм с центральным циклом, это довольно очевидно: a * pathfinder, например, может быть структурирован таким образом, что он поддерживает свои списки узлов полупостоянно, обрабатывая только несколько узлов из открытого списка каждый кадр, вместо того, чтобы пытаться сделать всю работу за один раз. В конце концов, если вы блокируете частоту кадров на 60 или 30 кадров в секунду, то ваш процесс будет выполнять только 60 или 30 шагов в секунду, и это может привести к тому, что процесс просто слишком долго. Аккуратный дизайн может предложить наименьшую возможную единицу работы на одном уровне-например, обработать один узел A* – и слой сверху способ группировки работы вместе в большие куски-например, продолжать обработку узлов A* в течение X миллисекунд. (Некоторые люди называют это "timeslicing", хотя я этого не делаю).

тем не менее, позволяя работе быть разбитой таким образом, означает, что вы должны передать состояние от одного кадра к другому. Если вы нарушаете итерационный алгоритм, то вы должны сохранить все состояние, общее для итераций, а также средство отслеживания, какая итерация должна быть выполнена следующей. Обычно это не так уж плохо – дизайн класса "A * pathfinder" довольно очевиден – - но есть и другие случаи, которые менее приятны. Иногда вы столкнетесь с длинными вычислениями, которые выполняют разные виды работы от кадра к кадру; объект, захватывающий их состояние, может закончиться большим беспорядком полуполезных "местных жителей", сохраняемых для передачи данных из один кадр за другим. И если вы имеете дело с редким процессом, вам часто приходится внедрять небольшую государственную машину, чтобы отслеживать, когда работа должна быть выполнена вообще.

не было бы аккуратно, если бы вместо того, чтобы явно отслеживать все это состояние на нескольких кадрах, и вместо того, чтобы многопоточно и управлять синхронизацией и блокировкой и так далее, вы могли бы просто написать свою функцию как один кусок кода и отметить определенные места, где функция должна "пауза" и продолжить позже?

единство – вместе с рядом других средах и языках – предоставляет такую возможность в виде сопрограмм.

как они выглядят? В "Unityscript" (Javascript):

function LongComputation()
{
    while(someCondition)
    {
        /* Do a chunk of work */

        // Pause here and carry on next frame
        yield;
    }
}

В C#:

IEnumerator LongComputation()
{
    while(someCondition)
    {
        /* Do a chunk of work */

        // Pause here and carry on next frame
        yield return null;
    }
}

как они работают? Позвольте мне сразу сказать, что я не работаю на Unity Technologies. Я не видел исходный код Unity. Я никогда не видел мужества. двигателя сопрограмма единства. Однако, если они реализовали его способом, который радикально отличается от того, что я собираюсь описать, тогда я буду очень удивлен. Если кто-нибудь из UT хочет вмешаться и поговорить о том, как это на самом деле работает, тогда это было бы здорово.

Большие Ключи в версии C#. Во-первых, обратите внимание, что типом возврата для функции является IEnumerator. И во-вторых, обратите внимание, что одно из заявлений-yield возвращаться. Это означает, что yield должен быть ключевым словом, и поскольку поддержка Unity C# - это vanilla C# 3.5, это должно быть ключевое слово vanilla C# 3.5. Действительно,вот он в MSDN – говорим о том, что называется ‘итератор блоков.- Так что же происходит?

во-первых, есть этот тип IEnumerator. Тип IEnumerator действует как курсор над последовательностью, предоставляя два значимых элемента: Current, который является свойством, дающим вам элемент, над которым курсор в настоящее время находится, и MoveNext (), функция, которая перемещается к следующему элементу в последовательность. Поскольку IEnumerator является интерфейсом, он не указывает точно, как эти члены реализованы; MoveNext() может просто добавить один ток, или он может загрузить новое значение из файла, или он может загрузить изображение из интернета и хэшировать его и сохранить новый хэш в текущем... или он может даже сделать одну вещь для первого элемента в последовательности, и что-то совершенно другое для второго. Вы даже можете использовать его для генерации бесконечной последовательности, если захотите. метод MoveNext() вычисляет следующее значение в последовательности (возвращает false, если больше нет значений), а Current получает вычисленное значение.

обычно, если вы хотите реализовать интерфейс, вам нужно написать класс, реализовать членов и так далее. Блоки итераторов-удобный способ реализации IEnumerator без всех этих хлопот – вы просто следуете нескольким правилам, и реализация IEnumerator генерируется автоматически компилятором.

An блок итератора-это регулярная функция, которая (a) возвращает IEnumerator, и (b) использует ключевое слово yield. Итак, что же на самом деле делает ключевое слово yield? Он заявляет, что следующее значение в последовательности или нет больше значений. Точка, в которой код сталкивается с выходом return X или yield break-это точка, в которой IEnumerator.MoveNext () должен остановиться; возврат доходности X заставляет MoveNext () возвращать true andCurrent для присвоения значения X, в то время как выход перерыв вызывает MoveNext() для возвращать false.

теперь, вот трюк. Это не должно иметь значения, каковы фактические значения, возвращаемые последовательностью. Вы можете вызвать MoveNext() repeatly и игнорировать Current; вычисления все равно будут выполняться. Каждый раз, когда вызывается MoveNext (), ваш блок итератора переходит к следующему оператору "yield", независимо от того, какое выражение он фактически дает. Таким образом, вы можете написать что-то вроде:

IEnumerator TellMeASecret()
{
  PlayAnimation("LeanInConspiratorially");
  while(playingAnimation)
    yield return null;

  Say("I stole the cookie from the cookie jar!");
  while(speaking)
    yield return null;

  PlayAnimation("LeanOutRelieved");
  while(playingAnimation)
    yield return null;
}

и то, что вы на самом деле написали, это итератор блок, который генерирует длинную последовательность нулевых значений, но что важно, так это побочные эффекты работы, которую он выполняет для их вычисления. Вы можете запустить эту корутину, используя простой цикл:

IEnumerator e = TellMeASecret();
while(e.MoveNext()) { }

или, что более полезно, вы можете смешать его с другой работой:

IEnumerator e = TellMeASecret();
while(e.MoveNext()) 
{ 
  // If they press 'Escape', skip the cutscene
  if(Input.GetKeyDown(KeyCode.Escape)) { break; }
}

все дело во времени Как вы видели, каждый оператор yield return должен предоставлять выражение (например, null), чтобы блок итератора имел что-то на самом деле назначить IEnumerator.Текущий. Длинная последовательность нулей не совсем полезна, но нас больше интересуют побочные эффекты. Не так ли?

есть что-то удобное, что мы можем сделать с этим выражением, на самом деле. Что делать, если вместо того, чтобы просто давать null и, игнорируя это, мы дали что-то, что указывало, когда мы ожидаем, что нам нужно сделать больше работы? Часто нам нужно будет нести прямо на следующий кадр, конечно, но не всегда: будет много раз, когда мы хотите продолжить после того, как анимация или звук закончили играть, или после определенного количества времени прошло. Те, пока (playingAnimation) yield return null; конструкции немного утомительны, не так ли?

Unity объявляет базовый тип YieldInstruction и предоставляет несколько конкретных производных типов, которые указывают на определенные виды ожидания. У вас есть WaitForSeconds, который возобновляет корутин после того, как определенное количество времени прошло. У вас есть WaitForEndOfFrame, который возобновляет корутину в определенной точке позже в том же фрейме. У вас есть сам тип корутина, который, когда корутина A дает корутину B, приостанавливает корутину A до тех пор, пока корутина B не закончит.

как это выглядит с точки зрения среды выполнения? Как я уже сказал, Я не работаю в Unity, поэтому я никогда не видел их код; но я бы предположил, что это может выглядеть немного так:

List<IEnumerator> unblockedCoroutines;
List<IEnumerator> shouldRunNextFrame;
List<IEnumerator> shouldRunAtEndOfFrame;
SortedList<float, IEnumerator> shouldRunAfterTimes;

foreach(IEnumerator coroutine in unblockedCoroutines)
{
    if(!coroutine.MoveNext())
        // This coroutine has finished
        continue;

    if(!coroutine.Current is YieldInstruction)
    {
        // This coroutine yielded null, or some other value we don't understand; run it next frame.
        shouldRunNextFrame.Add(coroutine);
        continue;
    }

    if(coroutine.Current is WaitForSeconds)
    {
        WaitForSeconds wait = (WaitForSeconds)coroutine.Current;
        shouldRunAfterTimes.Add(Time.time + wait.duration, coroutine);
    }
    else if(coroutine.Current is WaitForEndOfFrame)
    {
        shouldRunAtEndOfFrame.Add(coroutine);
    }
    else /* similar stuff for other YieldInstruction subtypes */
}

unblockedCoroutines = shouldRunNextFrame;

нетрудно представить, как можно добавить подтипы YieldInstruction для обработки других случаев – например, можно добавить поддержку сигналов на уровне ядра с поддержкой WaitForSignal("SignalName")YieldInstruction. Путем добавлять больше YieldInstructions, coroutines сами могут стать выразительн-выходом возврат новый WaitForSignal("сайт Gameover") приятнее читать thanwhile(!Сигналы.HasFired("Сайт Gameover")) yield return null, если вы спросите меня, не говоря уже о том, что делать это в двигателе можно быстрее чем делать это по сценарию.

несколько неочевидных последствий Во всем этом есть пара полезных вещей, которые люди иногда упускают, и я подумал, что должен указать на них.

во – первых, доходность просто дает выражение – любое выражение-и YieldInstruction является регулярным типом. Это означает, что вы можете делать вещи, как:

YieldInstruction y;

if(something)
 y = null;
else if(somethingElse)
 y = new WaitForEndOfFrame();
else
 y = new WaitForSeconds(1.0f);

yield return y;

конкретные строки yield возвращают новые WaitForSeconds (), yield return new WaitForEndOfFrame () и т. д. являются общими, но на самом деле они не являются специальными формами сами по себе.

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

IEnumerator DoSomething()
{
  /* ... */
}

IEnumerator DoSomethingUnlessInterrupted()
{
  IEnumerator e = DoSomething();
  bool interrupted = false;
  while(!interrupted)
  {
    e.MoveNext();
    yield return e.Current;
    interrupted = HasBeenInterrupted();
  }
}

в-третьих, тот факт, что вы можете передать на другой сопрограммы могу позволить вам реализовать свой собственный YieldInstructions, пусть и не так performantly, как если бы они были реализованы двигателя. Например:

IEnumerator UntilTrueCoroutine(Func fn)
{
   while(!fn()) yield return null;
}

Coroutine UntilTrue(Func fn)
{
  return StartCoroutine(UntilTrueCoroutine(fn));
}

IEnumerator SomeTask()
{
  /* ... */
  yield return UntilTrue(() => _lives < 3);
  /* ... */
}

тем не менее, я бы не рекомендовал это – стоимость запуска Coroutine немного тяжеловата на мой вкус.

вывод Я надеюсь, что это немного прояснит некоторые из того, что действительно происходит, когда вы используете корутину в Unity. Блоки итераторов C# - это заводная маленькая конструкция, и даже если вы не используете Unity, возможно, вы находите полезным воспользоваться ими таким же образом.