蘑菇街直播架构分析

摘要：     直播简介 直播最主要的特色就是实时性与互动性，这也是直播与点播之间的差异所在，它能够实时将主播端的视频信息以较低延迟传输到观众端，与此同时，观众能够经过群聊或者送礼物的方式与主播进行互动。 图 1 直播主要由如下几个环节所组成（图 1） 1.

直播简介

直播最主要的特色就是实时性与互动性，这也是直播与点播之间的差异所在，它能够实时将主播端的视频信息以较低延迟传输到观众端，与此同时，观众能够经过群聊或者送礼物的方式与主播进行互动。

图 1

直播主要由如下几个环节所组成（图 1）

1. 主播端采集

2. 处理：美颜、水印，基于人脸识别的动态贴纸；

3. 编码：视频主要是基于 H264 的编码格式；

4. 推流：使用 RTP 的实时传输协议，如 RTSP、RTMP、HLS；

5. 网络传输：使用 CDN 服务厂商的服务；

6. 拉流：须要服务端处理转码，支持多分辨率，支持 RTP 实时传输协议；

7. 解码：可使用硬件或者软件解码；

8. 播放。

以上主要环节绝大部分由云服务解决。蘑菇街直播目前在前处理中加入了蘑菇街自研的基于人脸识别的动态贴纸功能。前处理和播放都是使用强大的开源库 GPUImage。

移动端直播形态

直播形态及框架组成

目前移动端直播形态大致分为如下几种：全民直播、社交直播、电商直播和手游直播。蘑菇街的直播，主要以电商为主。下面主要介绍蘑菇街直播的组成。

图 2

图 2 是蘑菇街直播的大体组成，包含三大模块，分别是媒体模块、服务模块和管理模块。

1）媒体模块

由直播和直播回放组成。直播回放的目的有两个，一是在直播过程当中，将平台上优质的内容沉淀下来，其次是能够在直播较少的时间段提供直播回放，增长内容的广度。

2）服务模块

也称为业务模块，其中包括电商、支付、聊天、礼物、运营、抽奖、安全以及统计系统；

图 3

其中，电商系统（图 3）是蘑菇街本身加入的一个特有的系统，主要是让卖家在直播过程当中，能够上架商品发放优惠券，主打商品通道，以后观众就能够在观众端进行商品浏览、加购、下单、购买以及领取优惠券这些行为。观众端的大小窗自由切换，为观众提供了更加便捷的消费模式，能够无缝地进行观看和购买，这个模块无论是从产品层面仍是技术层面都算是作的比较成功的。统计数据显示，大部分直播间的成交场景，都来源于从直播间切换到详情页时所产生的下单购买行为。

3）管理模块

管理模块主要用于后台管理。

图 4

蘑菇街的直播的页面主要分为主播端和观众端两部分；图 4 为蘑菇街直播的主播端页面的综合展现。

图 5

图 5 为主播信息页面，页面下面为主推商品以及其价钱显示。

图 6

图 6 页面底部依次为人脸识别/贴纸、电商、切换分辨率、美颜这些功能模块。其中电商模块主要是主播用于设置商品展现这些功能；分辨率这块默认标清为 960P，能够切换为高清（1280P）/流畅（640P）。

图 7

图 7 为蘑菇街直播的观众端页面综合展现。

图 8

如图 8 所示，观众端和主播端最主要的区别是大小窗切换功能（页面底端从左向右数第二个模块），点开以后切换到小窗，小窗能够任意拖动。

图 9

电商模块点开以后（图 9）能够显示完整的商品信息(价格、名称、规格)，这里能够加入购物车或者当即购买；好比点击商品信息，就能够直接跳转到详情页进行小窗模式的播放，这个时候观众不只能够看到主播在介绍本身的商品，同时能够很清晰直观地经过图片，还有文字的形式，去察看这个商品的一些主要的功能介绍。这也就是为何在蘑菇街平台上，直播的大部分下单或者成交场景，都来源于详情页的缘由。

直播难题及优化实践

直播难题

蘑菇街在直播中所遇到的问题，主要为迭代、云服务、代码质量、稳定性以及性能这五点。

