蘑菇街作为一个电商平台，主要服务对象是女性用户。而蘑菇街直播是今年3月21号正式上线的，最初模仿了已有的直播平台，比如映客、花椒这类的秀场直播。但是上线之后，发现秀场直播的模式并不适合我们。随后我们很快推出了第二个版本，加入了电商模块。4月到7月，加入了各种各样丰富的内容。

7月对于蘑菇街直播算是一个重要的里程碑，我们开发了“自由小窗”功能。对于电商而言，直播的成交是可以忽略不计的，但是增添“自由小窗”之后，成交数量直线上升。

蘑菇街直播近期的变化在10月16号，我们开发了一个回放功能。回放功能就是说直播结束之后，可以把直播的内容录制在云平台上，然后进行回放。

介绍完蘑菇街直播的历程，我们进入今天的分享。

今天讲的内容主要分两大部分：

• 第一部分：蘑菇街直播的业务架构、功能、价值；
• 第二部分：直播项目中遇到的难点及对应制定的解决方案。

蘑菇街直播的业务架构

蘑菇街直播具体的业务模块，主要分为电商、颜值、礼物、支付、抽奖、聊天，以及运营后台与监控后台。

监控后台对于直播现在的业务形态来说，是很重要的。大家刚刚开始做直播的时候，觉得这个部分可有可无，但是我们蘑菇街直播做到如今，得出的结论就是监控后台应该在项目开始就被考虑进去，否则会给后期的发展带来很多不必要的麻烦。

从内容上来讲，蘑菇街直播分为直播、直播回放两块。直播里又分时尚直播和全民直播，时尚直播就是召集一些网络红人，通过红人效益来出售货品，看起来是半专业的直播。全民直播，可以进行创意直播，可以跟大家分享。蘑菇街的时尚直播，跟其他电商平台有一样的内容架构。

直播项目的开发难点

开发新的直播项目存在哪些难点，五木将其分为四个部分：

• 项目节奏
• 云服务质量
• 性能、稳定性
• 业务代码架构

项目的节奏

蘑菇街的直播，从立项到第一个版本上线，只有短短二十天。项目虽然按时完成，但它的完成质量以及所实现的东西是未尽人意的。项目开始的时候，我们并没有把项目跟业务结合起来。

等到直播上线之后，就出现很多的问题，例如卡、黑屏、延时高，前期的不充足准备导致我们要在后期花很多时间去弥补和优化。

因此在开发过程中，立项、开发、优化、上线的节奏一定要把握好。

云服务质量

这里要讲一下云服务和直播的关系，以及如何在一个云服务之上建立一个好的直播平台云服务对于直播来讲非常重要。

云服务在蘑菇街直播的架构当中，处于最核心的位置，从云服务延时、稳定性、接口丰富度到接入难易度及后续维护都值得关注。

云服务需要配合政治正确性,这里牵涉到了后台。蘑菇云直播刚开始的时候，也疏忽了这个模块，后来就发现会有很多内容管理上的难题，比如说一些不合法的内容。直播内容在网络上传播很快，如果一个不合法的内容在上面传播，对于平台的打击是致命的，所以内容管理一定要尽早完成。如果有人发表不正当的言论，可以提供证据给到公安，公安可以根据证据追踪到个人，可以撇清平台的责任，这个就是监控的重要性。

蘑菇街如何利用云服务？什么样的云服务算是一个好的云服务呢？这部分当然就要讲到云服务的延时、稳定性和接口丰富度，比如说业务层想要很多的内容，云平台云服务是不是可以给到；还有接入的难易度的部分，一天之内接入云平台，一天之内搭建业务；后续的维护是不是可以跟得上。这些都是云服务的标准。

当然如果有实力的话，可以自己来完成这个东西，花椒、映客都是自己完成的云服务。蘑菇街直播着重于业务上，云服务这一块就交给了云服务厂商。

性能和稳定性

关于性能和稳定性，我大概列了五点，算是比较突出的五个地方：

• 视频采集、处理
• 礼物、点赞
• 聊天
• 内存管理
• Crash上报、日志系统

视频采集、处理

我列举下蘑菇街直播在视频采集、处理的思路。

大概介绍一下蘑菇街直播进行视频采集、处理的流程。从Camnra，再到Face Detect，到人像的美容，再到贴纸，一直到最右边。这部分可能每一步都会出现问题。

这里有四个需要注意的地方：

