工作记录 - OBB的解决方案
之前关于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无法解决.即便自己实现的有了问题, 跟着代码调试也能很快修复,代码也会越来越稳定.
