設(shè)計(jì)：團(tuán)隊(duì)分工與C++底層實(shí)現(xiàn))
1. 從零開(kāi)始理解游戲引擎的團(tuán)隊(duì)分工邏輯很多人第一次接觸“游戲引擎架構(gòu)”這個(gè)詞腦子里浮現(xiàn)的是一堆類(lèi)和繼承關(guān)系圖或者某個(gè)開(kāi)源引擎的源碼目錄樹(shù)。但我在實(shí)際帶項(xiàng)目和跟團(tuán)隊(duì)協(xié)作的過(guò)程中發(fā)現(xiàn)真正決定一個(gè)引擎能不能跑起來(lái)、能不能被團(tuán)隊(duì)用起來(lái)的往往不是某個(gè)渲染算法有多精妙而是團(tuán)隊(duì)分工和底層架構(gòu)之間的匹配關(guān)系。換句話說(shuō)架構(gòu)不是畫(huà)出來(lái)的是被團(tuán)隊(duì)的組織方式和協(xié)作模式“逼”出來(lái)的。這個(gè)系列我打算從最基礎(chǔ)的地方講起第一篇就聊清楚兩件事一個(gè)游戲引擎團(tuán)隊(duì)通常怎么分工以及這些分工如何映射到底層架構(gòu)的模塊劃分上。適合剛?cè)胄邢肜斫庖嫒驳拈_(kāi)發(fā)者也適合已經(jīng)在一線寫(xiě)業(yè)務(wù)邏輯、想往引擎層深入的朋友。我會(huì)盡量用實(shí)際項(xiàng)目中的例子來(lái)說(shuō)明而不是照搬教科書(shū)上的分層圖。1.1 為什么先講團(tuán)隊(duì)分工而不是直接講代碼你可能會(huì)問(wèn)講引擎架構(gòu)為什么不直接從渲染管線、內(nèi)存管理、資源系統(tǒng)這些硬核內(nèi)容開(kāi)始原因很簡(jiǎn)單引擎架構(gòu)的本質(zhì)是協(xié)作契約。一個(gè)引擎的模塊邊界幾乎總是對(duì)應(yīng)著團(tuán)隊(duì)里某個(gè)角色或某個(gè)小組的職責(zé)邊界。如果你不理解誰(shuí)在用什么、誰(shuí)在改什么你就無(wú)法理解為什么某個(gè)模塊要設(shè)計(jì)成那樣。舉個(gè)例子渲染組的人希望材質(zhì)系統(tǒng)盡可能靈活能直接操作Shader參數(shù)但工具組的人希望材質(zhì)系統(tǒng)有穩(wěn)定的序列化格式和編輯器界面。這兩個(gè)訴求會(huì)直接影響到材質(zhì)系統(tǒng)在架構(gòu)上被拆成“運(yùn)行時(shí)核心”和“編輯器層”兩個(gè)部分。如果你只看代碼會(huì)覺(jué)得這是過(guò)度設(shè)計(jì)但如果你知道有兩個(gè)不同角色在同時(shí)使用這個(gè)系統(tǒng)就會(huì)明白這種拆分是必然的。所以我的建議是在學(xué)習(xí)任何引擎源碼之前先花點(diǎn)時(shí)間搞清楚一個(gè)典型引擎團(tuán)隊(duì)的角色劃分。這比死磕某個(gè)類(lèi)的實(shí)現(xiàn)細(xì)節(jié)有用得多。1.2 一個(gè)典型游戲引擎團(tuán)隊(duì)的角色劃分不同規(guī)模的團(tuán)隊(duì)分工粒度差別很大。大廠可能一個(gè)渲染模塊就有幾十號(hào)人小團(tuán)隊(duì)可能一個(gè)人同時(shí)負(fù)責(zé)渲染、物理和工具。但不管規(guī)模如何核心職能是逃不掉的。我把它歸納為五個(gè)方向核心運(yùn)行時(shí)組負(fù)責(zé)引擎最底層的模塊包括內(nèi)存管理、數(shù)學(xué)庫(kù)、容器、任務(wù)調(diào)度、平臺(tái)抽象層。這個(gè)組的人通常C功底極深關(guān)注性能和跨平臺(tái)兼容性。渲染與圖形組負(fù)責(zé)渲染管線、材質(zhì)系統(tǒng)、光照、后處理、Shader管理。這個(gè)組需要同時(shí)懂圖形API和GPU硬件特性。物理與動(dòng)畫(huà)組負(fù)責(zé)碰撞檢測(cè)、剛體模擬、骨骼動(dòng)畫(huà)、IK等。這個(gè)組對(duì)數(shù)值穩(wěn)定性和實(shí)時(shí)性要求極高。資源與工具組負(fù)責(zé)資源導(dǎo)入管線、序列化、編輯器、資產(chǎn)管理系統(tǒng)。這個(gè)組是引擎和內(nèi)容創(chuàng)作者之間的橋梁。游戲框架組負(fù)責(zé)實(shí)體組件系統(tǒng)、腳本綁定、事件系統(tǒng)、網(wǎng)絡(luò)同步等。這個(gè)組直接服務(wù)于游戲玩法開(kāi)發(fā)者。這五個(gè)方向不是孤立的它們之間有大量的交叉依賴(lài)。而底層架構(gòu)要解決的核心問(wèn)題就是如何讓這五個(gè)方向的人能并行工作而不互相踩腳。1.3 分工如何影響架構(gòu)的模塊邊界我拿一個(gè)實(shí)際場(chǎng)景來(lái)說(shuō)明。假設(shè)渲染組要新增一種材質(zhì)類(lèi)型工具組要能在編輯器里編輯這種材質(zhì)的參數(shù)游戲框架組要能在腳本里動(dòng)態(tài)修改材質(zhì)屬性。這三個(gè)訴求對(duì)應(yīng)到架構(gòu)上就要求材質(zhì)系統(tǒng)至少分成三層第一層是運(yùn)行時(shí)材質(zhì)核心只包含GPU需要的參數(shù)和狀態(tài)由渲染組維護(hù)。第二層是序列化與反射層負(fù)責(zé)把材質(zhì)參數(shù)映射到編輯器可編輯的字段由工具組維護(hù)。第三層是腳本綁定層把材質(zhì)接口暴露給腳本系統(tǒng)由游戲框架組維護(hù)。如果架構(gòu)上沒(méi)有做這個(gè)拆分而是把材質(zhì)做成一個(gè)巨大的類(lèi)那么三個(gè)組的人就會(huì)同時(shí)修改同一個(gè)文件代碼沖突和溝通成本會(huì)急劇上升。這就是為什么我說(shuō)架構(gòu)是協(xié)作契約——它的第一目標(biāo)是讓不同角色能高效并行而不是追求代碼本身的優(yōu)雅。注意很多新手在自研引擎時(shí)容易把所有功能塞進(jìn)一個(gè)模塊覺(jué)得“反正我一個(gè)人寫(xiě)”。但一旦團(tuán)隊(duì)超過(guò)三個(gè)人這種架構(gòu)就會(huì)成為瓶頸。提前做好模塊邊界劃分比后期重構(gòu)代價(jià)小得多。2. 底層架構(gòu)的核心分層與C實(shí)現(xiàn)要點(diǎn)聊完團(tuán)隊(duì)分工接下來(lái)進(jìn)入底層架構(gòu)本身。游戲引擎的底層架構(gòu)通常分為幾個(gè)大層每一層解決不同的問(wèn)題。我用一個(gè)從下往上的順序來(lái)講這樣你能看清楚依賴(lài)關(guān)系是怎么建立的。2.1 平臺(tái)抽象層屏蔽操作系統(tǒng)差異最底層是平臺(tái)抽象層它的職責(zé)是把操作系統(tǒng)相關(guān)的API封裝成統(tǒng)一的接口。比如文件讀寫(xiě)、線程創(chuàng)建、時(shí)間獲取、窗口管理這些在不同平臺(tái)上實(shí)現(xiàn)方式不同但上層模塊不應(yīng)該關(guān)心這些差異。為什么這一層要用C來(lái)做因?yàn)槠脚_(tái)抽象層需要直接調(diào)用系統(tǒng)API而C提供了足夠的底層控制能力同時(shí)又能通過(guò)虛函數(shù)或函數(shù)指針實(shí)現(xiàn)運(yùn)行時(shí)多態(tài)。常見(jiàn)的做法是定義一組純虛接口然后每個(gè)平臺(tái)提供一份實(shí)現(xiàn)。// 平臺(tái)抽象層的文件接口示例 class IFileSystem { public: virtual ~IFileSystem() default; virtual FileHandle Open(const char* path, FileMode mode) 0; virtual size_t Read(FileHandle handle, void* buffer, size_t size) 0; virtual size_t Write(FileHandle handle, const void* buffer, size_t size) 0; virtual void Close(FileHandle handle) 0; };這個(gè)接口看起來(lái)簡(jiǎn)單但實(shí)際項(xiàng)目中需要考慮的細(xì)節(jié)很多。比如路徑分隔符在Windows上是反斜杠在類(lèi)Unix系統(tǒng)上是正斜杠文件編碼在不同平臺(tái)上也有差異。這些細(xì)節(jié)都應(yīng)該在這一層被消化掉上層模塊只看到統(tǒng)一的接口。我在實(shí)際項(xiàng)目中的一個(gè)經(jīng)驗(yàn)是平臺(tái)抽象層的接口設(shè)計(jì)要盡量窄。不要為了“以后可能用到”而暴露大量平臺(tái)特有的功能。接口越窄跨平臺(tái)移植時(shí)的工作量越小。曾經(jīng)有個(gè)項(xiàng)目在平臺(tái)層暴露了Windows特有的重疊IO接口結(jié)果移植到其他平臺(tái)時(shí)不得不重寫(xiě)整個(gè)資源加載模塊。2.2 核心系統(tǒng)層內(nèi)存、數(shù)學(xué)與容器平臺(tái)抽象層之上是核心系統(tǒng)層這一層是引擎的“基礎(chǔ)設(shè)施”。主要包括內(nèi)存管理、數(shù)學(xué)庫(kù)、容器和字符串處理。內(nèi)存管理是引擎性能的關(guān)鍵。游戲引擎通常不會(huì)直接使用全局的new和delete而是實(shí)現(xiàn)自己的內(nèi)存分配器。原因有三個(gè)第一減少內(nèi)存碎片第二提高分配速度第三方便追蹤內(nèi)存泄漏。常見(jiàn)的做法是分層分配器底層是一個(gè)大塊內(nèi)存池上層根據(jù)不同用途劃分不同的分配策略。比如幀分配器用于每幀臨時(shí)分配的內(nèi)存生命周期只有一幀對(duì)象池用于頻繁創(chuàng)建銷(xiāo)毀的同類(lèi)型對(duì)象通用堆分配器用于長(zhǎng)生命周期對(duì)象。// 簡(jiǎn)單的幀分配器示意 class FrameAllocator { public: void* Allocate(size_t size, size_t alignment) { // 從當(dāng)前幀的內(nèi)存塊中分配 // 每幀結(jié)束時(shí)整體重置不需要逐個(gè)釋放 } void Reset() { // 幀結(jié)束時(shí)調(diào)用一次性回收所有分配 } };數(shù)學(xué)庫(kù)方面引擎通常需要向量、矩陣、四元數(shù)、射線、包圍盒等基礎(chǔ)類(lèi)型。這些類(lèi)型的實(shí)現(xiàn)要特別注意精度和性能的平衡。比如矩陣乘法用SIMD指令加速可以帶來(lái)數(shù)倍的性能提升但代碼復(fù)雜度也會(huì)上升。我的建議是先用標(biāo)量實(shí)現(xiàn)跑通邏輯確認(rèn)瓶頸后再做SIMD優(yōu)化。容器方面引擎通常不會(huì)直接用STL的全部容器而是根據(jù)場(chǎng)景選擇或自研。比如std::vector在大多數(shù)場(chǎng)景下夠用但std::unordered_map的哈希函數(shù)和內(nèi)存布局可能不適合性能敏感的場(chǎng)景。很多引擎會(huì)實(shí)現(xiàn)自己的開(kāi)放尋址哈希表或扁平化容器。2.3 資源系統(tǒng)層資產(chǎn)的生命周期管理資源系統(tǒng)負(fù)責(zé)管理游戲中的各種資產(chǎn)包括紋理、模型、音頻、材質(zhì)、動(dòng)畫(huà)等。這一層的核心問(wèn)題是如何高效地加載、引用、緩存和釋放資源。資源系統(tǒng)的架構(gòu)通常圍繞幾個(gè)核心概念展開(kāi)資源句柄、資源加載器、資源緩存、引用計(jì)數(shù)。資源句柄是一個(gè)輕量級(jí)的標(biāo)識(shí)符上層模塊通過(guò)句柄來(lái)引用資源而不是直接持有資源指針。這樣做的好處是資源可以在內(nèi)存中移動(dòng)或重新加載而句柄保持不變。資源加載器負(fù)責(zé)從磁盤(pán)或網(wǎng)絡(luò)加載資源數(shù)據(jù)并轉(zhuǎn)換成運(yùn)行時(shí)格式。這里涉及到一個(gè)重要的設(shè)計(jì)決策同步加載還是異步加載。同步加載實(shí)現(xiàn)簡(jiǎn)單但會(huì)阻塞主線程導(dǎo)致卡頓。異步加載需要配合任務(wù)系統(tǒng)和回調(diào)機(jī)制復(fù)雜度更高但能保證流暢體驗(yàn)。我在實(shí)際項(xiàng)目中的做法是關(guān)鍵路徑上的小資源用同步加載大資源和非關(guān)鍵資源用異步加載。同時(shí)提供一個(gè)“占位資源”機(jī)制在異步加載完成前先用低精度版本頂上避免畫(huà)面出現(xiàn)空洞。2.4 渲染層從場(chǎng)景數(shù)據(jù)到屏幕像素渲染層是引擎中最復(fù)雜的模塊之一它的職責(zé)是把場(chǎng)景數(shù)據(jù)轉(zhuǎn)換成最終的屏幕像素。這個(gè)過(guò)程涉及場(chǎng)景遍歷、剔除、排序、批處理、Shader執(zhí)行、后處理等多個(gè)階段。渲染層的架構(gòu)設(shè)計(jì)要解決的核心問(wèn)題是如何在保證畫(huà)質(zhì)的前提下最大化性能。這涉及到很多權(quán)衡。比如延遲渲染和前向渲染的選擇前者適合大量動(dòng)態(tài)光源的場(chǎng)景后者適合透明物體和抗鋸齒要求高的場(chǎng)景。很多現(xiàn)代引擎會(huì)同時(shí)支持兩種路徑根據(jù)場(chǎng)景配置切換。渲染層的另一個(gè)重要設(shè)計(jì)是渲染圖的概念。渲染圖把一幀的渲染過(guò)程描述成一組帶依賴(lài)關(guān)系的Pass引擎可以根據(jù)依賴(lài)關(guān)系自動(dòng)調(diào)度執(zhí)行順序并管理中間渲染目標(biāo)的分配和復(fù)用。這種架構(gòu)讓渲染管線的修改和擴(kuò)展變得非常靈活。// 渲染圖的簡(jiǎn)化示意 class RenderGraph { public: void AddPass(const char* name, std::functionvoid(RenderContext) execute, const std::vectorResourceHandle inputs, const std::vectorResourceHandle outputs); void Compile(); // 分析依賴(lài)分配資源 void Execute(); // 按拓?fù)漤樞驁?zhí)行 };2.5 游戲框架層面向玩法開(kāi)發(fā)者的接口最上層是游戲框架層它直接服務(wù)于游戲玩法開(kāi)發(fā)者。這一層包括實(shí)體組件系統(tǒng)、事件系統(tǒng)、腳本綁定、輸入處理等。實(shí)體組件系統(tǒng)的核心思想是組合優(yōu)于繼承。一個(gè)游戲?qū)ο蟛皇峭ㄟ^(guò)繼承層次來(lái)定義而是通過(guò)掛載不同的組件來(lái)組合出不同的行為。這樣做的好處是靈活避免了深層繼承樹(shù)帶來(lái)的僵化問(wèn)題。腳本綁定層負(fù)責(zé)把引擎的C接口暴露給腳本語(yǔ)言。常見(jiàn)的方案有手動(dòng)綁定、自動(dòng)生成綁定和直接嵌入腳本虛擬機(jī)。手動(dòng)綁定控制力最強(qiáng)但工作量大自動(dòng)生成綁定效率高但可能產(chǎn)生冗余代碼。選擇哪種方案取決于團(tuán)隊(duì)的技術(shù)棧和迭代速度要求。提示游戲框架層的接口設(shè)計(jì)要以“玩法開(kāi)發(fā)者的使用體驗(yàn)”為第一優(yōu)先級(jí)。引擎內(nèi)部可以復(fù)雜但暴露給玩法層的API要盡量簡(jiǎn)潔直觀。我見(jiàn)過(guò)太多引擎在內(nèi)部架構(gòu)上很優(yōu)雅但玩法開(kāi)發(fā)者用起來(lái)極其痛苦最后大家寧愿繞過(guò)引擎自己造輪子。3. 實(shí)操搭建一個(gè)最小可用的引擎骨架前面講了架構(gòu)分層和團(tuán)隊(duì)分工的對(duì)應(yīng)關(guān)系這一節(jié)我來(lái)實(shí)際演示如何搭建一個(gè)最小可用的引擎骨架。這個(gè)骨架不追求功能完整但會(huì)包含核心的分層結(jié)構(gòu)和模塊通信機(jī)制你可以在此基礎(chǔ)上逐步擴(kuò)展。3.1 項(xiàng)目目錄結(jié)構(gòu)與構(gòu)建系統(tǒng)選擇首先確定目錄結(jié)構(gòu)。我習(xí)慣按照架構(gòu)分層來(lái)組織目錄這樣模塊邊界一目了然engine/ source/ platform/ # 平臺(tái)抽象層 core/ # 核心系統(tǒng)層 resource/ # 資源系統(tǒng)層 renderer/ # 渲染層 framework/ # 游戲框架層 third_party/ # 第三方庫(kù) build/ # 構(gòu)建腳本 tests/ # 單元測(cè)試構(gòu)建系統(tǒng)方面C項(xiàng)目常見(jiàn)的選擇有CMake、Premake、Meson等。CMake是目前最主流的選擇生態(tài)成熟跨平臺(tái)支持好。我建議用CMake的target機(jī)制來(lái)管理模塊依賴(lài)每個(gè)層作為一個(gè)獨(dú)立的target上層target鏈接下層target。# 核心系統(tǒng)層 add_library(engine_core STATIC source/core/memory.cpp source/core/math.cpp source/core/container.cpp ) target_link_libraries(engine_core PUBLIC engine_platform) # 渲染層 add_library(engine_renderer STATIC source/renderer/render_graph.cpp source/renderer/material.cpp ) target_link_libraries(engine_renderer PUBLIC engine_core engine_resource)這種寫(xiě)法的好處是依賴(lài)關(guān)系顯式聲明如果某一層引用了不該引用的下層模塊編譯時(shí)會(huì)直接報(bào)錯(cuò)。這比靠文檔和口頭約定來(lái)維護(hù)架構(gòu)邊界可靠得多。3.2 模塊間通信事件總線與依賴(lài)注入引擎各層之間需要通信但又不希望產(chǎn)生強(qiáng)耦合。常見(jiàn)的解決方案有兩種事件總線和依賴(lài)注入。事件總線適合處理“某件事發(fā)生了誰(shuí)關(guān)心誰(shuí)處理”的場(chǎng)景。比如資源加載完成、窗口大小改變、幀開(kāi)始/結(jié)束等。實(shí)現(xiàn)上通常是一個(gè)類(lèi)型安全的回調(diào)注冊(cè)表。class EventBus { public: templatetypename EventType void Subscribe(std::functionvoid(const EventType) handler); templatetypename EventType void Publish(const EventType event); };依賴(lài)注入適合處理“某個(gè)模塊需要另一個(gè)模塊的服務(wù)”的場(chǎng)景。比如渲染層需要資源系統(tǒng)來(lái)加載紋理但不應(yīng)該直接依賴(lài)資源系統(tǒng)的具體實(shí)現(xiàn)。做法是定義一個(gè)接口渲染層依賴(lài)接口資源系統(tǒng)提供實(shí)現(xiàn)。// 渲染層定義的資源加載接口 class ITextureLoader { public: virtual ~ITextureLoader() default; virtual TextureHandle LoadTexture(const char* path) 0; }; // 資源系統(tǒng)提供實(shí)現(xiàn) class ResourceSystem : public ITextureLoader { public: TextureHandle LoadTexture(const char* path) override; };這兩種方式各有適用場(chǎng)景。我的經(jīng)驗(yàn)是跨層的通知用事件總線同層或相鄰層的服務(wù)調(diào)用用依賴(lài)注入。不要把所有通信都塞進(jìn)事件總線否則代碼會(huì)變得難以追蹤。3.3 內(nèi)存追蹤與性能計(jì)數(shù)器的接入在骨架階段就把內(nèi)存追蹤和性能計(jì)數(shù)器接進(jìn)來(lái)后期會(huì)省很多事。內(nèi)存追蹤的基本思路是重載全局的new和delete記錄每次分配的大小、位置和調(diào)用棧。void* operator new(size_t size) { void* ptr malloc(size); MemoryTracker::RecordAllocation(ptr, size); return ptr; } void operator delete(void* ptr) noexcept { MemoryTracker::RecordDeallocation(ptr); free(ptr); }性能計(jì)數(shù)器則是在關(guān)鍵路徑上打點(diǎn)記錄耗時(shí)。比如每幀的渲染時(shí)間、物理模擬時(shí)間、資源加載時(shí)間等。這些數(shù)據(jù)可以用一個(gè)簡(jiǎn)單的環(huán)形緩沖區(qū)存儲(chǔ)然后在調(diào)試界面上可視化。class ProfileScope { public: ProfileScope(const char* name) { m_name name; m_start GetHighResolutionTime(); } ~ProfileScope() { auto elapsed GetHighResolutionTime() - m_start; Profiler::RecordSample(m_name, elapsed); } private: const char* m_name; uint64_t m_start; };這兩個(gè)工具在骨架階段接入的成本很低但后期排查性能問(wèn)題和內(nèi)存泄漏時(shí)價(jià)值巨大。我強(qiáng)烈建議在項(xiàng)目一開(kāi)始就做這件事。3.4 一個(gè)可運(yùn)行的最小示例把上面的東西串起來(lái)一個(gè)最小的引擎主循環(huán)大概長(zhǎng)這樣int main() { // 初始化各層 PlatformLayer::Initialize(); CoreSystems::Initialize(); ResourceSystem::Initialize(); Renderer::Initialize(); Framework::Initialize(); // 主循環(huán) while (!PlatformLayer::ShouldQuit()) { PlatformLayer::PollEvents(); { PROFILE_SCOPE(Frame); ResourceSystem::Update(); Framework::Update(); Renderer::Render(); } PlatformLayer::SwapBuffers(); } // 按相反順序關(guān)閉 Framework::Shutdown(); Renderer::Shutdown(); ResourceSystem::Shutdown(); CoreSystems::Shutdown(); PlatformLayer::Shutdown(); return 0; }這個(gè)骨架看起來(lái)簡(jiǎn)單但它已經(jīng)包含了引擎架構(gòu)的核心要素分層初始化、主循環(huán)、性能打點(diǎn)、有序關(guān)閉。你可以在這個(gè)基礎(chǔ)上逐步往每一層里填充具體功能。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄在實(shí)際搭建和迭代引擎的過(guò)程中我踩過(guò)不少坑。這一節(jié)整理一些典型問(wèn)題和排查思路希望能幫你少走彎路。4.1 模塊循環(huán)依賴(lài)的識(shí)別與打破循環(huán)依賴(lài)是引擎架構(gòu)中最常見(jiàn)的問(wèn)題之一。比如渲染層依賴(lài)資源層來(lái)加載紋理資源層又依賴(lài)渲染層來(lái)創(chuàng)建GPU資源這就形成了環(huán)。識(shí)別循環(huán)依賴(lài)的方法很簡(jiǎn)單在CMake中把每個(gè)層設(shè)為獨(dú)立target如果出現(xiàn)循環(huán)鏈接錯(cuò)誤就說(shuō)明有循環(huán)依賴(lài)。打破循環(huán)依賴(lài)的常見(jiàn)手段有三種第一種是提取公共接口層。把雙方都依賴(lài)的部分抽到一個(gè)更底層的模塊中。比如上面例子中可以把“紋理句柄”和“紋理描述”抽到核心層渲染層和資源層都依賴(lài)核心層而不是互相依賴(lài)。第二種是依賴(lài)倒置。讓上層定義接口下層實(shí)現(xiàn)接口。比如渲染層定義ITextureLoader接口資源層實(shí)現(xiàn)它。這樣依賴(lài)方向就從“資源層←渲染層”變成了“渲染層←資源層”打破了環(huán)。第三種是事件解耦。把直接調(diào)用改成事件通知。比如資源層加載完成后發(fā)布一個(gè)事件渲染層訂閱這個(gè)事件來(lái)創(chuàng)建GPU資源。這種方式適合異步場(chǎng)景但會(huì)增加代碼的追蹤難度。4.2 跨平臺(tái)編譯中的典型坑跨平臺(tái)編譯是C引擎開(kāi)發(fā)中繞不開(kāi)的問(wèn)題。我整理了一個(gè)常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向Windows編譯通過(guò)Linux鏈接失敗符號(hào)可見(jiàn)性設(shè)置不同檢查是否有__declspec(dllexport)等平臺(tái)特有修飾結(jié)構(gòu)體大小不一致對(duì)齊方式或類(lèi)型長(zhǎng)度不同用static_assert檢查sizeof統(tǒng)一使用固定寬度類(lèi)型運(yùn)行時(shí)崩潰但編譯無(wú)警告未定義行為在不同平臺(tái)表現(xiàn)不同開(kāi)啟所有警告使用AddressSanitizer等工具文件路徑找不到路徑分隔符或大小寫(xiě)敏感差異統(tǒng)一使用正斜杠避免依賴(lài)大小寫(xiě)多線程行為異常內(nèi)存模型或線程調(diào)度差異使用標(biāo)準(zhǔn)庫(kù)的原子操作和內(nèi)存序我的經(jīng)驗(yàn)是盡早建立跨平臺(tái)CI。不要等到項(xiàng)目后期才做跨平臺(tái)適配那時(shí)候問(wèn)題會(huì)堆積如山。每天自動(dòng)在多個(gè)平臺(tái)上編譯和跑測(cè)試問(wèn)題能在第一時(shí)間被發(fā)現(xiàn)。4.3 性能瓶頸的定位思路引擎性能問(wèn)題通常集中在幾個(gè)地方渲染、物理、資源加載、內(nèi)存分配。定位瓶頸的基本流程是先測(cè)量再分析最后優(yōu)化。測(cè)量階段用性能計(jì)數(shù)器記錄各模塊耗時(shí)。如果某個(gè)模塊耗時(shí)明顯偏高就進(jìn)入分析階段。分析階段可以用采樣分析器或插樁分析器來(lái)定位具體的熱點(diǎn)函數(shù)。優(yōu)化階段則根據(jù)熱點(diǎn)類(lèi)型選擇策略計(jì)算密集型的考慮算法優(yōu)化或SIMD內(nèi)存密集型的考慮緩存友好性或減少分配。注意不要憑直覺(jué)優(yōu)化。我見(jiàn)過(guò)太多人花幾天時(shí)間優(yōu)化一個(gè)自認(rèn)為很慢的函數(shù)結(jié)果發(fā)現(xiàn)它只占總耗時(shí)的百分之二。先用數(shù)據(jù)說(shuō)話再動(dòng)手。4.4 團(tuán)隊(duì)協(xié)作中的架構(gòu)腐化與應(yīng)對(duì)架構(gòu)腐化是團(tuán)隊(duì)項(xiàng)目中的隱形殺手。表現(xiàn)包括模塊邊界模糊、依賴(lài)關(guān)系混亂、公共模塊越來(lái)越臃腫、編譯時(shí)間越來(lái)越長(zhǎng)。應(yīng)對(duì)架構(gòu)腐化的關(guān)鍵是自動(dòng)化約束?？看a審查和口頭約定是不夠的要把架構(gòu)規(guī)則寫(xiě)成可執(zhí)行的檢查。比如用CMake的target依賴(lài)來(lái)強(qiáng)制模塊邊界用靜態(tài)分析工具檢查代碼規(guī)范用編譯時(shí)間監(jiān)控來(lái)發(fā)現(xiàn)模塊膨脹。另外定期做架構(gòu)回顧也很重要。每個(gè)迭代結(jié)束時(shí)花半小時(shí)看看最近的代碼變更是否違反了架構(gòu)原則及時(shí)糾正。這比等到問(wèn)題積累到無(wú)法收拾再重構(gòu)要?jiǎng)澦愕枚唷?.5 從個(gè)人項(xiàng)目到團(tuán)隊(duì)項(xiàng)目的架構(gòu)演進(jìn)個(gè)人項(xiàng)目轉(zhuǎn)團(tuán)隊(duì)項(xiàng)目時(shí)架構(gòu)需要做幾個(gè)關(guān)鍵調(diào)整。首先是接口穩(wěn)定性個(gè)人項(xiàng)目可以隨意改接口但團(tuán)隊(duì)項(xiàng)目中接口變更會(huì)影響其他人需要更謹(jǐn)慎。其次是文檔和注釋個(gè)人項(xiàng)目可以靠記憶團(tuán)隊(duì)項(xiàng)目必須靠文檔。最后是構(gòu)建和測(cè)試自動(dòng)化個(gè)人項(xiàng)目可以手動(dòng)構(gòu)建團(tuán)隊(duì)項(xiàng)目必須自動(dòng)化。我的建議是即使一開(kāi)始是個(gè)人項(xiàng)目也盡量按照?qǐng)F(tuán)隊(duì)項(xiàng)目的標(biāo)準(zhǔn)來(lái)要求自己。用CMake管理構(gòu)建寫(xiě)單元測(cè)試維護(hù)接口文檔。這些習(xí)慣在項(xiàng)目變大或加入新成員時(shí)會(huì)帶來(lái)巨大回報(bào)。5. 引擎架構(gòu)后續(xù)擴(kuò)展的方向這個(gè)骨架搭起來(lái)之后后續(xù)可以往幾個(gè)方向擴(kuò)展。渲染方向可以加入渲染圖和延遲渲染管線資源方向可以加入異步加載和熱重載框架方向可以加入實(shí)體組件系統(tǒng)和腳本綁定。每個(gè)方向都可以獨(dú)立演進(jìn)只要保持模塊邊界清晰。我個(gè)人在實(shí)際操作中的體會(huì)是引擎架構(gòu)沒(méi)有“完成”的狀態(tài)它隨著團(tuán)隊(duì)規(guī)模和項(xiàng)目需求不斷演進(jìn)。重要的不是一開(kāi)始就設(shè)計(jì)出完美的架構(gòu)而是建立一套能讓架構(gòu)持續(xù)演進(jìn)的機(jī)制——清晰的模塊邊界、自動(dòng)化的約束檢查、定期的架構(gòu)回顧。有了這套機(jī)制架構(gòu)就能跟著項(xiàng)目一起成長(zhǎng)而不是成為項(xiàng)目的負(fù)擔(dān)。 游戲引擎架構(gòu)設(shè)計(jì)：團(tuán)隊(duì)分工與C++底層實(shí)現(xiàn)
1. 從零開(kāi)始理解游戲引擎的團(tuán)隊(duì)分工邏輯很多人第一次接觸“游戲引擎架構(gòu)”這個(gè)詞腦子里浮現(xiàn)的是一堆類(lèi)和繼承關(guān)系圖或者某個(gè)開(kāi)源引擎的源碼目錄樹(shù)。但我在實(shí)際帶項(xiàng)目和跟團(tuán)隊(duì)協(xié)作的過(guò)程中發(fā)現(xiàn)真正決定一個(gè)引擎能不能跑起來(lái)、能不能被團(tuán)隊(duì)用起來(lái)的往往不是某個(gè)渲染算法有多精妙而是團(tuán)隊(duì)分工和底層架構(gòu)之間的匹配關(guān)系。換句話說(shuō)架構(gòu)不是畫(huà)出來(lái)的是被團(tuán)隊(duì)的組織方式和協(xié)作模式“逼”出來(lái)的。這個(gè)系列我打算從最基礎(chǔ)的地方講起第一篇就聊清楚兩件事一個(gè)游戲引擎團(tuán)隊(duì)通常怎么分工以及這些分工如何映射到底層架構(gòu)的模塊劃分上。適合剛?cè)胄邢肜斫庖嫒驳拈_(kāi)發(fā)者也適合已經(jīng)在一線寫(xiě)業(yè)務(wù)邏輯、想往引擎層深入的朋友。我會(huì)盡量用實(shí)際項(xiàng)目中的例子來(lái)說(shuō)明而不是照搬教科書(shū)上的分層圖。1.1 為什么先講團(tuán)隊(duì)分工而不是直接講代碼你可能會(huì)問(wèn)講引擎架構(gòu)為什么不直接從渲染管線、內(nèi)存管理、資源系統(tǒng)這些硬核內(nèi)容開(kāi)始原因很簡(jiǎn)單引擎架構(gòu)的本質(zhì)是協(xié)作契約。一個(gè)引擎的模塊邊界幾乎總是對(duì)應(yīng)著團(tuán)隊(duì)里某個(gè)角色或某個(gè)小組的職責(zé)邊界。如果你不理解誰(shuí)在用什么、誰(shuí)在改什么你就無(wú)法理解為什么某個(gè)模塊要設(shè)計(jì)成那樣。舉個(gè)例子渲染組的人希望材質(zhì)系統(tǒng)盡可能靈活能直接操作Shader參數(shù)但工具組的人希望材質(zhì)系統(tǒng)有穩(wěn)定的序列化格式和編輯器界面。這兩個(gè)訴求會(huì)直接影響到材質(zhì)系統(tǒng)在架構(gòu)上被拆成“運(yùn)行時(shí)核心”和“編輯器層”兩個(gè)部分。如果你只看代碼會(huì)覺(jué)得這是過(guò)度設(shè)計(jì)但如果你知道有兩個(gè)不同角色在同時(shí)使用這個(gè)系統(tǒng)就會(huì)明白這種拆分是必然的。所以我的建議是在學(xué)習(xí)任何引擎源碼之前先花點(diǎn)時(shí)間搞清楚一個(gè)典型引擎團(tuán)隊(duì)的角色劃分。這比死磕某個(gè)類(lèi)的實(shí)現(xiàn)細(xì)節(jié)有用得多。1.2 一個(gè)典型游戲引擎團(tuán)隊(duì)的角色劃分不同規(guī)模的團(tuán)隊(duì)分工粒度差別很大。大廠可能一個(gè)渲染模塊就有幾十號(hào)人小團(tuán)隊(duì)可能一個(gè)人同時(shí)負(fù)責(zé)渲染、物理和工具。但不管規(guī)模如何核心職能是逃不掉的。我把它歸納為五個(gè)方向核心運(yùn)行時(shí)組負(fù)責(zé)引擎最底層的模塊包括內(nèi)存管理、數(shù)學(xué)庫(kù)、容器、任務(wù)調(diào)度、平臺(tái)抽象層。這個(gè)組的人通常C功底極深關(guān)注性能和跨平臺(tái)兼容性。渲染與圖形組負(fù)責(zé)渲染管線、材質(zhì)系統(tǒng)、光照、后處理、Shader管理。這個(gè)組需要同時(shí)懂圖形API和GPU硬件特性。物理與動(dòng)畫(huà)組負(fù)責(zé)碰撞檢測(cè)、剛體模擬、骨骼動(dòng)畫(huà)、IK等。這個(gè)組對(duì)數(shù)值穩(wěn)定性和實(shí)時(shí)性要求極高。資源與工具組負(fù)責(zé)資源導(dǎo)入管線、序列化、編輯器、資產(chǎn)管理系統(tǒng)。這個(gè)組是引擎和內(nèi)容創(chuàng)作者之間的橋梁。游戲框架組負(fù)責(zé)實(shí)體組件系統(tǒng)、腳本綁定、事件系統(tǒng)、網(wǎng)絡(luò)同步等。這個(gè)組直接服務(wù)于游戲玩法開(kāi)發(fā)者。這五個(gè)方向不是孤立的它們之間有大量的交叉依賴(lài)。而底層架構(gòu)要解決的核心問(wèn)題就是如何讓這五個(gè)方向的人能并行工作而不互相踩腳。1.3 分工如何影響架構(gòu)的模塊邊界我拿一個(gè)實(shí)際場(chǎng)景來(lái)說(shuō)明。假設(shè)渲染組要新增一種材質(zhì)類(lèi)型工具組要能在編輯器里編輯這種材質(zhì)的參數(shù)游戲框架組要能在腳本里動(dòng)態(tài)修改材質(zhì)屬性。這三個(gè)訴求對(duì)應(yīng)到架構(gòu)上就要求材質(zhì)系統(tǒng)至少分成三層第一層是運(yùn)行時(shí)材質(zhì)核心只包含GPU需要的參數(shù)和狀態(tài)由渲染組維護(hù)。第二層是序列化與反射層負(fù)責(zé)把材質(zhì)參數(shù)映射到編輯器可編輯的字段由工具組維護(hù)。第三層是腳本綁定層把材質(zhì)接口暴露給腳本系統(tǒng)由游戲框架組維護(hù)。如果架構(gòu)上沒(méi)有做這個(gè)拆分而是把材質(zhì)做成一個(gè)巨大的類(lèi)那么三個(gè)組的人就會(huì)同時(shí)修改同一個(gè)文件代碼沖突和溝通成本會(huì)急劇上升。這就是為什么我說(shuō)架構(gòu)是協(xié)作契約——它的第一目標(biāo)是讓不同角色能高效并行而不是追求代碼本身的優(yōu)雅。注意很多新手在自研引擎時(shí)容易把所有功能塞進(jìn)一個(gè)模塊覺(jué)得“反正我一個(gè)人寫(xiě)”。但一旦團(tuán)隊(duì)超過(guò)三個(gè)人這種架構(gòu)就會(huì)成為瓶頸。提前做好模塊邊界劃分比后期重構(gòu)代價(jià)小得多。2. 底層架構(gòu)的核心分層與C實(shí)現(xiàn)要點(diǎn)聊完團(tuán)隊(duì)分工接下來(lái)進(jìn)入底層架構(gòu)本身。游戲引擎的底層架構(gòu)通常分為幾個(gè)大層每一層解決不同的問(wèn)題。我用一個(gè)從下往上的順序來(lái)講這樣你能看清楚依賴(lài)關(guān)系是怎么建立的。2.1 平臺(tái)抽象層屏蔽操作系統(tǒng)差異最底層是平臺(tái)抽象層它的職責(zé)是把操作系統(tǒng)相關(guān)的API封裝成統(tǒng)一的接口。比如文件讀寫(xiě)、線程創(chuàng)建、時(shí)間獲取、窗口管理這些在不同平臺(tái)上實(shí)現(xiàn)方式不同但上層模塊不應(yīng)該關(guān)心這些差異。為什么這一層要用C來(lái)做因?yàn)槠脚_(tái)抽象層需要直接調(diào)用系統(tǒng)API而C提供了足夠的底層控制能力同時(shí)又能通過(guò)虛函數(shù)或函數(shù)指針實(shí)現(xiàn)運(yùn)行時(shí)多態(tài)。常見(jiàn)的做法是定義一組純虛接口然后每個(gè)平臺(tái)提供一份實(shí)現(xiàn)。// 平臺(tái)抽象層的文件接口示例 class IFileSystem { public: virtual ~IFileSystem() default; virtual FileHandle Open(const char* path, FileMode mode) 0; virtual size_t Read(FileHandle handle, void* buffer, size_t size) 0; virtual size_t Write(FileHandle handle, const void* buffer, size_t size) 0; virtual void Close(FileHandle handle) 0; };這個(gè)接口看起來(lái)簡(jiǎn)單但實(shí)際項(xiàng)目中需要考慮的細(xì)節(jié)很多。比如路徑分隔符在Windows上是反斜杠在類(lèi)Unix系統(tǒng)上是正斜杠文件編碼在不同平臺(tái)上也有差異。這些細(xì)節(jié)都應(yīng)該在這一層被消化掉上層模塊只看到統(tǒng)一的接口。我在實(shí)際項(xiàng)目中的一個(gè)經(jīng)驗(yàn)是平臺(tái)抽象層的接口設(shè)計(jì)要盡量窄。不要為了“以后可能用到”而暴露大量平臺(tái)特有的功能。接口越窄跨平臺(tái)移植時(shí)的工作量越小。曾經(jīng)有個(gè)項(xiàng)目在平臺(tái)層暴露了Windows特有的重疊IO接口結(jié)果移植到其他平臺(tái)時(shí)不得不重寫(xiě)整個(gè)資源加載模塊。2.2 核心系統(tǒng)層內(nèi)存、數(shù)學(xué)與容器平臺(tái)抽象層之上是核心系統(tǒng)層這一層是引擎的“基礎(chǔ)設(shè)施”。主要包括內(nèi)存管理、數(shù)學(xué)庫(kù)、容器和字符串處理。內(nèi)存管理是引擎性能的關(guān)鍵。游戲引擎通常不會(huì)直接使用全局的new和delete而是實(shí)現(xiàn)自己的內(nèi)存分配器。原因有三個(gè)第一減少內(nèi)存碎片第二提高分配速度第三方便追蹤內(nèi)存泄漏。常見(jiàn)的做法是分層分配器底層是一個(gè)大塊內(nèi)存池上層根據(jù)不同用途劃分不同的分配策略。比如幀分配器用于每幀臨時(shí)分配的內(nèi)存生命周期只有一幀對(duì)象池用于頻繁創(chuàng)建銷(xiāo)毀的同類(lèi)型對(duì)象通用堆分配器用于長(zhǎng)生命周期對(duì)象。// 簡(jiǎn)單的幀分配器示意 class FrameAllocator { public: void* Allocate(size_t size, size_t alignment) { // 從當(dāng)前幀的內(nèi)存塊中分配 // 每幀結(jié)束時(shí)整體重置不需要逐個(gè)釋放 } void Reset() { // 幀結(jié)束時(shí)調(diào)用一次性回收所有分配 } };數(shù)學(xué)庫(kù)方面引擎通常需要向量、矩陣、四元數(shù)、射線、包圍盒等基礎(chǔ)類(lèi)型。這些類(lèi)型的實(shí)現(xiàn)要特別注意精度和性能的平衡。比如矩陣乘法用SIMD指令加速可以帶來(lái)數(shù)倍的性能提升但代碼復(fù)雜度也會(huì)上升。我的建議是先用標(biāo)量實(shí)現(xiàn)跑通邏輯確認(rèn)瓶頸后再做SIMD優(yōu)化。容器方面引擎通常不會(huì)直接用STL的全部容器而是根據(jù)場(chǎng)景選擇或自研。比如std::vector在大多數(shù)場(chǎng)景下夠用但std::unordered_map的哈希函數(shù)和內(nèi)存布局可能不適合性能敏感的場(chǎng)景。很多引擎會(huì)實(shí)現(xiàn)自己的開(kāi)放尋址哈希表或扁平化容器。2.3 資源系統(tǒng)層資產(chǎn)的生命周期管理資源系統(tǒng)負(fù)責(zé)管理游戲中的各種資產(chǎn)包括紋理、模型、音頻、材質(zhì)、動(dòng)畫(huà)等。這一層的核心問(wèn)題是如何高效地加載、引用、緩存和釋放資源。資源系統(tǒng)的架構(gòu)通常圍繞幾個(gè)核心概念展開(kāi)資源句柄、資源加載器、資源緩存、引用計(jì)數(shù)。資源句柄是一個(gè)輕量級(jí)的標(biāo)識(shí)符上層模塊通過(guò)句柄來(lái)引用資源而不是直接持有資源指針。這樣做的好處是資源可以在內(nèi)存中移動(dòng)或重新加載而句柄保持不變。資源加載器負(fù)責(zé)從磁盤(pán)或網(wǎng)絡(luò)加載資源數(shù)據(jù)并轉(zhuǎn)換成運(yùn)行時(shí)格式。這里涉及到一個(gè)重要的設(shè)計(jì)決策同步加載還是異步加載。同步加載實(shí)現(xiàn)簡(jiǎn)單但會(huì)阻塞主線程導(dǎo)致卡頓。異步加載需要配合任務(wù)系統(tǒng)和回調(diào)機(jī)制復(fù)雜度更高但能保證流暢體驗(yàn)。我在實(shí)際項(xiàng)目中的做法是關(guān)鍵路徑上的小資源用同步加載大資源和非關(guān)鍵資源用異步加載。同時(shí)提供一個(gè)“占位資源”機(jī)制在異步加載完成前先用低精度版本頂上避免畫(huà)面出現(xiàn)空洞。2.4 渲染層從場(chǎng)景數(shù)據(jù)到屏幕像素渲染層是引擎中最復(fù)雜的模塊之一它的職責(zé)是把場(chǎng)景數(shù)據(jù)轉(zhuǎn)換成最終的屏幕像素。這個(gè)過(guò)程涉及場(chǎng)景遍歷、剔除、排序、批處理、Shader執(zhí)行、后處理等多個(gè)階段。渲染層的架構(gòu)設(shè)計(jì)要解決的核心問(wèn)題是如何在保證畫(huà)質(zhì)的前提下最大化性能。這涉及到很多權(quán)衡。比如延遲渲染和前向渲染的選擇前者適合大量動(dòng)態(tài)光源的場(chǎng)景后者適合透明物體和抗鋸齒要求高的場(chǎng)景。很多現(xiàn)代引擎會(huì)同時(shí)支持兩種路徑根據(jù)場(chǎng)景配置切換。渲染層的另一個(gè)重要設(shè)計(jì)是渲染圖的概念。渲染圖把一幀的渲染過(guò)程描述成一組帶依賴(lài)關(guān)系的Pass引擎可以根據(jù)依賴(lài)關(guān)系自動(dòng)調(diào)度執(zhí)行順序并管理中間渲染目標(biāo)的分配和復(fù)用。這種架構(gòu)讓渲染管線的修改和擴(kuò)展變得非常靈活。// 渲染圖的簡(jiǎn)化示意 class RenderGraph { public: void AddPass(const char* name, std::functionvoid(RenderContext) execute, const std::vectorResourceHandle inputs, const std::vectorResourceHandle outputs); void Compile(); // 分析依賴(lài)分配資源 void Execute(); // 按拓?fù)漤樞驁?zhí)行 };2.5 游戲框架層面向玩法開(kāi)發(fā)者的接口最上層是游戲框架層它直接服務(wù)于游戲玩法開(kāi)發(fā)者。這一層包括實(shí)體組件系統(tǒng)、事件系統(tǒng)、腳本綁定、輸入處理等。實(shí)體組件系統(tǒng)的核心思想是組合優(yōu)于繼承。一個(gè)游戲?qū)ο蟛皇峭ㄟ^(guò)繼承層次來(lái)定義而是通過(guò)掛載不同的組件來(lái)組合出不同的行為。這樣做的好處是靈活避免了深層繼承樹(shù)帶來(lái)的僵化問(wèn)題。腳本綁定層負(fù)責(zé)把引擎的C接口暴露給腳本語(yǔ)言。常見(jiàn)的方案有手動(dòng)綁定、自動(dòng)生成綁定和直接嵌入腳本虛擬機(jī)。手動(dòng)綁定控制力最強(qiáng)但工作量大自動(dòng)生成綁定效率高但可能產(chǎn)生冗余代碼。選擇哪種方案取決于團(tuán)隊(duì)的技術(shù)棧和迭代速度要求。提示游戲框架層的接口設(shè)計(jì)要以“玩法開(kāi)發(fā)者的使用體驗(yàn)”為第一優(yōu)先級(jí)。引擎內(nèi)部可以復(fù)雜但暴露給玩法層的API要盡量簡(jiǎn)潔直觀。我見(jiàn)過(guò)太多引擎在內(nèi)部架構(gòu)上很優(yōu)雅但玩法開(kāi)發(fā)者用起來(lái)極其痛苦最后大家寧愿繞過(guò)引擎自己造輪子。3. 實(shí)操搭建一個(gè)最小可用的引擎骨架前面講了架構(gòu)分層和團(tuán)隊(duì)分工的對(duì)應(yīng)關(guān)系這一節(jié)我來(lái)實(shí)際演示如何搭建一個(gè)最小可用的引擎骨架。這個(gè)骨架不追求功能完整但會(huì)包含核心的分層結(jié)構(gòu)和模塊通信機(jī)制你可以在此基礎(chǔ)上逐步擴(kuò)展。3.1 項(xiàng)目目錄結(jié)構(gòu)與構(gòu)建系統(tǒng)選擇首先確定目錄結(jié)構(gòu)。我習(xí)慣按照架構(gòu)分層來(lái)組織目錄這樣模塊邊界一目了然engine/ source/ platform/ # 平臺(tái)抽象層 core/ # 核心系統(tǒng)層 resource/ # 資源系統(tǒng)層 renderer/ # 渲染層 framework/ # 游戲框架層 third_party/ # 第三方庫(kù) build/ # 構(gòu)建腳本 tests/ # 單元測(cè)試構(gòu)建系統(tǒng)方面C項(xiàng)目常見(jiàn)的選擇有CMake、Premake、Meson等。CMake是目前最主流的選擇生態(tài)成熟跨平臺(tái)支持好。我建議用CMake的target機(jī)制來(lái)管理模塊依賴(lài)每個(gè)層作為一個(gè)獨(dú)立的target上層target鏈接下層target。# 核心系統(tǒng)層 add_library(engine_core STATIC source/core/memory.cpp source/core/math.cpp source/core/container.cpp ) target_link_libraries(engine_core PUBLIC engine_platform) # 渲染層 add_library(engine_renderer STATIC source/renderer/render_graph.cpp source/renderer/material.cpp ) target_link_libraries(engine_renderer PUBLIC engine_core engine_resource)這種寫(xiě)法的好處是依賴(lài)關(guān)系顯式聲明如果某一層引用了不該引用的下層模塊編譯時(shí)會(huì)直接報(bào)錯(cuò)。這比靠文檔和口頭約定來(lái)維護(hù)架構(gòu)邊界可靠得多。3.2 模塊間通信事件總線與依賴(lài)注入引擎各層之間需要通信但又不希望產(chǎn)生強(qiáng)耦合。常見(jiàn)的解決方案有兩種事件總線和依賴(lài)注入。事件總線適合處理“某件事發(fā)生了誰(shuí)關(guān)心誰(shuí)處理”的場(chǎng)景。比如資源加載完成、窗口大小改變、幀開(kāi)始/結(jié)束等。實(shí)現(xiàn)上通常是一個(gè)類(lèi)型安全的回調(diào)注冊(cè)表。class EventBus { public: templatetypename EventType void Subscribe(std::functionvoid(const EventType) handler); templatetypename EventType void Publish(const EventType event); };依賴(lài)注入適合處理“某個(gè)模塊需要另一個(gè)模塊的服務(wù)”的場(chǎng)景。比如渲染層需要資源系統(tǒng)來(lái)加載紋理但不應(yīng)該直接依賴(lài)資源系統(tǒng)的具體實(shí)現(xiàn)。做法是定義一個(gè)接口渲染層依賴(lài)接口資源系統(tǒng)提供實(shí)現(xiàn)。// 渲染層定義的資源加載接口 class ITextureLoader { public: virtual ~ITextureLoader() default; virtual TextureHandle LoadTexture(const char* path) 0; }; // 資源系統(tǒng)提供實(shí)現(xiàn) class ResourceSystem : public ITextureLoader { public: TextureHandle LoadTexture(const char* path) override; };這兩種方式各有適用場(chǎng)景。我的經(jīng)驗(yàn)是跨層的通知用事件總線同層或相鄰層的服務(wù)調(diào)用用依賴(lài)注入。不要把所有通信都塞進(jìn)事件總線否則代碼會(huì)變得難以追蹤。3.3 內(nèi)存追蹤與性能計(jì)數(shù)器的接入在骨架階段就把內(nèi)存追蹤和性能計(jì)數(shù)器接進(jìn)來(lái)后期會(huì)省很多事。內(nèi)存追蹤的基本思路是重載全局的new和delete記錄每次分配的大小、位置和調(diào)用棧。void* operator new(size_t size) { void* ptr malloc(size); MemoryTracker::RecordAllocation(ptr, size); return ptr; } void operator delete(void* ptr) noexcept { MemoryTracker::RecordDeallocation(ptr); free(ptr); }性能計(jì)數(shù)器則是在關(guān)鍵路徑上打點(diǎn)記錄耗時(shí)。比如每幀的渲染時(shí)間、物理模擬時(shí)間、資源加載時(shí)間等。這些數(shù)據(jù)可以用一個(gè)簡(jiǎn)單的環(huán)形緩沖區(qū)存儲(chǔ)然后在調(diào)試界面上可視化。class ProfileScope { public: ProfileScope(const char* name) { m_name name; m_start GetHighResolutionTime(); } ~ProfileScope() { auto elapsed GetHighResolutionTime() - m_start; Profiler::RecordSample(m_name, elapsed); } private: const char* m_name; uint64_t m_start; };這兩個(gè)工具在骨架階段接入的成本很低但后期排查性能問(wèn)題和內(nèi)存泄漏時(shí)價(jià)值巨大。我強(qiáng)烈建議在項(xiàng)目一開(kāi)始就做這件事。3.4 一個(gè)可運(yùn)行的最小示例把上面的東西串起來(lái)一個(gè)最小的引擎主循環(huán)大概長(zhǎng)這樣int main() { // 初始化各層 PlatformLayer::Initialize(); CoreSystems::Initialize(); ResourceSystem::Initialize(); Renderer::Initialize(); Framework::Initialize(); // 主循環(huán) while (!PlatformLayer::ShouldQuit()) { PlatformLayer::PollEvents(); { PROFILE_SCOPE(Frame); ResourceSystem::Update(); Framework::Update(); Renderer::Render(); } PlatformLayer::SwapBuffers(); } // 按相反順序關(guān)閉 Framework::Shutdown(); Renderer::Shutdown(); ResourceSystem::Shutdown(); CoreSystems::Shutdown(); PlatformLayer::Shutdown(); return 0; }這個(gè)骨架看起來(lái)簡(jiǎn)單但它已經(jīng)包含了引擎架構(gòu)的核心要素分層初始化、主循環(huán)、性能打點(diǎn)、有序關(guān)閉。你可以在這個(gè)基礎(chǔ)上逐步往每一層里填充具體功能。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄在實(shí)際搭建和迭代引擎的過(guò)程中我踩過(guò)不少坑。這一節(jié)整理一些典型問(wèn)題和排查思路希望能幫你少走彎路。4.1 模塊循環(huán)依賴(lài)的識(shí)別與打破循環(huán)依賴(lài)是引擎架構(gòu)中最常見(jiàn)的問(wèn)題之一。比如渲染層依賴(lài)資源層來(lái)加載紋理資源層又依賴(lài)渲染層來(lái)創(chuàng)建GPU資源這就形成了環(huán)。識(shí)別循環(huán)依賴(lài)的方法很簡(jiǎn)單在CMake中把每個(gè)層設(shè)為獨(dú)立target如果出現(xiàn)循環(huán)鏈接錯(cuò)誤就說(shuō)明有循環(huán)依賴(lài)。打破循環(huán)依賴(lài)的常見(jiàn)手段有三種第一種是提取公共接口層。把雙方都依賴(lài)的部分抽到一個(gè)更底層的模塊中。比如上面例子中可以把“紋理句柄”和“紋理描述”抽到核心層渲染層和資源層都依賴(lài)核心層而不是互相依賴(lài)。第二種是依賴(lài)倒置。讓上層定義接口下層實(shí)現(xiàn)接口。比如渲染層定義ITextureLoader接口資源層實(shí)現(xiàn)它。這樣依賴(lài)方向就從“資源層←渲染層”變成了“渲染層←資源層”打破了環(huán)。第三種是事件解耦。把直接調(diào)用改成事件通知。比如資源層加載完成后發(fā)布一個(gè)事件渲染層訂閱這個(gè)事件來(lái)創(chuàng)建GPU資源。這種方式適合異步場(chǎng)景但會(huì)增加代碼的追蹤難度。4.2 跨平臺(tái)編譯中的典型坑跨平臺(tái)編譯是C引擎開(kāi)發(fā)中繞不開(kāi)的問(wèn)題。我整理了一個(gè)常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向Windows編譯通過(guò)Linux鏈接失敗符號(hào)可見(jiàn)性設(shè)置不同檢查是否有__declspec(dllexport)等平臺(tái)特有修飾結(jié)構(gòu)體大小不一致對(duì)齊方式或類(lèi)型長(zhǎng)度不同用static_assert檢查sizeof統(tǒng)一使用固定寬度類(lèi)型運(yùn)行時(shí)崩潰但編譯無(wú)警告未定義行為在不同平臺(tái)表現(xiàn)不同開(kāi)啟所有警告使用AddressSanitizer等工具文件路徑找不到路徑分隔符或大小寫(xiě)敏感差異統(tǒng)一使用正斜杠避免依賴(lài)大小寫(xiě)多線程行為異常內(nèi)存模型或線程調(diào)度差異使用標(biāo)準(zhǔn)庫(kù)的原子操作和內(nèi)存序我的經(jīng)驗(yàn)是盡早建立跨平臺(tái)CI。不要等到項(xiàng)目后期才做跨平臺(tái)適配那時(shí)候問(wèn)題會(huì)堆積如山。每天自動(dòng)在多個(gè)平臺(tái)上編譯和跑測(cè)試問(wèn)題能在第一時(shí)間被發(fā)現(xiàn)。4.3 性能瓶頸的定位思路引擎性能問(wèn)題通常集中在幾個(gè)地方渲染、物理、資源加載、內(nèi)存分配。定位瓶頸的基本流程是先測(cè)量再分析最后優(yōu)化。測(cè)量階段用性能計(jì)數(shù)器記錄各模塊耗時(shí)。如果某個(gè)模塊耗時(shí)明顯偏高就進(jìn)入分析階段。分析階段可以用采樣分析器或插樁分析器來(lái)定位具體的熱點(diǎn)函數(shù)。優(yōu)化階段則根據(jù)熱點(diǎn)類(lèi)型選擇策略計(jì)算密集型的考慮算法優(yōu)化或SIMD內(nèi)存密集型的考慮緩存友好性或減少分配。注意不要憑直覺(jué)優(yōu)化。我見(jiàn)過(guò)太多人花幾天時(shí)間優(yōu)化一個(gè)自認(rèn)為很慢的函數(shù)結(jié)果發(fā)現(xiàn)它只占總耗時(shí)的百分之二。先用數(shù)據(jù)說(shuō)話再動(dòng)手。4.4 團(tuán)隊(duì)協(xié)作中的架構(gòu)腐化與應(yīng)對(duì)架構(gòu)腐化是團(tuán)隊(duì)項(xiàng)目中的隱形殺手。表現(xiàn)包括模塊邊界模糊、依賴(lài)關(guān)系混亂、公共模塊越來(lái)越臃腫、編譯時(shí)間越來(lái)越長(zhǎng)。應(yīng)對(duì)架構(gòu)腐化的關(guān)鍵是自動(dòng)化約束?？看a審查和口頭約定是不夠的要把架構(gòu)規(guī)則寫(xiě)成可執(zhí)行的檢查。比如用CMake的target依賴(lài)來(lái)強(qiáng)制模塊邊界用靜態(tài)分析工具檢查代碼規(guī)范用編譯時(shí)間監(jiān)控來(lái)發(fā)現(xiàn)模塊膨脹。另外定期做架構(gòu)回顧也很重要。每個(gè)迭代結(jié)束時(shí)花半小時(shí)看看最近的代碼變更是否違反了架構(gòu)原則及時(shí)糾正。這比等到問(wèn)題積累到無(wú)法收拾再重構(gòu)要?jiǎng)澦愕枚唷?.5 從個(gè)人項(xiàng)目到團(tuán)隊(duì)項(xiàng)目的架構(gòu)演進(jìn)個(gè)人項(xiàng)目轉(zhuǎn)團(tuán)隊(duì)項(xiàng)目時(shí)架構(gòu)需要做幾個(gè)關(guān)鍵調(diào)整。首先是接口穩(wěn)定性個(gè)人項(xiàng)目可以隨意改接口但團(tuán)隊(duì)項(xiàng)目中接口變更會(huì)影響其他人需要更謹(jǐn)慎。其次是文檔和注釋個(gè)人項(xiàng)目可以靠記憶團(tuán)隊(duì)項(xiàng)目必須靠文檔。最后是構(gòu)建和測(cè)試自動(dòng)化個(gè)人項(xiàng)目可以手動(dòng)構(gòu)建團(tuán)隊(duì)項(xiàng)目必須自動(dòng)化。我的建議是即使一開(kāi)始是個(gè)人項(xiàng)目也盡量按照?qǐng)F(tuán)隊(duì)項(xiàng)目的標(biāo)準(zhǔn)來(lái)要求自己。用CMake管理構(gòu)建寫(xiě)單元測(cè)試維護(hù)接口文檔。這些習(xí)慣在項(xiàng)目變大或加入新成員時(shí)會(huì)帶來(lái)巨大回報(bào)。5. 引擎架構(gòu)后續(xù)擴(kuò)展的方向這個(gè)骨架搭起來(lái)之后后續(xù)可以往幾個(gè)方向擴(kuò)展。渲染方向可以加入渲染圖和延遲渲染管線資源方向可以加入異步加載和熱重載框架方向可以加入實(shí)體組件系統(tǒng)和腳本綁定。每個(gè)方向都可以獨(dú)立演進(jìn)只要保持模塊邊界清晰。我個(gè)人在實(shí)際操作中的體會(huì)是引擎架構(gòu)沒(méi)有“完成”的狀態(tài)它隨著團(tuán)隊(duì)規(guī)模和項(xiàng)目需求不斷演進(jìn)。重要的不是一開(kāi)始就設(shè)計(jì)出完美的架構(gòu)而是建立一套能讓架構(gòu)持續(xù)演進(jìn)的機(jī)制——清晰的模塊邊界、自動(dòng)化的約束檢查、定期的架構(gòu)回顧。有了這套機(jī)制架構(gòu)就能跟著項(xiàng)目一起成長(zhǎng)而不是成為項(xiàng)目的負(fù)擔(dān)。