觀察 Unity 終於讓我理解了 C++ 協程的意義

背景

這篇文章探討了 C++ 協程（Coroutines）自推出以來因缺乏具體應用案例而難以推廣的現狀。作者透過觀察 Unity 遊戲引擎中 C# 協程的實作，發現其在處理隨時間變化的效果與複雜狀態機時具有極高價值，並嘗試在 C++23 中以類似的「每幀暫停」邏輯實作一套輕量級的協程執行器。

社群觀點

Hacker News 的討論聚焦於協程在遊戲開發與非同步編程中的實務價值。支持者認為，遊戲開發的核心挑戰之一在於處理「時間」維度，傳統的狀態機或 Lambda 回調在處理跨越多幀的邏輯時，極易演變成難以維護的「魯布·戈德堡機械」。協程最大的價值在於「控制流的重新反轉」，它能將破碎的狀態轉移轉化為直觀的線性代碼。許多開發者分享了從回調函數遷移到協程後的正面經驗，認為這種開發模式在網路通訊與 UI 執行緒管理上同樣能顯著提升代碼的可讀性與維護性。

然而，針對 Unity 風格的協程實作，社群中存在激烈的爭論。反對者指出，Unity 的協程本質上是基於迭代器的「黑箱」，缺乏明確的所有權模型與結構化併發。這導致協程在物件被銷毀後可能繼續運行，進而引發空指標異常或記憶體洩漏，且在除錯器中難以追蹤其內部狀態。部分資深開發者主張，與其使用隱晦的協程，不如將狀態顯式地儲存在物件變數中，以便利用編輯器進行即時監控。此外，關於 C++20 協程的設計也受到批評，部分觀點認為其過於複雜且偏向底層，導致開發者必須撰寫大量樣板代碼才能使用，相比之下，傳統的堆疊式協程（Stackful Coroutines）雖然需要組合語言支援，但在避免「函數著色」問題上更具優勢。

另一派觀點則從語言演進的角度切入，認為 C++ 協程目前的尷尬處境源於標準庫支援的缺失。目前 C++23 僅提供基本的生成器支援，而真正的非同步執行框架預計要到 C++26 才會完備。這導致現階段開發者若不依賴 Boost.Asio 等大型函式庫，就必須自行實作底層的 Promise 與 Awaitable 邏輯。討論中也提到，儘管 Unity 的做法被某些純粹主義者視為「黑客手段」，但它在實務上成功解決了遊戲循環中的時序問題，這種「夠用就好」的工程思維對於推廣複雜的語言特性至關重要。

延伸閱讀

在討論中，開發者們推薦了幾個深入理解協程與時序邏輯的資源。針對遊戲 AI 與輪詢問題，推薦觀看 GDC 演講「The Polling Problem」。若想了解 C++ 協程的底層實作與應用，Simon Tatham 與 Daniela Engert 的技術分享被視為極佳的入門教材。在工具方面，除了廣為人知的 Boost.Asio，也有開發者推薦輕量級的 C 語言堆疊式協程庫 minicoro 與 libco，以及專為非同步任務設計的 libtask。此外，針對 C# 在 Unity 中的演進，相關討論也提及了 CoreCLR 的遷移計畫與 Awaitable 支援的更新。