在 2025 年 5 月 24 日的 Unity User Group 北京站活動中，完美世界《誅仙手游》客戶端負責人劉彥麟帶來分享《重度游戲在小游戲平臺下的探索與實踐》。本文為演講全文實錄，點擊閱讀原文，可下載演講 PPT 資料。演講視頻可通過下方鏈接地址觀看。

https://www.bilibili.com/video/BV1rzj9zVEGd/?spm_id_from=333.788.videopod.sections&vd_source=6ad5666ecbc7fe0e80d963da7e237d92

我來自完美世界《誅仙手游》項目組。本次分享的內容聚焦于完美世界小游戲開發的經驗，特別是小游戲下 WASM 和堆內存的優化方案，以及團結引擎對于小游戲的技術支持。

我們的小游戲移植工作啟動于 2023 年中旬。然而，早在幾年前，嘗試小游戲的想法就已經萌生，并且進行過技術嘗試。這其中包括對 Unity 和其他 H5 引擎的探索，但由于未能達到預期的綜合目標，這些嘗試最終未能繼續推進。

隨著 2022 年和 2023 年小游戲市場快速發展，以及大量“爆款”涌現，其中不乏 MMO（大型多人在線）、SLG 等中重度游戲也表現出色。無論從產品、運營，還是從技術角度來看，都促使我們決定再次嘗試小游戲平臺。

經過約半年的調研和分析，發現無論是市場前景還是技術承載能力來看，都存在機會。因此，我們在 2023 年 6 月正式啟動小游戲的項目。經過約半年時間的移植工作和產品調優，項目從 2024 年的 1 月開始對外進行多輪 CCB 測試，今年 1 月，在微信小游戲平臺開啟正式 OB。目前，開發團隊也正在進行抖音平臺的性能調優，后續還會發行到更多小游戲平臺。

MMO 類游戲因其固有的特性，即使在硬件資源豐富的端游或手游平臺上，如果技術方案欠妥，亦可能產生相當大的性能問題。這因為此類游戲需要更大內存，更大的計算承壓（包括 CPU 與 GPU），且部分功能需要多線程支持，而這些問題在小游戲平臺上將進一步放大。這其中，內存和 CPU 是相對關鍵的要素，亦是攻克小游戲平臺性能瓶頸的關鍵點。

在小游戲平臺上，iOS 設備的內存普遍限制在 1.4G。然而，在手游平臺上，1.4G 僅是部分低端機型的內存閾值，且此類機型在 APP 平臺上的占比極小。此外，小游戲平臺的 CPU 性能大約僅為手游的 1/3，并且不支持多線程，這使得小游戲平臺對密集性運算更為敏感。然而，重度游戲恰恰需要大量計算，以及運行時的內存支持。同時，Unity 中的許多功能也依賴多線程支持，例如動畫、蒙皮、粒子系統和物理系統。一些功能甚至會借助 Job System 來加速計算。然而，在小游戲平臺上，這些功能都會轉為主線程上的線性計算，不僅無法利用多線程優勢，還會搶占主線程資源，進一步加重運算壓力。

小游戲內存主要分為幾個方面，其中影響最大是 UnityHeap、WASM 以及 GPU 顯存，這三者是移植后造成小游戲平臺內存暴增的主要因素，只要妥善處理這三方面，整體內存使用基本就能達標。

WebAssembly性能優化與內存挑戰

WebAssembly 并非旨在替代 JavaScript（JS），而是通過擴展 Web 的能力提升其性能上限，從而更好地支持 3D 游戲、vr/ar 圖像/視頻編輯等類似的需要高性能計算要求的任務，其主要作用在于彌補 JS 在算力方面的不足。JS 作為解釋性語言，運行效率相對較低；而 WASM 則是編譯型的字節碼，性能更接近原生。

在一篇關于 WASM 與 JS 能耗對比的論文中，對比了在安卓平臺下，不同的手機瀏覽器中 WASM 與 JS 的能耗表現，可以清楚地看到，JS 的能耗遠遠大于 WASM，最大能耗差異接近三倍。這意味著將 WebAssembly 用于 Web 應用能顯著降低對移動設備的能耗，最直接的影響就是降低發熱。

