遊戲設計

我用unity雖然不久但也有3.4年了
我還真沒聽過這種說法

不過我猜大概就unity中IEnumerator是模擬Thread
所以會有跟Thread一樣的缺點.加深複雜程度且難以debug
大概是老手會叫新手還沒基本概念前先不要用

至於效能來說寫在Update通常都比較耗能啦

我是原PO~
其實是讀了這篇：
http://unitytaiwan.blogspot.tw/2017/03/unity_15.html

然後讀了不少有關Update或Coroutine的相關文章
嗯...但還是沒什麼想法

目前練習的小程式用了幾個Coroutine時間大約在2~10秒結束
同一時間執行最大數量約在3~4個

不確定這樣的寫法好不好 (畢竟方便而且程式容易懂)
用在一些遊戲邏輯的計時之中

這篇文章指的耗能方面是記憶體.而我之前提到是CPU的部分
是會依據需求決定的.兩邊的寫法並沒有絕對

而他說就要盡力避免的是需要長時間即時判斷之類的情況
我舉例子來說好了

IEnumerator TestA()
{
int x = 1;
while (true)
{
print(x);
yield return null;
}
}


Update()
{
int x = 1;
print(x);
}

這兩段雖然都是每幀印出x這值.但在記憶體內Coroutine那個
除了紀錄Coroutine執行階段的值外.還需要紀錄x的值

但Update中x這值在離開Update生命週期後就會重記憶體內被釋放掉.雖然每幀執行Update時會在建立出來.但卻不必額外負擔Coroutine的固定消耗.

簡單來說如果這個Coroutine真有必要長時間存在.竟量使用在需要異步操作的功能上.如他所說的HTTP 傳輸、資源載入或是檔案 I/O之類

Coroutine 真正造成問題的時間點並不在於建立時配置的記憶體
而是在於累計了一段時間後 GC 導致的畫面卡頓現象
會說適合長時間等待的用途 是因為這樣的用途通常不會頻繁的開啟 Coroutine 而在 heap 上配置暫存用的記憶體
這樣的用途相對拉長了 GC 發生的頻率 或 GC 發動時 需要回收的記憶體數量

如果有從 Profiler 觀察頻繁使用 Coroutine 對記憶體配置時的效能影響
那麼要觀察的對象並非 GC Allocated 時的突波 而是 Total GC Allocated 暴跌的那個瞬間 (這時的的 CPU usage 遠大於 GC Allocated 時的 CPU usage)

當然要迴避 Total GC Allocated 暴跌時 CPU 的突波現象 最快的方法還是回頭查找 GC Allocated 的時機點 並視其情況重構

所以 並不是怕新手搞亂程式結構或閱讀困難的問題 事實上 Coroutine 的本意 就是拿來簡化 並增加程式碼可讀性的 所以有時候明知道可能會多一點效能問題 還是會視情況而使用 Coroutine 來處理事情