萬物都有度，都有規則，這個資源加載的框架也不是萬能的，只不過是羅列了大部分內容而已，所以使用的時候需要按照項目需求去摘取或者使用。
廢話不多說，首先我們來講一下資源加載框架當中都包含哪些內容。
第一：資源類型；
第二：資源信息；
第三：資源加載回調；
第四：資源打包。
總共來講，就是這四個部分，下面我們按照順序逐個進行講解。
第一部分，資源類型，這個很好理解吧，其實就是你需要加載的內容屬於那個類型的資源的一個標識枚舉，其中包含了被依賴包【AssetBundle】這個內容標明的是被別人依賴的內容，一般來說外部是不會使用到的；場景預製內容【GameObject】這個是場景內的其他3D2D預製；材質球【Material】；3D圖片資源【Texture】；ui預製體【UIPrefab】；2D圖片資源【Icon】；音效內容【Aduio】；特效【Effect】；影片【Move】；配置文件【Configuration】；腳本文件【Lua】。當中有很多內容其實都沒有用的，只是預製進去，預防後面進行框架擴展的時候使用的。
具體哪些是目前框架當中使用到了的呢，看下面代碼我們就知道了。
這個圖片當中，清楚的知道了我們使用了哪些內容，但是有些內容我們依然不是這樣使用的，比如配置文件【Configuration】和腳本文件【Lua】，我們在配置文件框架和lua框架當中都會避開使用資源加載框架，爲的是第一時間加載配置文件和lua腳本文件，達到及時讀取的效果，剩下的還有未使用到的比如影片【Move】和音效【Audio】這兩個部分，也沒有使用和經過測試的，因爲框架還不完善嘛。
上面的也就是我們資源的預定義類型，既然叫預定義，是因爲後續框架想做成可擴展性，使得框架內容的適應性更加強大。
下面我們來講一下資源加載回調，還記得之前我們講過的消息分發系統，裏面有一個消息回調，這個資源回調和那個消息回調是如出一轍，可以說相似度非常的高，唯一不同的是回調參數少了，接下來我們詳細的講一下。
首先由虛基類IResObjectCallBack開頭，這個是資源加載回調的虛基類，所有的加載回調都應該由他派生出來，否則資源加載系統將識別不了這個內容。其中虛基類當中定義了兩個函數，一個是HandleLoadCallBack，進行回調方法的；LoadCallBackPriority，進行同資源排序的。當然，框架內部還集成了一個資源加載的預定基類【ResObjectCallBackBase】，他就多了兩個內容，一個是加載類型成員屬性和一個加載結束回調函數成員屬性而且實現了虛基類裏面的兩個接口，內容相當的簡單，可以查看IResObjectCallBack.cs文件就一目瞭然了。
資源信息，爲什麼明明是第二點內容，非要放到第三點當中講呢，其實這個內容是可以不講的，因爲他屬於框架內部數據，並不開放出來的一個內容，但是爲了更好的理解資源加載框架，我們這裏還是稍微的講解一下。
資源信息，其實就是AB包的內容，框架目前其實沒有怎麼使用到裏面的一些數據，只是在等待加載和加載完成之後，封裝保存到框架字典當中的一些數據集合，比如說我們等待加載隊列當中，就是使用了資源信息，其中包含的是資源名字，資源類型以及回調列表三個內容，當我們加載完成之後，字典保存的又是另外一個AB信息，他包含了是否常駐內存、AB名字、AB、上一次使用時間、被使用次數這五個內容，但是目前框架當中我們只使用了AB名字和AB，其他的內容暫時都還沒有使用到，不過基本使用的規則是可以知道的，是否常駐內存，是用來進行資源清理的，AB上一次使用時間和關聯次數，這個說白了也是用來控制資源使用量的，目前框架沒有涉及，但是思路就是，如果不是常駐內存的AB信息，那麼在場景下來的時候，上一次使用時間和被使用次數都太長以及沒有被使用，那麼切換場景的時候就有可能被清除掉這個內容。
最後我們來講一下資源打包，本來想說把這部分內容單獨提取出來進行講解的，後來想想，沒有這個必要，因爲這個只是一個配套使用的工具內容。
首先，項目當中需要一個目錄【UseAB】，這個目錄是固定的，等到後續打包完成之後，可以將這個目錄刪除掉進行測試，當然，項目研發當中其實不需要刪除，接下來，我們先看一下這個打包工具的界面內容。
簡單的一個unity窗口，都是中文內容，其實很好理解，前面的我們都不講，主要開始位置是打包粒度開始，打包粒度這個目前框架當中預定就是1，意思就是說如果某個資源被多個預製引用，那麼這個資源將使用文件名字進行打包，否則使用的都是資源名字進行打包，這個很好理解吧，其實就是控制AB包名字的一個粒度內容；接下來是版本號，這個版本號就是用來做增量比較的，其中項目外還包含了一個資源比對項目，是一個win32的程序，具體的在其他工具框架當中會詳細講解，這裏就不多做冗述了。清理依賴關係，分析依賴關係都很好理解，就是清除之前的AB名字，然後重新使用新的依賴關係名字作爲AB包名字，最後是打包。
當我們AB包打包完成之後，窗口會有一定的變化。
其實就是多了幾個步驟，因爲我們打包的時候是帶着版本號的【其實現在修改了，文件當中不帶版本號，因爲版本號內容會打入文件AB包中，影響後面的正常加載，所以去除掉，後面修改成打包完成之後重置文件名字的方式進行，目前還未修改。】，所以需要去除版本號，然後分析hash數據，用作版本對比的，最後是Editor測試，說白了就是將文件放到指定的目錄當中去，當開啓了Build測試的時候就可以了，其中Build測試的意思就是說類似於打包測試，前面我們講到的宏定義當中有講述這個內容。
整體上來講，整個資源加載的框架就是這樣的。
首先打包機制已經蠻完善了，可以直接使用，配套使用資源加載機制，基本上普通的項目都適用。
當然，很多小夥伴會問，你的資源加載是不是同步加載的，加載順序是怎麼樣的，這個怎麼沒有講。那麼好的，我們現在來講一講。
首先，這個加載的機制不是同步加載的，使用的是WWW異步加載，加載的順序是這樣的，假如有一個資源需要加載，那麼我們先看看這個資源有沒有依賴別的AB包，如果有，那麼我們需要先加載別的依賴包之後才加載這個內容，如果沒有，那麼就會直接WWW加載這個內容，我們用一個圖進行描述一下。
這個圖當中，很清楚的看出我們整個加載的順序，其中最重要的加載部分，我們是放再協程當中去做的，避免使用線程加鎖的內容，協程也不是一直運行，當加載隊列空了的時候，我們就會停止該協程，也就是說我們壓入加載隊列的時候都會去判斷一下隊列之前是不是空的，如果是，那麼啓動協程進行加載，否則就不管。
最後我們講一下這個框架使用的一些細節。
使用這個框架之前，必須使用的方法是InitResManager這個方法，這個方法是使用同步方法加載所有AB的依賴關係的一個內容，如果這個沒有做，那麼後面的加載在使用AB的情況下都無法使用，除此之外，別的沒有特別的要求。
項目GitHub地址
https://github.com/FengFaming/ClientEngine