盡管 WASM 的性能接近原生，但兩者之間仍存在一定差距。下面這篇論文對多種 WASM 獨立運行時的程序進行了表征性研究，并從內存、機器指令、緩存命中等方面與原生程序進行了性能對比。最終的結論就是在獨立運行時下，wasm 就會比原生程序降低 1.5～9.5 倍的性能。以上兩篇論文發表于 2022 年，具有很高的參考價值。

WASM 調用 WebGL API 時，同樣也需要遵守瀏覽器的安全模型和策略。 WebGL 中每次調用 API 都會伴隨著一定開銷，這主要是由于安全驗證所引入的。 在重度游戲中，WebGL API 調用極為頻繁，這意味著在 Web 平臺下，狀態切換的代價會更高。 因此，有必要盡可能減少 SetPass 調用以及與 WebAPI 的交互。

WASM 雖然解決了 JavaScript 在高性能計算的問題，但也帶來了內存挑戰。 在小游戲中，編譯后的 C++ 代碼會再次通過 emscripten 編譯成 WASM。 在運行時，WASM 代碼會被再次編譯并實例化，而編譯+實例化的過程將會產生近 10 倍 wasm 文件大小的內存占用。

例如，在誅仙第一個 Chrome 版本中，WASM 文件大小為 90M，這意味著在運行時產生了 900M 的內存。 鑒于 iOS 小游戲內存限制為 1.4GB，WASM 占據了 900MB，僅剩 500MB 可用空間，這對于 MMO 游戲而言是遠遠不夠的。 這部分內存的實際最終大小與平臺、內核版本也有關系。 我們在不同的手機及不同瀏覽器上進行過詳細測試，結果顯示，盡管內存大小存在一定浮動，但最終結論都接近于 10 倍。 因此，對 WASM 進行縮減是必要的。

WASM 是代碼編譯的結果，因此，縮減 WASM 的本質就是縮減代碼的使用。 Unity 項目的代碼主要由引擎代碼、package、第三方庫，以及游戲邏輯代碼組成。 可以通過 Player settings 對引擎代碼和托管代碼進行剔除，但這種剔除并不徹底，部分代碼可能被引擎誤判為已使用，或因錯誤操作產生引用，此時便需要進行手動剝離。 其中，最常見的就是 package 和第三方庫，特別是對于僅在 editor 下使用的代碼庫，要正確設置其程序集平臺，保證其只在 editor 環境下使用。

除此之外，還有一些需要注意的方面。例如命名空間，小游戲中無法使用多線程，盡管使用多線程的代碼編譯無誤且運行結果正確，但最終還會以單線程方式執行，這會導致性能差異。因此，需要剔除線程類的命名空間。

對于 Job、Task 等與線程相關的，由于無法發揮其多線程優勢，也應該直接代碼中剔除，并相應的將功能改為單線程實現，同時基于單線程優化代碼算法。

另外，關于共享庫的使用，例如 json，在微信和抖音小游戲 SDK 當中都包含一份 json，而一些第三方庫或 package 也可能包含或引用一份 json。對于此類問題，需要進行手動修改，確保項目存在一份 json。

關于代碼設計模式，優秀的設計模式固然能提高項目的可擴展性和可維護性，但是過度設計則會影響開發效率，尤其在小游戲環境中，過度的設計模式會使 WASM 變得更加臃腫。

WASM 作為相對低級的編譯目標，不支持泛型或模板等高級語言特性，生成的 wasm 代碼是針對具體類型的具體實現。雖然在編譯時，可以設置編譯參數，進行編譯優化，但對于過度復雜的設計模式，編譯優化也無能為力。

舉例來說，將屬性寫為訪問器形式，編譯后會額外產生 2 個函數。 此外，foreach 循環還會額外產生包含 try-catch 的語句，這些都會增大 WASM 的體積。

除編譯問題，代碼方面還有許多值得注意的地方。比如，對于 string，運行中產生的并且頻繁使用的 string，最好使用 intern 把它強制放到常量池。能使用常量就使用常量，比如 vector.one，沒必要再 new vector(0,0,0)。類似的問題還有很多。因此，需開發人員更加了解 IL2CPP，和 WASM 的機制，以便編寫出更高質量的代碼。

再說回到編譯的問題，編譯時可以導出一張符號表，如右上這張圖 symbols.json 就是導出的明文符號表，左下就是該符號表的內容。利用這張符號表就可以對其文件進行解析，從而統計代碼中每個類的占比。圖右下，顯示了對符號表處理的結果，例如 uilabel 約占整個 WASM 的 0.1%。開發團隊會根據解析結果，從占比最高的類入手，逐步進行分析和優化，進而實現代碼的剝離。圖右下的是我們最開始生成的 wasm 分析文本。

