以我的項目經歷來說，要保證通用性必須分清需求是框架需要還是項目需要。舉一個例子，所有的項目都需要一個彈窗提示的接口，但是不同項目彈窗都不一樣，當時做的時候我沒有想好怎么分離，那就放到項目類庫里，保證框架不受影響，以后再重構。

下面根據題主提的要點針對性說下方案（以NGUI框架為基礎，UGUI還在研究中）：

UI 和場景中物體的交互如何控制

目前遇到的場景中交互有幾種：

類似血條的顯示：通過攝像機轉換坐標的方法轉換為UI坐標來同步血條位置。

對點擊等操作的響應：屬于控制管理器，不應該放在UI框架中，但是UI框架需要提供UI尺寸和實際尺寸的比例便于規劃控制范圍。

3D物體的展示：可以直接放在界面中也可以使用renderTexture，前者更方便。

切換場景時對 UI 如何處理

雖然unity提供了Scene這個功能給我們使用，但是我個人的最終目標是將整個游戲運行在一個場景中，但這并不影響UI框架。一個場景一個單例的管理器（M2），還有一個跨場景的管理器（M1），M2負責具體的創建和關閉，M1負責對象池之類的功能。如果多場景，場景切換時M2實例和界面就都銷毀了，不需要特別處理；如果單場景，創建和銷毀都已經由M2實例負責了。

UI 如何分組/分類以方便管理

個人看來這一條本身提的比較模糊，因為可以理解為資源的管理也可以理解為結構的管理，下面分別回答。

資源管理：小的項目可以使用公用圖集（+Texture）的方式，大的項目UI資源太多，只靠公用圖集肯定會造成內存的嚴重占用，所以建議是公用圖集+功能圖集（+Texture）。功能圖集就是一個功能模塊的公用圖集，在功能操作完畢時就可以釋放掉了。這里涉及到的細節太多，就不展開了。

結構管理：我的思路是分為三類：1控件，就是button、label、sprite等等。（像buttonGroup就是button的組合，使用代碼創建和控制）2彈窗/界面/列表項，這三者都由控件組成。3共用布局，這一類是為了節省時間而分的，比方說卡牌游戲中反復出現的卡牌布局其實就是共用布局，每個界面重復制作顯然浪費，是否有這類關鍵在于UE結構是否明確和復雜布局的復用程度。

如何統一管理 UI 的深度

這條可以引申為Z坐標（如果UI中有3D物體或者UI本身就是3D的）、renderQueue、界面的調用順序等全局屬性的管理。這些內容都應該在界面制作的時候就記錄在界面信息上，在創建、聚/失焦、關閉界面時記錄在管理器中。

UI本身的深度其實很好管理，麻煩在UI上可能會有3D物體和特效，不同的shader可能會導致不同的問題。

打開、關閉時的動效，以及被遮擋時的動效

動效本身其實更應該當作項目需求而不是框架需求。首先建議有單獨的動效管理器，其次如果域名出售規劃中對動效規劃不明確，可以放在具體實現中。

如果項目中沒有靠譜的UE設計，框架做得越多其實越累。引用程序界的質能公式：error=(more code)^{2}

3DUI相比2D多了很多問題，要提前想清楚，比方說在界面上有3D物體的情況下（不用renderTexture）打開彈窗時，Z坐標和縮放的管理。

總結

以上是生活随笔為你收集整理的基于 Unity 中的 NGUI 插件，通用的 UI 如何设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。