一、数据库选型

1. 客户端数据库常用的几种方案:Core Data,FMDB,WCDB,WHC还有其他未知的方案。

1. 我从几个方面进行考虑:是否支持ORM？线程安全？性能？数据库升级是否方便？使用复杂程度？是否支持数据库加密？熟悉程度？

2. 下面是总结出的表格

   
   对比结果.png

2.最后选择了WCDB，微信出品必是精品。

1. 支持swift与OC,api提供的接口比较友好。性能方面也好，支持ORM，这也是没有选择FMDB的原因。
2. 微信提供error全局监控,sql耗时，能监控ms及以上的sql执行耗时。对排查db卡顿很有帮助。

3.WCDB

1. demo下载编译报错:选择release版本下载
   wcdb 报错:编译错误 'sqlcipher/sqlite3.h' file not found

2. WCDB - 腾讯开源的移动数据库框架

4.小结

1. 选择WCDB是正确的选择。没有FMDB的语法糖问题，没有数据库开关的问题，支持批量操作。
2. 简单易用才是我们的选择。

二、多线程使用优化

数据库选用的WCDB，WCDB支持线程安全，但不代表读写都是子线程操作。

问题:发现操作DB时，很多地方都是在主线程调用的。

思考:如何做到真正的多线程使用DB？

1. 上层异步子线程调用,底层改用Block的形式回调结果
   业务都是一层嵌套一层,带来的问题是改动非常大。

2. 串行队列，异步读、异步写
   改动地方多，而且读写顺序不受控制。
   block结果可能出现嵌套，出现闪退。如读操作回调之后直接写操作。

3. 串行队列，同步读、异步写
   写操作的地方少，而且很多时候并不需要等待结果回调。修改的地方不是很多，改动起来方便很多。

4. 栅栏函数
   多读单写。异步写、同步读。增删改都是异步，读是同步。

5. 针对特定场景的在主线程的读操作做异步处理
   针对比较耗时的在主线程的读操作，从上到下改造移至子线程。

6. 能批量操作的，就批量操作。

7. 数据库字段尽量与接口字段保持一致。
   例如消息表，想存储一些本地的属性，有可能在插入数据时被覆盖掉。
   insertOrReplaceObjects:会替换整个对象，做不到单个属性替换。