目前，此功能在團結下已經得到了非常大的改進，能夠可視化查看和對比兩版本的差別，極大地提高了研發效率。

經過上述處理，WASM 文件已從最初的 90MB 精簡至目前的 51MB，相當于節省了 400MB 的內存空間。

從圖右側可以看出，前述的每一步 WASM 精簡方法，都對 WASM 內存產生了顯著的影響，然而，目前仍有 500 兆的 WASM 編譯內存，這仍然是一個相當大的數值。

即使通過代碼剔除，在游戲的實際運行中，仍會存在一部分使用不到的函數。 事實上，每個小游戲平臺目前都提供了代碼分包的能力，可以將運行時使用的函數收集到主包，未收集到的函數劃分到子包。 主包中所包含的函數，才是整個游戲生命周期所使用的函數。 通常情況下，大部分游戲的主包代碼占比不會超過 50%，這意味著在最差的情況下，可以通過代碼分包將 WASM 的編譯內存再次減半。

首次進行代碼分包是一個相對耗時的過程，需要進行充分的函數收集，以避免因收集不全導致函數被劃分到子包。頻繁地遠程拉取子包函數，會使游戲運行變得異常卡頓。以上便是我們針對 WASM 文件的所有優化方法。

小游戲中的Unity堆內存

小游戲中的堆內存結構與 APP 基本一致，兩者均通過貝母 GC 進行管理，但在細節上存在差異。

在 web 平臺，UnityHeap 被實現為一個連續的線性內存空間數組，這部分內存是通過瀏覽器分配的，并且在生命周期內不會返還給瀏覽器。

在初始化階段，需要為 UnityHeap 設定并設置一個大小，即預留內存。 當內存不足的時候，系統會通過 CopyArray 的方式進行擴容，此過程會產生一個內存峰值，極有可能導致內存崩潰。 例如，若預留內存設置為 600 兆，由于內存對齊，實際可能匹配到 608 兆，當內存不足進行擴容時，該幀的內存峰值可能達到 1.4GB，此時極易發生崩潰。 多數中重度游戲崩潰的原因，都是未能設置合理的預留內存，從而在內存擴容時發生崩潰。

通常對于重度游戲，推薦的預留內存值為 768 兆。 然而，并非必須嚴格遵循此值，只要確保內存峰值不超過預留內存即可，即使略大于 768MB 也無妨。 同理，如若游戲內存峰值肯定達不到 768 兆，也可設置得更小，將內存讓給其他空間，比如 js。 因此，設置預留內存的目的是在合理的范圍內使用內存，避免觸發內存擴容和內存浪費。

托管內存方面，與 APP 不同，托管堆（Managed Heap）來自于 Unity 堆，釋放后也只會返回給 Unity 堆，而不會返回給系統。 尤其在 Web 平臺下，托管堆具有只增不降的特性，這是一個顯著的差異。

托管堆不只一塊，會根據實際的內存使用，在 Unity 堆中開辟多塊，那么就會產生托管堆的碎片。 盡管 Unity 沒有提供相關的設置或者相關的編譯參數，來提前預留托管內存，微小抖小平臺也沒有提供相關的接口進行設置，但可以利用托管堆只增不降的機制，提前開辟一大塊托管堆內存進行復用，以減小內存碎片，提高內存的整體使用率。 通過對比圖示可以看出，上圖未進行托管內存預留時，內存分布較為分散； 而下圖進行預留后，內存碎片明顯減少，整體內存消耗也隨之降低。

在內存管理方面，GC（垃圾回收）在移動平臺和 Web 平臺也存在顯著差異。 移動平臺上，GC 在觸發后會立即執行，而在 Web 平臺，GC 僅在兩個特定時機觸發： 每幀結束時會執行少量 GC，以及切換場景時會執行一次完整的 GC。 因此，在 Web 平臺的單場景尤其是單幀內，對內存的使用要注意以下幾個方面：

一是設置合理的預留內存： 避免因為預留內存不足而造成 Copyarray。

二是避免內存碎片：特別針對托管內存，可以提前申請合理的使用空間并善用對象池來有效預防。

