OpenIM开发团队花费了2个月时间，加班加点对代码进行了局部重构，优化代码结构，规范代码开发流程，为社区未来深度参与开发打好基础。由于改动较大，涉及大量的测试工作，并且还有打包 发布 等一些琐碎的事情，导致发布延期了十天，在此略表歉意。后续会建立相对完整的开发和发布计划，也邀请各位社区同学参与OpenIM的建设工作。有志于参与OpenIM建设的同学，可以与我私聊，介绍系统架构，并探讨社区开发流程和规范。

由于涉及到数据库字段变化，下载前要先删除app把历史数据全部清理干净

web端体验地址：

http://121.37.25.71:23232/

pc端下载：

https://pan.baidu.com/s/16MW36rKVFtDCBewMOdD0pA 密码: jd15

安卓下载：

https://www.pgyer.com/OpenIM

iOS下载：审核中 稍后更新

新版本有哪些更新

客户端SDK架构重构

WsConn：

ws连接管理器。提供函数供其他方调用，具体包括：

（1）ws连接服务端，和OpenIM服务端保持长连接；

（2）关闭ws连接；

（3）通过ws发送请求；

WsRespAsyn：

ws请求-响应同步器，因为ws是异步处理，需要把请求和响应关联起来，提供函数供其他方调用（消息发送，心跳发送，拉取历史消息等）

（1）getCh：为每个请求生成一个channel和msgIncr，使用map关联起来 msgIncr->channel

（2）notifyResp：对于ws收到的每个响应，通过msgIncr找到channel，并往channel发送响应，通知响应到达；

模块对WsConn 和 WsRespAsyn功能进行整合（1）请求响应同步化，提供函数SendReqWaitResp，调用者通过ws发送请求后，等待此请求的响应达到。（2）对于接收到的推送消息，把消息写入PushMsgAndMaxSeqCh channel，触发MsgSync消息同步协程。

具体实现：ReadData协程：接收服务端ws数据，并根据收到的数据类型（心跳、推送、踢出登录、拉取历史消息等），触发不同的逻辑处理，（1）对于主动发送请求的响应，则调用WsRespAsyn的notifyResp响应触发接口；（2）对于push消息，写入PushMsgAndMaxSeqCh ，触发MsgSync消息同步协程。

MsgSync：

消息同步器；包含Ws 和conversationCh 、 PushMsgAndMaxSeqCh ，启动消息同步协程，对PushMsgAndMaxSeqCh 中的读取的数据做处理，具体包括：

（1）从PushMsgAndMaxSeqCh 读取服务端最大seq:SvrMaxSeq（由heartbeat写入的），对比本地最大seq：LocalMaxSeq和服务端最大seq: SvrMaxSeq，计算出缺失的seq，从服务器拉取历史消息，放入conversationCh ，触发conversation协程处理；

（2）从PushMsgAndMaxSeqCh 读取ws推送消息（由Ws的ReadData写入的推送消息），如果消息中的seq+1==LocalMaxSeq，则写入conversationCh，触发conversation处理，否则从服务端拉取消息补齐[LocalMaxSeq+1, seq]，放入conversationCh ，触发conversation协程处理；

heartbeat：

心跳管理器，包括MsgSync

（1）心跳协程，从服务端定时获取最大seq:SvrMaxSeq，然后把SvrMaxSeq让入PushMsgAndMaxSeqCh ，触发MsgSync消息同步协程。

管理后台第一版发布

管理后台第一版体验地址：

http://121.37.25.71:22331/#/login

账号openIM123456

密码openIM1 db字段调整

好友申请表老版本 好友申请表新版本

以好友申请表为例，（1）统一并规范字段命名；（2）增加更多字段，可以实现更多的业务场景，同时增加扩展字段。

同样其他表都全部进行了规范：用户表，好友关系表，，群组表，群成员表，群申请表，黑名单表等

通知机制完善

通知机制完善，可以实现多端同步，实时更新本端以及其他端的本地db。比如移动端设置好友备注，会实时同步到pc端，同样pc端设置完好友备注，会实时同步到移动端，并更新本地db。具体实时同步通知包括：从用户资料修改，到关系链建立，到群组的全方位通知机制。

////////////////////////////////////////// NotificationBegin = 1000 FriendNotificationBegin = 1200

