使用unity引擎時(shí)有哪些禁忌

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

程序方面：

禁忌1：錯(cuò)誤的認(rèn)為Unity有Terrain這個(gè)功能。

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

禁忌2: 使用Resources文件夾。

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

禁忌3：寫代碼時(shí)搞混FixedUpdate與Update的關(guān)系。

其實(shí)這個(gè)設(shè)計(jì)本身是一個(gè)非常聰明的設(shè)計(jì)，將物理計(jì)算使用一個(gè)單獨(dú)的固定幀時(shí)間。假設(shè)默認(rèn)FixedUpdate是20ms一幀，而每幀實(shí)際執(zhí)行時(shí)間為10ms，那么FixedUpdate就會(huì)每?jī)蓭瑘?zhí)行一次，如果每幀實(shí)際執(zhí)行時(shí)間為40ms，那么FixedUpdate則會(huì)每幀執(zhí)行兩次，這樣物理引擎就不會(huì)出現(xiàn)時(shí)鐘問題。所以諸如輸入輸出一類的代碼寫在FixedUpdate中是錯(cuò)誤的，因?yàn)橛锌赡苡|發(fā)的時(shí)候FixedUpdate完全沒有被執(zhí)行，所以正確的做法是統(tǒng)一管理輸入輸出，將鍵盤鼠標(biāo)的輸入以消息方法的形式發(fā)送出去，等到執(zhí)行FixedUpdate時(shí)處理消息。這點(diǎn)許多老程序剛剛轉(zhuǎn)到Unity時(shí)很容易陰溝里翻皮水，要特別注意。

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

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

禁忌5：粗放式的內(nèi)存管理。

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

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

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

禁忌7：項(xiàng)目過度封裝。

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

美術(shù)(TA)方面：

禁忌1: 導(dǎo)入模型時(shí)有多套UV。

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

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

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

禁忌3： 慎用GPU Skinning。

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

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

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

禁忌4： 模型LOD處理不恰當(dāng)。

Unity內(nèi)置的LOD Group組件并不實(shí)用，畢竟是一個(gè)很古老的組件了。實(shí)際開發(fā)過程中應(yīng)該根據(jù)需求采用不同的LOD方法，如開放地形的建筑群可以使用HLOD，人物可以使用動(dòng)態(tài)曲面細(xì)分，平坦地形和海面可以使用四叉樹等……按需分配才是正解。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。