工作記錄 - OBB的解決方案

標籤：android   blog   http   java   使用   檔案   

之前關於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無法解決.即便自己實現的有了問題, 跟著代碼調試也能很快修複,代碼也會越來越穩定.