基于声网SDK的双师授课系统开发

"领导，现在您看到的就是使用了声网SDK达到的效果，目前是1080p 60帧，16路视频，cpu占用不到30%。"

“效果不错么，有种身临其境的感觉。”领导满意的点了点了头。

“达到这个效果，还挺不容易的。”

“不会吧，SDK不是现成的么，集成进去不就可以了？”领导睁大他的小眼睛看着我，眉宇间透漏着不相信。

“SDK是现成的，但声网没有现成的解决方案，因为我们的业务比较特殊，听我给您慢慢道来......”

 

"keiler，今天你第一天入职，我先给你讲下我们的业务场景，我们主要的业务是双师课堂。所谓双师是当前K12领域一种新的教学模式。每堂课采取主讲与辅师相互配合的方式完成。其中，主讲教师主要通过视频直播的形式讲解课程内容，辅老师在课上负责与主讲老师配合开展教学及互动，记录学生课堂表现，并维持课堂秩序，在课后负责答疑、批改作业及与家长沟通等服务工作。学生仍需到教室观看视频上课，课上通过平板等设备与主讲老师进行答题互动，听懂了么？“

“没听懂。”我自信的回答道。

“我给你画张图。”领导无奈的拿起了笔。

 

 

“主讲老师在北京的专业演播室进行授课，通过实时音视频技术将音频及视频传输到外地的教室。外地教室的学生通过位于前方的大屏幕电视进行观看，同时有一个辅师在现场配合主师，主要是维持秩序，辅导学生。 实时音视频不同于直播，一般都是毫秒级延时，所以主讲老师在和学生互动时，不存在沟通障碍，这种模式解决了资源分配不均匀的问题。同时也降低教育机构的师资成本，一般三线及以下地区很难聘请到优质的师资。使用一线城市的优质教师资源，可以提高教学质量。但它也有自身的局限性，比如：线上课程场景单一，互动缺乏；主讲老师端对学生不熟悉，学情难掌握，无法及时抓住学生兴趣点等问题往往会造成学生“被动”听课，缺少参与感。这回明白了么？”

“好像明白了一些。” 我单手拖着下巴回答，同时陷入了深深思考。

“这其中用到的技术，就是实时音视频传输。我们目前采用的是一套国外的视频会议系统，下面我们要利用声网来搭建一套更贴合我们业务场景的系统。那么你接下来的任务就是了解下声网的SDK，熟悉api，熟悉demo。知道自己干啥了吧，我还有个会。”领导默默转身离开，留下我一个人静静发呆。

 

"帧率、分辨率、码率、直播、RTC 这都什么鬼？"看了一遍文档和api，我发出了这样的感慨。之后我决定换种思路，任何知识点的外围都存在一个整体的框架，当学习一个新的知识的时候，先从框架入手，然后再去填充细节，这是多年的工作经验积累下来的认知。于是我开始在互联网搜索关于实时音视频相关的知识，开始还是看不懂，但是当量积累到了一定程度之后，按照哲学理论，一定会引起质变，于是乎在一个阳光明媚的下午，感觉灵光一闪，仿佛被什么东西击中了一样。我明白了那些复杂的概念，此时再去看声网的文档，就变得简单了，在此也希望声网的官网上能有些音视频基础知识的讲解，起到给一些小白用户一个引路的作用。那么如何使用声网SDK来完成我们的业务需求呢，其是很简单。

（1），所有主师端和辅师端都进入同一个频道，对应我们的场景就是同一堂课。类似视频会议系统一样，所有人进入了同一个会议，大家相互可看见，可听见。

（2），根据业务需求，辅师端只需要接受主师的音视频即可，无需看其他辅师端，所以需要将其他的音视频流禁用。而主师需要接受所有的音视频流。

（3），主师利用手中的ipad，采用IM消息推送的方式，对所有的终端进行信令控制，而这也是声网建议的做法。

