技术详解:实现互动直播全过程

本文主要整理互动直播中各端的逻辑,重点是与前端相关的教师端IM的部分和Web/Wap学生端。希望通过这份整理,对于前端在维护时可以尽快的理解互动直播的流程,提高项目的可维护性;对于客户端和教师端来说,可以了解到前端提供的接口和消息的实现。也能提高对整个请麦过程的理解,便于联调和后期的定位问题。

相关阅读推荐

连麦互动直播方案全实践1:什么是连麦互动直播?

连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程

连麦互动直播方案全实践3:网易云信连麦互动的实现方案

概    况

互动直播涉及到服务端,教师客户端,iOS/Android学生端,Web/Wap学生端。本文重点介绍的是请麦的交互流程,前端请麦模块的设计,前端互动和聊天组件的设计。对于聊天室本身的聊天功能的实现,因为接入云信IM SDK,主要是通过Api调用封装实现的,就不细说了。

在设计系统之前,首先需要考虑以下几个问题:

•     各端的需求定义以及功能划分,各端如何交互

•     各端之间的协议

•     客户端请麦与教师端接收

•     客户端进入互动直播房间后互动信息的同步

带着以上几个问题,我们先整理一下可以依赖的的服务,通过网易云提供的以下服务如下图所示,结合自有系统的需求设计,让我们能迅速集成IM和互动直播的功能。

•     云信IM服务提供了一整套即时通讯基础能力,可以将即时通讯、实时网络能力快速集成至企业自身应用中。

•     云信的互动直播功能,支持主播和观众实时连麦互动。

架    构

我们的基本需求主要是以下三部分:

1.    学生在App客户端进入聊天室,可以发起请麦;

2.    在教师端可以对学生的请麦进行同意或拒绝的处理;

3.    在教师同意某位学生的请麦后,这位学生可以进入直播间进行互动。

结合需求整理出以下的基本请麦,连麦,互动的流程, 如下图,不同样式的数据流向代表不同的协议。

这里有几个概念补充介绍一下:

1、客户端云信IM的SDK,客户端通过云信IM发送P2P消息到教师端

2、客户端互动直播SDK,客户端接入互动直播

3、教师端云信SDK,接受p2p消息

4、教师端互动直播SDK,与客户端直播互动

5、Web端云信IM的SDK,发送接收消息

6、自定义消息,各端发送信息的数据结构

设计与实现

实现这节主要介绍上一节概述中提到的教师客户端 ,Web/Wap学生端的实现。主要包括以下几部分:流程细化、教师IM模块、Web学生端模块、配置、优势、存在的问题。

流程细化      

先来介绍一下教师端的实现,按照下图中的标号顺序,对其中的一些细节做补充说明。教师端主要有两部分,一部分是native,本文中称为教师端native,另一部分是Web页面,本文中称为教师IM。教师端native和教师IM通过jsbridge以及自定义消息进行通信。

首先,整理一下教师端native与教师IM通信的jsbridge如下:

- notifyQueueChange

- notifyVolume

- notifyCustomMsg

- checkUpdate

- notifyLiveStatus

结合以上的流程图,再对流程进行一下细化说明:

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模块

结合流程图以及上面的流程细化说明,对前端的模块进行设计和拆分,如下图。

这里的LivePcChat是Tab中的聊天组件,LiveInteractivePresenter是处理互动操作的组件,XXcache是封装对应数据层操作的组件。具体的组件实例,调用,数据请求和处理的过程,如下图所示的时序图:

Web学生端模块

对于Web/Wap学生端,因为Web/Wap学生端本身还未开发请麦的功能。这里以Web学生端为例介绍一下Web/Wap学生端在互动列表和聊天互动中的实现。本身聊天室部分与教师端的聊天室是复用聊天组件的,因而这里也先把模块划分一下。可以参考教师端的组件划分,对比一下教师端和学生端复用的部分组件,下图是web学生端的组件拆分。

从下表的对比可以看到,除了请麦相关的处理逻辑,教师端IM和Web学生端在IM的其他功能是可以复用的。

