介绍
OpenIM 开发团队破费了 2 个月工夫，加班加点对代码进行了部分重构，优化代码构造，标准代码开发流程，为社区将来深度参加开发打好根底。因为改变较大，波及大量的测试工作，并且还有打包 公布 等一些琐碎的事件，导致公布延期了十天，在此略表歉意。后续会建设绝对残缺的开发和公布打算，也邀请各位社区同学参加 OpenIM 的建设工作。有志于参加 OpenIM 建设的同学，能够与我私聊，介绍零碎架构，并探讨社区开发流程和标准。
因为波及到数据库字段变动，下载前要先删除 app 把历史数据全副清理洁净
web 端体验地址：
http://121.37.25.71:23232/
pc 端下载：
https://pan.baidu.com/s/16MW3… 明码: 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/#/l…
账号 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/…
有劳敌人们 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/…
服务端和 SDK 要放弃大版本统一，即版本号的第一位数字统一。OpenIM 团队不再反对 v1.0 版本，请大家更新到 v2.0 版本。