迭代主要遇到的问题是，前期需求调研不充分，从立项到上线差很少三个星期，这个时候其实大部分同窗对直播的技术是陌生的。新需求一上线，产品就罗列了一堆须要上线的需求列表，而后按照优先级进行了排序，而后致使的问题是，直播团队须要常常加班来解决线上的问题以及迭代新的需求。 除此以外，快速迭代致使的新老 Bug 的问题，以及接入第三方服务时所碰见的一些问题也成为直播过程当中所碰见的一系列难题。

关于稳定性的问题，致使其存在的缘由主要有如下几方面：内存泄露、客户端 SDK 不稳定、硬件的兼容性问题以及复杂的多线程带来的时序异常的问题。稳定性的问题，主要会致使观众没法正常观看直播以及主播没法正常进行直播这两种状况。后续也会针对稳定性的问题，作一系列的优化措施。

图 10

图 10 为性能上面存在的问题，在直播初期，刚接入云服务时，其实并不支持硬件编解码，这样会致使主播手机端会很是卡顿、手机发烫这样的状况发生；除此以外，还会存在评论列表刷新过于频繁，点赞、礼物和弹幕渲染以及高并发下如何打点着一系列的问题。

直播优化实践

1. 稳定性优化

针对稳定性，蘑菇街团队内部作了不少努力，其中包括进行 Code Review 、代码规范、接入整个静态分析和内存泄露的检测工具；同时也对日志作了必定的处理，在关键流程和出错的地方，都打上 log，日志能够进行本地察看和发送并定向上报分析。

图 11

关于稳定性方面的案例，如图 11 所示是一个多层 block 嵌套的模型，是进行稳定性优化时作的代码优化处理案例，多层 block 嵌套在大屏幕上以及在上下文参数和回调的使用方面仍是挺舒服的，可是伴随着较差的可阅读性，好比说笔记本电脑，只能显示前面半部分，几乎不可阅读，因而可知它的阅读性是很是差的。还会致使回调流丢失以及由于 block 嵌套致使的循环引用。后期，针对这些代码，进行了一系列修改以后，将多层的 block 嵌套修改为「单一职责」的方法调用，新增了代码的可阅读性和可维护性，同时不易形成回调流失，内存泄露等问题。

稳定性优化还包括内容泄露方面的优化，使用 instruments 进行内存泄露的检测，在 iOS 客户端使用 MLeaksFinder 针对直播组件进行了 Debug 下的内存泄露检测，这样作就能够将内存泄露扼杀在开发阶段。

图 12

图 13

图 12 是 MLeaksFinder 的使用，图 13 是它的原理。 MLeakerFinder 的原理简单说就是当 VC 被 POP 时 ，它会在 3 s 后 ping 全部的 view，若是 ping 到了，就说明这个 view 在 3 s 内尚未释放，说明有可能发生了泄露，虽然会有一些误报，可是当添加一段新代码时，他有提示，那么这样就能够重新加的代码当中找到问题，能够用来辅助开发。

流程打点，也是稳定优化当中很是重要的一块，流程打点里面的定制性很是高，能够生成一些文件或者是存储到本地。能够在关键流程上打 log，出错、SDK 报警均可以打上 log，给 App 的生命周期打 log，VC 的生命周期打 log，这样一来就很容易经过日志找到线索，来解决线上碰见的问题。

2.性能优化

1)进房速度慢

图 14

性能优化中最主要的部分，就是进房速度慢；图 14 是串行的进房流程，这是最开始采起的一种进房方案，串性地支持一段流程，最后拉取流，这样作会花费较长时间，由于须要每一个步骤时间的累加，时间总和确定是超过 1 s 的，这样一来也就达不到视频秒开的要求。

图 15

图 15 是针对进房速度慢的优化方案。针对能够抽出的审检部分，进行了预登录；进行了同步处理和异步处理，这样一来，节省了云服务预登录的 300 ms 和加入聊天室的 50 ms，以及后续获取直播间详情信息的 200 ms 时间，统计下来节省了近 550 ms的时间。

图 16