FriendApplicationApprovedNotification = 1201 FriendApplicationRejectedNotification = 1202 FriendApplicationNotification = 1203 FriendAddedNotification = 1204 FriendDeletedNotification = 1205 FriendRemarkSetNotification = 1206 BlackAddedNotification = 1207 BlackDeletedNotification = 1208 FriendNotificationEnd = 1299 ConversationOptChangeNotification = 1300

UserNotificationBegin = 1301 UserInfoUpdatedNotification = 1303 ConversationNotification = 1307 ConversationNotNotification = 1308 UserNotificationEnd = 1399

GroupNotificationBegin = 1500

GroupCreatedNotification = 1501 GroupInfoSetNotification = 1502 JoinGroupApplicationNotification = 1503 MemberQuitNotification = 1504 GroupApplicationAcceptedNotification = 1505 GroupApplicationRejectedNotification = 1506 GroupOwnerTransferredNotification = 1507 MemberKickedNotification = 1508 MemberInvitedNotification = 1509 MemberEnterNotification = 1510 GroupNotificationEnd = 1599 NotificationEnd = 2000

//////////////////////////////////////// 开发流程规范

IM能力从客户端sdk->api->rpc，每层都有自身的协议，协议文档通过包集中管理，方便文档生成。比如在sdk层有sdk_params_callback

在api层有server_api_params

在rpc层有proto

离线推送配置化

在sdk发送消息函数中提供单条消息的离线推送的配置能力

SendMessage(callback open_im_sdk_callback.SendMsgCallBack, message, recvID, groupID string, offlinePushInfo string, operationID string) offlinePushInfo是个json string，他是title, desc, ex三元组，开发者可以自行设置具体内容。目前采用极光推送，需要开发者在极光申请相关key，并在后台配置。

MinIO支持

服务端配置项如下

bucket: openim location: us-east-1 endpoint: http://127.0.0.1:9000 accessKeyID: minioadmin secretAccessKey: minioadmin 客户端sdk在初始化时需要传入相关参数"object_storage":"minio"

InitSDK(listener open_im_sdk_callback.ConnListener, operationID string, config string)

config是json字符串，格式为 { "platform":1, "api_addr":"http://127.0.0.1:10000", "ws_addr":"ws://127.0.0.1:17778", "data_dir":"./", "log_level":6, "object_storage":"minio" } 其他

还包括合并转发消息bug修复，seq拉取机制完善，发送中、发送失败状态对齐，退出登录状态清理，会话及消息的容错能力等等。

下一步计划

（1）社区开发规范发布，社区开发者能深度参与OpenIM开发，从新业务开发、bug修复，到架构优化等全方位介入，共同提高OpenIM的稳定性、性能，把OpenIM打造成IM开源社区的领跑者。

（2）第三方callback机制完善，从功能角度来看，回调可以分为四大类：

用户在线状态变化回调

好友关系链变化回调

单聊消息回调

群组变化系统回调

从处理角度来看，回调可以分为以下两大类：

事件发生之前回调：回调的主要目的在于让 App 业务后台可以干预该事件的处理逻辑，OpenIM Server 会根据回调返回码确定后续处理流程（例如发送群消息之前回调）。

事件发生之后通知：回调的主要目的在于让 App 业务后台实现必要的数据同步。

官方文档：https://doc.rentsoft.cn/

github地址：https://github.com/OpenIMSDK/Open-IM-Server

有劳朋友们github点一下 star，一个小小的 star 是作者们前进的动力，也是我们力争开源IM项目No1的基石。

OpenIM不是个人兼职项目， 是商业化全职团队运作，大家可以放心使用，SDK和Server都可免费试用，无需授权。项目star增长迅速，达到6.5k，微信群开发者4000人。

商业版本是OpenIM技术团队在100%开源的OpenIM服务端和IMSDK基础上，开发的功能完整的、带有UI界面的IM产品。可以直接部署运营，也可以在此基础上二次开发。商业版本已经开源，需要商业授权，请遵守开源协议。

docker已更新，请拉取最新镜像，docker部署常见问题总结分析和解决办法 见文档：https://doc.rentsoft.cn/demo/server_deploy/docker_singe.html

服务端和SDK要保持大版本一致，即版本号的第一位数字一致。OpenIM团队不再支持v1.0版本，请大家更新到v2.0版本。

有疑问加站长微信联系（非本文作者））