簡(jiǎn)介面向 Unity 開發(fā)者的運(yùn)行時(shí) 3D 模型導(dǎo)入加載源碼工程基于 TriLib 插件實(shí)現(xiàn)可在游戲或應(yīng)用中動(dòng)態(tài)選擇 FBX、OBJ、GLTF2、STL、ZIP 等模型加載后在場(chǎng)景中實(shí)時(shí)預(yù)覽與替換適合需要模型動(dòng)態(tài)更新、關(guān)卡/場(chǎng)景編輯器或 AR/VR 可視化功能的項(xiàng)目。工程基于 Unity 2021.3.27 標(biāo)準(zhǔn)渲染管線編寫使用 TriLib 2.3.7 版本并兼容 Standard、Universal、HDRP 等多種渲染管線Windows、Mac、Linux、UWP、Android、WebGL 平臺(tái)均可接入。壓縮包為 7z 格式共 879 個(gè)文件、26.37MB以 C# 腳本、插件 DLL、材質(zhì)與 Shader、FBX 示例模型、Unity 場(chǎng)景及配置文件為主結(jié)構(gòu)完整便于直接學(xué)習(xí)模型加載流程、UI 交互和渲染管線適配方式。已有 267 人學(xué)習(xí)下載適合具備一定 Unity/C# 基礎(chǔ)、希望快速落地動(dòng)態(tài)模型導(dǎo)入與替換功能的開發(fā)者。 做這類運(yùn)行時(shí)加載的Unity3d項(xiàng)目最煩的就是編輯器里拖拽導(dǎo)入FBX那套經(jīng)驗(yàn)完全失效。我去年接了一個(gè)工具向的工程核心需求就是讓用戶在程序運(yùn)行過(guò)程中自己導(dǎo)入外部3D模型當(dāng)時(shí)在C#里選了TriLib插件來(lái)實(shí)現(xiàn)整套運(yùn)行時(shí)3D模型導(dǎo)入加載功能從本地路徑、服務(wù)器URL到拖拽文件全都走了一遍。這篇就把我的封裝思路、核心代碼和踩過(guò)的坑完整記錄下來(lái)給同樣在搞運(yùn)行時(shí)模型加載的朋友一個(gè)能直接參考的底子。先說(shuō)我為什么放棄Unity自帶的Resources和AssetBundle方案Resources只能加載打進(jìn)化包里的資源運(yùn)行時(shí)根本讀不到用戶磁盤上的文件AssetBundle每換一次模型就得重新打一次包不適合偏工具型和沙盒型產(chǎn)品。TriLib這種第三方加載器雖然要付費(fèi)但它是專門干這件事的支持FBX、OBJ、glTF、GLB、STL、PLY、3MF這些常見格式解析在子線程完成回調(diào)回主線程API設(shè)計(jì)得很順手。你要做的其實(shí)不是“能不能加載”而是怎么把加載能力封裝成穩(wěn)定、可控、不泄漏內(nèi)存的一套服務(wù)。1. 運(yùn)行時(shí)加載3D模型的真實(shí)場(chǎng)景什么時(shí)候必須用它1.1 編輯器導(dǎo)入與運(yùn)行時(shí)導(dǎo)入的本質(zhì)差異在Unity編輯器里FBX模型是通過(guò)AssetImporter導(dǎo)入的Unity會(huì)幫你生成Mesh、Material、Avatar、AnimationClip這些資源跟隨打包流程進(jìn)入最終包體。但運(yùn)行時(shí)加載是完全另一套邏輯程序已經(jīng)打包發(fā)布用戶在任意一臺(tái)機(jī)器上拿到一個(gè)模型文件丟給你的程序你必須當(dāng)場(chǎng)解析這個(gè)文件并創(chuàng)建出GameObject。兩者最大的差異是——編輯器導(dǎo)入有Unity官方元數(shù)據(jù)支撐運(yùn)行時(shí)導(dǎo)入完全依賴解析器自己。我那個(gè)項(xiàng)目最開始是讓用戶把SolidWorks導(dǎo)出的模型塞進(jìn)場(chǎng)景做展示后來(lái)需求擴(kuò)到了fbx、obj、gltf混著來(lái)。如果不借助TriLib這種成熟插件你等于要從FBX二進(jìn)制解析開始寫用C#手搓一個(gè)FBX解析器工作量堪比重新發(fā)明輪子。TriLib內(nèi)部把格式解析和Unity對(duì)象創(chuàng)建隔離開解析文件在后臺(tái)線程做創(chuàng)建GameObject、Mesh、Material這些Unity對(duì)象時(shí)自動(dòng)切回主線程從設(shè)計(jì)上就繞開了Unity API不能在子線程調(diào)用的硬限制。1.2 Unity原生加載方案對(duì)比為什么TriLib是更優(yōu)解方案能否加載外部文件支持格式是否需要打包流程運(yùn)行時(shí)成本Resources.Load不能Unity原生資產(chǎn)必須打包低AssetBundle不能直接讀磁盤自定義打包格式必須打包中UnityWebRequest 自寫解析可以取決于自寫解析器否極高TriLib可以FBX/OBJ/glTF/GLB/STL/PLY/3MF等否中等很多團(tuán)隊(duì)在做一個(gè)需要導(dǎo)入外部模型的需求時(shí)第一反應(yīng)是“讓用戶把模型上傳到服務(wù)器我們?cè)诤笈_(tái)轉(zhuǎn)成AssetBundle再下發(fā)”。這種思路能跑通但延遲大還強(qiáng)制用戶必須通過(guò)服務(wù)器中轉(zhuǎn)對(duì)于純本地工具類軟件完全說(shuō)不通。TriLib這種方案把加載過(guò)程放在客戶端天然支持離線模型格式兼容性還比AssetBundle好——AssetBundle本身就是Unity私有格式TriLib加載的是行業(yè)通用格式用戶用Blender、3ds Max、SolidWorks導(dǎo)出的原始文件就能直接用體驗(yàn)完全不一樣。我建議下面這幾類項(xiàng)目可以優(yōu)先考慮TriLib而不是自研模型展示類工具、CAD/BIM預(yù)覽軟件、沙盒建造類游戲、自動(dòng)化測(cè)試框架里需要?jiǎng)討B(tài)換模型的地方。如果是做純網(wǎng)游所有模型都由服務(wù)器分發(fā)那還是AssetBundle更合適。2. TriLib導(dǎo)入與前置配置版本、授權(quán)、文件訪問(wèn)權(quán)限2.1 版本選擇和API風(fēng)格差異TriLib目前市面上能搜到兩類版本1.x老版本和2.x重寫版。1.x的回調(diào)風(fēng)格偏舊很多歷史教程和論壇帖子都是1.x的寫法比如AssetLoader.LoadModelFromFile這個(gè)API在1.x里并不存在或者參數(shù)順序完全不同。我建議新項(xiàng)目一律用2.x因?yàn)?.x把加載入口收斂成AssetLoaderOptionsAssetLoader.LoadModel*靜態(tài)方法代碼可讀性好很多。安裝方式就是從Asset Store導(dǎo)入或者官網(wǎng)下載.unitypackage再Import。導(dǎo)入后如果工程報(bào)編譯錯(cuò)誤最常見的兩個(gè)原因一是Scripting Runtime Version沒升到.NET 4.x或.NET Standard 2.0TriLib用了一些較新的C#語(yǔ)法老版本的.NET 2.0 Subset編譯不過(guò)去二是有其他插件和TriLib共用DLL導(dǎo)致沖突。第二個(gè)情況比較棘手我的建議是剛導(dǎo)入時(shí)先開一個(gè)純凈工程驗(yàn)證TriLib能編譯再往主工程里合并這樣排查沖突快很多。2.2 Player Settings里容易漏掉的打包配置運(yùn)行時(shí)加載外部模型打包配置和編輯器里純調(diào)API完全是兩回事。我最先踩到的是打包后Android上讀不了SD卡文件iOS上讀不了Documents目錄下的文件Windows桌面版倒是沒這問(wèn)題。TriLib開箱只幫你做文件讀取和解析文件系統(tǒng)權(quán)限這個(gè)事得自己處理。Android平臺(tái)必須在Manifest里聲明READ_EXTERNAL_STORAGE權(quán)限iOS用Application.persistentDataPath繞過(guò)沙箱限制Windows桌面端反而是最省心的。還有一個(gè)打包后才會(huì)暴露的坑Shader Stripping。如果你的工程開啟了Strip Engine CodeIL2CPP裁剪而TriLib加載的模型材質(zhì)用到的Shader沒有提前打進(jìn)包運(yùn)行時(shí)材質(zhì)就會(huì)變成洋紅色。解決辦法是把可能用到的Shader加到Project Settings Graphics Always Included Shaders列表里或者是給Shader打上[Preserve]之類的標(biāo)記。我在做glTF加載時(shí)被這個(gè)問(wèn)題卡過(guò)一下午因?yàn)間lTF的PBR材質(zhì)映射到的Standard Shader在打包時(shí)被裁掉了。2.3 授權(quán)方式和商用邊界TriLib不是免費(fèi)插件但授權(quán)策略比較清晰個(gè)人開發(fā)者買一個(gè)License可以在多個(gè)自己名下的項(xiàng)目里用。需要注意的是如果你把TriLib封裝成SDK再賣給其他公司要確認(rèn)你買的授權(quán)是否允許分發(fā)Runtime代碼。我去年差點(diǎn)犯這個(gè)錯(cuò)——準(zhǔn)備把封裝好的加載服務(wù)作為中間件交付給甲方仔細(xì)看了License后才改成只交付源碼工程不交付預(yù)編譯的TriLib DLL。具體條款以你購(gòu)買時(shí)的版本為準(zhǔn)這個(gè)一定不能拍腦袋。3. 本地文件加載的完整鏈路從文件選擇器到場(chǎng)景GameObject3.1 運(yùn)行時(shí)文件選擇器怎么選Unity編輯器里有個(gè)EditorUtility.OpenFilePanel能用但它只在編輯器下有效打包后根本調(diào)不到。運(yùn)行時(shí)彈文件選擇框主流方案有三種Windows下用System.Windows.Forms.OpenFileDialog需要引入System.Windows.Forms程序集實(shí)測(cè)能用但UI風(fēng)格和Unity游戲畫面完全脫節(jié)偏桌面工具風(fēng)。用Asset Store里的Runtime File Dialog插件UI是Unity繪制的可定制性強(qiáng)適合游戲內(nèi)嵌界面。自己寫一套文件瀏覽器工作量中等優(yōu)點(diǎn)是完全貼合項(xiàng)目交互風(fēng)格。我當(dāng)時(shí)做的是工具類應(yīng)用直接選Windows Forms方案代碼最短。如果是游戲里給玩家用的還是建議用Unity UI做一套不然體驗(yàn)割裂。下面是Windows Forms方式的示例using System; using System.Windows.Forms; using UnityEngine; public static class RuntimeFileDialog { public static string ShowModelFileDialog() { using (OpenFileDialog dialog new OpenFileDialog()) { dialog.Filter 3D 模型文件|*.fbx;*.obj;*.gltf;*.glb;*.stl;*.ply;*.3mf; dialog.Multiselect false; dialog.RestoreDirectory true; if (dialog.ShowDialog() DialogResult.OK) { return dialog.FileName; } return null; } } }注意在Unity里直接調(diào)用WinForms時(shí)需要保證工程的Api Compatibility Level不是.NET Standard 2.0的子集否則編譯會(huì)報(bào)System.Windows.Forms找不到。Windows桌面項(xiàng)目建議把Api Compatibility Level設(shè)為.NET Framework。3.2 核心加載API和AssetLoaderOptions參數(shù)解讀拿到文件路徑后加載本身非常簡(jiǎn)潔。我這里給你一個(gè)完整的加載方法用到了TriLib 2.x的AssetLoader.LoadModelFromFileusing TriLib; using TriLib.Interfaces; using TriLib.Utils; using UnityEngine; public class ModelLoader : MonoBehaviour { private AssetLoaderOptions _options; private void Awake() { _options AssetLoaderOptions.CreateInstance(); _options.AutoLoadMaterials true; _options.AutoLoadLightmaps false; _options.GenerateColliders false; _options.MarkAssetsLoadedAsLoadedByDefault false; _options.ImportBlendShapes true; _options.ImportMorphs true; } public void LoadFromFile(string filePath, Transform parent) { AssetLoader.LoadModelFromFile(filePath, _options, (AssetLoaderContext context) { GameObject loaded context.LoadedGameObject; if (loaded null) return; loaded.transform.SetParent(parent, false); loaded.transform.localPosition Vector3.zero; loaded.transform.localRotation Quaternion.identity; loaded.transform.localScale Vector3.one; // 這里可以做后處理比如生成Collider、設(shè)置Layer AttachMeshCollider(loaded); }, (AssetLoaderContext context, float progress) { Debug.Log($加載進(jìn)度: {progress:P0}); }, (AssetLoaderContext context, IError error) { Debug.LogError($加載失敗: {error}); }); } private void AttachMeshCollider(GameObject root) { foreach (var filter in root.GetComponentsInChildrenMeshFilter()) { if (filter.GetComponentMeshCollider() null) { filter.gameObject.AddComponentMeshCollider(); } } } }這里的幾個(gè)關(guān)鍵參數(shù)展開說(shuō)下AutoLoadMaterials如果模型文件同目錄下有紋理貼圖TriLib會(huì)自動(dòng)找到并創(chuàng)建材質(zhì)。但注意這個(gè)只在加載本地文件時(shí)有效從字節(jié)數(shù)組加載時(shí)紋理文件不在內(nèi)存里AutoLoadMaterials是幫不上忙的。MarkAssetsLoadedAsLoadedByDefault它的作用是控制加載出來(lái)的Mesh、Material等資源是否被標(biāo)記為“已加載”。如果你打算緩存模型模板建議設(shè)成false這樣在卸載資源時(shí)更可控。GenerateColliders如果你用不到MeshCollider保持false可以省不少時(shí)間和內(nèi)存。大模型生成Collider非常耗時(shí)我實(shí)測(cè)加載一個(gè)30萬(wàn)面的FBX時(shí)生成Collider硬生生多了近1秒。ImportBlendShapes和ImportMorphs處理帶BlendShape的表情模型和Morph動(dòng)畫時(shí)打開。不過(guò)這倆默認(rèn)值有些情況是關(guān)的需要你手動(dòng)打開。3.3 異步加載與回調(diào)線程邏輯為什么UI不會(huì)卡死我剛才提到TriLib的解析是在子線程完成的。很多朋友第一次寫異步回調(diào)時(shí)會(huì)擔(dān)心“回調(diào)里訪問(wèn)Transform會(huì)不會(huì)線程不安全”這里明確一下AssetLoader.LoadModelFromFile傳進(jìn)去的三個(gè)回調(diào)成功、進(jìn)度、失敗一定是在主線程執(zhí)行的TriLib內(nèi)部用UnityMainThreadDispatcher幫你切換好了。游戲運(yùn)行時(shí)在主線程直接操作GameObject完全沒問(wèn)題。這也是我敢在成功回調(diào)里直接SetParent、加Collider的原因。不過(guò)進(jìn)度回調(diào)確實(shí)可能在短時(shí)間內(nèi)頻繁觸發(fā)如果你在進(jìn)度回調(diào)里直接更新UI Text會(huì)出現(xiàn)搶主線程的問(wèn)題尤其大模型加載期間。我的經(jīng)驗(yàn)是把進(jìn)度值暫存到一個(gè)字段只有變化超過(guò)1%才刷新UI避免每幀更新。4. 網(wǎng)絡(luò)URL與二進(jìn)制數(shù)據(jù)加載突破本地文件限制的兩種方式4.1 用UnityWebRequest下載到緩存再加載項(xiàng)目做到一半產(chǎn)品提了新需求用戶要從服務(wù)器拉取模型。TriLib官方也有LoadModelFromUrl但我實(shí)測(cè)下來(lái)并不總省心遇到網(wǎng)絡(luò)超時(shí)、重試、斷點(diǎn)續(xù)傳這些場(chǎng)景還是自己控制下載流程更可靠。我的方案是先用UnityWebRequest把文件下載到本地緩存目錄然后再走LoadModelFromFile。using System.Collections; using System.IO; using UnityEngine; using UnityEngine.Networking; public class RemoteModelLoader : MonoBehaviour { public IEnumerator LoadFromUrl(string url, Transform parent) { using (UnityWebRequest request UnityWebRequest.Get(url)) { request.timeout 30; yield return request.SendWebRequest(); if (request.result ! UnityWebRequest.Result.Success) { Debug.LogError($下載失敗: {request.error}); yield break; } byte[] data request.downloadHandler.data; string cachedPath Path.Combine(Application.persistentDataPath, cached_model.bin); File.WriteAllBytes(cachedPath, data); // 復(fù)用本地加載邏輯 GetComponentModelLoader().LoadFromFile(cachedPath, parent); } } }好處就一個(gè)字穩(wěn)。模型下載完一次后下次再用時(shí)走本地緩存和網(wǎng)絡(luò)完全解耦上傳新版本模型時(shí)換URL即可。這種方案還能在下載階段就用原生的UnityWebRequest處理HTTPS證書、斷網(wǎng)重試等邏輯比把網(wǎng)絡(luò)狀態(tài)直接拋給TriLib更可控。4.2 從Byte數(shù)組加載并解析常見格式還有一種數(shù)據(jù)源是Byte數(shù)組從網(wǎng)絡(luò)流、從加密包、從數(shù)據(jù)庫(kù)BLOB字段里讀出來(lái)的模型數(shù)據(jù)都是byte[]。TriLib提供了LoadModelFromBytes但這里有個(gè)必須注意的細(xì)節(jié)第二參數(shù)要傳文件名后綴TriLib依賴擴(kuò)展名判斷格式。public void LoadFromBytes(byte[] modelBytes, string fileName) { AssetLoader.LoadModelFromBytes(modelBytes, fileName, _options, context { /* 同樣處理 */ }, (context, progress) { /* 進(jìn)度處理 */ }, (context, error) { /* 錯(cuò)誤處理 */ }); }我遇到的情況是服務(wù)器返回的響應(yīng)頭里不帶文件名得在客戶端拼一個(gè)比如model_ System.DateTime.Now.Ticks .fbx。后綴傳錯(cuò)就很折磨人比如數(shù)據(jù)明明是glTF但你傳了.objTriLib會(huì)拿OBJ解析器去硬解成功率極低。如果你從URL里實(shí)在看不出格式可以先下載后探測(cè)文件頭特征判斷是FBX還是glTF還是OBJ再?zèng)Q定后綴這個(gè)方法在關(guān)鍵接口場(chǎng)景下能救你一命。4.3 拖拽加載桌面端一個(gè)容易忽略的便利功能桌面工具類應(yīng)用里用戶最自然的一個(gè)操作就是直接把模型文件拖進(jìn)窗口。Unity UGUI本身沒提供拖拽文件進(jìn)入窗口的原生支持但Windows下可以通過(guò)接管消息循環(huán)來(lái)拿到文件路徑或者在Windows Forms里托管Unity窗口實(shí)現(xiàn)拖拽。我的實(shí)現(xiàn)比較取巧在游戲窗口外層包一層WinForms容器設(shè)置AllowDrop true然后在DragEnter和DragDrop事件里讀取e.Data.GetData(DataFormats.FileDrop)拿到文件路徑后轉(zhuǎn)給ModelLoader。整個(gè)過(guò)程不到一百行代碼體驗(yàn)提升卻非常明顯用戶不用再去點(diǎn)“瀏覽”按鈕找文件了。5. 加載FBX時(shí)踩過(guò)的三個(gè)坑骨骼、材質(zhì)、主線程卡死5.1 坑一FBX帶骨骼但加載出來(lái)沒有Animator怎么辦我這個(gè)項(xiàng)目的模型大多是從外部DCC工具導(dǎo)出的FBX有些是帶角色骨骼的。第一次實(shí)測(cè)的時(shí)候發(fā)現(xiàn)模型層級(jí)、骨骼Transform都導(dǎo)進(jìn)來(lái)了但Animator組件壓根沒掛上或者掛上了也沒有Avatar。查了TriLib的文檔和論壇結(jié)論是TriLib主要負(fù)責(zé)把網(wǎng)格和材質(zhì)加載出來(lái)Humanoid Avatar重定向信息不是FBX標(biāo)準(zhǔn)里一定有內(nèi)容的它強(qiáng)依賴Unity的Avatar生成邏輯。FBX文件里如果有Unity自定義的Avatar配置TriLib會(huì)嘗試讀取如果純粹是Maya/Max導(dǎo)出通常沒有。我的處理是加載后手動(dòng)檢查并補(bǔ)一個(gè)Animator用在Generic模式或運(yùn)行時(shí)生成Avatarvoid EnsureAnimator(GameObject root) { var animator root.GetComponentInChildrenAnimator(); if (animator null) { animator root.AddComponentAnimator(); } // 如果模型包含humanoid骨骼可以嘗試生成Avatar if (animator.avatar null) { animator.avatar CreateAvatarFromBones(root); } }運(yùn)行時(shí)生成Avatar是一個(gè)比較深的話題簡(jiǎn)單做法是用AvatarBuilder.BuildHumanAvatar配合骨骼映射。但骨骼命名不同時(shí)容易映射失敗所以我的兜底方案是如果Build失敗就退回Generic模式至少保證模型display正確。5.2 坑二材質(zhì)變紫和貼圖丟失的完整排查鏈路運(yùn)行時(shí)加載出來(lái)的FBX材質(zhì)變紫是最常見的現(xiàn)象。有一次我打包后測(cè)試模型貼圖全部消失在編輯器里卻一切正常。排查過(guò)程走了一遍很典型的鏈路先在編輯器里用TriLib加載同一個(gè)文件現(xiàn)象正常。這排除了模型自身貼圖路徑錯(cuò)誤的問(wèn)題。打包后再次去加載發(fā)現(xiàn)材質(zhì)變紫。開始懷疑是Shader裁剪問(wèn)題。打開Player Log日志看到Material ... has no shader之類的警告。去Graphics Always Included Shaders里把Standard、Standard (Specular setup)加進(jìn)去重新打包問(wèn)題解決。如果紋理貼圖本身丟失多半是FBX旁邊的貼圖文件沒被找到。TriLib加載本地文件時(shí)會(huì)按FBX記錄的相對(duì)路徑找紋理。如果用戶把FBX拷走時(shí)沒帶上貼圖文件夾就會(huì)貼圖丟失。這個(gè)沒法在代碼層面完全解決只能力所能及地在UI里提示用戶“請(qǐng)確認(rèn)模型文件與貼圖在同一目錄”。另外從Byte數(shù)組加載時(shí)AutoLoadMaterials失效的問(wèn)題我的解法是加載后用統(tǒng)一的材質(zhì)覆蓋整個(gè)模型省去貼圖映射的麻煩也能避免Shader差異化導(dǎo)致的表現(xiàn)不一致。5.3 坑三大模型加載時(shí)卡死主線程進(jìn)度條還救不了TriLib的解析在子線程但當(dāng)模型網(wǎng)格數(shù)據(jù)量巨大時(shí)解析完成后創(chuàng)建Unity Mesh和Material對(duì)象的過(guò)程仍然要消耗大量主線程時(shí)間。我有個(gè)測(cè)試文件面數(shù)超過(guò)200萬(wàn)打開時(shí)Unity Editor直接白屏十幾秒進(jìn)度條卡住不動(dòng)。原因是創(chuàng)建大量Unity原生對(duì)象時(shí)內(nèi)存分配和引擎底層操作沒法完全異步化。對(duì)于這種情況我的建議有三個(gè)層面從源頭限制UI上給出面數(shù)上限提示或者在加載完成后檢查頂點(diǎn)數(shù)超出閾值就提示用戶簡(jiǎn)化模型。分批創(chuàng)建TriLib支持加載選項(xiàng)里設(shè)置一些后處理延遲但實(shí)際效果有限。更可靠的是加載完先隱藏模型用Loading畫面過(guò)渡等成功回調(diào)執(zhí)行完再顯示。加載前用縮略圖預(yù)覽先用AssetPreview生成預(yù)覽圖讓用戶確認(rèn)模型無(wú)誤再真正加載減少無(wú)效加載次數(shù)。我從這個(gè)坑里得到一個(gè)經(jīng)驗(yàn)運(yùn)行時(shí)加載模型這個(gè)功能永遠(yuǎn)不要假設(shè)用戶會(huì)傳“合理大小”的文件。程序里必須設(shè)定保護(hù)閾值比如超過(guò)一定頂點(diǎn)數(shù)直接拒絕加載并給出明確提示而不是讓用戶等幾分鐘然后崩潰。6. 加載器上線的最后一步內(nèi)存管理與重復(fù)加載優(yōu)化6.1 反復(fù)加載同一模型為什么會(huì)內(nèi)存爆炸如果用戶反復(fù)點(diǎn)“導(dǎo)入模型”每次都新建Mesh、Material、TextureUnity不會(huì)自動(dòng)幫你清理GC也管不了那些通過(guò)new Mesh()創(chuàng)建的引擎對(duì)象。我實(shí)測(cè)連續(xù)加載同一個(gè)200MB模型10次內(nèi)存直接翻了十倍這是因?yàn)門riLib每次都會(huì)重新解析并創(chuàng)建一套全新的資源對(duì)象。先前的資源沒有被銷毀Resources.UnloadUnusedAssets()也不會(huì)主動(dòng)清那些被C#對(duì)象引用的Mesh。這就要求我們?cè)O(shè)計(jì)一套模型緩存機(jī)制至少在“模板”層面做復(fù)用。我實(shí)際用的結(jié)構(gòu)是這樣public class ModelCache { private Dictionarystring, GameObject _templateCache new Dictionarystring, GameObject(); public GameObject GetOrLoadTemplate(string filePath, Transform parent) { if (_templateCache.TryGetValue(filePath, out var template)) { return template; } // 調(diào)用TriLib異步加載 // 成功后存入_cache并返回加載出來(lái)的GameObject作為模板 return null; } public GameObject InstantiateModel(string filePath, Transform parent) { var template GetOrLoadTemplate(filePath, parent); if (template null) return null; return GameObject.Instantiate(template, parent); } }核心思路就是模板與實(shí)例分離。用戶每次新開一個(gè)模型只是從模板Instantiate一份Mesh、Material、Texture這些大資源全部被模板持有每個(gè)文件在內(nèi)存里只有一份。6.2 模板緩存和實(shí)例銷毀的邊界處理有緩存就必然要處理“什么時(shí)候清緩存”。我的經(jīng)驗(yàn)是提供顯式的“清空緩存”按鈕用戶在切換項(xiàng)目或打開新模型時(shí)觸發(fā)Resources.UnloadUnusedAssets()。銷毀模板前必須保證所有Instantiate出來(lái)的實(shí)例都被Destroy掉否則實(shí)例會(huì)引用已經(jīng)被卸載的Mesh控臺(tái)會(huì)刷Missing引用錯(cuò)誤。如果用Resources.UnloadUnusedAssets()卸載外部加載的模型資源要注意它只對(duì)“不再被任何C#對(duì)象引用”的資源生效。所以模板一旦被緩存引用著就不會(huì)被卸載你必須在卸載前先從Dictionary里Remove掉。我最終做出來(lái)的ModelLoaderService是個(gè)單例對(duì)外暴露LoadFromFile、LoadFromBytes、LoadFromUrl、ClearCache四個(gè)方法。UI層只跟這個(gè)服務(wù)打交道完全不直接碰TriLibAPI。后邊新增需求時(shí)比如想加個(gè)“模型最近使用列表”也只需要在服務(wù)層加內(nèi)存和記錄的邏輯UI和加載邏輯都不用動(dòng)。6.3 網(wǎng)格合并與DrawCall優(yōu)化加載完不是終點(diǎn)模型加載到場(chǎng)景里如果直接把FBX的整個(gè)層級(jí)結(jié)構(gòu)原封不動(dòng)交給玩家看有可能一個(gè)模型十來(lái)個(gè)MeshDrawCall直接爆掉。尤其CAD導(dǎo)出的模型零部件極多。我建議在加載成功回調(diào)里做一個(gè)可選的網(wǎng)格合并步驟把靜態(tài)的、不動(dòng)的模型合并成一個(gè)Mesh。void CombineMeshesOnRoot(GameObject root) { var filters root.GetComponentsInChildrenMeshFilter(); if (filters.Length 1) return; var combine new CombineInstance[filters.Length]; for (int i 0; i filters.Length; i) { combine[i].mesh filters[i].sharedMesh; combine[i].transform root.transform.worldToLocalMatrix * filters[i].transform.localToWorldMatrix; filters[i].gameObject.SetActive(false); } var finalFilter root.AddComponentMeshFilter(); finalFilter.sharedMesh new Mesh(); finalFilter.sharedMesh.CombineMeshes(combine, true, true); var renderer root.AddComponentMeshRenderer(); // 這里需要手動(dòng)指定材質(zhì) }網(wǎng)格合并的代價(jià)是失去了子物體的獨(dú)立性如果模型里有需要單獨(dú)交互的零部件不能全班合并。所以我的方案是做成一個(gè)開關(guān)只在“純展示模式”下啟用。實(shí)操下來(lái)幾十個(gè)零件的CAD模型合并后DrawCall降到個(gè)位數(shù)性能提升非常明顯。說(shuō)了這么多最后分享一個(gè)我自己的使用習(xí)慣如果你要把TriLib封進(jìn)正式項(xiàng)目建議單獨(dú)搞一個(gè)拆分包ModelLoaderService放在獨(dú)立的程序集里里面不要混任何業(yè)務(wù)UI邏輯。這樣以后升級(jí)TriLib版本時(shí)只需要替換加載層不用動(dòng)業(yè)務(wù)代碼。我在實(shí)際項(xiàng)目里用這個(gè)結(jié)構(gòu)經(jīng)歷了TriLib小版本升級(jí)替換DLL后只改了幾個(gè)配置字段業(yè)務(wù)層完全沒受影響。這就是封裝帶來(lái)的安全感。本文還有配套的精品資源點(diǎn)擊獲取