蘑菇街直播架构

直播简介

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

图 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 分发；最后是在播放时，手动设置房间状态，直播状态分为三种。直播没开始时为订阅状态；直播结束了则会跳转到直播结束页；只有在正常状况下才可以进入直播间进行拉流播放，房间状态由运营后台维护，添加了推流、断线、重连。