基于第三方融云的即时通讯--转载请注明出处

一、融云接入架构
融云在进行接入时 , 具有不影响原APP架构的特性 , 提供有专门的sdk用于进行APP端的开发 。在不需要自身服务器的前提下 , 可以使APP与融云服务器进行自行交互 。同时服务端可以与融云服务端以API调用的形式进行互相交互 , 提供的功能有消息推送 , 消息路由 , 群组管理 , 聊天室管理 , 聊天记录下载等 。
二、融云的聊天类型 1. 1V1单聊
1v1单聊是指A直接向B发送消息 , 然后A与B产生的消息对接 , 消息的对接列表由客户端自己进行维护 , 融云不会进行维护用户的聊天列表 , 只会进行维护用户的聊天记录 , 并且 , 该聊天记录仅保存6个月 。(如果用户A分别和B、C、D三个人进行了聊天 , 然后清空APP数据 , 则再打开时就无法获取之前的聊天列表了 , 但是重新发起聊天以后 , 可以获取到历史的聊天消息记录)
2. 群组聊天
群组聊天与微信群一样 , 在加入一个群后 , 该群中只要产生新的消息 , 就会发送给群内的每一个用户 。但是在融云的服务器 , 不会维护群的列表信息 , 用户所加入的群的列表 , 需要由我们自己的服务端进行控制维护 , 并且融云不提供拉取某用户加入的群的功能 。

基于第三方融云的即时通讯--转载请注明出处

文章插图
3. 聊天室聊天
聊天室与群组聊天具有不同 , 群组聊天是在退出群组界面后 , 依然会给群成员发送推送 , 而聊天室则不会继续发送推送 。(本质上可以理解为一个在退出聊天界面以后 , 就退出的一个群聊 。)
三、服务端开发方案 1. 最简单的聊天-零改动
如果希望实现一个最简单的聊天系统 , 直接可以使用融云的聊天系统进行接入APP , 后端无需任何接口进行来与APP进行对接即可实现最简单的聊天功能 。但是在进行开发时 , 如果采用最简方案 , 将会出现无法获取到用户之间的聊天记录的问题 , 因此需要使用融云的消息路由服务进行消息的同步 , 或者通过下载聊天记录文件的形式进行聊天记录的获取 。
2. 消息路由-实时消息保存
在融云上 , 提供了消息路由服务 , 该服务的用途为将用户所发送的消息内容转发到一个指定的接口 。如果该接口没有正常的响应 , 则会再重新推送两次 , 如果依然失败则会将不会再进行消息的推送 。利用这个功能 , 我们可以对用户的消息进行实时保存 , 也可以用于与正在使用的第三方IM进行兼容使用 , 便于用户从其他第三方平台迁移到融云 。
3. 第三方平台迁移
【基于第三方融云的即时通讯--转载请注明出处】上图为融云官方所给出的迁移后的消息收发流程 , 在进行消息收发时 , 需要由我们自己的服务器 , 将每一条收到的融云消息转发到旧的第三方IM平台 , 同时将每一条旧的IM平台收到的消息转发到融云平台 , 这样就可以实现融云与旧的IM平台进行互通聊天 。
4.融云带来的问题
如果完全依托于融云进行对接 , 则会面临以下的问题:
对接IM会话的列表页无法进行UI层面以及数据的完全自定义:再融云的SDK中 , 对接的列表页将会由融云来提供 , 我们仅能做一些极少的UI改动 。因此我们无法过多的自定义融云会话列表的UI以及内容 。例如我们希望做一个招聘软件 , 此时 , 我们的会话对接页面 , 将无法在列表上直接提供所沟通的岗位 。离线消息仅保存七天:如果A用户向B用户发送消息 , 但是B用户7天中都处于离线状态 , 而B用户在七天后登录了APP , 重新处于上线状态 , 此时A向B发送的消息仅会保存七天就不再进行推送了 , 会造成A和B的消息不同步的问题 。即 , 如果一个用户出现了七天以上的离线 , 那么会丢失 上一次下线时间 ~ (当前时间-7天)的所有聊天信息 。历史聊天记录问题:历史聊天记录仅会保存6个月 , 如果想要查看更早的聊天记录 , 则会无法查看 。如果清空本地数据 , 则无法获取之前的聊天列表:对于某些特定的APP , 可能会出现数据清空后 , 无法重新发起会话的 , 或者查看历史消息记录的情况 。在对接列表中 , 不能穿插其他元素:在对接页面中 , 无法穿插推荐等信息 , 只能将这些信息放在某个特定的位置进行显示 。5.自定义的对接