Coroutines：

Coroutines與其他腳本代碼的執行方式不同。在性能分析中，大多數的腳本代碼只會在Unity的生命周期方法下出現一次。但是協程總是會在兩個地方出現。

在性能分析中，Coroutines中所有從協程開始到第一個yield中的代碼，都會出現在協程出現的地方。通常，它會在StartCoroutine的方法中出現。由Unity回調產生的Coroutines（例如Start回調返回一個IEnumerator），首先會出現在各自的回調中。

協程中剩余的代碼（從第一次恢復到完成執行），會出現在Unity的主循環，DelayedCallManager方法中。

要理解為什么出現這種情況，就需要理解協程實際上是怎么執行的：

協程運行時，C#編譯器會自動生成一個類。這個類會在多個調用中，追蹤Coroutine的狀態。對于局部變量，由于協程中的局部變量在yield后也必須存在，所以這些局部變量會被封裝到生成類里面。在協程執行期間，這些變量就會在托管堆中持續存在。這個對象也會追蹤協程的內部狀態：它會記錄在yield之后，協程會在什么時候繼續執行。

正因為如此，啟動一個coroutine的內存開銷等于一個固定的開銷成本加上它的局部變量的開銷。

開始調用一個協程的代碼，在協程滿足yield條件時，Unity會通過DelayedCallManager再次調用它們。因為協程有時候是被另一個協程調用的，這時候它們的開銷就是上述兩個被拆分的開銷。

在上述的截圖中，我們可以看到，DelayedCallManager執行執行了幾個協程，PopulateCharacters, AsyncLoad 和LoadDatabase。

在可能的情況下，最好在單個協程中執行一系列的操作，雖然在代碼的清晰度和可維護方面，嵌套調用的協程比較好，但由于需要追蹤對象，嵌套調用將會花費更高的內存。

如果，一個協程每幀都會被執行， 并且在長時間的操作中沒有yield語句。那么最好把里面的代碼放到Update或者LateUpdate中。

當一個對象被設置成disable時，協程不會停止，只有當對象被destroy時，才會停止。就是說，disable一個對象時，協程仍然在運行，需要的話，可以在協程中enable這個對象。調用Destroy（this）會立即觸發OnDisable回調，同時，協程也會被停止。最后，在最后一幀會調用OnDestroy方法。

協程不是線程，記住這個很重要。協程中的操作依舊運行在主線程上。如果在優化的目標是減少CPU在主線程上話費的時間，那么在協程中避免出現一些阻塞的操作跟在其他代碼中避免出現一樣重要。

當然，當我們需要執行一些例如Http傳輸、Asset加載或者文件I/O操作這類長時間的異步操作時，最好使用協程。

本文內容來自Unity官方文檔：

Unity - Manual: Coroutines?docs.unity3d.com

作者水平有限，如有錯誤請多加指正。

總結

以上是生活随笔為你收集整理的unity 下一帧执行_理解Unity中的优化（三）：协程（Coroutines）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。