現在手機遊戲的常規更新方案都是在啟動時下載所有資源更新，遊戲質量高的、使用者粘性大的有底氣，先安裝2個G，啟動再更新2個G，檔案小了玩家還覺得品質不行不想玩。
最近在做微信、抖音小遊戲，使用他們提供的資源快取方案，現在要轉成Android APP, 也想用這種邊下邊玩的機制把首包做小。
其實很簡單，直接用Unity內部的Caching機制即可，但是因為沒怎麼接觸過，一開始用的就是那種啟動時下載資源更新的方案，反而繞了一些彎路。
資源方案：AssetBundle (現在推Addressable的比較多，解決了AssetBundle難以處理的一些問題，但是比較久的專案肯定都對AssetBundle進行了相應的封裝來處理這些問題，沒有本質區別）
1. 打包AssetBundle時獲取hash
呼叫自己封裝的SBP ContentPipeline.BuildAssetBundles(), 遍歷IBundleBuildResults.BundleInfos可以取到對應的hash和crc，
如果用舊的BuildPipeline.BuildAssetBundles(), 也可以透過manifest取到對應的hash，但如果想拿到crc，需要手動傳引數進去。
另外，需要設定打包壓縮格式為LZ4。預設的LZMA會重新壓縮成LZ4，造成比較明顯的卡頓。
2. 載入AB時的快取機制
var uwr = UnityWebRequestAssetBundle.GetAssetBundle(url, hash, crc);
怎麼樣，是不是非常簡單？只需要填上hash引數，就可以依靠Unity內部機制實現邊下邊玩。hash也不一定是hash，實際作用只是一個版本號，只要請求的時候對應的版本的資源在快取中存在，就會下載新的，否則就讀快取中的，如果不填這個引數就是預設值0）
crc引數是用來校驗的，如果AB和呼叫時的crc對不上，uwr.downloadHandler.error會表現出來，並且取不到資源。預設值0表示不進行校驗
3. 優缺點
優點自然是非常簡單，改一下就能用，如果要部分資源放進包裡，部分資源邊下邊玩，改一下判斷就行。
缺點是沒法精細操作，資源出問題了最簡單粗暴的就是直接Caching.ClearCache，沒有辦法對單個檔案進行完整性檢查。