Unity3D開發技巧：如何避開unity編輯器的那些坑

文/瀚陽

以下總結一部分來自經驗之談，一部分來自其他人的分享。總的來講，Unity開發原型和效果、驗證想法，確實是無比便利。可能一個月就把核心玩法 做得差不多。強大的編輯器功能讓我們也有很大的可擴展空間來協助我們開發工具。可是編輯器是把雙刃劍。如果提前看清楚有什么坑在前面，或者其他人踩過什么 坑。我想這會對項目風險的把控會有很大幫助。

避開unity的坑

1.制作抽象的prefab來做關卡編輯

盡可能制作抽象的prefab來做關卡編輯，該prefab應該足夠抽象簡單（只有一個GameObject，然后通過Gizmo來繪制是個不錯 的手段），否則以后變化的時候（常見的就是改美術資源），所有關卡都lost prefab，那么對策劃來說是一場災難。可以考慮通過數據表+編輯器的方式來提供策劃操作同時也不再需要擔心lost prefab的問題。prefab越簡單抽象越不容易丟失，prefab之間嵌套的正確方式是通過鏈接而不是掛在節點下面。

2.盡可能避免修改Scene，方法有幾種：

• 使用xml之類的數據組織場景

• 盡量多讓scene由prefab組成，這樣變動都在prefab上

• 使用工具做場景Merge

3.不要過度依賴Component特性來開發，考慮數據驅動。

4.邏輯容易散落在編輯器各處，可以做一個中心管理。

利用Unity的特性

• 組織好hierarchy，不管是編輯的時候還是運行的時候，編輯的時候可以通過工具來簡化組織層級的工作。

• 讓每個場景自己能跑。

• 利用基于組件的架構，盡可能少的使用繼承（用C#的話），多通過組合來完成開發。遇 到需要數據訪問的通用接口，我們可以通過組合的方式來完成，而不是提供一個公共基類接口來繼承，只要大家都認識這個公共組件就可以取到數據了。遇到通用的 事件派發，我們可以用字符串拼接的方式派發到指定的對象或者更參數組合派發事件到對象身上。

• 框架采用星型架構+事件機制，由于Unity3D沒有一個所謂的入口函數，不利于代碼跟蹤，這樣的基礎架構能帶來很多便利。

• unity界面擴展能力很強，而且借助CLR(commom language runtime)的反射能力，C#里面開發界面非常容易。

• 做好tag、layer規劃，要考慮業務中哪類物體之間需要交互。

• 在代碼里面get某個prefab或者GameObject，可以考慮利用界面拖目標過來，這樣更加直觀，而且也能對抗變化，比如目標名字變了也不怕，而且還能節省代碼量。

代碼

這里針對C#，靜態強類型面向對象本身就是一個坑，繼承帶著兩個職責，一個是復用代碼，一個是接口繼承。雖然性能比lua高那么一丟丟，因為性能 瓶頸不在業務本身，設計上的問題要嚴重得多。我認為像lua這種動態語言的元編程才能夠貫徹單點真理，通過元編程把真理推導到系統的每一處。讓代碼始終保 持語義，而我認為寫業務代碼最重要的是保持語義。保持語義的簡單有效評判方法就是看這個類中的某個函數，單獨看它能否看懂；多個接口能否組成完備的解決方 案。靜態強類型面向對象語言比較適合需求穩定的嚴謹的系統開發，而不是游戲開發。容易經過多次的策劃需求沖刷，語義很容易扭曲，各種抽象泄露、各種 hack。好吧，跑題了。

• Unity3D容易被破解，因為發布版本的IL是非常容易被反編譯的，要做好混淆的考慮。在Unity3D中混淆要考慮對編輯器的影響。

• 復雜類型盡量使用引用類型，值類型反射麻煩，不方便序列化以及做成編輯器。值類型要小心賦值對象是否只是臨時對象。

• 引用類型釋放之后，引用它的指針會置為null，可以放心使用。

• foreach、linq、協程慎用，反射只在編輯器中使用。

• 考慮封裝Time，方便做暫停。

• 考慮使用調度器來完成功能，而不是在Update自己維護狀態，這樣做暫停也很容易，代碼更清晰，功能更內聚。

• 增量更新要一開始就想清楚。

美術

• Unity3D可以通過擴展編輯器讓非技術人員編輯界面來工作，組織好美術資源規格、路徑，并且自動生成prefab。游戲場景物件也要規劃好邏輯節點，這個也應該通過編輯器擴展好。復雜功能也應該通過編輯器開發給策劃微調，特別是可視化比較重要的模塊，比如動作調整。

• 制作原型美術，讓開發提升開發效率。

• 有統一的約定，比如模型總是中心對齊，角色總是腳部對齊，統一的縮放、統一的動畫骨骼命名，資源有統一的路徑。

• 支持換裝(avatar)要一開始就想清楚。

• 資源加載和優化盡可能早地給出雛形(只是雛形，幫助你對需求的把握，因為這時候你還不知道熱點在哪)，因為一旦沒有規劃好異步和資源釋放，那么阻塞卡頓和內存飆升那是意料之內的。因為有雛形，那么代碼會間接一點，也為改變提供了空間。