配置

互动直播是在原来的直播基础上做的迭代,所以这里要保证互动直播在教育各产品线的可配置性。这里所说的配置与教育公共组件池其他的模块和组件接入的配置类似,也是依赖于教育通用组件cache-base,通过在直播页面或者工程单页加载时(机构后台),读取config中的配置,一键配置。

优劣分析

采用这套设计的优点是

1、所有的服务端请求都是通过web页面发送,减少教师端维护的成本;

2、模块的可配置性,在不同的业务线,可以通过配置来决定是否接入互动直播;

3、组件颗粒化,在不同的模块中,教师端可以接入聊天组件和互动组件,请麦组件,学生端可以只接入互动列表组件;

4、最大程度的依赖了现有的云信sdk实现的功能,能在较短的时间实现需求。

存在的问题

1、请麦的流程比较复杂,因为涉及到多端,各端调试比较浪费时间,这也是整理此文的目的。在打通对各端流程的认识后,各端在调试中都能首先定位到出问题的端,然后才能有的放矢的在某一个环节中发现问题。

2、因为是在原来的迭代基础上进行的,很多组件没有封装成教育规范的组件,不过逻辑清晰的前提下,可以在后面的迭代中优化掉。

3、优化前端实现的方法。

总    结

通过本文整理一下互动直播中各端的逻辑,便于后期接入对互动直播流程的理解。对客户端和教师端来说,可以了解到前端提供的接口和消息的实现。如果在后续另外的工程中,需要接入互动直播模块,能够快速的接入和调试,同时可以就以上提出来的存在的问题做进一步优化。

另外,想要获取更多产品干货、技术干货,记得关注网易云信博客

原文地址:https://www.cnblogs.com/wangyiyunxin/p/11122153.html

时间: 2024-10-25 16:19:31

技术详解:实现互动直播全过程的相关文章

「视频直播技术详解」系列之七:直播云 SDK 性能测试模型

?关于直播的技术文章不少,成体系的不多.我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面.深入地了解视频直播技术,更好地技术选型. 本系列文章大纲如下: (一)采集 (二)处理 (三)编码和封装 (四)推流和传输 (五)延迟优化 (六)现代播放器原理 (七)SDK 性能测试模型 本篇是<视频直播技术详解>系列的最后一篇直播云 SDK 性能测试模型,SDK 的性能对最终 App 的影响非常大.SDK 版本迭代快速,每次发布前都要进行系统的测试,测试要

CDN技术详解及实现原理

