1、使用依賴注入管理組織容器

解耦的最好形式之一就是IOC容器，市面上很多現(xiàn)成的東西都可以用，實(shí)在不行也可以使用一個(gè)簡易的方式實(shí)現(xiàn)管理。

針對問題：老版本中充斥著大量持久化單例，用單例可以，但要注意其生命周期。（內(nèi)存問題）

相關(guān)文檔學(xué)習(xí)鏈接：

https://www.cnblogs.com/artech/p/asp-net-core-di-ioc.html

2、盡可能少使用魔法數(shù)（常量），要用配置化制作

老版本中很多配置化的東西，也使用直接寫在代碼中的形式（甚至不以變量的方式管理）制作，導(dǎo)致修改時(shí)需要對一系列相同變量，跨文件、跨區(qū)域進(jìn)行修改，重復(fù)性高，影響系統(tǒng)穩(wěn)定度。

此外采用配置化，與產(chǎn)品部分需求對接也有便利。

3、項(xiàng)目組織管理

對外：

• 與外界合作溝通上要有明確標(biāo)準(zhǔn)。

對內(nèi)：

• 注意使用程序集，優(yōu)化編譯速度。

• 嚴(yán)格劃分模塊，以功能的形式？以模塊的形式？以文件夾的形式？（待定）

4、一切事物均加載

老版本中包體過大的原因之一，就是在于很多資源由于在場景下掛載，實(shí)際上被打成了一式兩份，因此。

場景內(nèi)只留起動器及相似功能物體，其余均用加載的方式生成，同時(shí)嚴(yán)格遵守表現(xiàn)邏輯分離原則。

5、新架構(gòu)

架構(gòu)一

重度依賴Unity，但要配合第一點(diǎn)使用Unity外相關(guān)代碼，同時(shí)注意腳本內(nèi)容職責(zé)單一化，管理方式可參考官方推薦管理方式。

https://github.com/UnityTechnologies/open-project-1

https://github.com/UnityTechnologies/open-project-1/wiki

架構(gòu)二（或許太麻煩了）

最理想的模式就是用這套仿網(wǎng)絡(luò)框架的架構(gòu)來運(yùn)行游戲，模塊間使用接口進(jìn)行隔離，無需知道其實(shí)現(xiàn)細(xì)節(jié)。

這么做有額外的好處就是便于做單元測試、替換性強(qiáng)，可以直接替換任何模塊。

框架搭起來成本或許會高，但是最終可以真正意義上做到及換及用，甚至可以作為公司游戲通用框架，因?yàn)椴挥每紤]業(yè)務(wù)需求，只需考慮實(shí)際內(nèi)容。

6、狀態(tài)機(jī)控制流程

老項(xiàng)目的問題在于，沒有明確的節(jié)點(diǎn)做一些切面操作，如加載器、游戲狀態(tài)這種。

使用狀態(tài)機(jī)控制后，可以避免老版本中在一個(gè)節(jié)點(diǎn)做了太多的事情。

7、新的UI系統(tǒng)

老版本UI Manager最大的問題就是他不是個(gè)UIManager，實(shí)際上是一個(gè)資源加載器，它缺少一切UIManager應(yīng)該具有的功能，如彈窗隊(duì)列、更新UI數(shù)據(jù)等。

可以針對第二點(diǎn)和第五點(diǎn)中的render部分進(jìn)行相應(yīng)設(shè)計(jì)。

8、資源回收（待議）

Unity中要在OnDestroy 或 OnDisable中做一些收尾處理

非Unity內(nèi)容，要在銷毀時(shí)做一些釋放處理？

9、開發(fā)擴(kuò)展器組件要加入日程

一些增加開發(fā)效率，避免重復(fù)性工作的事情要做成一鍵式

導(dǎo)入地址關(guān)聯(lián)

打包前一體化配置工作？

debug調(diào)試功能最好編輯器，實(shí)體一式兩份？

10、事件系統(tǒng)

之前使用過的SOChannel系統(tǒng)，只能做Unity層間通信，基于需求可能要對其修改，或使用更通用的事件系統(tǒng)？（待議）

11、引用公共庫內(nèi)容

目前根據(jù)名字判斷，可以也許可以引用的有：

• 日志庫

• 實(shí)驗(yàn)庫

• 存檔庫

• 多語言庫

具體引用及其表現(xiàn)還要與相關(guān)維護(hù)組進(jìn)行咨詢。

12、使用啟動器啟動

在游戲中有一個(gè)單進(jìn)入點(diǎn)，用于初始化和保存全局對象。這將幫助咱們創(chuàng)建、配置和維護(hù)全局對象：廣告管理器、音頻系統(tǒng)、調(diào)試選項(xiàng)等。同時(shí)可以設(shè)置并顯示系統(tǒng)初始化順序，構(gòu)建依賴關(guān)系圖。

Eg：

13、使用疊加場景模式

對于預(yù)制體來說，始終牢記一點(diǎn)：一旦對預(yù)制體（基本上是任何其他對象）的引用實(shí)力化，其內(nèi)容將完全（遞歸）地加載到內(nèi)存中。這意味著，包括紋理、幾何、其他引用的預(yù)制件、音頻剪輯等在內(nèi)的所有資產(chǎn)都將同步加載到內(nèi)存里。它們是否被實(shí)例化并不重要，因?yàn)閷?shí)例化過程只會創(chuàng)建一個(gè)淺拷貝，然后調(diào)用Awake/Start/OnEnable/...方法。

因此解決方案是有一個(gè)根場景（例如主菜單），然后根據(jù)需要以加法和異步方式動態(tài)加載和卸載場景。它們將自動堆疊在一起，盡管仍然要小心畫布排序順序。這種方法比預(yù)制體加載更先進(jìn)一些，有相當(dāng)大的好處：

• 內(nèi)存占用空間大大減少，因?yàn)槟S時(shí)只加載所需的目標(biāo)場景的內(nèi)容。

• 加載時(shí)間大幅度縮短，因?yàn)樘幚?、加載和反序列化的時(shí)間要少得多。

• 合并時(shí)避免了很多版本沖突，因?yàn)轫?xiàng)目被分成較小的獨(dú)立部分（場景），而不是所有人都在一起工作。

• 產(chǎn)生的層次結(jié)構(gòu)更干凈、組織良好。更好的組織意味著更有效的工作。

14、命令模式

編程界黃金法則之一是：負(fù)責(zé)開始一個(gè)過程的對象也應(yīng)該負(fù)責(zé)完成和清理它。

在這種法則下，一個(gè)有效的想法是命令模式。這種情況下一個(gè)行為可以被視為一條流水線。

命令是一個(gè)可實(shí)例化的類，用于包裝方法調(diào)用，并在完成后銷毀。這有利于我們可以用對象變量的形式沿其異步調(diào)用存儲時(shí)間信息。命令確實(shí)以干凈的狀態(tài)開始和結(jié)束，并且只有在有最終結(jié)果（數(shù)據(jù)、成功/失?。r(shí)才會返回。

通過使用協(xié)程，Unity可以很好地利用這種模式。