介绍

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版本。