對於資源加密的思考
很多人認為ab包不需要加密，但是這樣的人我認為，他思考問題的方式是片面的且狹隘。
是否加密應該根據項目本身的資源價值來決定。是否提高資源的破解難度，比如對於一個沒什么價值的項目，也沒有人會想要去拿你的資源，自然不需要。但是比如像閃耀暖暖這樣，資源密集且開發代價較高的項目，資源應該在一定程度上保護起來，使得破解的代價也得到提高。當然，對於破解高手而言，破解只是時間問題。這里主要的目標還是提高破解的代價。
古老的加密方法：二進制加密
在2013年，曾經寫過一個文檔(Unity3d服務器資源加密,其實是ab包加密)，當時由於unity提供的API比較少，所以當時的方法是將ab包作為bytes數據進行加密，加載時讀取文件數據，解密之后，通過LoadFromMemory進行加載。雖然這種方式是有效的，但是很顯然，加載時間和內存的問題讓我們困擾好久。
裸奔的資源
隨着Unity的普及，現在已經越來越多的項目使用AB包，但是大部分都是沒有加密的。比如某IP侵權的app，可以通過或者Unity內置的AssetBundleBrower直接看到ab包的所有資源
更甚者可以通過AssetStudio直接看到ab包的所有資源，圖片，音頻，動畫，文本，CG視頻等等（蒙皮動畫目前不行），並且導出。
如果會寫點代碼，還可以在unity中，直接實例化出來，然后另存為Prefab，這樣雖然無法獲得fbx（其實fbx開源，自己反推寫入數據也可以導出fbx），但是我們可以獲得完整的Prefab，設置內含了蒙皮信息。這樣可以輕松獲得所有的數據，貼圖，音頻，視頻，模型，材質，蒙皮，動畫等等
所以，沒有加密的資源和裸奔沒有什么差別。
二進制加密優化
那么ab加密，上述的加密，有什么優化的方法呢。方法很多，雨松在2019年的一篇文檔（Unity3D研究院之加密Assetbundle不占內存（一百零五））提到利用Unity2017.2提供的新API：AssetBundle.LoadFromStream可以實現沒有內存額外消耗的方法。
一個更簡單有效的加密方式
其實我們用的API有個參數offset就可以解決加密的問題
public static AssetBundle LoadFromFile(string path, uint crc, ulong offset);
我們完全可以在打完資源的時候，隨機寫入一段bytes數據到ab包的前面，然后記錄寫入的長度，也就是offset。在加載時，將offset作為參數就可以實現加載。（這里有一個風險，如果ab包的有效數據是以固定格式開頭，那么還是容易被破解，未測試）。下圖展示了一個隨機寫入22個byte之后，AssetbundBrower和AssetStudio看到的情況
下圖展示，從帶有22個byte的ab包中加載的結果
總結
LoadFromFile(string path, uint crc, ulong offset)
這種帶offset的打包/加載方法的最大好處是沒有內存的消耗，也沒有加載上性能的損失，可以視作沒有更改引擎代碼或者hook引擎的情況下最好的方法。
簡單，高效，易用。
Simlpe is Good !!!!!