本文篇幅较长，预计阅读时长1-2h，欢迎收藏+点赞+关注。
这是《千亿级IM独立开发指南！全球即时通讯全套代码4小时速成》的第三篇：《APP 内部流程与逻辑》
系列文章可参考：
三、APP 内部流程与逻辑
作为即时通讯的App，将会有很多的数据需要本地存储。比如联系人的信息，聊天的历史消息。假设如果每次都是从网上实时拉取对话的历史聊天记录，当一个延绵不绝的会话超过1个月以上时，比如，你和你好友的会话，那海量的聊天记录，不经时间漫长，而且还会让用户的带宽痛苦不已～～
所以，我们将使用数据库保存联系人信息和聊天记录。
对于数据库的选择，一向是够用就行，第三方依赖越少越好。刚好iOS自带SQLite，作为数据库的老手，我们决定直接使用SQLite，至于SQLite.swift这个知名的第三方库，目前感觉至少在这个Demo中，没有使用的必要。
打开项目属性页面，选择”TARGETS” -> “IMDemo” -> “General”：
点击页面上 “Frameworks, Libraries, and Embendded Content” 栏下方的”+”号，打开框架与库添加窗口：
在搜索框内输入”SQLite”，选择”libsqlite3.tbd”，点击”Add”按钮进行添加。
添加完毕后，”Frameworks, Libraries, and Embendded Content” 一栏显示为：
添加 swift 代码文件 DBOperator.swift，编辑代码如下：
因为每个用户的数据需要隔离，所以最简单的方式便是每个用户使用一个独立的数据库。因此我们无法在App一起动的时候便打开数据库，而需要等到登录成功后，获取到了用户唯一的 userId，才可知道，该为谁打开数据库，应该打开那个数据库。
因此，我们完成 openDatabase() 的代码如下：
每次打开数据库时，将先检查目标数据库是否存在，不存在则进行创建。
我们设计联系人信息表如下：
历史消息表如下：
此外，如果历史消息非常多，一次拉取不完，则需要分段拉取。而如果在分段拉取的过程中，用户退出，便会造成拉取的中断。而此时如果一段时间后，用户再登录，则必然需要先拉取最新的历史消息，而不是从上次中断处继续拉取。而如果在拉取到上次中断处之前，用户再次退出，则拉取将再次停止。而此时，历史消息连续性上的空洞便产生了。
为了避免历史消息连续性上的空洞造成的消息遗留，我们还需要第三个表，来储存历史消息的中断位置，和中断的拉取方向。于是我们增加历史消息检查点数据表如下：
因为很多时候，我们知道需要执行的SQL必然会成功，而且我们不关心其状态和返回值。
因此，我们增加 executeSQL() 函数如下：
最后，完成 createContactTable() 函数如下：
然后编辑 IMCenter.swift，加入对 DBOperator的引用：
我们添加IMDemoApp所需的数据库其余操作如下，具体功能请参见函数注释：
Original: https://blog.csdn.net/weixin_39367158/article/details/124414487
Author: 云上曲率
Title: 千亿级IM独立开发指南丨全球即时通讯全套代码4小时速成（三）：App内部流程与逻辑（上）
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/815450/
转载文章受原作者版权保护。转载请注明原作者出处！