三是避免幀內內存峰值：在移植過程中，曾出現過單幀內加載多張配置文件導致托管內存暴增的情況。對于 native 內存的暴增，最常見的原因是對 AssetBundle 的加載。避免單幀內存峰值的最佳方法是拆分數據，分幀加載。

尤其值得注意的是，強烈推薦使用小游戲平臺提供的 AssetBundle 接口，例如微信的 WXAssetBundle 和抖音的 TTAssetBundle。盡管早期項目曾嘗試不依賴小游戲平臺接口，但效果不佳。實踐證明，WXAssetBundle 或 TTAssetBundle 能真正利用文件系統，從而顯著減少內存占用。

四是，避免不當使用像代理、匿名 lambda、閉包等，這些不規范的使用方式會頻繁產生堆內存，進而造成內存碎片，降低堆的利用率。

基于Unity的優化策略

許多常用的 Unity 優化方法在小游戲和手游上同樣適用，對于優化來說，可以把小游戲視為對性能要求更為嚴苛的手游，以下是一些手游和小游戲開發中被驗證實用的優化方法。

首先，針對 Unity 資源件，可根據項目的實際需求進行進一步精簡。 比如 anim，Unity 下，anim 可以針對不同文件，設置不同的誤差，采用不同的壓縮率。 但在相同的骨骼點下，它們所需的精度有所差異； 這意味著相同的誤差對于不同的骨骼點會產生不同的影響。

對于站立動作，其通常是新玩家進入游戲創角場景后看到的第一個動作。 較大的壓縮誤差會使腳步與地面產生較大的位移。 通過對比 error 1.0 和 0.5 的設置，可以觀察到模型腳步與地面之間存在顯著差異。 盡管有些項目為了給新玩家提供更好的體驗，會在創角場景采用獨立的資源以保證更優質的效果，但這會額外增加包體大小，并可能導致頻繁的下載。

在《誅仙》項目中，我們采用了程序化方法對動畫文件進行組合性壓縮，針對不同動作、不同肢體部位采用不同的壓縮誤差，以此實現效果與性能的平衡。可以看到經過組合壓縮的站立動作，腿部與地面的相對位移幾乎很小。

具體來說，對于于站立動作，在腿部會采用更低的誤差以減少滑步現象，而其他部位則會采用高誤差低精度的方式進行處理，從而平衡整個動作文件的大小并保障局部動作效果。 經過這種處理，動作文件在腿部組合壓縮后會擁有更多的采樣點，確保了腿部的精度。

同時，在不影響手臂效果的前提下，組合壓縮會盡可能減少手臂的采樣點，從而平衡了整體文件的內存占用。

通過下圖可以看出，組合壓縮會更加擬合原始動作文件，而 Error 1.0 和 Error 0.5 的文件則與原始動作文件存在明顯的曲線偏差。

這種組合壓縮方法不僅能達到預期的效果，而且壓縮后的文件大小也非常理想，甚至在某些情況下會比 Error 1.0 的文件更小。

除了 AssetBundle，全局光照（GI）數據也是重度游戲，尤其是 MMO 類游戲消耗內存的重要部分。在大場景中，目前通常通過光照貼圖（Lightmap）和光照探針（Light Probe）的方式實現效果。光照探針作為一種實現 GI 的方式，相比 Lightmap，它更容易規避單幀內申請過多內存，也更便于實現離散的分幀加載，并且在制作 TOD 時更為便捷，顯著增加了靈活性。

然而，光照探針的靈活性也伴隨著內存的問題。 一個 Lightmap 中的采樣點可視為一個 RGB 值（即 3 個 float），而 Unity 中的光照探針使用的是三階球諧函數（3rd order Spherical Harmonics），這需要 9 個系數，共計 27 個 float。 對于 GI 而言，采樣點越多，效果自然越好。 但是，過多的光照探針相比 Lightmap 內存勢必也會翻倍。

鑒于球諧函數用作 GI 通常是低頻信號，其在空間中的變化是平滑且連續的，因此相鄰球諧函數的系數也極為相似。基于這一特性，可以對場景中的探針進行基于特征空間的降維壓縮，從而有效優化內存占用。

在二維空間中，可以通過找到一個特征軸來表達平面內點的特征。同理，在三維空間中，也可以通過多個特征軸來表達三維空間的特征。因此，可以提取所有球諧函數的特征數據，并將其映射到特征空間，再根據前 n 個特征來重構原始數據，從而實現高保真度的壓縮與還原。

