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

　　图 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