介绍
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发送响应，通知响应到达；
Ws：
模块对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版本。