1. 不要做无效的数据转换。我们知道对于Android来讲，如果在做处理的时候，不可能把这个数据转成RGB，数据转换很慢的，中间千万不要有反复的转换；

2. 第二个，Native更加高效。我本身做图形、图象出身的，对于GPU更加熟悉。开始设计直播软件的时候，我就想有美肤模块，再做动画效果，之后再去做编码，但是后来发现，这件事情其实是行不通的。大家知道从GPU的现存到内存，要把现实内容转移过来的过程是很慢的。所以蘑菇街只能把所有的流程转移。我们基本上对于这一块来讲，基本上都在Native，这样可以很快完成整个步骤；

3. 第三，即便你有Native，也要用Neon？有了Neon这个并行指令，我可以一次实行四个视频处理。这样的话，Native更加高效。这部分是可以用Native加速的，而且记住，能用Native加速的地方就用Native，效率可以提高很多；

4. 最后一个，最终你做渲染的时候，还是要做GPU渲染，会变得更高效。

互动：礼物、点赞、聊天

礼物、点赞，加上后面的聊天，算是一个类型的东西，都属于互动，所以这里放到一起，但聊天的解决思路和点在、礼物是不一样。

• 点赞、礼物

用户在手机上疯狂地点赞、送礼，会在低端Android手机上做频繁的动画，特别耗CPU，而且处理不当，会造成内存的浪费。

所以我们第一个要控制点赞的数量。这个怎么控制呢？第一要从服务端开始做控制。蘑菇街的点赞是气泡模式，大家虽然看到很多气泡，但是不会都显示出来。一次显示过程，就把气泡所有的都绘制上去，在过程当中要保留到每个气泡的位置，它的动漫效果，再加上轨迹。

Android里面，就是根据它的运动轨迹，一次性把这些都画上去。。这里的优化是什么呢？我之前做过游戏引擎，一看到这个，就联想到游戏里面的粒子效果，跟手游的炸弹爆炸有点像。这么考虑的话，点赞的气泡可以用粒子系统来做，会更加高效。再一个优化是必要的缓存。点赞的气泡类型其实就这么几种，可以先放到内存里。当然我们还做了一些其他业务上的逻辑，比如说我点五个泡的时候，会有巴掌效果。我点几个泡的时候，会有另外一个大的气泡出来。做个缓存可以更好地利用资源。

当然服务端控制的不止是点赞这回事，服务端控制服务端到客户端数据的量，要做判断——哪一些东西是必须的，哪一些是可以抛弃的。点赞，不需要把用户所有点赞都显示出来。主播一秒钟大概能收到几万个点赞，只要露出几个就可以了。

关于礼物动画，我这里简单要提几个点：

• 动画其实就是一个PAG序列，要控制图片的尺寸。这里面尺寸，一个指大小，另一个是指尽可能去压缩它的文件；
• 图片要进行解码控制，这样能明显会减少内存的占用；

• 要关注缓存机制。

• 聊天

聊天的数据并发大，相当于组建一个巨型的聊天室，但是露出的地方可能只是这么一点点。聊天的内容不可能都显示上去，所以这里也牵涉到一些优先级，还有量的控制。

直播聊天的难点：

• 数据并发大
• 更新逻辑复杂，叠加、合并、样式类型复杂
• 多窗口切换
• 支持网络和本地IM两种数据源

聊天的更新逻辑很复杂。大家可能看不清楚，蘑菇街直播不止有漏出的聊天内容，还有其他内容露出：比如直播分享、截屏、下单购买了。我们让用户看到他想看到的内容，把内容去重、叠加，把更多的主要东西——聊天漏出来。我们对于大量的重复、无效信息做了叠加。再加上最重要的商品信息——某用户购买了什么商品、某用户给你分享了商品之类的。对于后台，这样可以很好地控制性能。

直播窗口要能够变成一个小窗口，浮动在其他页面之上。这里面会牵涉一个问题，用户在小窗口回答时需要保证消息的延续性。其实这个聊天框，可以往上拉的，在视频界面消失的时候，聊天框可以继续接受数据、去重、叠加；等用户回到视频界面，聊天还可以显示出来。

内存管理

直播本身就是一个视频流，本身很消耗资源，再有复杂交互的话，需要控制好性能。Android手机播放视频时会有巨大的发热量，要尽量控制。

除了这些，我大概讲一下一些可以做到的简单手段。

• 尽可能控制图像尺寸，利用开源系统开发图片缓存机制

内存缓存、CPU解码都可以用上。我们有很多不同的解码库可供选择，不同的解码库之间可能有一些不同的问题。大家在做CPU解码的时候，要注意一下，避免踩到一些坑。

