Soul基础服务之IM搭建分享-iOS端从0开始

背景

Soul的核心业务就是在线聊天，私聊，群聊，聊天室，都需要文档的IM系统去支持。

很早之前使用的是三方IM，有很多不可控的缺点，这里就不一一例举。

而随着用户井喷式增长，极需自研一套稳定的，可控的，灵活的IM系统，以下以IOS客户端举例。

[h1Head]流程思考[/h1Head]
接收IM时，我在思考，IM直观上就是我打字，然后给对方发消息。
而这个消息的流转过程是：

因为字数限制，这个流程描述省略

[h1Head]架构上分为4层[/h1Head]

1.网络层

最底层，负责TCP连接，收发，二进制流封装成包，递交给上层数据解析层

网络协议选择用TCP协议，因为UDP是无连接不安全的，需要在上层做可靠到达安全机制，如超时重传，顺序重组等，实现繁杂技术成本高。

socket编程的大体流程是

1.创建一个socket套接字，指定协议 tpc udp和ipv4/ipv6

2.根据ip和端口解析地址清单。（getaddrinfo）

3.建立三路握手，获取一个稳定的tcp连接

4.基于这个连接，实现收发流接口。

因为客户端只需实现建立连接，也就是一个通道套接字，就是socketId，无需像服务端一样做accept做多路连接处理，所以实现较为简单。

具体想了解网络层编写步骤和具体需注意事项，可关注下面的连接：

《Soul自研IM之网络层步骤梳理》

《Soul自研IM之网络层异常处理及注意事项》

[H2]2.网络处理层[/H2]

此层通过pb 反序列化二进制包，递交给上层，此层处理心跳，负责调度网络层各种网络异常，如重连，断连，异常信号等、提供数据收发中转功能。

在这一层处理网络异常重连、监听网络变化、心跳包计时器、网络IO接口。

这里是与socket通信层交流的唯一通道，任何其他层都不许与socket交互层有交互，使网络层整体隔离出业务之外。

这里推荐google开源框架protocol buffer，目前微信也开始采用。

protobuf优点

1、性能好/效率高
时间开销： protobuf在这个方面就进行了优化。可以使序列化和反序列化的时间开销都减短。
空间开销：也减少了很多
2、有代码生成机制
3、支持向后兼容和向前兼容

[H2]3.业务调度层[/H2]

再解耦纯粹的sdk也不可能完全脱离业务，所谓IM SDK 大多提供无非是.1v1 n v n 聊天室功能等。

此层，会初始化几个管理类，消息根据类型会传递到响应的管理类去处理，消息db存储也是在此层处理。

我们在网络处理层之上初始化一个消息调度管理器的模块，由他对消息进行分发，分发给各个子调度器进行具体处理：

私聊调度器：私聊消息分配给此管理器，由他处理私聊消息去重，收发，存数据库等。

再对数据进行包装，由统一接口传递到业务层

群聊调度器和聊天室调度器：和私聊类似，不同的是数据存储在不同的表，这个后面会详说。而且聊天室业务是不要历史记录。

所以聊天室调度器不需处理存储业务。

基础消息调度器：处理和业务无关的消息，比如用户登录鉴权，离线消息拉取，

根据拉取的字段判断是否拉取完历史消息，推送消息处理等。

这么做的目的是使私聊 群聊 等消息处理完全解耦，不同类型的消息由具体的相应的管理者去处理，彼此不影响

就算以后新起一个直播业务，只需新建一个直播调度管理器就可以了，之前的业务管理器不需要改变。

数据存储

这里首推sqlite，可以选择开源框架FMDB，但纯用FMDB存在一些缺点：

1.无wal模式，想做高性能读写数据库，不开启wal模式肯定是不容许的，关于wal相关知识可查，网上一堆。

2.用一个串行队列去同步数据库的所有操作，这样做虽然解决了线程安全问题，但在多线程模式下浪费了sqlite的并发读写的优势。

而且擅自修改FMDB源码会引起一些不可控的问题，

当然用腾讯开源数据库WCDB性能非常棒棒哒，但考虑到万一以后IM toB的情况，并且早期导入时会和项目中一些已存在的数据库引起兼容问题，所以在此决定自己封装sqlite。

具体优化步骤请看链接：

《Soul即时通讯之数据库优化》

[H2]4. 业务调用层：[/H2]

此层封装给业务方调用的接口，业务方无需观察底层实现。

太专业了, 请问我们有什么办法可以使用你们的代码吗.