环信sdk就的基础架构体系.pptxVIP

环信SDK的基础架构体系 zhaoliang@ 主要内容 IM SDK基本要素 IM SDK 架构 开发IM SDK的挑战与应对 IM SDK的基本要素 连接管理 消息 会话 好友管理 通知 实时音视频 扩展 长连接与短连接 SDK IM Server HTTP Server 心跳 消息 消息 上传 长连接 TCP 连接 及时收到服务器的推送 占用服务器大量资源 短连接 HTTP 连接 前端发起HTTP请求，通常情况下每次请求都会创建个新连接(设置keep-alive除外)，每次返回数据后server就会关闭连接 服务器不会特殊管理连接，减轻服务器负担 心跳保活 定时通知服务器连接存在 服务器设定TCP keep-alive time 过期没有收到数据启动探针 多次探测没有收到前端响应，关掉相应连接 即时刷新路由器NAT（ Network Address Translation）内外网IP映射表 只保存最新连接 老连接会被移除 连接DNS配置 防止DNS劫持 获取DNS配置列表 不同的APP会对应不同的Server IP 重连 重连原因 主动断网，切网 服务器主动断开连接(connection reset by peer) 路由器外网断开 永远重连 New thread.start - wait(random(time)) while(true and not coneccted){ reconnect() wait(random(time)) } 始终保持同一个连接实例 避免自踢 消息 消息 ID Global Unique ID 消息类型 收发方ID To, From Bind Resource Mobile PC 消息body ID from to body Bind type message id=“0123456789” To=uni3 From=un8/mobile type=chat body {from:uni8,to:uni3,bodies:[{type:txt,msg:测试}],ext:{}} /body /message 支持多种聊天模型 单聊 群组模型 聊天室模型 支持多种消息类型 Text, Image, Video File 透传消息 支持扩展消息 消息发送与回执 离线消息 离线消息 对方不在线，没有相应的session 服务器没有收到收方的回执 消息体内含离线标识 获取方式 服务器推大量离线导致效率低下 送(push) 试想如果推送2000条离线？ 客户端拉取(pull) 根据消息ID获取 逐页去获取 附件消息 图片，语音，视频，文件，等类型的消息统一为附件消息 如何发送 方案一 直接走长连接 方案二 先上传附件到服务器 获取附件UID 再把载有UID的IM消息 IM Server 收方读取消息，根据UID下载附件到本地 大小限制 附件消息 会话管理 消息管理 消息查询，删除，插入 批量消息加载 批量消息导入 消息发送 已读标记 好友管理 添加好友 删除好友 黑名单管理 群组管理 添加好友 通知 事件通知 新消息，已读，已送达通知 API 回调 加减联系人，群组，聊天室相关通知 SDK只负责消息通知 SDK不负责铃声，震动，提醒等定制化模块 实时音视频 支持实时音视频 使用Jingle XMPP扩展协议作为控制信令 使用ICE作为P2P打洞协议 支持媒体relay中继功能 多人语音功能 内部测试中 支持扩展 消息的扩展 通过扩展属性 会话的扩展 通过扩展字段 其他扩展，如安全性 通过插件扩展 总体设计 模块的划分 平台层会根据各平台的不同，实现不同的接口，开放符合平台层的API给第三方开发者。  适配层主要要适配到ONE SDK 核心层所需要的一些接口，起到承上启下的作用。  核心层主要提供IM 功能和业务逻辑，保证最大化的代码重用 App vs SDK 共同点： 易用性，稳定性，可扩展等 用户 vs 开发者 单一平台 vs 多平台 功能多vs 接口少（Rich features vs Less APIs） 可裁剪性 对待错误的使用: 忽略 vs 提示 测试出发点： 模拟用户 vs 模拟程序员？ 安全性 Not as general single function SDK such as voice recognition, map , etc Less API Façade Pattern Private class data 裁剪性 用户需求不同，可以选择配置不同的功能 基础功能 + 群组功能 + 实时音视频 安全性 插件式设计 用户可以提供自己的加密方式 日志 日志开关 日志级别 日志内容 测试 单元测试 - Unit Test API Test Develop