之前關於OBB的內容:
自從用了Java來mount OBB, 再也沒有遇到掛載的問題.
但最近在LG Nexus5 和LG G2上測試, 發現某個大約30K文件的文件, 一次性讀取出來以后, 處理會報錯.
最后排除各種因素, 比如為了排除buffer壞掉的因素,讀的時候單獨new一個新buffer,一次性讀取,然后dump到sd卡.對比dump出的文件, 發現整個文件中間有n個字節(大約是32-64,沒有數), 跟原文件不一樣.
而用測試用例單獨測試該文件時, 又沒有出現問題. 而出問題的情況比較復雜, 已經連續讀取了N個文件, 但是到這個文件,錯誤100%重現. 測試其他平台沒有出現這樣的問題. 感覺很惡心. StackOverflow上也有人遇到類似的問題,但是沒有解決.
最后終於決定使用公司自己定義的格式,問題解決.
自己業余寫的Blade引擎已經用了自定義的BPK格式. 而工作中由於很多因素, 所以自定義的方式一直沒有采用. 現在用了公司自己定義的格式后, 更加可控, 如果問題也好修復. 至此, 總結一下當前native下使用obb的最佳方式.
使用android sdk自帶的jobb (SDK的可選預置格式):
打包的限制: 用的FAT16, 有很多限制, 比如根目錄512個entry, 單個文件512M限制, 整個包2G限制.而jobb的bug導致整個包不能超過512M,但網上可以找到修復代碼.
runtime的問題, 第一個時native端mount不上, 用java之后解決. 然后是最近遇到的讀文件壞數據問題.
總的來說, 做輕量級的小游戲或許不會遇到這么多的限制和問題, 但是個人仍然不建議使用系統內置的格式. 因為android的開放性,每個硬件廠商可以定制代碼, 或許google的原系統有bug,其他廠商修復了.或許本身沒有bug, 廠商開發過程中產生了新的bug, 這個在OpenGL ES 2.0上已經遇到了類似的問題, 各種設備的各種bug層出不窮.
1.對於有積累的公司, 可以嘗試將原有的文件包系統移植過來, 如果現有系統本來就比較穩定, 那么移植的成本將會很低.
2.如果是剛起步的公司,手里沒有穩定的文件包系統,但是沒有時間和精力去自己寫, 可以選擇zip格式, 打包簡單方便bug少, runtime有n多種庫而且大多是開源的, 相對來說比較穩定. 這也是比較快的實現方式. 缺點是資源容易被破解, 即便簡單加密了,相對來說還是好破解.
3.如果手頭沒有現成的文件系統包, 而有充足時間和精力, 可以考慮自己重寫.
這么做最大的好處是更可控,不會被系統的API坑,各種莫名其妙的bug無法解決.即便自己實現的有了問題, 跟着代碼調試也能很快修復,代碼也會越來越穩定.