app开发直播功能实践案例 系统讲解

　　电商模块点开之后（图 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