一亩冬、編輯器：打包
1、使用ScriptableObject配置打包規(guī)則
- 分包方式可以隨著項目迭代靈活調(diào)整届良，只要不改底層的設(shè)定贝攒，就不用動代碼
- 將部分流程控制的接口盗誊，以虛方法的形式放到ScriptableObject里，可以給項目提供一定的拓展性隘弊，又不用主動向ABMgr傳遞對象或者做額外的配置哈踱。（由ABMgr主動尋找規(guī)則配置的ScriptableObject）
2、用Pipeline的結(jié)構(gòu)梨熙，處理打包規(guī)則的解析（生成AssetBundleBuild列表）
- 后置Pipe可以選擇在前置Pipe結(jié)果的基礎(chǔ)上進行修改开镣，也可以完全丟棄前面的結(jié)果。效果同裝飾者模式咽扇。
- 可以很大程度上保證【開閉原則】
- 規(guī)避新增需求時到處插入修改代碼
二邪财、運行時：加載&使用
1、兼容AB包的循環(huán)引用問題
以目錄為單位的打包方式质欲，在資源放置不當?shù)臅r候树埠，比較容易出現(xiàn)AB包循環(huán)引用問題。研發(fā)階段嘶伟，經(jīng)常出現(xiàn)發(fā)版后由于循環(huán)引用導(dǎo)致的卡死問題怎憋，要浪費不少時間定位、修改奋早、重新出包（特別時半夜出版盛霎，遇到這個問題極其惡心！５⒆啊）。
為了不在節(jié)點出浪費時間期揪，決定從程序上允許循環(huán)引用的存在掉奄。但是規(guī)范上還是不允許，發(fā)現(xiàn)問題后仍然需要相關(guān)人員進行解決，只是不在發(fā)版的當口處理姓建。
2诞仓、支持異步加載轉(zhuǎn)同步完成
通常我們要求所有資源都應(yīng)該采用異步加載的方式；或者先異步預(yù)加載再同步使用速兔。但總有一些情況需要真正的同步加載墅拭，從業(yè)務(wù)使用上無法保證同步、異步只存在一個涣狗。所以要在同步加載的時候谍婉，將當前存在的異步加載請求立刻完成，返回給同步請求使用镀钓。（Unity不允許同一個AB包被同時加載兩次）
3穗熬、支持取消加載
從業(yè)務(wù)角度，我們希望玩家不被加載卡住操作丁溅。比如：玩家做了一個需要加載較長時間的操作唤蔗，玩家應(yīng)該可以退出系統(tǒng)放棄這個操作，而不是必須等待加載完成窟赏。Unity底層沒有相關(guān)的支持妓柜，只能自己在框架里做。
4涯穷、支持延遲卸載
- 延遲卸載的主要意義是棍掐，避免一個資源剛卸載馬上又加載，浪費性能（IO求豫、內(nèi)存塌衰、發(fā)熱、時間）
- 延遲卸載要放在底層支持蝠嘉，用一個模塊進行統(tǒng)一的管理最疆，不要讓業(yè)務(wù)來關(guān)注這個事情（特殊業(yè)務(wù)有特殊需求，也應(yīng)該有可操作的支持）
5蚤告、以資源名為Key努酸，用雙緩存的方式記錄已加載的資源
我允許不同類型的資源重名，定位資源就需要名+類型兩個信息杜恰。大多數(shù)情況下名字跟資源是一對一的获诈，少數(shù)情況下才會出現(xiàn)一對多。為了同時兼顧內(nèi)存與查找效率心褐，建立雙緩存舔涎。多數(shù)情況，只需要一次查找就定位到資源逗爹；少數(shù)情況亡嫌，需要追加一個小規(guī)模的遍歷。
6、支持模擬模式加載資源
- 研發(fā)階段頻繁打AB包會浪費大量時間挟冠，所以要支持直接加載資源的方式跑游戲（模擬模式）
- 加載方式差異應(yīng)當放在底層處理于购、切換，業(yè)務(wù)層不應(yīng)該對這件事有感知
- 為了方便在編輯器下知染，快速切換加載模式測試不同的問題肋僧，用ScriptableObject提供配置切換
- AB包模式與模擬模式相互獨立，不應(yīng)該有相互依賴