從上圖右側可以看出，在不同特征數量下所表達的平面結果：特征數越多，越接近原始效果。在三維空間中，對于光照探針、環境光遮蔽（AO）等具有方向性的數據，均可通過這種方法進行降維壓縮。

上圖左側的圖像展示了三階球諧函數的原始效果。中間的四幅圖是經過降維并還原后的結果，其中特征是疊加的。當特征數量為一時，它表達的是最主要的特征。隨著特征數的增加，細節也隨之增多。在中間的四張圖中也可以觀察到，隨著特征數量的增加，綠色部分變得更加明顯。當特征數達到 13 時，整體效果與原始球諧采樣幾乎一致。

當然，也可以直接使用二階球諧函數，但它會產生明顯的差異。從上圖左側的兩張圖可以看出，盡管二階球諧函數的色調與三階一致，但在明度上存在較大差異，并且這種差異會隨著建筑結構、光源等空間復雜度的增加而愈發明顯。但是當特征 =13 的時候， 與三階球諧相比，無論從色調還是明度，幾乎感受不出差距。

利用特征空間進行降維的目的不僅是為了實現高還原度，更在于其在內存方面具備顯著優勢。

通過左上的兩個公式可以更直觀地看出，在大量探針的應用場景下，基于特征空間的降維顯著降低了球諧階數對內存的影響。具體而言，三階球諧函數每增加一個探針將穩定增加 108 字節。而基于特征空間的壓縮方法，每次增加的字節數是特征數乘以 4。當特征數等于 13 時，每個探針僅增加 52 字節。并且此時幾乎可以還原原始探針的全部效果。

鑒于球諧函數主要用于表達 GI 的低頻信號，在實際應用中可以適度縮小特征數。這樣做既能有效減少內存占用，又能確保 GI 效果的質量。

以上闡述了針對數據壓縮的方法。如前所述，小游戲對 Draw Call 和 SetPass 更為敏感。在保證效果的前提下，LOD 是降低 Draw Call 和面數的最佳方法。

LOD 的優勢在于可以通過全局劃分顯著減少 Draw Call 和面數。但值得注意的是，單場景、單幀內對內存的申請也會隨之增大。

我們重寫了 LODGroup 組件，在切換不同物體的同時，能夠使其以流式的方法逐步加載卸載對應的資源，這意味著僅加載當前可見的資源，而非一次性加載所有資源。這種做法能夠平衡 LOD 帶來的內存增加，有效管理和利用模型資源，從而達到平衡內存、Draw Call 和面數的目的。

值得注意的是，由于 web 環境下不支持多線程，所以 Unity 自帶的的流式紋理也是無法正常工作。所有資源的流式加載都需要手動重新實現。

除了實體，我們也對粒子做 LOD。 如上圖，隨著 LOD 等級變化，部分粒子發射器會被直接剔除，而另一些粒子并不會被剔除，但其粒子的產生速率與生命周期會明顯的縮短。 這種優化方式在團戰等特效密集的的場景中效果明顯，能在保證整體視覺效果的同時，進一步降低粒子消耗，優化場景性能。

對于草地特效這類同質物體群落，使用 LODGroup 無法達到理想效果。LODGroup 主要表達的是單個物體隨距離遠近的變化，而植被群落則表達為一個面。因此，我們通過 CullingGroup 的方式，基于距離實現不同密度的實例化繪制。使用 CullingGroup 的主要目的是彌補實例化合批無法被剔除的問題。后面我也會介紹一種在團結引擎下能夠進行剔除的實例化合批的方法。

對于大型場景，還可以根據地塊和距離調整特征數，讓不同的地塊使用不同的特征數，可以進一步降低探針內存。比如近處使用 13 特征的 GI，盡可能還原效果，而中距離、遠距離逐步降低特征數，減少內存消耗。

團結引擎支持下的優化與實踐

團結引擎對小游戲的支持是開發團隊當前正在利用的重要引擎功能之一。借助團結引擎，我們能夠進一步降低內存消耗。在將項目從 Unity 切換至團結引擎后，開發團隊在所有配置（包括 projectsetting，playersetting 等引擎層面的參數設置）均保持相同的前提下進行了內存對比。結果顯示，直接使用團結引擎能夠為項目額外節省約 60 兆的內存，這一優化效果非常可觀。

