- 有哪些痛点？
- 黑屏是如何发生的？
- 怎样监控黑屏发生？
- 怎么样解决黑屏？
- 链路追踪
- 架构升级之路
- 总结
有哪些痛点？
1、性能痛点，直播课偶现的黑屏、卡顿、WebSocket重连 & 疑难问题
排查起来非常困难，不能确定是声网的问题还是APP性能问题，影响用户体验。
2、没有清晰的架构，代码耦合度高，不利于扩展，不利于敏捷迭代和产品需求延伸拓展。
有了痛点，我们需要调研下这些痛点都是咋造成的？
痛点这么多，我们怎么入手呢？
设定一个主目标（黑屏），把其他痛点当做阶段节点，顺带一起解决了。
下面我们主攻黑屏，其他的卡顿、重连其实都可以用同样的套路。
黑屏是如何发生的？
想要知道黑屏是如何发生的？
0）我们首先得明确什么是黑屏?
1）课堂如何直播？
2）学生端和教师端如何建立起联系？又是如何进行音视频传输的?
0）黑屏
Q:黑屏是啥？
R:直播画面变黑我们称之为黑屏。
比如在直播的过程中，学生端老师的画面变黑了，老师端学生的画面变黑了，课堂黑板变黑了...
Q:为啥会黑屏？
R：造成黑屏主要有三个方面的原因
0）网络传输丢帧导致GOP的帧没了，出现短暂或者长时间的黑屏。
1）教师端出现问题，流采集失败，可能是机型兼容、部分机型权限问题，渲染卡顿。
2）学生端出现问题，视频流播放失败，可能是机型兼容、性能卡顿、
播放器问题、x5内核浏览器问题
Q:如何解决黑屏？
关键点位监控，找出问题所在，优化,那么那些是关键点位呢？
Q:推拉流的过程基本都是声网在完成，而声网对我们来说是一个黑盒;
我们无法确定是不是声网出现问题了，只能在后台水晶球查看通话质量，
那么客户端可以做什么来发现可能出现的黑屏或者性能问题呢？
下面我们需要做个调研，明确课堂是怎么直播的？以及推拉流的过程。
1） 课堂如何直播？
0）cms排课
1）教师端 & 学生端进声网的channel，建立音视频通讯通道。
2）教师端推流 / 学生端拉流
3）声网Channel 进入成功之后，客户端（教师端&学生端）建立Socket通道。
2）推拉流过程
0Eltron音视频采集接口：Eltron采集音视频
1音视频采集：声网SDK通过调用Eltron音视频采集，进行音视频采集
2编码：声网SDK进行编码
3Buffer:编码后写入buffer，做传输准备。
4传输策略：声网SDK根据教师端网络情况对Buffer做帧率处理&码率处理，然后上传。
5声网:教师端的教师头像视频流会传输两个流。
大视频流&小视频流；大视频流分辨率会高些720*480，
小视频流分辨率会小些320*240，帧率都是15。
6拉取策略:声网SDK根据学生端网络情况，做拉取策略，拉取大视频流还是小视频流。
7Buffer:写入buffer
8解码
9Surface:渲染到界面。
ps:课件共享流分辨率1000*600，帧率7
怎样监控黑屏发生？
Q:学生端 & 教师端如何发现黑屏？
R:从上面的推拉流过程可以发现两个红色的块就是我们需要管控的；
学生端管控的就只有Surface，其他的都是由声网来完成的
，那么我们只要管控好Surface，理论上就可以管控好学生端的黑屏、卡顿等问题；
而教师端则需要管控好Eletron的音视频采集，据我所知Eletron去调用音视频采集或者读取本地文件，有一些版本兼容性问题。
Q:怎样管控学生端的Surface？
R:管控影响Surface的操作行为，这些行为有哪些呢？
1）进房上课，挂载Surface，如果这时候Surface出现问题，就有可能有问题，比如初始化等等呀。
2）学生上台，黑板创建Surface，而原先的学生头像区域的Surface并没有释放掉，此时存在两个Surface。
3）还有其他一些什么ppt播放等等一些行为。
通过什么方法可以管控这些操作行为呢？
链路追踪
Q:啥是链路追踪？
R:在课堂对老师端&学生端的关键点位做日志记录，比如进入课堂、下载课件、上台、共享黑板、ppt翻页、SIO重连、静音、下线学生、学生重进入课堂、下课等等操作行为。
记录到本地，然后在合适的时机触发上传日志。
合适的时机可能是下课了，
或者下一次重新进入课堂了，
或者触发了我们认定的异常条件了，比如频繁多次重进课堂这个肯定是有问题。
Q:链路追踪可以做什么？
R：
0）一是可以帮助产品做数据分析，知道老师和学生在课堂都干了些啥，那些可能是他们用得比较频繁的
1）另一个是可以帮助研发定位问题，比如有用户反馈说，哪个房间老师又遇到黑屏了，
这时候我们可以根据链路去分析课堂里发生了啥？是不是那个操作路径有问题，SIO消息服务端发了。
客户端没有收到呀。还是说客户端的那个操作行为耗时过长，导致app没有响应或者卡顿发生了呀。
Q:怎么做到链路追踪？
R：
1）明确关键点位 -产品同学配合梳理出服务端&教师端&学生端关键点位，最好形成图稿
2）解耦代码，分离出关键点位 - 研发
架构升级之路
由最上面我们提出的痛点出发，我们只要主抓一个主目标（黑屏），顺带把其他痛点也解决了；
要做到链路追踪，我们客户端需要做架构升级。
0）先处理疑难问题，这里面包括Bugly的疑难问题处理 & Bugly日志完善；内存泄露处理；
疑难业务问题处理。
1)监控体系：检测体系，首先需要建立日志监控上报。监控系统的定位不单单是为链路追踪而生，
它还有一个更重要的使命，监测APP关键操作的性能；
性能监测，我选择了两个：
一个是dev环境下的Dokit便于我们在开发环境下发现性能问题，
尽可能防止问题上线上，方便测试同学做性能测试，
比如我们搞了一个大的功能块，这个时候需要去测试一下性能，Dokit就可以发挥作用了。
另一个是Aspectj主要用于线上检测，
可用于链路追踪和APP关键点位的性能监测，便于我们及时预警。
2）模块化，把架构雏形搭建起来，因为这里可能业务耦合还比较深，
贸然进行组件化会有大坑,不可控。
完成模块化有三个步骤，Base建立 & 模块化声网 & 重构直播课。
Base构建：主要有包括一些基础能力-网络、SIO、Crash、友盟。
[模块化-网络Done](https://juejin.cn/post/6844904169346711559)
模块化声网：主要是解耦直播课中声网的深度耦合，为下一步重构直播课做准备，
也提供另一个能力支持接入其他第三方的SDK。
重构直播课：
0:APP最核心的就是课堂了，很多疑难问题其实都是从这里发生的，
清晰的架构和业务逻辑非常有利于问题的排查和预防bug的产生。
1:主要是为链路追踪做最后的准备，直播课堂耦合度还比较深。
2:结构不是特别清晰，链路的关键点位没有抽象出来。
3:面业务端的同学也可以参与进来设计，也是一个很不错的组内提升和交流。
4:后面课堂也可以组件化，便于后面实现热更新；有些边际功能我们还可以插件化，减少包体积。
3）组件化：最后一步，真正的实现模块解耦，实现功能的拔插；
这里面还有代码隔离、资源隔离、开发规范...也是一个大project...
总结
至此我们的痛点问题大致解决了,总结下我们在解决黑屏这个目标的路上，捎上了哪些改进措施
0）解决黑屏、卡顿、重连
1）日志能力，直播课链路追踪 & 整个APP关键点位追踪& 后期重要功能链路追踪。
2）支持除声网外的第三方SDK接入。
3）重构直播课，更加便捷的拓展。
4）直播课性能检测 & 整个APP性能监控 Dokit & Aspectj
5）模块化
6）组件化
