使用unity引擎時有哪些禁忌

使用unity引擎時有哪些禁忌，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

程序方面：

禁忌1：錯誤的認為Unity有Terrain這個功能。

Unity沒有這個功能，你看到的那個組件是個玩具，要常常這么告訴自己。想做開放世界大地形？成，自己擼Procedural Virtual Texture，自己擼四叉樹LOD，流式加載，Terrain Decal……Unity是不會有的，反正我目前就是在自己做這些工作，因為這個組件真是完全不能用。。。團隊需要做這一方面，別多想馬上拉一支渲染團隊自己搞吧，畢竟自己的輪子才是靠譜的。

禁忌2: 使用Resources文件夾。

我的經驗告訴我，沒什么使用這個文件夾的必要，如果是美術資源或Shader，應該使用ScriptableObject進行全局管理，如果是二進制文件應該直接使用.Net提供的文件讀取，這個功能官方都不推薦使用，無論是從實現效率，還是項目管理上來講，直接用地址去讀取項目資源看起來都是一種非常低效的辦法。

禁忌3：寫代碼時搞混FixedUpdate與Update的關系。

其實這個設計本身是一個非常聰明的設計，將物理計算使用一個單獨的固定幀時間。假設默認FixedUpdate是20ms一幀，而每幀實際執行時間為10ms，那么FixedUpdate就會每兩幀執行一次，如果每幀實際執行時間為40ms，那么FixedUpdate則會每幀執行兩次，這樣物理引擎就不會出現時鐘問題。所以諸如輸入輸出一類的代碼寫在FixedUpdate中是錯誤的，因為有可能觸發的時候FixedUpdate完全沒有被執行，所以正確的做法是統一管理輸入輸出，將鍵盤鼠標的輸入以消息方法的形式發送出去，等到執行FixedUpdate時處理消息。這點許多老程序剛剛轉到Unity時很容易陰溝里翻皮水，要特別注意。

禁忌4：邏輯都懟主線程。

其實現在Unity的多線程已經放的比較開了，甚至連Transform都有了一個TransformAccess這么個東西，而且多線程計算邏輯在大多數時候都能帶來明顯的性能提升，畢竟現在四核都算少的，六核八核都快成主流了。不能在分線程訪問的一般是一些內置組件的屬性值，比如Light.intensity{get;set;}，而這種賦值類型的計算其實消耗很小，完全可以把最耗時的計算邏輯放在Job System中計算，大大降低主線程的負擔。

禁忌5：粗放式的內存管理。

一般游戲開發中是絕對不允許GC帶來的高昂消耗的，動輒幾十毫秒的GC時間就是頂配I9處理器也得乖乖的跪下，而高昂的GC消耗實際上99%來自開發者工作的疏忽。譬如unmanaged數據類型可以使用引擎自帶的Memory Allocator進行分配，每次new的時候都要想清楚自己這個new是否可以復用，是否會像黃河的河床一樣越埋越高，隱患越來越大，最終造成“決堤”，帶來不可挽回的毀滅性的損失。如果是UI帶來的GC壓力，可以考慮魔改UI層源碼，通過提交一個字符串的引用而不是強硬的深復制，一般正確的做法是直接調用UnityEngine.Scripting.GarbageCollector關掉自動GC，并在需要的時候手動調用GC，如果在游戲運行過程中內存直接炸掉，這就要準備分鍋了，看誰寫的代碼在不斷的制造內存垃圾，引發內存泄露。

禁忌6：Shader中使用大量的multi_compile分支。

multi_compile是一個比較尷尬的設計，是會導致包體體積巨量增大的一個隱患，如果需要做分支功能，建議使用多個Pass等操作，盡可能減少multi_compile的數量。

禁忌7：項目過度封裝。

過度封裝是一些開發經驗不足的團隊常出現的問題。過度封裝很多時候是開發團隊成員之間互相不信任，通過多層保護和限制使項目能work，然而這樣會使得項目開發效率和運行效率嚴重低下。如果老板為了省成本招了一堆工資低水平低的搬磚工，然后指望依賴少數的高手做框架把項目封裝死讓搬磚工們老實搬磚不出幺蛾子，那么這個項目的下場已經可想而知了，反正高手們到哪都能混的風生水起，如果實在改變不了老板的主意就另作打算吧。。

美術(TA)方面：

禁忌1: 導入模型時有多套UV。

自己在DCC軟件中分UV2當然是一種可行的方案，如果自己分光照UV，那么最好直接在軟件中制作好光照貼圖，并在引擎中將光照貼圖打包成一個一整塊，比如TexArray，供場景使用。如果不是為了提前烘焙光照則盡量不要在DCC中分UV2。

禁忌2：使用大量SubMesh/SubMaterial。

Drawcall中比較昂貴的部分就在重新綁定材質資源屬性上，也就是SetPass Call，同一個物體上有多個材質將會迫使引擎在每次進行多次SetPass Call。如果只有一個材質，那么引擎可能將周圍一片使用相同材質統一進行SetPass，繪制效率可以大幅度提高。因此在確保使用了統一的基于物理的著色模型后，可以大幅度降低材質種類和Shader種類，盡可能消滅SubMesh。

禁忌3： 慎用GPU Skinning。

Unity提供的GPU Skinning比較弱，有時候不僅沒有優化反而負優化，這是歷史遺留問題。如果希望使用GPU Skinning建議使用剛才上方提到的TransformAccess在Job中導出骨骼矩陣數據，并傳遞到Compute Buffer在Compute Shader中計算，我在文章中講過這方面的內容：

MaxwellGeng：GPGPU Computing Animation & Skinning      zhuanlan.zhihu.com

https://zhuanlan.zhihu.com/p/50640269

禁忌4： 模型LOD處理不恰當。

Unity內置的LOD Group組件并不實用，畢竟是一個很古老的組件了。實際開發過程中應該根據需求采用不同的LOD方法，如開放地形的建筑群可以使用HLOD，人物可以使用動態曲面細分，平坦地形和海面可以使用四叉樹等……按需分配才是正解。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。