背景
Soul的核心业务就是在线聊天，私聊，群聊，聊天室，都需要文档的IM系统去支持。
很早之前使用的是三方IM，有很多不可控的缺点，这里就不一一例举。
而随着用户井喷式增长，极需自研一套稳定的，可控的，灵活的IM系统，以下以IOS客户端举例。
流程思考
接收IM时，我在思考，IM直观上就是我打字，然后给对方发消息。
1.比如一段文字”你好”这个字符串，通过业务端调用SDK的接口，传入到SDK里
2.而SDK做什么呢，第一步肯定先把这个字符封装成一个自定义的结构体model，可通过多种方式如json，probuffer等转化压缩成二进制数据对象data。
3.通过把data传递给socket接口，通过网络通道发送到对端。
- 建立长连接，可参考网络编程自己写或直接使用开源看GCDAsyncSocket。
5.数据库系统存储此data。
6.接收到此消息后，再反序列化，解析data，组装成业务可识别的model，上传至业务层使用
大致流程就是如此，那么所要做的第一步，就是搭建最底层 网络层，先搭建TCP连接
架构上分为4层：网络连接层、网络处理层、业务调度层、业务调用层
1.网络层
最底层，负责TCP连接，收发，二进制流封装成包，递交给上层数据解析层
网络协议选择用TCP协议，因为UDP是无连接不安全的，需要在上层做可靠到达安全机制，如超时重传，顺序重组等，实现繁杂技术成本高。
socket编程的大体流程是
1.创建一个socket套接字，指定协议 tpc udp和ipv4/ipv6
2.根据ip和端口解析地址清单。（getaddrinfo）
3.建立三路握手，获取一个稳定的tcp连接
4.基于这个连接，实现收发流接口。
因为客户端只需实现建立连接，也就是一个通道套接字，就是socketId，无需像服务端一样做accept做多路连接处理，所以实现较为简单。
具体想了解网络层编写步骤和具体需注意事项，可关注下面的连接：
2.网络处理层
此层通过pb 反序列化二进制包，递交给上层，此层处理心跳，负责调度网络层各种网络异常，如重连，断连，异常信号等、提供数据收发中转功能。
在这一层处理网络异常重连、监听网络变化、心跳包计时器、网络IO接口。
这里是与socket通信层交流的唯一通道，任何其他层都不许与socket交互层有交互，使网络层整体隔离出业务之外。
这里推荐google开源框架protocol buffer，目前微信也开始采用。
protobuf优点
1、性能好/效率高
时间开销： protobuf在这个方面就进行了优化。可以使序列化和反序列化的时间开销都减短。
空间开销：也减少了很多
2、有代码生成机制
3、支持向后兼容和向前兼容
3.业务调度层
再解耦纯粹的sdk也不可能完全脱离业务，所谓IM SDK 大多提供无非是.1v1 n v n 聊天室功能等。
此层，会初始化几个管理类，消息根据类型会传递到响应的管理类去处理，消息db存储也是在此层处理。
我们在网络处理层之上初始化一个消息调度管理器的模块，由他对消息进行分发，分发给各个子调度器进行具体处理：
私聊调度器：私聊消息分配给此管理器，由他处理私聊消息去重，收发，存数据库等。
再对数据进行包装，由统一接口传递到业务层
群聊调度器和聊天室调度器：和私聊类似，不同的是数据存储在不同的表，这个后面会详说。而且聊天室业务是不要历史记录。
所以聊天室调度器不需处理存储业务。
基础消息调度器：处理和业务无关的消息，比如用户登录鉴权，离线消息拉取，
根据拉取的字段判断是否拉取完历史消息，推送消息处理等。
这么做的目的是使私聊 群聊 等消息处理完全解耦，不同类型的消息由具体的相应的管理者去处理，彼此不影响
就算以后新起一个直播业务，只需新建一个直播调度管理器就可以了，之前的业务管理器不需要改变。
数据存储
这里首推sqlite，可以选择开源框架FMDB，但纯用FMDB存在一些缺点：
1.无wal模式，想做高性能读写数据库，不开启wal模式肯定是不容许的，关于wal相关知识可查，网上一堆。
2.用一个串行队列去同步数据库的所有操作，这样做虽然解决了线程安全问题，但在多线程模式下浪费了sqlite的并发读写的优势。
而且擅自修改FMDB源码会引起一些不可控的问题，
当然用腾讯开源数据库WCDB性能非常棒棒哒，但考虑到万一以后IM toB的情况，并且早期导入时会和项目中一些已存在的数据库引起兼容问题，所以在此决定自己封装sqlite。
具体优化步骤请看链接：
4. 业务调用层
此层封装给业务方调用的接口，业务方无需观察底层实现。
随着业务复杂度的增加，业务方可能会对IM提更多的需求，而频繁修改sdk底层明显不美好，这里我在sdk和业务层中间维护了一层业务缓冲层，缓冲层可以在不修改sdk底层的同时，为复杂业务添加各种逻辑处理函数和底层不方便提供的的接口。
如：
1.对取出的数据做不同业务的排序。
2.为数据库的每个会话根据不同业务添加不同标签
3.通过业务接口获取IMSDK所需的IP、端口等。
这样即使以后IM为不同产品做迁移，处理不同的业务，SDK底层是不需变化的，仅需要在缓冲层为不同业务添加不同的缓冲接口即可。
如图：
IMSDK总流程图
如有疑问可下方留言：
