背景

我们都知道，在Android开发中，一般都使用sqlite来进行数据的存储与访问，而使用sqlite也可分为两种方式，一是在app中手动创建database，这种情况下大多使用SQLiteOpenHelper来进行数据库的创建与升级管理；另一种则是我们事先处理一份只读的数据库放在assets文件夹里，使用的时候则必须先把sqlite文件从assets文件里里拷贝到程序中才可使用，这种情况下的升级则是通过判断版本号来直接覆盖拷贝。

问题

在one的项目中以上两种做法都用到了，本地放了一份只读的部分食物数据，大概1.1M左右，用户的记录数据如：饮食、运动、体重记录存储在自己创建的另一个数据库中。这看似没什么问题，实际测试中也没发现有什么异常。项目上线后后台监测会有一些异常出现，大概意思是food_groups找不到这个表之类的，由于异常次数比较少，加上本地测试也没重现，所以也没在意。但是这个异常每一个版本都会出现，加上偶尔有个别用户反馈食物查询不了，甚是纳闷。

解决

通过询问几位用户以及后台错误的版本分布来看，大多集中在2.2。这个时候便定位到了问题，2.2版本一下的已经非常少了，实际测试时公司也没有那么低版本的手机了，所以一直没有重现，于是在模拟器上用2.1版本进行测试，果然查询模块无法查看。通过监测日志发现，在2.1版本copy数据库时失败，但是在2.3以上版本却一直正常。经过google查看了很多资料，加上自己实际的测试才发现在2.3以下版本的系统中放在assets文件夹里的数据库文件大小不能超过1M，于是经过重新整理把文件缩小到900多k，再在2.1版本的模拟器上运行，一些ok了。

总结

安卓平台上的版本兼容问题确实是令人比较头痛的事，但是4.0之后这些兼容问题不再那么明显了，就目前来看我们的app还是要兼容大多数的系统版本的，后台的异常还是有很大作用的，在测试机器不充分的条件下，这种方式还是非常依赖的。相信等4.0以后的版本普及之后，兼容问题便不用花费太多精力了。