Config全局参数控制
- 服务器 Ip 或域名
- 服务器端口号
- AppKey
- 本地数据发送和端口侦听，debug 下固定端口号，观察 NAT 网络下的外网端口分配情况
- 预设的敏感度模式
客户端模式的设定必须要与服务端的模式设置保持一致，登录前调用
SenseMode3s
- keepAlive心跳间隔为3秒
- 10秒后未收到服务端心跳反馈即认为连接已断开（相当于连接3个心跳间隔后仍未收到服务端反馈）
SenseMode10s
- keepAlive心跳间隔为10秒
- 10秒后未收到服务端心跳反馈即认为连接已断开（相当于连接2个心跳间隔后仍未收到服务端反馈）
SenseMode30s
- keepAlive心跳间隔为30秒
- 10秒后未收到服务端心跳反馈即认为连接已断开（相当于连接2个心跳间隔后仍未收到服务端反馈）
SenseMode60s
- keepAlive心跳间隔为60秒
- 10秒后未收到服务端心跳反馈即认为连接已断开（相当于连接2个心跳间隔后仍未收到服务端反馈）
SenseMode120s
- keepAlive心跳间隔为120秒
- 10秒后未收到服务端心跳反馈即认为连接已断开（相当于连接2个心跳间隔后仍未收到服务端反馈）
对于客户端而已，此模式决定了用户与服务端网络会话的监控模式，原则上越敏感客户端的体验越好
Core 控制
初始化
自动重新登录
debug 模式设置
释放（守护进程等）
通讯协议代理
连接服务器标识，作为唯一依据
本地用户登录时的额外信息
token
登录标识
基础通讯消息的回调事件接口
本地用户的登录结果回调事件通知
登录结果：0表示成功；自定义错误码通常为>1025的数。
与服务器的通信断开的回调事件通知
该消息只有在客户端连接服务器成功之后网络异常中断时触发。
数据通信消息的回调事件接口
收到普通消息的回调事件通知
应用层可以将此消息进一步按自己的 IM 协议进行定义，从而实现完整的即时通讯逻辑。
服务端反馈的出错信息回调事件通知
质量保证机制的回调事件接口
QoS 机制支持全部的 C2C、C2S、S2C 三种消息交互场景下的消息送达质量保证； QoS 机制的目标是：尽权利送达消息，即时无法送达也会回调告之应用层（消息黑洞问题）。
消息已被对方收到的回调事件通知。
目前，判定消息被对方收到有两种可能：
- 对方确实是在线并且实时收到了
- 对方不在线或者服务端转发过程中出错了，由服务端离线存储成功后的反馈（此种情况严格来讲不能算是"已被收到"，但对于应用层来说，离线存储了的消息原则上就是已送达了的消息：因为用户下次登录时肯定能通过 HTTP 协议取到）
消息未送达的回调事件通知
QoS算法判定出的未送达消息列表，应用层可通过指纹特征码找到原消息做出相关处理
与服务通信中断后的自动登录重连独立线程
鉴于无线网络的不可靠性与特殊性，移动端的即时通讯经常存在网络通讯断断续续的状况，可能的原因有（但不限于）：无线网络不稳定、WiFi 与2G/3G/4G 等通开情况下的网络切换、收集系统的省电策略等。这就使得即时通讯框架拥有对上层透明且健壮的健康深度探测和自动治愈机制非常有必要。自动登录重连只可能发送在登录成功后与服务端的网络通讯断开时。
KeepAlive守护线程
防止 NAT 路由器算法导致的端口老化：
路由器的 NAT 路由算法存在所谓的"端口老化"概念（理论上 NAT 算法中 UDP 端口老化事件未300秒，但这不是标准，而且中高端路由器可由网络管理员自行设定此值），Keep alive 机制可确保在端口老化时间到来前重置老化时间，进而实现端口"保活"的目的。否则端口老化导致的后果是服务器将向客户端发送的数据将被路由器抛弃。
即时探测由于网络状态的变动而导致的通信中单（进而触发自动治愈机制）
此种情况可能的原因有（但不限于）：无线网络信号不稳定、WiFi 与2G/3G/4G 等情况下的网络切换、手机系统的省电策略等。
协议
协议数据内容
指纹特征码（用于 QoS 消息包的质量保证时作为消息的特征值，理论上全局唯一，使用 UUID）
发出消息方id
QoS 质量保证
消息接收方id
应用层专用字段 typeu（用于存放聊天、推送等场景下的消息类型，不需要时使用-1）
协议类型（如需定义应用层的消息类型，使用 typeu 配合协议数据内容一起使用）
标记是否来自跨服务器的消息，为跨服务器或者集群准备