• 视频采集处理中的内存使用

这里只有一点，Android来讲，如果是用Camera.PreviewCallback，会发现它有一个大家不太用的Camera.PraviewCallbackWithBuffer，这个是什么意思呢？时间久了会导致性能很慢，这里就会给设定一个内存大小。为了适应不同主播不同的网络，服务器对于输出的内容做大小裁减，网络快一点，视频就大一点，网络慢一点，视频就小一点。大家在实际做的时候，要找到适合自己的方案。对于我们来讲，我们的buffer是没有变的。最终我们是从这里面，把图片缩放到适合的size。

• 严防ACT泄露

如果ACT泄露的话，也会出现各种各样的问题。

• 内存泄露排查工具使用

有很多排查内容泄露的工具。现在大家用Android，Android提供了比较丰富的内存泄露排查工具。在这里再次提醒大家，一定要控制好内存。

Crash上报、日志系统

Crash上报、日志系统能讲的东西很少，我就写了两条。

第一个在用云服务的时候，其实云服务绝大部分是Native，要能很好地使用云服务的Crash。

第二个是用户异常流程的搜集。这里有一些东西可以讲，可能是产品没有设计好，导致在用户在某个节点，进入到异常流程。比如用户反馈回来说我到哪个地方卡住了，出现什么问题。用户的描述很可能是不准确的，所以要开发一套日志的搜集上报系统。这里要注意，不能影响到主线程的性能。所以为了更好的配合异常流程的排查，去更好的为用户服务，我们还是要写一套日志上报系统，根据我们自己设置的优先级，有不同的路径，定点查询问题。

主播出现问题的次数要多一点，一开始我们要到主播家里查问题。因为主播都是妹子，我们研发当成福利去解决问题。但是日志上报系统上来之后，大家就再也没有福利了。

“Crash上报、日志系统”不止是针对直播平台，所有的App都应该关注如何搜集问题，如何针对流程中的问题去做很好的后期追查。如果发现问题，如何去定义问题。

打造优秀的业务代码结构

构建业务代码的架构时，先建立好一个Coresdk，里面有音视频服务及云SDK、人脸检测、视频处理、图象处理等模块，然后构造技术组件库。第一个版本的蘑菇街直播，主播和观众版块就有四五千行代码，后来我们为其安插上了各种各样的业务组件，做更好的PE组合，为我们更上层的业务进行服务。

这是现在蘑菇街直播的整个业务代码的架构。这里面运用了整体的云服务，在这个基础之上，蘑菇街建立好一个coresdk，这里有音视频服务、云SDK、人脸检测、视频处理、图象处理（美肤、添加效果等）。右下角是技术组件库。

蘑菇街直播上第一个版本的时候，一个主播App、观众App都有四五千行代码。后来我们插上了各种各样的业务组件，做更好的PE组合，为我们更上层的业务进行服务。比如大家现在看到的互动直播间，跟花椒、映客一样。回放间、专业直播间本身的架构差不多，但是要适应新的问题。比如专业直播间是用专业设备录制视频，所有的视频要做业务上的适配。

在蘑菇街里面，不仅仅是蘑菇街一个App，还有其他的APP，有了这么一个组件，可以给到其他App，让他们可以接入，使用蘑菇街App的东西。

接下来讲Android里的RxJava。它有什么功能？

以蘑菇街直播的进房流程为例，这个流程很复杂，首先要检查一下房间信息，请求token，然后登录云服务，开启视频服务，加入视频房间，加入聊天室。整个流程当中可能由于耗时较长被用户叉掉。

用传统代码写，流程特别长；但RxJava可以把所有的代码写成流式布局。这样所有就会特别的清晰，而且可以很迅速、很简便地把代码写下来。所以有这部分困扰的，可以参考一下。

另外代码架构的时候，如何做拆分，如何搭建一个很好的架构，对于客户端来讲，大家用的比较多的是MVP。Presenter相当于逻辑控制中心，跟上面的view交互，跟Model交互。我觉得现在绝大部分应该是基于这种架构来写的，大家有兴趣在自己的项目里面可以实践起来。

现在大家发展下来就能发现，直播已经不能称之为一种业务。它本身可能就是一种交际手段， 或者说是让内容去跟用户交流的手段。基于这种交互信息产生什么样的功能、如何配合自己的App和平台、有什么样的方式，这些才是目前对直播行业来说最重要的任务。