所在项目之前做过互动直播的需求, 在这里总结一下, 更多的是想整理一下互动直播中各端的逻辑, 重点是整理下跟前端相关的教师端 IM 的部分和 web/wap 学生端希望通过这份整理, 对于前端在维护时可以尽快的理解互动直播的流程, 提高项目的可维护性; 对于客户端和教师端来说, 可以了解到前端提供的接口和消息的实现也能提高对整个请麦过程的理解, 便于联调和后期的定位问题(云信的相关 SDK 下载: https://netease.im/im-sdk-demo)
概况
互动直播涉及到服务端, 教师客户端, iOS/android 学生端, web/wap 学生端本文重点介绍的是请麦的交互流程, 前端请麦模块的设计, 前端互动和聊天组件的设计对于聊天室本身的聊天功能的实现, 因为接入云信 IM SDK, 主要是通过 api 调用封装实现的, 就不细说了
在设计系统之前, 首先需要考虑以下几个问题:
各端的需求定义以及功能划分, 各端如何交互
各端之间的协议
客户端请麦与教师端接收
客户端进入互动直播房间后互动信息的同步
带着以上几个问题, 我们先整理一下可以依赖的的服务, 通过网易云提供的以下服务如图 1 所示, 结合自有系统的需求设计, 让我们能迅速集成 IM 和互动直播的功能
云信 IM 服务提供了一整套即时通讯基础能力, 可以将即时通讯实时网络能力快速集成至企业自身应用中
云信的互动直播功能, 支持主播和观众实时连麦互动
图 1
架构
我们的基本需求主要是以下三部分:
1. 学生在 app 客户端进入聊天室, 可以发起请麦;
2. 在教师端可以对学生的请麦进行同意或拒绝的处理;
3. 在教师同意某位学生的请麦后, 这位学生可以进入直播间进行互动
结合需求整理出以下的基本请麦, 连麦, 互动的流程, 如图 2, 不同样式的数据流向代表不同的协议
图 2
这里有几个概念补充介绍一下:
1 客户端云信 IM 的 sdk, 客户端通过云信 IM 发送 p2p 消息到教师端
2 客户端互动直播 sdk, 客户端接入互动直播
3 教师端云信 sdk, 接受 p2p 消息,
4 教师端互动直播 sdk, 与客户端直播互动
5web 端云信 IM 的 sdk, 发送接收消息
6 自定义消息, 各端发送信息的数据结构
设计与实现
实现这节主要介绍上一节概述中提到的教师客户端 ,web/wap 学生端的实现主要包括以下几部分: 流程细化教师 IM 模块 web 学生端模块配置优势存在的问题
流程细化
先来介绍一下教师端的实现, 按照图 2 中的标号顺序, 对其中的一些细节做补充说明教师端主要有两部分, 一部分是 native, 本文中称为教师端 native, 另一部分是 web 页面, 本文中称为教师 IM 教师端 native 和教师 IM 通过 jsbridge 以及自定义消息进行通信
首先, 整理一下教师端 native 与教师 IM 通信的 jsbridge 如下:
- #NAME?
- #NAME?
- #NAME?
- #NAME?
- #NAME?
结合以上的流程图, 再对流程进行一下细化说明:
1 客户端初始化
各端通过请求服务端获取统一的聊天室地址
2 教师端初始化
教师 IM, 在初始化后, 通过服务端请求(getPresenterLiveInfo), 获取聊天室地址, 取得聊天室单例, 通知教师端 native 聊天室就绪, 获取互动直播数据
3 请麦的过程
客户端发送 p2p 消息到教师端 native, 教师端 native 通过 jsbridge, 调用教师 IM 的 notifyCustomMsg, 教师 IM 更新自身维护的请麦请求等待队列
教师 IM 点击同意或拒绝, 通过消息通知教师端 native, 教师端 native 通过 p2p 通知请麦的客户端
客户端通过互动直播 sdk, 连麦进入直播间, 通过互动直播 sdk 发送消息给教师端 native
教师端 native 调用 notifyQueueChange 方法, 更新教师 IM 中各列表
教师 IM, 异步请求 (informServer) 更新服务端上下麦队列, 发送自定义消息(im-sdk), 广播通知各客户端
教师 IM 模块
结合流程图以及上面的流程细化说明, 对前端的模块进行设计和拆分, 如图 3
图 3
这里的 LivePcChat 是 Tab 中的聊天组件, LiveInteractivePresenter 是处理互动操作的组件, XXcache 是封装对应数据层操作的组件具体的组件实例, 调用, 数据请求和处理的过程, 如图 4 所示的时序图:
图 4
web 学生端模块
对于 web/wap 学生端, 因为 web/wap 学生端本身还未开发请麦的功能这里以 web 学生端为例介绍一下 web/wap 学生端在互动列表和聊天互动中的实现本身聊天室部分与教师端的聊天室是复用聊天组件的, 因而这里也先把模块划分一下可以参考教师端的组件划分, 对比一下教师端和学生端复用的部分组件, 如图 5 是 web 学生端的组件拆分
图 5
从表 1 的对比可以看到, 除了请麦相关的处理逻辑, 教师端 IM 和 web 学生端在 IM 的其他功能是可以复用的
配置
互动直播是在原来的直播基础上做的迭代, 所以这里要保证互动直播在教育各产品线的可配置性这里所说的配置与教育公共组件池其他的模块和组件接入的配置类似, 也是依赖于教育通用组件 cache-base, 通过在直播页面或者工程单页加载时(机构后台), 读取 config 中的配置, 一键配置
优劣分析
采用这套设计的优点是
1 所有的服务端请求都是通过 web 页面发送, 减少教师端维护的成本;
2 模块的可配置性, 在不同的业务线, 可以通过配置来决定是否接入互动直播;
3 组件颗粒化, 在不同的模块中, 教师端可以接入聊天组件和互动组件, 请麦组件, 学生端可以只接入互动列表组件;
4 最大程度的依赖了现有的云信 sdk 实现的功能, 能在较短的时间实现需求
存在的问题
1 请麦的流程比较复杂, 因为涉及到多端, 各端调试比较浪费时间, 这也是整理此文的目的在打通对各端流程的认识后, 各端在调试中都能首先定位到出问题的端, 然后才能有的放矢的在某一个环节中发现问题
2 因为是在原来的迭代基础上进行的, 很多组件没有封装成教育规范的组件, 不过逻辑清晰的前提下, 可以在后面的迭代中优化掉
3 优化前端实现的方法
总结
通过本文整理一下互动直播中各端的逻辑, 便于后期接入对互动直播流程的理解对客户端和教师端来说, 可以了解到前端提供的接口和消息的实现如果在后续另外的工程中, 需要接入互动直播模块, 能够快速的接入和调试, 同时可以就以上提出来的存在的问题做进一步优化
来源: http://geek.csdn.net/news/detail/256996