Detailed technical: to achieve the whole process of interactive live

This paper finishing interactive live in logic on each side, the focus is associated with the front part of the Teacher IM and Web / Wap students end. We hope that through this order, can be understood as soon as possible to the front of a live interactive process during maintenance, improve the maintainability of the project; the client and teachers end, it can understand and implement the interface provided by the front end of the message. Also can improve the understanding of the whole process of your wheat to locate the problem late to reconcile.

 

Related reading recommendation

" Even Jimmy interactive live program full practice 1: What is even wheat interactive live? "

" Even Jimmy interactive live program full practice 2: the evolution of NetEase cloud letter Lianmai interactive live program "

" Even Jimmy interactive live program full practice 3: Netease cloud letter Lianmai interactive implementations "

 

 

Overview

Live interactive service related to the end, teachers client, iOS / Android student end, Web / Wap students end. This article focuses on the interaction process is to ask Jimmy, Jimmy please module design front-end design, front-end components interact and chat. Chat rooms for the chat function itself, since the access channel cloud IM SDK, mainly through the package to achieve Api calling, not elaborate.

Before designing the system, we first need to consider the following questions:

• each end of the division of functions and requirements definition, how they interact with each end

• Agreement between each end

• The client receives Please wheat and teachers

• After synchronization interactive information interactive live client enters the room

With a few more questions, we can rely on to sort out the service, the following services provided by NetEase cloud as shown below, with the needs of its own design of the system, so that we can quickly integrate IM and live interactive features.

• cloud letter IM service provides a set of basic instant messaging capability, it can instant messaging, real-time network capability to quickly integrate their own applications.

• cloud letter of interactive broadcast capabilities to support real-time anchor and even wheat audience interaction.

 

 

 

 

Architecture

Our basic demand is mainly the following three parts:

1. Students App client to enter the chat room, you can launch your wheat;

2. At the end the teacher can ask the students were wheat consent or refusal of treatment;

3. Please wheat agreed to a student in the teacher, the student can enter the studio to interact.

Combined with the needs sorting out the following basic Please wheat, even wheat, interactive processes, as shown below, the flow of data representative of different styles of different protocols.

 

 

 

Here are a few concepts complement introduction:

1, IM client of the SDK cloud letter, P2P client sends a message to the teacher through the cloud side channel IM

2, interactive live client SDK, clients access to interactive live

3, the teacher ends the SDK cloud letter, acceptance message p2p

4, teachers end interactive live SDK, live interaction with the client

5, Web IM cloud letter end of SDK, message transmission

6, a custom message, each end of the transmission data configuration information

      

Design and Implementation

This section describes how to achieve the realization of teachers clients on an overview mentioned, Web / student end of Wap. Includes the following sections: flowdown, teachers IM module, Web students end module configuration, advantages, problems.

 

Flowdown      

First to introduce teachers to achieve an end, in accordance with the order numbers in the figure below, some of the details of which do supplement. Tutor has two parts, part native, referred to herein as teachers end native, another part of the Web page is referred to herein as teachers IM. Tutor native and teachers communicate via IM jsbridge and custom message.

First, sort out jsbridge end native teachers and teacher IM communication as follows:

- notifyQueueChange 

- notifyVolume

- notifyCustomMsg

- checkUpdate

- notifyLiveStatus

Combination with the above flowchart, and then the flow proceeds to refine what described:

1, the client initialization

Each side gets a unified chat room address by requesting the server

2, teachers end initialization

Teachers IM, after initialization, the server requests (getPresenterLiveInfo), to obtain the chat room address, chat rooms made a single case, inform teachers end native chat room ready, get interactive live data.

3, please process wheat

• p2p client sends a message to the teacher-side native, native teachers end by jsbridge, calling the teacher IM notifyCustomMsg, IM teachers update their wheat maintenance please request queue.

• Click IM teachers approve or reject, message notification by the end native teachers, teachers end by native wheat P2P please notify clients

• clients through interactive live SDK, even the wheat into the studio, SDK to send a message through interactive live to the end native teachers

• Tutor native method call notifyQueueChange updated each teacher IM list

• Teachers IM, asynchronous requests (informServer) update the server down wheat queue, send a custom message (im-sdk), broadcast to inform the client.

 

Teachers IM module

And the flowchart described above refining process, the front end module and a split design, as shown below.

 

 

 

Tab LivePcChat here is the chat component, LiveInteractivePresenter interactive component of a processing operation, XXcache corresponding data is encapsulation layer assembly operations. Specific examples of the component, called a data processing request and processes, as the timing chart shown in FIG:

 

 

 

Web students end module

For Web / Wap student end, because Web / Wap students end in itself untapped Please wheat function. Here to tell us about the Web as an example of students end achieve Web / Wap students end in interactive lists and chat interaction. Chat portion itself and the teacher ends the chat room to chat component is multiplexed, and therefore here divided at first module. Can refer to components into teacher terminal, compare the end portion of the assembly of teachers and students of the multiplexer, the figure is split web assembly Student side.

 

 

Contrast can be seen from the table below, in addition to your wheat-related processing logic, teachers, students end end IM and Web IM in other functions that can be multiplexed.

 

 

 

Configuration

Interactive live broadcast is done on the basis of the original iteration, so here live interactive education to ensure that each product line configurability. Similar public education mentioned configuration and other components pool and component configuration module access, and also depends on the general education component cache-base, when the live page or by engineering a single page load (backstage), read the config configuration, a key configuration.

 

Analysis of the pros and cons

The advantage of using this design is

1, all server requests are sent via web pages, reducing the cost of teacher-side maintenance;

2, the module can be disposed of in a different line of business may decide whether to access interactive live configure;

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

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

 

存在的问题

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

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

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

 

总    结

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

 

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

Guess you like

Origin www.cnblogs.com/wangyiyunxin/p/11122153.html