一回SQLite的踩坑记录

先是说一下题目点吗。
近些年在优化旧代码。优化六个界面的渲染速度时踩了个坑。因为这五个界面的数据量相比较大,所从前面一向有做缓存处理。离线缓存效能是一位老同事写的,用的SQlite。当时也没多看,没悟出上线后直接被吐槽数据量过大时加载有卡顿现象。于是我从图层渲染到数量加载都优化了一下,也确实流畅了很多。但随之
bug就来了。

Snip20170111_1.png

接下来顶级一流往上调试….平昔找不出原因。果断求助stack,发现原来是线程导致的数量安全问题。

Snip20170111_3.png

接下来我想了弹指间,确实是。因为事先加载界面时首先读取的是数据库的多寡,而且是在主线程…….这样领悟的一无是处我即刻居然没察觉!于是自己把读取缓存的操作放到了子线程完成,数据读取完成后再次来到主线程做UI处理。

Snip20170111_2.png

没悟出就造成了这一个bug。是在多线程格局下,并发对同一个数据库连接调用sqlite3_prepare_v2()来创设prepared
statement,或者对同一个数据库连接的其他prepared
statement并发调用sqlite3_bind_*()和sqlite3_step()等函数都会出错(在iOS上,该线程会产出EXC_BAD_ACCESS而中止)。这种不当无关读写,就是只读也会出错。因为SQLitePersistentObject这一个事物太老了,对多线程的支撑很不友善,放到子线程操作会有题目。但前几日也没时间去重做离线缓存效率。只好先连续放到主线程操作。

哎…..别人的旧代码是一踩一个坑。

听讲Realm不错,有时间领悟一下。

相关文章