一样软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不错,有日了解一下。

相关文章