原則(1): 不在場景里面除啟動節(jié)點意外的任何節(jié)點。

Unity 提供方便的場景編輯器，好像我們拖拉帶拽，直接往場景里面搭建游戲場景，然后來做場景切換，這個我們在開放項目的時候是不提倡的。這樣做有兩個缺點:

A: 不方便多人同時編輯場景后的代碼提交與合并, 如果有沖突更麻煩。

B: 不方便打空包,節(jié)點都在場景，打包時,節(jié)點依賴的資源都會被打包進(jìn)去。

C: 方便維護(hù)，維護(hù)復(fù)雜的場景，誰維護(hù)過誰知道。

原則(2): 不要在節(jié)點或預(yù)制體上直接掛與邏輯相關(guān)的代碼組件。

這個很好理解，如果我們直接在節(jié)點or預(yù)制體上掛代碼組件，代碼極難維護(hù)，如果我們要搜索哪些代碼在哪些地方調(diào)用，根本就無法通過搜索查到，如果一個一個節(jié)點，一個一個預(yù)制體的點開找，這樣維護(hù)起來非常麻煩, 也不方便資源更新與代碼熱更。

原則(3) 不要直接拖動節(jié)點,組件, 資源到代碼邏輯組件的屬性編輯器上。

比如直接給Button組件掛響應(yīng)函數(shù)等，原則2可以保證原則(3)不會出現(xiàn)，但是我還是要強調(diào)一下。理由是不方便維護(hù)代碼，和多人協(xié)作開發(fā)與提交。

原則(4) 運行的時候只有一個場景，所有的內(nèi)容代碼控制。

場景里面不允許放內(nèi)容，那么做場景切換也就沒有意義了，所以我們只有一個運行時的場景。所有的內(nèi)容，我們都要通過代碼來生成出來，這樣，搜索代碼，維護(hù)代碼就能看到整個完整的游戲邏輯。其他的場景可以用來編輯地圖，編輯角色等。編輯好后生成一個一個的資源預(yù)制體。所以我們項目里面一個運行時的空場景，以及其他資源編輯器關(guān)卡編輯的場景，而這些是編輯資源地圖而用，不會被打包進(jìn)去。

原則(5) 使用純AssetsBundle來管理整個資源的加載與卸載, 不使用Resouces機制。

為什么不使用Resources, 機制來加載與卸載資源呢？Resources機制不方便資源更新，不方便打空包, Resources下的所有資源以及相關(guān)依賴都會被打包進(jìn)去。 Resources也不方便資源更新, 所以干脆使用純AssetsBundle來做資源的加載與卸載，方便打空包，同時也方便資源更新。如果不打空包，只要把打包出來的ab包放到StreammingAssets目錄下，這個目錄下的所有的資源都會打包進(jìn)去，到時候到這里來讀取ab包就可以了。

原則(6) 第三方的資源與插件的目錄結(jié)構(gòu)要統(tǒng)一放到一個文件夾下。

我們完成一個Unity項目會經(jīng)常需要用到Unity插件，而Unity插件在開發(fā)的時候，從自己的角度出發(fā)，所以目錄結(jié)構(gòu)可能和我們的項目目錄結(jié)構(gòu)理念維護(hù)不一致，所以我們要整理第三方插件, 還有可能包含代碼。