图 16 是进行优化后的结果，原来须要花费 1.3 s 进房，在优化以后只需 700 ms 就能够进房。

2)消息

直播的的消息包括评论消息或者其余消息，这块常常会遇到的问题主要是触发时机过于频繁、缺乏消息缓存池、没有缓存列表的高度计算。

图 17

图 17 是以前作的消息系统。首先由 VC 调用消息管理类发送消息接口，消息管理类持有聊天室实例进行发送，该接口异步回调给直播间 VC 去作消息内容的接收、缓存，以后进行消息的合并和转发。这样的处理方式应该是比较简单清晰的，可是随着业务的发展，直播间 VC 承担了太多消息处理，同时伴随着消息相关业务的耦合。由于直播相对来讲就一个主播间和观众间，自己会集成不少功能，代码量相对来讲也会比较大，如今又将消息功能也写进直播间内部，这样就会致使直播间 VC 将成为一个「上帝类」，不易开发和维护。

图 18

图 18 是消息优化的四个流程。

第一是消息注册。在进入直播间时，会针对消息类型将消息注册到消息分发管理类中，消息分发管理类内部持有 NSHashTable，弱引用注册消息的对象。

第二是发送消息。各业务模块单独调用消息管理类的发送接口，消息管理类内部调用持有的实例进行消息发送，去除了直播间 VC 这个中介者。

第三是消息处理。消息管理类收到消息回调后，调用消息分发管理，而后根据第一步的消息注册，进行消息的分发（一对多），评论列表相关的消息须要进入消息池，消息按需回调。

第四是评论列表刷新。最开始都是收到消息后当即刷新视图，在高并发下，这样作会致使刷新过于频繁，严重时会占用一半的 CPU 资源，使得直播间很是卡顿；优化以后的作法是，定时轮询消息池内部的消息，存在消息时才将消息从消息池取出，作相应的业务处理后再进行视图刷新。

对消息进行这样四个流程的设计，是比较清晰合理的，既减小了直播间 VC 的耦合性，同时也提高了消息的性能。

3）动画

图 19

性能优化方面，动画也是很大的一块。如图 19 所示，动画控件的可复用性，离屏渲染严重，序列帧图片缓存都是这里所面临的问题。

对于点赞（弹幕），主要是会限制其点赞（弹幕）频次上线。20次/s 即可以达到渲染直播间气氛的行为，直播间 100 个用户每一个人点一下就收到 100 个，而若是同时显示 100 个，确定会形成直播间主播端卡顿，所以，限制最高频次就能避免这种现象的发生。

离屏渲染，能够去除大量圆角(好比直播间列表的一些可复用性圆角)，都用图片代替，由于离屏渲染是很是影响 CPU 性能的，会形成很明显的列表卡顿或者直播间卡顿。

对于序列帧，复用程度高的小图片能够进行缓存，可是对于一些礼物大动画，图片比较大，长时间在直播间播放会一直占用内存，因此在使用完以后应该立马释放。

4）打点

图 20

图 20 是最初使用的打点流程，会将这些主流程的打点都附加到磁盘，从磁盘取出以后再发送数据上报给服务器，这样作会使磁盘和网络 IO 操做很是频繁。

图 21

针对这一点，作了如图 21 的流程优化。在进行打点时，会优先将其存入内存当中，在异常状况下才会从内存中将打点数据存储到磁盘，而后定时去作一个打点数据发送的检测，当数据达到阙值时再发送出去，这样一来减小了网络和磁盘的 IO 操做。

图 22

图 22 是性能打点优化的结果。原来每秒打点 50 次，须要占用 70% 的 CPU 资源，优化之后只须要占用 35% 的 CPU 资源。

3.直播组件化

图 23

图 23 是直播组件化的一些功能模块，其中包含房间管理、消息通道、红包、礼物、评论等功能模块。

组件化主要是为了解决直播间代码耦合性高，对外提供可定制化功能模块，自定义 UI 的功能。在选择整体的设计方案的时候，按照需求进行了总体设计模式的选择：

1）须要明确的接口定义和面向接口编程，而且能够重写具体的实现达到自定义UI和功能的需求；