大的方向知道了之后，接下来投入开发么？当然没那么简单。我们的业务场景对性能有要求，主师端需要采集1080p 60帧。这个指标在业内并不常见，而这也是我们的优势，如果达不到这个指标那投入 开发就是浪费公司资源，所以需要先确定性能是否达到满足，这样才能最小程序减少风险。在声网官网找到了他们提供的demo，不得不夸奖一下，demo的类型和平台还是很丰富的。与我们最相符的openLive，找了能采集60帧的相机和配置不错的电脑，输入频道号，等待奇迹发生。但奇迹好像不那么容易出现，领导过来只瞧了一眼，就告诉我帧率不到60。我看了一下声网后台的统计数据，果然只有50帧左右。都说领导的视角不一样，这么一看真的不一般。找了声网的售前技术支持，一番沟通后，对方说我方网络环境不可以。领导听后大发雷霆，因为我们现在使用的软件并没有网络而产生问题，并且我们这是专线。结果又是一番沟通，测试最后还是达不到要求，无奈声网售前只能亲自跑一趟。在售前到达了之后又是一番测试，排查。后来在使用了硬件编码之后终于达到了稳定的60帧。强烈建议声网对于不同的性能要求出一套实测的硬件标准，什么的网络，什么样的cpu或者显卡 才能符合这个标准。一切准备就绪，貌似可以大干一场了，但是突然间，疫情来了。悄无声息但浩浩荡荡。

 

万众一心，众志成城，国家忙着抗击疫情，公司忙着转到线上，所有线下教室全部停掉。为此研发春节期间加了近半个月的班，每天直到凌晨，到现在加班的工资还没有发放，疫情带每个人的伤痛都是不可弥补的。时间进入5月，疫情缓和，各行业开始复工复产，疫情就像一个淘气的孩子，跑来折腾一圈，然后又走掉了，跟当前它哥哥----非典性格一样。项目重新开始上马，一切照旧。 不过这次我决定将UI框架进行更换，因为基于C++语言， 在开发客户端方面，有一套叫做Quick的界面框架，开发效率高并且美观，所以我决定将框架更改，做的更炫一些，但就是这个唐突的想法，让进度又耽误了一周。

 

时间在指尖飞快的流逝，代码也一行一行写下。一周时间，产品出炉，看着漂亮的界面，满意的点了点头。因为它确实挺好看的。

 

 

领导了看也表示满意，然后随口一问：“帧率怎么样，稳不稳？”

“年前测试过了，没有问题！”我坚定的回答道。

可是结果出乎所有人意料，帧率确实稳定在60左右，但是出现了频繁的跳帧现象。这个是以前没有出现的。和声网的一番沟通之后，对方说我的渲染方式有问题，因为这次为了更换界面，我用了自渲染。自渲染无法达到我们的性能要求，需要更改为SDK渲染，就相当于一种方式是我自己绘制视频，一种是利用声网SDK绘制视频。这个结果令我沮丧，辛苦改过来的代码，难道还要改回去。我让领导去和声网沟通，表示更改方式，时间上太长，并且不利于后续扩展，希望对方解决自渲染的问题。领导听我一番讲解，觉得很有道理。于是去和声网沟通，为此对方特意派来了一个很牛的技术和一个很美的商务。一番了解之后，表示我方要求合理，承诺回公司和研发沟通。一天之后，明确表示无法更改，技术上实现困难，建议更改为SDK渲染。听到这个消息，我脑海中想起了那首歌，“我想哭但是哭不出来。。。”

 

在牺牲了陪娃的时间，做美梦的时间之后，用了大概一周又改回到了原来的模式，但是主界面仍然保留了Qucik的框架，这样既美观也满足要求。我将软件按照了到了不同的电脑，开启自动测试，不听的进入和退出频道，本想冲杯咖啡，坐等结果。可是咖啡还没泡好，软件崩溃了。“我想哭但是哭不出来。。。。”，歌声再次响起。 我从头到尾排查了自己的代码，没发现任何问题， 无奈只好又找到了声网的技术支持，在对方的指导了我捕捉 到了崩溃的异常，发给声网的工程师，经过短暂的分析后，定位到了问题，此版本SDK有bug，我既欣慰又难过。欣慰的是球不在我这里，难过的事，时间又耽搁了。但出于意料，这次问题的解决比以往顺利，声网的研发人员，用了不到一周时间就将bug解决，经过我验证，性能满足要求，不再崩溃。后续反思，声网的技术没有问题，但是我方业务比较特殊，所以这个合作的过程一定不是一帆风顺的，需要双方相互理解，共同努力。就此，所以底层问题问题解决，客户端开发完毕，目前正在等待移动端开发介入。

 

 

“有点意思。”领导听完我漫长的讲述后，意味深长的点头说道。