工做記錄 - OBB的解決方案

以前關於OBB的內容:

Android上使用native IO

最近工做中的問題筆記

工做記錄[續] android 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沒法解決.即使本身實現的有了問題, 跟着代碼調試也能很快修復,代碼也會愈來愈穩定.