聊到 Unreal Engine 4 的核心概念UObject 幾乎是繞不開的第一站。不少剛?cè)肟拥呐笥褧?huì)把 UObject 簡(jiǎn)單理解成“一個(gè)所有類都要繼承的基類”這個(gè)理解不算錯(cuò)但只看到了一層皮毛。真正用起來之后你會(huì)發(fā)現(xiàn)UE4 整套對(duì)象系統(tǒng)的入口級(jí)設(shè)計(jì)幾乎都掛在 UObject 這棵樹上反射、垃圾回收、序列化、編輯器集成、藍(lán)圖支持甚至網(wǎng)絡(luò)復(fù)制的前提條件全都在這里。它的地位用“萬物之源”形容真的不夸張。這篇文章我想拋開教科書式的定義從一個(gè)實(shí)際開發(fā)者的角度把 UObject 的設(shè)計(jì)動(dòng)機(jī)、核心機(jī)制、常用姿勢(shì)和常見坑一次性講清楚。無論你是剛接觸 UE4 的初學(xué)者還是寫過一段時(shí)間藍(lán)圖想往 C 底層扎的進(jìn)階者都應(yīng)該能從中拿到點(diǎn)東西。1. 為什么UE非要搞一個(gè)“萬物之源”——UObject誕生的動(dòng)機(jī)理解 UObject 之前先要理解一個(gè)很現(xiàn)實(shí)的問題C 本身不具備游戲引擎需要的“對(duì)象管理能力”。1.1 C這份“普通話”在游戲引擎里很難直接上崗C 是一門非常自由的語言你可以用new創(chuàng)建對(duì)象用delete銷毀對(duì)象也可以把一個(gè)對(duì)象指針傳來傳去。但在一個(gè)中大型游戲項(xiàng)目里純 C 的對(duì)象管理會(huì)迅速變成一場(chǎng)災(zāi)難。舉個(gè)例子你做了一個(gè)武器類里面存了一把武器的名字、傷害、等級(jí)。如果這個(gè)對(duì)象是純 C 類編輯器根本不知道它的存在藍(lán)圖不知道它有哪些字段存檔系統(tǒng)不知道怎么把它保存到磁盤網(wǎng)絡(luò)層也沒法自動(dòng)判斷哪個(gè)字段需要同步給其他客戶端。這些事情不是不能手工做而是每做一個(gè)功能都要手寫一堆配套代碼而且每加一個(gè)新類這些代碼都要重寫一遍。幾十個(gè)類還好幾百個(gè)類、上千個(gè)類的時(shí)候就完全撐不住了。C 缺少的東西總結(jié)下來就是三個(gè)運(yùn)行時(shí)反射能力不夠類有哪些字段、哪些方法在編譯后的二進(jìn)制里沒有現(xiàn)成可查的信息。內(nèi)存管理完全是“野生的”誰來負(fù)責(zé)釋放、什么時(shí)候釋放全靠程序員自覺。對(duì)象沒有統(tǒng)一的“身份”兩個(gè)對(duì)象之間怎么組織、怎么查找、怎么序列化沒有公共約定。引擎要穩(wěn)定運(yùn)轉(zhuǎn)就得在這些問題上給出確定性答案。這就是 UObject 出現(xiàn)的根本原因。1.2 UObject給對(duì)象辦了一張“引擎戶籍”如果說普通 C 類是一個(gè)“自由職業(yè)者”那 UObject 就是一個(gè)“正式注冊(cè)過的市民”。UE4 給每一個(gè) UObject 實(shí)例都安排了固定的身份信息它有一個(gè)全局范圍內(nèi)相對(duì)穩(wěn)定的名字FName。它有一個(gè)外層次結(jié)構(gòu)Outer通常指向“創(chuàng)建它的那個(gè)對(duì)象”。它有一個(gè)唯一的路徑形如/Game/Content/XXX.MyObject可以在運(yùn)行時(shí)被查找和解析。它也掛在一個(gè)由引擎統(tǒng)一管理的圖結(jié)構(gòu)上GC 垃圾回收器可以根據(jù)引用關(guān)系判斷它還能不能被訪問到。這套設(shè)計(jì)讓引擎擁有了一個(gè)可以統(tǒng)一治理的基礎(chǔ)“戶籍系統(tǒng)”。任何對(duì)象只要注冊(cè)成 UObject引擎就能用同一種機(jī)制去管理它、讀取它、保存它甚至把它暴露給編輯器。順帶說一句可能有人會(huì)疑惑為什么不直接把所有類都搞成 UObject答案也很簡(jiǎn)單不是所有東西都需要“戶籍”。比如一個(gè)單純用來傳數(shù)據(jù)的臨時(shí)結(jié)構(gòu)體、一個(gè)只在內(nèi)存里短暫存活的狀態(tài)信息如果也做成 UObject反而要承擔(dān) GC 追蹤、反射標(biāo)記、序列化檢查等一系列開銷得不償失。所有包裝成本最終都要有人買單。2. UObject到底提供了什么——五大核心能力拆解UObject 之所以能成為萬物之源是因?yàn)樗烊怀袚?dān)了五個(gè)核心職責(zé)。這五個(gè)能力單獨(dú)拿出來任何一個(gè)普通 C 類都能模擬但五個(gè)組合在一起并有標(biāo)準(zhǔn)機(jī)制支撐只有 UObject 做到了。2.1 反射讓代碼能在運(yùn)行時(shí)“看見自己”反射是 UObject 所有高級(jí)功能的地基。沒有反射后面講的 GC、序列化、編輯器集成全都無從談起。你寫的UCLASS()、UPROPERTY()、UFUNCTION()這些宏看起來只是給類加了幾行標(biāo)注但實(shí)際上它們會(huì)被 UnrealHeaderToolUHT在編譯前掃描并生成對(duì)應(yīng)的反射代碼。運(yùn)行時(shí)的引擎才能回答這些原本 C 回答不了的問題這個(gè)類叫什么名字它繼承了誰它有哪些屬性每個(gè)屬性的類型是什么我能不能通過字符串的形式拿到一個(gè)對(duì)象的某個(gè)屬性值我能不能通過函數(shù)名在運(yùn)行時(shí)動(dòng)態(tài)調(diào)用這個(gè)對(duì)象的方法舉個(gè)平時(shí)可能不太注意的例子。你在藍(lán)圖中給某個(gè)變量賦值編輯器其實(shí)不知道這個(gè)變量在 C 里是怎么存的。它之所以能正常讀取和寫入就是因?yàn)橐嫱ㄟ^反射拿到了FProperty的地址然后調(diào)用對(duì)應(yīng)的屬性訪問接口。我在實(shí)際工作中用反射做過一個(gè)通用配置工具把策劃填的表直接批量映射到 UObject 的屬性上整個(gè)過程不需要為每個(gè)類單獨(dú)寫解析邏輯靠的就是FindFProperty和屬性實(shí)例的枚舉。// 例如查一個(gè) UObject 上的屬性 FProperty* ScoreProp FindFPropertyFProperty(UMyDataObject::StaticClass(), GET_MEMBER_NAME_CHECKED(UMyDataObject, Score)); if (ScoreProp) { int32* ValuePtr ScoreProp-ContainerPtrToValuePtrint32(MyDataObject); *ValuePtr 100; }反射系統(tǒng)的存在讓 UE4 具備了“用統(tǒng)一的代碼處理任意對(duì)象”的能力。這是純 C 單靠模板和虛函數(shù)很難完全替代的。2.2 垃圾回收引擎替你管理對(duì)象的生死UObject 的長(zhǎng)生邏輯很簡(jiǎn)單不從根集合Root Set出發(fā)可達(dá)的對(duì)象最終會(huì)被 GC 回收。這里的核心概念有兩個(gè)一個(gè)是根集合一個(gè)是引用邊。根集合可以理解成一個(gè)“地基”列表比如當(dāng)前 World、當(dāng)前引擎實(shí)例、被AddToRoot()標(biāo)記過的對(duì)象都是根集合的一部分。GC 每次運(yùn)行時(shí)會(huì)從根集合開始遍歷所有引用把能走到的對(duì)象全部標(biāo)記為“存活”剩下沒標(biāo)記的就被判定為不可達(dá)直接回收。這個(gè)過程里只有被UPROPERTY()標(biāo)記的引用才會(huì)計(jì)入引用邊。這是個(gè)極其重要的細(xì)節(jié)。如果你在一個(gè) UObject 里寫了一個(gè)裸 C 指針指向另一個(gè) UObject并且沒有加UPROPERTY()那 GC 完全無視這條引用。哪天 GC 跑起來被指的那個(gè)對(duì)象可能就被回收了而你手里的指針并不知道繼續(xù)訪問就是典型的懸空指針崩潰。所以我在團(tuán)隊(duì)里反復(fù)強(qiáng)調(diào)一條紀(jì)律UObject 指向 UObject 的成員變量要么加UPROPERTY()要么用TStrongObjectPtr這類強(qiáng)引用包裝器絕對(duì)不要只寫一個(gè)裸指針就了事。需要主動(dòng)保命的時(shí)候可以用AddToRoot()把一個(gè) UObject 加到根集合里這樣它不會(huì)被 GC 掃掉。但記住用完要RemoveFromRoot()否則它就會(huì)成為一個(gè)永不被回收的對(duì)象等于內(nèi)存泄漏。2.3 序列化讓對(duì)象在磁盤和內(nèi)存之間搬家游戲里到處都需要“保存”和“讀取”存檔系統(tǒng)要把玩家狀態(tài)寫到硬盤關(guān)卡文件要把所有 Actor 的狀態(tài)保存下來資源編輯器也要把資產(chǎn)數(shù)據(jù)持久化。UObject 天然支持這個(gè)過程調(diào)用Serialize(FArchive Ar)或者讓引擎走資產(chǎn)系統(tǒng)的保存流程即可。序列化為什么依賴反射因?yàn)楫?dāng)引擎保存一個(gè)對(duì)象的時(shí)候它不需要針對(duì)每個(gè)類寫單獨(dú)的保存代碼。它只要拿到對(duì)象的 UClass遍歷所有UPROPERTY()然后把屬性的值逐個(gè)寫入FArchive就行。加載的時(shí)候反向操作。這也是為什么UPROPERTY()中的一個(gè)常見版本叫SaveGame它本質(zhì)上就是告訴序列化系統(tǒng)這個(gè)字段需要出現(xiàn)在存檔里。反過來也能推出一個(gè)常見的踩坑場(chǎng)景如果某個(gè)數(shù)據(jù)沒有加UPROPERTY()它就不會(huì)被序列化到磁盤下次重新加載資源時(shí)值就丟了。這在編輯器資產(chǎn)上尤其陰險(xiǎn)因?yàn)槟阍诰庉嬈骼锟匆谎蹟?shù)據(jù)還在內(nèi)存中一切正?？墒侵匦麓蜷_工程發(fā)現(xiàn)之前設(shè)的東西全回到了默認(rèn)值。2.4 編輯器集成細(xì)節(jié)面板不是魔法用過 UE4 編輯器的人應(yīng)該都對(duì)細(xì)節(jié)面板Detail Panel有印象選中一個(gè) Actor 或者資產(chǎn)右側(cè)就會(huì)列出所有可編輯屬性還能實(shí)時(shí)修改。這套能力背后的核心機(jī)制也是反射。只要你的類繼承自 UObject或更具體的 AActor、UActorComponent 等并且屬性上用UPROPERTY(EditAnywhere)做了標(biāo)記編輯器就能自動(dòng)識(shí)別這些屬性并把它們暴露給策劃和美術(shù)。不需要你再手動(dòng)寫任何界面代碼。這對(duì)一個(gè)工具鏈成熟的引擎來說價(jià)值怎么強(qiáng)調(diào)都不過分。更進(jìn)一步如果你定義了一個(gè)UDataAsset子類那么它可以直接作為一種資產(chǎn)出現(xiàn)在內(nèi)容瀏覽器里項(xiàng)目里所有人共享同一份配置。我經(jīng)常在項(xiàng)目里用這招做全局配置先把需要用到的數(shù)據(jù)規(guī)劃成一個(gè)個(gè) UObject 子類再做成 DataAsset最后由主邏輯在初始化時(shí)加載。整個(gè)流程天然自帶序列化和編輯器可視化比塞一堆共性的 JSON 或文本配置要直觀得多。2.5 網(wǎng)絡(luò)復(fù)制多人游戲的前置條件嚴(yán)格說不是所有 UObject 都能直接參與網(wǎng)絡(luò)復(fù)制但它是這條路線的起點(diǎn)。UE 的網(wǎng)絡(luò)同步核心是把某個(gè)對(duì)象上的屬性定期從服務(wù)器同步到客戶端。要想被復(fù)制這個(gè)對(duì)象首先得能有一個(gè)穩(wěn)定的身份并且能被引擎整體管理和打標(biāo)記UObject 正好符合這些條件。在實(shí)際項(xiàng)目中涉及聯(lián)網(wǎng)最終繼承的往往是 AActor 這類更上層的對(duì)象因?yàn)?Actor 自帶世界位置、生命周期和復(fù)制接口。但所有這條路線的底層身份、路徑、反射查詢?nèi)匀挥?UObject 提供。甚至可以說如果你想設(shè)計(jì)一套輕量的網(wǎng)絡(luò)協(xié)議或者自研同步框架UObject 提供的統(tǒng)一標(biāo)識(shí)和反射信息就是最方便的基礎(chǔ)設(shè)施。3. 實(shí)操從零正確創(chuàng)建一個(gè)UObject子類光講理論沒用關(guān)鍵還得會(huì)用、用對(duì)。這一節(jié)我把創(chuàng)建和使用 UObject 子類的完整姿勢(shì)拆開每一步給到可直接抄的代碼和理由。3.1 第一步寫一個(gè)帶反射宏的骨架最簡(jiǎn)單的 UObject 子類長(zhǎng)這樣#pragma once #include CoreMinimal.h #include UObject/NoExportTypes.h #include MyDataObject.generated.h UCLASS(BlueprintType) class MYGAME_API UMyDataObject : public UObject { GENERATED_BODY() public: UPROPERTY(EditAnywhere, BlueprintReadWrite, Category Data) int32 Score; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category Data) FString DisplayName; UFUNCTION(BlueprintCallable, Category Data) void ResetData(); };這里有幾個(gè)必須養(yǎng)成的習(xí)慣GENERATED_BODY()不能少它是 UHT 生成的元數(shù)據(jù)代碼的入口沒有它編譯都過不了。UCLASS()/UPROPERTY()/UFUNCTION()是反射的標(biāo)記不是隨便寫寫裝飾用的。頭文件末尾要包含YourClass.generated.h而且必須放在最后這是 UHT 的固定要求。.generated.h是從哪里來的它是編譯時(shí)由 UnrealHeaderTool 生成的不需要自己維護(hù)但你在源碼中必須顯式 include。你可能會(huì)問這些宏在真實(shí)編譯中只是展開成普通代碼真正起作用的是 UHT 生成的.gen.cpp。它里面記錄了類的反射信息比如屬性列表、函數(shù)列表、靜態(tài) UClass 指針等。引擎啟動(dòng)時(shí)這些信息會(huì)被注冊(cè)到全局反射系統(tǒng)里。3.2 第二步創(chuàng)建實(shí)例的三種姿勢(shì)UObject 子類不能直接new這句話是新手最需要記住的。正確創(chuàng)建方式是用NewObject。UMyDataObject* Data NewObjectUMyDataObject(this, UMyDataObject::StaticClass(), TEXT(MyData)); Data-Score 100;第一個(gè)參數(shù)是 Outer外層次結(jié)構(gòu)通常傳this。第二個(gè)參數(shù)是 UClass可以用類的StaticClass()獲取。第三個(gè)參數(shù)是對(duì)象名可以省略但要傳就盡量保證在 Outer 下唯一。為什么不能直接new因?yàn)?UObject 的創(chuàng)建過程不僅要分配內(nèi)存還要注冊(cè)到全局對(duì)象表、關(guān)聯(lián) UClass、設(shè)置 Outer、初始化標(biāo)志位等。這些工作只有引擎的標(biāo)準(zhǔn)工廠函數(shù)能完整做掉。除了運(yùn)行時(shí)創(chuàng)建還有一個(gè)很常用的對(duì)象叫 CDO全稱 Class Default Object也就是“類默認(rèn)對(duì)象”。每個(gè) UClass 都有一個(gè) CDO它用來保存這個(gè)類所有屬性的默認(rèn)值。在編輯器里你修改一個(gè)類的默認(rèn)屬性改的基本就是 CDO 上的值。// 獲取類的默認(rèn)對(duì)象 UMyDataObject* DefaultData UMyDataObject::StaticClass()-GetDefaultObjectUMyDataObject(); // 或者直接用類的靜態(tài)方法 UMyDataObject* DefaultData2 UMyDataObject::GetDefaultObjectUMyDataObject();獲取 CDO 后你可以讀取它的默認(rèn)值但盡量不要?jiǎng)邮中薷乃?shí)例的默認(rèn)值應(yīng)該通過繼承和屬性配置去調(diào)整而不是在代碼中偷偷改 CDO。第三類姿勢(shì)是給 UObject 套一個(gè)“安全的 C 持有器”TStrongObjectPtr。它適合在非 UObject 類比如純 C 管理器里保存一個(gè) UObject 引用這樣能保證對(duì)象在你持有期間不會(huì)被 GC 回收。TStrongObjectPtrUMyDataObject SafeData TStrongObjectPtrUMyDataObject(NewObjectUMyDataObject());用完就把TStrongObjectPtr置空或讓它析構(gòu)UObject 就又回到 GC 的管理范圍內(nèi)了。3.3 第三步類型判斷、路徑查詢與序列化常用API實(shí)際操作中這幾個(gè) UObject 的原生接口出現(xiàn)頻率極高我整理成一張速查表方便查閱接口作用常用場(chǎng)景GetFName()獲取對(duì)象的短名字FName日志輸出、快速比較GetPathName()獲取對(duì)象完整路徑運(yùn)行時(shí)查找、資產(chǎn)路徑記錄GetOuter()獲取對(duì)象的“外層次宿主”找回創(chuàng)建者、對(duì)象歸屬分析IsAT()判斷對(duì)象是否屬于某類型或派生類型安全檢查CastT()類型安全向下轉(zhuǎn)換失敗返回 nullptr轉(zhuǎn)換接口對(duì)象GetClass()獲取對(duì)象的 UClass反射遍歷、運(yùn)行時(shí)類型識(shí)別IsValid()判斷對(duì)象是否有效且未被回收指針安全檢測(cè)StaticClass()獲取類的 UClass配合 NewObject、反射比如你拿到一個(gè)UObject*想確認(rèn)它到底是不是某個(gè)自定義類型直接寫if (Obj Obj-IsAUMyDataObject()) { UMyDataObject* MyObj CastUMyDataObject(Obj); }另外序列化雖然多數(shù)情況由引擎隱式觸發(fā)但也可以手動(dòng)調(diào)用。比如你有一個(gè) UObject 想丟進(jìn)內(nèi)存歸檔FBufferArchive Buffer; MyDataObject-Serialize(Buffer);它的內(nèi)部實(shí)現(xiàn)就是遍歷反射屬性并寫入歸檔。這也是 UObject 最典型的“反射 序列化”聯(lián)動(dòng)。4. 開發(fā)避坑實(shí)錄這些坑我基本都踩過這一節(jié)我更想以“老玩家回憶錄”的方式來寫。下面的幾個(gè)問題只在文檔里看可能覺得離自己很遠(yuǎn)但實(shí)際項(xiàng)目里幾乎天天有人翻車尤其是剛脫離藍(lán)圖想轉(zhuǎn) C 的同學(xué)。4.1 構(gòu)造函數(shù)里new子對(duì)象編輯器笑而不語很多新手在寫 UObject 子類時(shí)會(huì)下意識(shí)在構(gòu)造函數(shù)里做這些事UMyDataObject::UMyDataObject() { // 錯(cuò)誤示范 SubObject new UOtherObject(); }這樣做最常見的結(jié)果是編譯沒問題編輯器一啟動(dòng)就崩或者對(duì)象創(chuàng)建后屬性錯(cuò)亂、生命周期詭異。核心原因在于UObject 的構(gòu)造函數(shù)發(fā)生在 CDO 創(chuàng)建階段引擎還沒準(zhǔn)備好完整的對(duì)象注冊(cè)環(huán)境普通new出來的 UObject 沒有走NewObject的完整流程會(huì)被引擎視為非法對(duì)象。正確做法是如果子對(duì)象真的很必要應(yīng)該用CreateDefaultSubobject來創(chuàng)建或者把需要在運(yùn)行時(shí)初始化的邏輯放到PostInitProperties/BeginPlay中再用NewObject動(dòng)態(tài)創(chuàng)建。UMyDataObject::UMyDataObject() { // 如果確實(shí)要有一個(gè)默認(rèn)子對(duì)象 SubObject CreateDefaultSubobjectUOtherObject(TEXT(SubObject)); // 注意不是所有UObject子對(duì)象都適合這種方式動(dòng)態(tài)場(chǎng)景優(yōu)先PostInitProperties }我的經(jīng)驗(yàn)是能不在構(gòu)造函數(shù)里做的事盡量不要做。構(gòu)造函數(shù)里越干凈對(duì)象創(chuàng)建越穩(wěn)。4.2 忘寫UPROPERTY數(shù)據(jù)“人間蒸發(fā)”這一節(jié)放一個(gè)優(yōu)先級(jí)最高的坑成員變量沒加UPROPERTY()然后你發(fā)現(xiàn)藍(lán)圖上看不到這個(gè)變量、存檔里讀不回這個(gè)變量、甚至 GC 一跑指向其他 UObject 的指針失效。前面講過反射系統(tǒng)只看標(biāo)記過的屬性。沒標(biāo)記的變量對(duì)引擎是完全透明的。它不會(huì)出現(xiàn)在編輯器細(xì)節(jié)面板不會(huì)參與序列化也不會(huì)被 GC 納入引用關(guān)系。我之前遇到過一個(gè)很典型的現(xiàn)場(chǎng)工具類里存了一個(gè)UDataTable*因?yàn)閷懙臅r(shí)候忘了加UPROPERTY()結(jié)果運(yùn)行時(shí)有時(shí)能用、經(jīng)常莫名其妙變成無效對(duì)象。查了半天最后給變量加個(gè)UPROPERTY()就痊愈了。所以寫類的第一反應(yīng)應(yīng)該是凡是你希望“引擎能看見”的變量一律加UPROPERTY()不希望引擎看見的也要想清楚這個(gè)變量是否會(huì)被 GC 或序列化影響。4.3 手動(dòng)delete UObject千萬別這么干沒接觸過 UE 內(nèi)存模型的 C 程序員會(huì)習(xí)慣性地在析構(gòu)或者清理階段寫delete SomeUObject;。在 UObject 體系里這幾乎等于自殺。UObject 的內(nèi)存由引擎的 GC 統(tǒng)一管理。你手動(dòng)刪了它但全局對(duì)象表里還留著這個(gè)對(duì)象的條目幾條引用關(guān)系鏈也沒有更新后續(xù)任何系統(tǒng)碰到這條殘留記錄都可能崩潰。正確做法是讓 GC 做回收斷開所有強(qiáng)引用把對(duì)象從根集合移除接下來交給 GC 掃描。如果對(duì)象還活著但你想主動(dòng)淘汰可以先調(diào)用MarkAsGarbage()或者把對(duì)象從根集合移除不要直接 delete。UE5 之后垃圾回收機(jī)制做了一些改進(jìn)但核心原則沒有變創(chuàng)造交給 NewObject銷毀交給 GC你自己盡量別碰內(nèi)存釋放。4.4 用UObject存海量高頻數(shù)據(jù)一場(chǎng)性能災(zāi)難最后這個(gè)坑屬于“架構(gòu)級(jí)”的。UObject 之所以不適合所有場(chǎng)景是因?yàn)橐粋€(gè) UObject 實(shí)例本身有較大的內(nèi)存開銷。它包含對(duì)象基類信息、名稱、Outer、標(biāo)志位、反射相關(guān)的緩存信息等。單個(gè)看不出問題但如果你在游戲里創(chuàng)建十萬個(gè) UObject 小對(duì)象來存一粒粒的彈道數(shù)據(jù)、技能結(jié)算臨時(shí)數(shù)據(jù)內(nèi)存會(huì)被迅速吃穿GC 壓力也會(huì)爆炸。正確的做法是需要反射、資產(chǎn)、藍(lán)圖交互、序列化、網(wǎng)絡(luò)復(fù)制的數(shù)據(jù)才用 UObject純粹的、輕量的、生命周期可控的數(shù)據(jù)用 USTRUCT 或普通 C 結(jié)構(gòu)體。比如一個(gè)武器的攻擊數(shù)據(jù)包用USTRUCT放在TArray里就很好完全沒有必要做成 UObject。UE4 里大量基礎(chǔ)數(shù)學(xué)結(jié)構(gòu)FVector、FTransform都是 USTRUCT不是 UObject不是沒有原因的。值類型和引用類型的使用邊界需要一開始就明確。類型內(nèi)存模型是否會(huì)被GC追蹤是否支持反射編輯器集成典型場(chǎng)景UObject引用類型引擎統(tǒng)一管理是完整支持支持資產(chǎn)、組件、對(duì)象實(shí)體AActor繼承自UObject有世界存在感是完整支持支持關(guān)卡中可生成的對(duì)象USTRUCT值類型通常按值傳遞否有限支持支持序列化/藍(lán)圖數(shù)據(jù)容器、傳輸結(jié)構(gòu)純C類完全自主管理否不支持不支持算法、系統(tǒng)內(nèi)部計(jì)算5. 關(guān)于UObject我最后留下的幾條使用原則寫了這么大一圈沉淀下來其實(shí)沒多少玄乎的東西都是實(shí)踐逼出來的經(jīng)驗(yàn)。第一一個(gè)對(duì)象需要被引擎“認(rèn)識(shí)”的時(shí)候才把它設(shè)計(jì)成 UObject。這個(gè)認(rèn)識(shí)包括需要存成資產(chǎn)、需要在藍(lán)圖里被訪問、需要被編輯器編輯、需要參與網(wǎng)絡(luò)復(fù)制或存檔。沒有這些需求別硬套。第二UObject 的類型邊界要在一開始就劃清楚。CC 里容易寫出“萬能 UObject”什么數(shù)據(jù)都往里塞最后 GC 壓力大、序列化慢、邏輯混亂。輕數(shù)據(jù)走 USTRUCT重實(shí)體走 UObject能省下大量調(diào)優(yōu)時(shí)間。第三永遠(yuǎn)別手欠去 delete 一個(gè) UObject也永遠(yuǎn)別信任一個(gè)沒有UPROPERTY()托管的裸指針。這兩條規(guī)則基本涵蓋了 UE 內(nèi)存管理里 80% 的坑。我見過太多項(xiàng)目崩潰信息的根因繞來繞去最后都回到“對(duì)象生命周期管理混亂”這一件事上。把 UObject 當(dāng)成萬物之源去理解關(guān)鍵不在于記住它的 API而在于理解它為什么把名字、內(nèi)存、反射、序列化都綁在一起。理解了這層原因以后遇到那些所謂“神秘問題”你基本都能一眼看穿它出現(xiàn)在哪條鏈路上。