两回SQLite的踩坑记录

接下来自己想了刹那间,确实是。因为后边加载界面时首先读取的是数据库的多少,而且是在主线程…….这样强烈的荒谬我及时甚至没觉察!于是自己把读取缓存的操作放到了子线程完成,数据读取完成后回来主线程做UI处理。

Snip20170111_2.png

闻讯Realm不错,有时光精通一下。

Snip20170111_3.png

Snip20170111_1.png

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

没悟出就导致了这些bug。是在多线程情势下,并发对同一个数据库连接调用sqlite3_prepare_v2()来创建prepared
statement,或者对同一个数据库连接的另外prepared
statement并发调用sqlite3_bind_*()和sqlite3_step()等函数都会出错(在iOS上,该线程会冒出EXC_BAD_ACCESS而暂停)。这种错误无关读写,就是只读也会出错。因为SQLitePersistentObject这么些东西太老了,对多线程的支撑很不协调,放到子线程操作会有题目。但现行也没时间去重做离线缓存效用。只好先连续放到主线程操作。

然后顶尖一级往上调试….一贯找不出原因。果断求助stack,发现原来是线程导致的数码安全问题。

先是说一下题材点啊。
近些年在优化旧代码。优化五个界面的渲染速度时踩了个坑。因为这五个界面的数据量比较大,所以在此以前一贯有做缓存处理。离线缓存效率是一位老同事写的,用的SQlite。当时也没多看,没悟出上线后平素被吐槽数据量过大时加载有卡顿现象。于是自己从图层渲染到数码加载都优化了弹指间,也真正流畅了成千上万。但随后
bug就来了。

网站地图xml地图