工做记录 - 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没法解决.即使本身实现的有了问题, 跟着代码调试也能很快修复,代码也会愈来愈稳定.