CDN技术详解 一本好的入门书是带你进入陌生领域的明灯,<CDN技术详解>绝对是带你进入CDN行业的那盏最亮的明灯.因此,虽然只是纯粹的重点抄录,我也要把<CDN技术详解>的精华放上网.公诸同好. 第一章    引言    “第一公里”是指万维网流量向用户传送的第一个出口,是网站服务器接入互联网的链路所能提供的带宽.这个带宽决定了一个 网站能为用户提供的访问速度和并发访问量.如果业务繁忙,用户的访问数越多,拥塞越严重,网站会在最需要向用户提供服务时失去用户.(还有“中间一公里” 和

Comet技术详解:基于HTTP长连接的Web端实时通信技术

前言 一般来说,Web端即时通讯技术因受限于浏览器的设计限制,一直以来实现起来并不容易,主流的Web端即时通讯方案大致有4种:传统Ajax短轮询.Comet技术.WebSocket技术.SSE(Server-sent Events). 关于这4种技术方式的优缺点,请参考<Web端即时通讯技术盘点:短轮询.Comet.Websocket.SSE>.本文将专门讲解Comet技术.(本文同步发布于:http://www.52im.net/thread-334-1-1.html) 学习交流 - 即时通

实现高性能纠删码引擎 | 纠删码技术详解(下)

作者介绍: 徐祥曦,七牛云工程师,独立开发了多套高性能纠删码/再生码编码引擎.柳青,华中科技大学博士,研究方向为基于纠删码的分布式存储系统. 前言: 在上篇<如何选择纠删码编码引擎>中,我们简单了解了 Reed-Solomon Codes(RS 码)的编/解码过程,以及编码引擎的评判标准.但并没有就具体实现进行展开,本篇作为<纠删码技术详解>的下篇,我们将主要探讨工程实现的问题. 这里先简单提炼一下实现高性能纠删码引擎的要点:首先,根据编码理论将矩阵以及有限域的运算工程化,接下来主

Linux磁盘阵列技术详解(二)--raid 1创建

我在Linux磁盘阵列技术详解(一)里已经详细介绍了几种RAID磁盘阵列方式,原理以及创建raid 0 的详细步骤.那么这篇文档就着重讲解如何创建raid 1的技术: 步骤如下: ① 分区 同样我们还是以一块硬盘的不同分区为例,实际工作中应该是不同的硬盘才对. 具体分区步骤不再赘述! 分区后结果如下图所示: ② 创建raid 1 mdadm -C -v /dev/md1 -l 1 -n 2 -x 1 /dev/sdc1 /dev/sdc2 /dev/sdc3 或者 mdadm -C -v /de

Protocol Buffer技术详解(语言规范)

Protocol Buffer技术详解(语言规范) 该系列Blog的内容主体主要源自于Protocol Buffer的官方文档,而代码示例则抽取于当前正在开发的一个公司内部项目的Demo.这样做的目的主要在于不仅可以保持Google文档的良好风格和系统性,同时再结合一些比较实用和通用的用例,这样就更加便于公司内部的培训,以及和广大网友的技术交流.需要说明的是,Blog的内容并非line by line的翻译,其中包含一些经验性总结,与此同时,对于一些不是非常常用的功能并未予以说明,有兴趣的开发者

红帽Linux故障定位技术详解与实例(2)

红帽Linux故障定位技术详解与实例(2) 2011-09-28 14:26 圈儿 BEAREYES.COM 我要评论(0) 字号:T | T 在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问,故障处理人员可通过console, ssh等方式登录到操作系统上,在shell上执行各种操作命令或测试程序的方式对故障环境进行观察,分析,测试,以定位出故障发生的原因. AD:2014WOT全球软件技术峰会北京站 课程视频发布 3.内核故障情形及处理 (1)内核panic panic是内

红帽Linux故障定位技术详解与实例(1)

红帽Linux故障定位技术详解与实例(1) 2011-09-28 14:26 圈儿 BEAREYES.COM 我要评论(0) 字号:T | T 在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问,故障处理人员可通过console, ssh等方式登录到操作系统上,在shell上执行各种操作命令或测试程序的方式对故障环境进行观察,分析,测试,以定位出故障发生的原因. AD:2014WOT全球软件技术峰会北京站 课程视频发布 红帽Linux故障定位技术详解与实例是本文要介绍的内容,主要

红帽Linux故障定位技术详解与实例(3)

红帽Linux故障定位技术详解与实例(3) 在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问,故障处理人员可通过console, ssh等方式登录到操作系统上,在shell上执行各种操作命令或测试程序的方式对故障环境进行观察,分析,测试,以定位出故障发生的原因. AD:2014WOT全球软件技术峰会北京站 课程视频发布 5.用kdump工具内核故障定位实例 A) 部署Kdump 部署 kdump 收集故障信息的步骤如下: (1)设置好相关的内核启动参数 在 /boot/grub

红帽Linux故障定位技术详解与实例(4)

红帽Linux故障定位技术详解与实例(4) 在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问,故障处理人员可通过console, ssh等方式登录到操作系统上,在shell上执行各种操作命令或测试程序的方式对故障环境进行观察,分析,测试,以定位出故障发生的原因. AD:2014WOT全球软件技术峰会北京站 课程视频发布 6.使用kprobe来观察内核函数的执行实例 kprobe是SystemTap对内核函数进行probing的功能在内核中的实现,由于内核中提供了正式的API来使