協(xié)程這東西剛接觸Unity那會兒我踩過的坑能寫滿一整塊白板。最開始我以為它就是個延時執(zhí)行的工具后來發(fā)現(xiàn)它還能做異步加載、分幀處理、動畫序列再后來讀了一些底層實現(xiàn)的分析才意識到它本質(zhì)上是一套基于迭代器的調(diào)度機制。而CustomYieldInstruction更是很多人聽過但沒用過的類——它其實是協(xié)程體系里一個非常關(guān)鍵的擴展點理解了它你才算真正摸到了Unity協(xié)程的門檻。這篇內(nèi)容我會從協(xié)程的底層原理講起把迭代器、狀態(tài)機、調(diào)度器這三層關(guān)系拆開揉碎然后重點分析CustomYieldInstruction的設(shè)計意圖和實戰(zhàn)用法。適合已經(jīng)用過協(xié)程但對其原理一知半解的開發(fā)者也適合想自己寫自定義等待邏輯的中級選手。讀完你至少能搞清楚三件事協(xié)程為什么能暫停和恢復(fù)、yield return背后到底發(fā)生了什么、以及怎么用CustomYieldInstruction寫出比WaitUntil更優(yōu)雅的等待條件。1. 協(xié)程到底是個什么東西1.1 從一次踩坑說起很早之前我寫過一個需求點擊按鈕后物體先移動到A點停頓0.5秒再移動到B點最后播放一個特效。當(dāng)時的我圖省事直接在Update里寫了一堆狀態(tài)變量和計時器代碼大概長這樣private int step 0; private float timer 0f; void Update() { timer Time.deltaTime; switch (step) { case 0: transform.position Vector3.Lerp(startPos, posA, timer / moveTime); if (timer moveTime) { step 1; timer 0f; } break; case 1: if (timer 0.5f) { step 2; timer 0f; } break; // ... 后面還有一堆 } }這段代碼能跑但問題是一旦步驟增加到七八個switch分支就會膨脹得沒法看而且每個步驟的計時邏輯散落在各處改一個需求要動好幾個地方。后來同事看了一眼說你用協(xié)程啊。改成協(xié)程之后同樣的邏輯變成了這樣IEnumerator Sequence() { yield return MoveTo(posA, moveTime); yield return new WaitForSeconds(0.5f); yield return MoveTo(posB, moveTime); PlayEffect(); }代碼量直接砍掉一大半而且邏輯是線性的從上往下讀就是執(zhí)行順序。這就是協(xié)程最直觀的價值把跨幀的異步邏輯寫成同步的線性代碼。但用起來爽和知道為什么爽是兩回事。很多人用了幾年協(xié)程被問到協(xié)程的暫停是怎么實現(xiàn)的就答不上來。下面我把這層窗戶紙捅破。1.2 迭代器協(xié)程的語法基礎(chǔ)協(xié)程能暫?？康氖荂#的迭代器Iterator機制。你寫的那個返回IEnumerator的方法編譯器在背后幫你生成了一個狀態(tài)機類。這個類實現(xiàn)了IEnumerator接口核心是三個成員Current、MoveNext()、Reset()。MoveNext()是靈魂。每次調(diào)用它狀態(tài)機就從上一次yield return的位置繼續(xù)往下執(zhí)行直到遇到下一個yield return或者方法結(jié)束。Current則保存了當(dāng)前yield return出來的那個對象。你可以把迭代器想象成一本書MoveNext()就是翻到下一頁Current就是當(dāng)前頁的內(nèi)容。Unity的協(xié)程調(diào)度器做的事情就是決定什么時候去翻這一頁。這里有個關(guān)鍵點很多人不知道迭代器方法在你調(diào)用它的那一刻并不會執(zhí)行任何代碼。比如你寫var e MyCoroutine();此時方法體一行都沒跑。只有當(dāng)你第一次調(diào)用e.MoveNext()時代碼才會執(zhí)行到第一個yield return。這個特性是理解協(xié)程調(diào)度的前提。1.3 yield return的返回值決定了什么yield return后面跟的東西不是隨便寫的。它決定了協(xié)程什么時候恢復(fù)。Unity內(nèi)置了幾種常見的等待指令指令恢復(fù)時機典型用途null下一幀Update之后分幀執(zhí)行讓出一幀WaitForEndOfFrame幀渲染完成后截圖、讀像素WaitForFixedUpdate下一次物理更新后物理相關(guān)邏輯WaitForSeconds指定秒數(shù)后受timeScale影響定時等待WaitForSecondsRealtime指定秒數(shù)后不受timeScale影響UI動畫、暫停菜單WaitUntil條件為true時等待某個狀態(tài)WaitWhile條件為false時等待某個狀態(tài)結(jié)束Coroutine另一個協(xié)程結(jié)束后協(xié)程嵌套AsyncOperation異步操作完成后場景加載、資源加載CustomYieldInstruction由子類自定義自定義等待邏輯這張表建議你存下來。我見過太多人只會用WaitForSeconds遇到等某個條件滿足再繼續(xù)的需求就不知道怎么寫了其實WaitUntil一行就能搞定。1.4 調(diào)度器誰在推動協(xié)程前進Unity的協(xié)程調(diào)度發(fā)生在MonoBehaviour的生命周期里。當(dāng)你調(diào)用StartCoroutine()時Unity會把這個IEnumerator包裝成一個Coroutine對象注冊到當(dāng)前MonoBehaviour所屬的調(diào)度隊列中。每一幀Unity的協(xié)程調(diào)度器會遍歷所有活躍的協(xié)程對每一個調(diào)用MoveNext()然后檢查Current返回的對象判斷這個協(xié)程是否應(yīng)該在本幀繼續(xù)。判斷邏輯大致是這樣的如果Current是null下一幀繼續(xù)如果是WaitForSeconds檢查內(nèi)部計時器是否到期如果是WaitUntil調(diào)用它的keepWaiting屬性如果返回false就繼續(xù)如果是CustomYieldInstruction同樣檢查keepWaiting如果是Coroutine檢查目標(biāo)協(xié)程是否完成如果是AsyncOperation檢查isDone注意最后兩條WaitUntil、WaitWhile、CustomYieldInstruction、Coroutine、AsyncOperation這些本質(zhì)上都是通過一個統(tǒng)一的接口來告訴調(diào)度器我還需不需要等。這個接口就是IEnumerator的Current返回對象所需要滿足的約定。而CustomYieldInstruction正是把這個約定顯式地抽象成了一個抽象類讓你可以自定義等待條件。2. CustomYieldInstruction的設(shè)計意圖2.1 它解決了什么問題假設(shè)你要寫一個等待條件等某個動畫播放到第3幀、等某個網(wǎng)絡(luò)請求返回、等某個UI面板完全展開。用WaitUntil當(dāng)然可以yield return new WaitUntil(() animator.GetCurrentAnimatorStateInfo(0).normalizedTime 0.5f);但WaitUntil有個問題它每幀都會執(zhí)行一次你傳進去的lambda。如果這個lambda里有復(fù)雜的計算或者頻繁的GC分配性能就會受影響。而且WaitUntil的語義是條件為true時恢復(fù)如果你想要更復(fù)雜的邏輯——比如條件滿足后還要再等兩幀——就得嵌套或者額外寫狀態(tài)。CustomYieldInstruction給了你一個更底層的入口你繼承它重寫keepWaiting屬性返回true表示繼續(xù)等返回false表示恢復(fù)協(xié)程。調(diào)度器每幀會讀一次這個屬性就這么簡單。它的定義非常精簡public abstract class CustomYieldInstruction : IEnumerator { public abstract bool keepWaiting { get; } public object Current { get { return null; } } public bool MoveNext() { return keepWaiting; } public void Reset() { } }看到?jīng)]它實現(xiàn)了IEnumeratorMoveNext()直接返回keepWaiting。也就是說調(diào)度器調(diào)用MoveNext()時實際上就是在問你還需要等嗎。這個設(shè)計非常巧妙——它把是否繼續(xù)等待這個決策權(quán)完全交給了你。2.2 和WaitUntil的本質(zhì)區(qū)別很多人覺得CustomYieldInstruction和WaitUntil差不多其實差別在于控制粒度和狀態(tài)保持。WaitUntil是一個無狀態(tài)的等待器它只關(guān)心你給的條件函數(shù)當(dāng)前返回什么。條件函數(shù)本身不能保存跨幀的狀態(tài)除非你用閉包捕獲外部變量但那很別扭。CustomYieldInstruction是一個有狀態(tài)的等待器。你可以在子類里定義字段記錄已經(jīng)等了多少幀、條件滿足了幾次、是否已經(jīng)觸發(fā)過某個事件等等。這讓它能表達(dá)更復(fù)雜的等待邏輯。舉個例子我要等一個條件連續(xù)滿足3幀才恢復(fù)。用WaitUntil很難優(yōu)雅地寫用CustomYieldInstruction就很自然public class WaitForStableCondition : CustomYieldInstruction { private Funcbool condition; private int requiredFrames; private int stableCount; public WaitForStableCondition(Funcbool condition, int requiredFrames 3) { this.condition condition; this.requiredFrames requiredFrames; this.stableCount 0; } public override bool keepWaiting { get { if (condition()) { stableCount; return stableCount requiredFrames; } stableCount 0; return true; } } }這個等待器會等條件連續(xù)滿足3幀才放行能有效過濾掉條件抖動的情況。這種邏輯用WaitUntil寫起來就很別扭。2.3 什么時候該用它我的經(jīng)驗是以下幾種場景優(yōu)先考慮CustomYieldInstruction等待條件需要跨幀保持狀態(tài)比如計數(shù)、計時、狀態(tài)機等待邏輯需要復(fù)用封裝成一個可配置的類需要組合多個條件比如A滿足且B滿足或A滿足后等2秒需要在等待過程中做副作用比如每幀更新一個進度條如果只是簡單的等一個bool變trueWaitUntil就夠了沒必要上CustomYieldInstruction。工具要用在合適的地方過度設(shè)計也是坑。3. 手寫一個CustomYieldInstruction實戰(zhàn)3.1 需求等待一個帶超時的條件我們來做一個實際中很常見的需求等待某個條件滿足但如果超過指定時間還沒滿足就放棄等待并執(zhí)行超時邏輯。這個需求用WaitUntil是做不到的因為它沒有超時概念。用CustomYieldInstruction就很自然。先看完整實現(xiàn)using System; using UnityEngine; public class WaitForConditionOrTimeout : CustomYieldInstruction { private Funcbool condition; private float timeout; private float startTime; private bool timedOut; public bool TimedOut timedOut; public WaitForConditionOrTimeout(Funcbool condition, float timeout) { this.condition condition; this.timeout timeout; this.startTime Time.realtimeSinceStartup; this.timedOut false; } public override bool keepWaiting { get { if (condition()) { timedOut false; return false; } if (Time.realtimeSinceStartup - startTime timeout) { timedOut true; return false; } return true; } } }用法IEnumerator LoadAndWait() { var waiter new WaitForConditionOrTimeout(() SomeManager.IsReady, 5f); yield return waiter; if (waiter.TimedOut) { Debug.LogWarning(等待超時走降級邏輯); FallbackLoad(); } else { ProceedNormally(); } }這里有幾個設(shè)計細(xì)節(jié)值得說第一用Time.realtimeSinceStartup而不是Time.time。因為Time.time受timeScale影響如果游戲暫停了Time.time不增長超時永遠(yuǎn)不會觸發(fā)。而超時邏輯通常希望是真實時間所以用realtimeSinceStartup更合適。當(dāng)然如果你的需求是游戲內(nèi)時間超時那就該用Time.time看場景。第二timedOut字段在條件滿足時被重置為false。這是為了防止一種邊界情況如果條件在超時判斷之前剛好滿足timedOut可能殘留上一次的值。雖然在這個簡單場景里不太會出現(xiàn)但養(yǎng)成習(xí)慣總是好的。第三keepWaiting里先判斷條件再判斷超時。順序很重要。如果先判斷超時那么當(dāng)條件剛好在超時那一刻滿足時可能會被誤判為超時。先判斷條件能保證條件滿足優(yōu)先于超時。3.2 需求升級帶進度回調(diào)的等待再做一個更實用的等待一個異步操作完成同時每幀回調(diào)進度。這在加載資源、下載數(shù)據(jù)時很常見。public class WaitForProgress : CustomYieldInstruction { private Funcbool isDone; private Funcfloat getProgress; private Actionfloat onProgress; private float lastReported; public WaitForProgress(Funcbool isDone, Funcfloat getProgress, Actionfloat onProgress null) { this.isDone isDone; this.getProgress getProgress; this.onProgress onProgress; this.lastReported -1f; } public override bool keepWaiting { get { if (isDone()) { onProgress?.Invoke(1f); return false; } float p getProgress(); if (Mathf.Abs(p - lastReported) 0.01f) { lastReported p; onProgress?.Invoke(p); } return true; } } }用法IEnumerator LoadLevel() { var op SceneManager.LoadSceneAsync(GameScene); op.allowSceneActivation false; yield return new WaitForProgress( () op.progress 0.9f, () op.progress / 0.9f, p progressBar.value p ); op.allowSceneActivation true; }這里有個細(xì)節(jié)onProgress只在進度變化超過0.01時才回調(diào)。為什么要做這個節(jié)流因為如果每幀都回調(diào)UI更新頻率可能過高而且進度值在小數(shù)點后很多位變化時視覺上根本看不出來。節(jié)流能減少不必要的UI刷新。提示CustomYieldInstruction的keepWaiting每幀都會被調(diào)用所以里面的邏輯要盡量輕量。避免在里面做復(fù)雜的計算、字符串拼接、或者頻繁的GC分配。如果確實需要重邏輯考慮加緩存或者降低檢查頻率。3.3 需求再升級組合等待器有時候你需要等多個條件同時滿足?？梢詫懸粋€組合器public class WaitForAll : CustomYieldInstruction { private CustomYieldInstruction[] waiters; public WaitForAll(params CustomYieldInstruction[] waiters) { this.waiters waiters; } public override bool keepWaiting { get { foreach (var w in waiters) { if (w.keepWaiting) return true; } return false; } } }用法yield return new WaitForAll( new WaitForConditionOrTimeout(() player.IsLoaded, 3f), new WaitForConditionOrTimeout(() ui.IsReady, 3f) );這個組合器會等所有子等待器都完成才放行。注意這里有個坑keepWaiting被調(diào)用時會依次調(diào)用每個子等待器的keepWaiting這意味著子等待器的狀態(tài)會被推進。如果某個子等待器已經(jīng)完成了它的keepWaiting返回false但每次調(diào)用仍然會執(zhí)行它的getter邏輯。所以子等待器的keepWaiting實現(xiàn)要保證冪等——多次調(diào)用結(jié)果一致不能有副作用累積。我上面寫的WaitForConditionOrTimeout就滿足這個要求因為它的狀態(tài)變化只依賴于時間和條件多次讀取不會改變結(jié)果。但如果你寫的等待器在keepWaiting里做了計數(shù)1這種操作放進組合器里就會出問題。4. 協(xié)程調(diào)度中的那些坑4.1 協(xié)程不是線程這是最基礎(chǔ)但也最容易被誤解的一點。協(xié)程運行在主線程上它只是把一段邏輯拆成多幀執(zhí)行并沒有真正的并行。所以協(xié)程里不能做耗時計算否則照樣卡幀協(xié)程里訪問Unity API是安全的因為主線程協(xié)程里不能用Thread.Sleep那會阻塞整個主線程我見過有人在協(xié)程里寫了個大循環(huán)做數(shù)據(jù)處理然后疑惑為什么游戲卡了。協(xié)程不會幫你把計算變快它只是幫你把計算分散到多幀。如果單幀的計算量本身就大該卡還是卡。4.2 yield return null不等于等一幀嚴(yán)格來說yield return null是等到下一幀的Update階段之后恢復(fù)。它的恢復(fù)時機和WaitForEndOfFrame不同。如果你在協(xié)程里做和渲染相關(guān)的事情比如截圖用yield return null可能會拿到不完整的畫面必須用WaitForEndOfFrame。另外yield return null在Update和LateUpdate之間的具體時機不同Unity版本可能有細(xì)微差異。如果你的邏輯對執(zhí)行順序敏感最好實測確認(rèn)。4.3 協(xié)程的生命周期綁定StartCoroutine是在MonoBehaviour上調(diào)用的協(xié)程的生命周期和這個MonoBehaviour綁定。當(dāng)MonoBehaviour被禁用enabled false時協(xié)程不會自動停止但當(dāng)它被銷毀Destroy時協(xié)程會停止。這里有個常見的坑如果你在一個會被頻繁銷毀的對象上啟動協(xié)程協(xié)程可能在執(zhí)行到一半時突然中斷導(dǎo)致一些清理邏輯沒跑。解決辦法是在OnDisable或OnDestroy里手動StopAllCoroutines并確保關(guān)鍵清理邏輯不依賴協(xié)程的完整執(zhí)行。4.4 CustomYieldInstruction的異常處理keepWaiting里如果拋異常協(xié)程會中斷但異?？赡懿粫阅闫谕姆绞矫芭荨＝ㄗh在keepWaiting里做好防御性判斷比如檢查委托是否為null、檢查對象是否已被銷毀。public override bool keepWaiting { get { if (condition null) return false; try { return !condition(); } catch (Exception e) { Debug.LogError($等待條件異常: {e.Message}); return false; } } }4.5 常見問題速查表問題現(xiàn)象可能原因排查方向協(xié)程不執(zhí)行對象未激活或組件未啟用檢查gameObject.activeInHierarchy和enabled協(xié)程執(zhí)行到一半停了對象被銷毀檢查是否有Destroy調(diào)用WaitForSeconds不準(zhǔn)確受timeScale影響改用WaitForSecondsRealtimeCustomYieldInstruction不恢復(fù)keepWaiting一直返回true打印條件值檢查邏輯協(xié)程嵌套后外層不恢復(fù)內(nèi)層協(xié)程被中斷檢查內(nèi)層協(xié)程的宿主對象協(xié)程里報空引用對象在等待期間被銷毀等待后加null檢查5. 一些進階玩法和經(jīng)驗5.1 用CustomYieldInstruction做狀態(tài)機協(xié)程天然適合做狀態(tài)機。你可以把每個狀態(tài)寫成一個協(xié)程用CustomYieldInstruction來控制狀態(tài)切換條件。比如一個簡單的AI行為IEnumerator AIBehavior() { while (true) { yield return new WaitUntil(() CanSeePlayer); yield return ChasePlayer(); yield return new WaitForConditionOrTimeout(() !CanSeePlayer, 3f); yield return Patrol(); } }這種寫法比傳統(tǒng)的switch(state)清晰得多而且每個狀態(tài)的邏輯可以獨立測試。5.2 避免在keepWaiting里分配內(nèi)存keepWaiting每幀調(diào)用如果里面有new、字符串拼接、LINQ查詢就會產(chǎn)生持續(xù)的GC壓力。我見過一個項目因為在一個自定義等待器里每幀new一個數(shù)組導(dǎo)致GC頻繁觸發(fā)幀率不穩(wěn)。改成緩存數(shù)組后問題消失。5.3 協(xié)程的替代方案雖然協(xié)程很好用但也不是萬能的。C#的async/await配合Task在某些場景下更合適尤其是需要真正異步IO的時候。Unity從2018開始對async/await的支持也越來越好。我的建議是幀同步邏輯、動畫序列、簡單的延時用協(xié)程網(wǎng)絡(luò)請求、文件IO、復(fù)雜異步流程考慮async/await需要取消、超時、組合的復(fù)雜異步async/awaitCancellationToken更成熟但協(xié)程的優(yōu)勢在于它和Unity的生命周期深度集成寫起來直觀調(diào)試也方便。兩者不是替代關(guān)系而是互補。5.4 調(diào)試協(xié)程的小技巧協(xié)程的調(diào)用棧在調(diào)試時不太直觀因為它是分幀執(zhí)行的。我的做法是在關(guān)鍵節(jié)點加日志用統(tǒng)一的標(biāo)簽前綴方便過濾Debug.Log($[Coroutine:{GetType().Name}] 開始等待); yield return new WaitForConditionOrTimeout(...); Debug.Log($[Coroutine:{GetType().Name}] 等待結(jié)束);另外Unity的Profiler里可以看到協(xié)程的CPU占用如果某個協(xié)程占用異常高多半是keepWaiting里的邏輯太重了。5.5 一個容易忽略的細(xì)節(jié)yield return的執(zhí)行時機yield return后面的表達(dá)式是在恢復(fù)時求值的而不是在暫停時。這意味著如果你寫yield return new WaitForSeconds(GetDelayTime());GetDelayTime()會在協(xié)程恢復(fù)的那一刻被調(diào)用而不是在yield return執(zhí)行的那一刻。大多數(shù)情況下這沒區(qū)別但如果GetDelayTime()依賴某個會變化的狀態(tài)就可能出問題。穩(wěn)妥的做法是先算好再yieldfloat delay GetDelayTime(); yield return new WaitForSeconds(delay);這個細(xì)節(jié)我在實際項目里踩過一次坑一個等待時間依賴玩家等級結(jié)果玩家在等待期間升級了等待時間就變了。雖然聽起來是正確的行為但和設(shè)計預(yù)期不符。5.6 CustomYieldInstruction的復(fù)用與池化如果你的等待器會被頻繁創(chuàng)建比如每幀都有新的等待可以考慮池化。但大多數(shù)場景下等待器的創(chuàng)建頻率并不高池化帶來的復(fù)雜度可能得不償失。我的建議是先用Profiler確認(rèn)GC壓力再決定是否優(yōu)化。如果確實需要優(yōu)化一個簡單的做法是把等待器設(shè)計成可重置的public class ReusableWaiter : CustomYieldInstruction { private Funcbool condition; private bool waiting; public void Setup(Funcbool condition) { this.condition condition; this.waiting true; } public override bool keepWaiting { get { if (!waiting) return false; if (condition()) { waiting false; return false; } return true; } } }但要注意池化后的對象如果被多個協(xié)程同時引用會出問題。所以池化只適合同一時間只有一個協(xié)程使用的場景。5.7 關(guān)于keepWaiting的調(diào)用頻率keepWaiting每幀被調(diào)用一次這個每幀具體是哪個階段根據(jù)我的實測它是在協(xié)程調(diào)度階段被調(diào)用的大致在Update之后、LateUpdate之前。如果你的等待條件依賴于LateUpdate里更新的狀態(tài)可能會有一幀的延遲。這種細(xì)節(jié)在大多數(shù)場景下無所謂但在對時序敏感的邏輯里要注意。我在實際項目里總結(jié)下來協(xié)程和CustomYieldInstruction這套機制核心價值在于它把異步這件事用同步的寫法表達(dá)出來了。你不需要管理狀態(tài)機、不需要手動寫計時器、不需要擔(dān)心回調(diào)地獄。而CustomYieldInstruction則是這套機制留給開發(fā)者的擴展口讓你能在不破壞協(xié)程語義的前提下定義自己的等待規(guī)則。理解了這兩層你在Unity里處理時序問題的能力會上一個臺階。