在團結引擎中，托管代碼精簡新增了“extreme”模式。相較于“high”模式，“extreme”模式在代碼剔除方面更為激進。對于 MonoBehaviour 和 ScriptableObject，該模式僅保留項目中實際使用的類及函數。在我們的項目中啟用此選項，能夠將最終的 WASM 文件大小進一步縮小約 10 兆字節，這相應地意味著可以節省約 100 兆字節的內存。

Unity 中 Skinned Mesh Renderer 是一個性能消耗較高的組件，但在 MMO 類游戲中又必不可少。小游戲平臺 CPU 性能大約只有 APP 的三分之一，因此需要盡可能減輕 CPU 的壓力。為應對此挑戰，我們將場景中可進行合批的角色通過“Instancing + VAT”的方式進行繪制，取得了較為理想的效果。

在驍龍 660 設備上，開發團隊分別使用 GPU 和 CPU 兩種方法為 140 個角色進行隨機動畫播放測試。結果顯示，完全依賴 CPU 播放的幀率僅能達到 21 幀，而采用 GPU 播放動畫則能穩定保持在 30 幀。

在 2023 年中旬開始小游戲移植時，缺少團結引擎和 gpu skinning，因此 VAT（vertex animation texture）是一個相對性價比很高的解決方案。 目前，團結引擎已經能夠通過 GPU skinning 在 GPU 端實現蒙皮計算，同樣可以減輕 CPU 壓力，并達到理想的性能標準。 因此，我們已經用 GPU skinning 替代了原有的 VAT 方案，也節省了額外的工作量。

從上圖中可以看出，在 108 個角色同屏的情況下，通過 GPU skinning 能夠穩定達到 30 幀。而在相同場景下，使用 CPU skinning 的幀率只能維持在 10 幀以下。

WASM 調用 WebGL API 需遵循瀏覽器的安全模型和策略，每次調用 API 都會產生一定的開銷。這部分對開發者來說是黑盒的，我們唯一的辦法就是降低 dc 和 setpass，也就是降低游戲的復雜度。

在團結引擎下，可以對 Shader 進行優化，包括直接通過引擎層面減少對 WebGL API 的調用。這種方法對于某些低系統設備效果非常顯著。我們在 iOS 16.4 系統上進行了不限幀測試，包括野外團戰和副本。開啟上圖所示選項后，幀率能夠提升大約 8 到 10 幀。

在合批方面，SRP Batcher 能夠通過排序，將使用相同 Shader 的物體放到一起去繪制，從而使每個批次僅調用一次 ApplyShaderPass，減少了重復設置 Shader 的時間消耗。

目前，項目主要采用的合批方式仍是 SRP Batcher。運行時相比 StaticBatch 會有一定的消耗，因為引擎每幀會根據可見的 renderers 生成 render nodes。然而經過大量測試發現，在我們項目中，SRP Batcher 和 static batch 對于幀率的影響是相近的。鑒于靜態合批會額外增加內存或包體大小，因此我們仍將 SRP Batcher 作為主要的合批方式。

后續團結引擎將推出一種更高效的合批方式，即 GPU Resident Drawer。目前團隊正配合團結的同學進行性能測試。理論上 GPU Resident Drawer 的執行效率將高于 SRP Batcher，主要通過 BRG（Batch Renderer Group）進一步提高渲染效率，并且根據小游戲的特性，在單線程上做了特定的優化。只要場景中的物體是靜態的，它的 buffer 就不需要更新，會長期駐留在 GPU 上。因此，與 SRP Batcher 相比，GPU Resident Drawer 在運行時也能減少一定的計算消耗。

GPU Resident Drawer 的主要目的是對于復雜場景的優化，尤其適用于場景中存在大量可以實例化合批的分散物體的情況。如果直接使用實例化進行合批，由于缺乏剔除，反而可能導致負優化。同樣，若在 CPU 端自己實現剔除后再調用 Graphic DrawInstance 進行繪制，也會加重 CPU 端的計算壓力，同樣可能造成負優化。

而 GPU Resident Drawer 的一個重要特性就是解決了剔除問題。上方的表格是主城的測試結果，在 Drawcall、Setpass 以及功耗方面都有了非常明顯的降低。

以上就是我今天的分享 謝謝大家。

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

每一個“點贊”、“在看”，都是我們前進的動力