2）低耦合，可定制化功能模块。

基于以上两个要求，选择了 MVP 的设计模式，MVP 能够很好的解耦直播间的各模块代码，同时有良好的接口层，具体的 View 和 Presenter 实现各自的 Interface 层的逻辑，替换 View 和 Presenter 的实现就能达到可定制化UI的需求。而后直播间对各模块 Presenter 的接口层的组合调用，也可以很好的支持功能模块的和定制化需求。相较于比较厚重的 MVC 模式和数据双向绑定的 MVVM，MVP 更适合蘑菇街的业务场景。

图 24

图 24 是一个主播信息展现组件，MVP 的组件化工做给以后的 SDK 化和平台化带来了极大的便利。对于直播回放的接入，则只需在回放的直播间组装业务组件就能够完成，操做上带来了很大的便利。

4.SDK化

SDK 化主要目的有四点：

1.下降集团内其余 App 的接入成本；

2.统一的接口和文档；

3.良好的框架设计和扩展性；

4.业务功能可配置化和 UI 定制化；

图 25

图 25 是整个蘑菇街 SDK 化的客户端框架图。

底部是视频直播 Core SDK ，包含两个模块，一个是直播音视频模块，一个是直播 IM 模块；音视频模块接入蘑菇街自研的人脸识别、开源的 GPUImage、同时还接入云服务登录 SDK；IM 模块包含消息分发模块和 IM SDK 两部分，消息分发模块就是以前说起的将消息的一个步骤拆分红四个步骤的组成模块；

业务模块就是刚才说起的组件化，包含一些功能模块。

图 26

图 26 是 Core SDK 的功能。建立视频直播、加入视频直播、注册 IM 消息回调、发送 IM 消息、退出视频直播等功能，这些都是一些基础功能。

图 27

图 27 是 SDK 业务层的方面。依赖于视频直播的 Core SDK，同时在上面会有一个本身的业务，而后进行组件化，能够实现其余 App 接入时的定制化功能。

5.平台化

平台化的工做，一方面是提供更好的业务方接入方式(与市面上常见的 SDK 相似，提供 UID )；另外一方面，针对平台内部能够提供一个便捷精准的数据平台，用于区分于业务端。这个事情主要由后端主导，而后客户端配合直播相关接口的改动，由于客户端已经作了组件化和 SDK 化两个主要的支持业务方快速接入而且能够定制化功能 UI 的工做。

图 28

图 28 是平台化大体的结构图，顶端是直播的来源，中间是平台化的一些工做，包括直播 SDK 接入、直播数据存储、直播报表以及后台系统。底端接入了互动直播、点播以及 IM 的云服务。

直播设备

因为用手机进行推流播放会形成分辨率有限以及稳定性方面也会产生一些问题，因此蘑菇街采起了专业设备推流播放的方式。

图 29

图 29 是采用专业设备推流的大体界面，里面支持横竖屏两种模式，而且能够任意切换。

图 30

针对专业设备推流，蘑菇街主要采起如下方案进行。视频采集可使用电脑摄像头或者专业的摄像设备；采集完成以后都推流给电脑(电脑上面须要装 OBS 软件)，OBS 接收到采集的视频流以后，经过视频流推流，上传到云端进行分发；播放端则比较简单，采用点播 SDK 就能够完成支持。图 30 为完整的流程图。

专业设备与正常直播之间的区别之一就是没有手机端的主播端，只有摄像头进行视频流采集。此时，也会遇到一些问题，好比房间号的产生、群聊的建立、业务信息的获取；这些信息目前都是在管理后台进行一系列的分配工做(推流地址由运营后台点击按钮后调用云服务的开启推流频道接口获取）；其次是在采集推流时须要经过电脑用 OBS 进行推流再进行 CDN 分发；最后是在播放时，手动设置房间状态，直播状态分为三种。直播没开始时为订阅状态；直播结束了则会跳转到直播结束页；只有在正常情况下才能够进入直播间进行拉流播放，房间状态由运营后台维护，添加了推流、断线、重连。

https://yq.aliyun.com/articles/62961