映客直播iOS App 性能优化实践

如需转载请联系听云College团队成员小尹邮箱：yinhy#tingyun.com

本文整理自APMCon2016中国应用性能管理大会移动性能优化专场，映客直播iOS高级开发工程师刘凯发表了题为《映客直播 iOS App 性能优化实践》的演讲，现场解读了映客直播iOS App的应用架构和性能优化方面的实践经验。具体包括App首页直播大厅的刷新机制，直播间内用户体验方面的优化。

刘凯：大家下午好，我是来自映客直播的iOS工程师刘凯，今天正式的分享主要讲一些偏向与客户端上层应用开发方面的优化。主要分为三点。第一个是有关直播大厅的优化，第二是直播间优化，直播间里面进行呈现。第三点，介绍一下私信消息模块的整体设计。

直播大厅

首先来看一下直播列表的刷新，这一点特别的重要，因为直播列表是作为APP入口的形式存在的，所以第一点需要保证高可用，直播大厅出现了问题可以说是非常糟糕的情况。第二，很多直播存在一个问题就是当用户看到了某一个直播封面，实际上点击进去的时候这个直播已经结束了，这样带给用户的体验也是非常不好的。作为APP入口，它承担了很多直播流，很多主播可以及时的进行露出吸引粉丝的关注。

在直播列表刷新的优化上，我们采用多种刷新机制相结合一个方式。第一个是全量刷新，用户登陆了以后全量拉取一些数据，第二点就是顶部刷新，实际上就相当于什么呢？TOP10一个直播流一个刷新，这个就可以根据当前App滑屏偏移来判断。第三点是局部刷新，这个策略主要来说是从用户体验还有服务端缓存策略两个方面进行的。我们对于直播流进行分组，因为实际上当用户来浏览直播大厅时需要对当前一些直播信息进行刷新，比如当前的直播人数。最后一点，时间间隔等信息都是服务器端可以配置的。

在用户体验方面，我们做了一个比较常见的优化。当用户在滑屏时有一些返回动作，这个时候就是延迟刷新当前界面。第二点，怎么对进入直播间的速度进行优化，我们发现有一些常见的现象：当用户点击直播以后进入页面会非常的慢；即使进入直播间，视频有时候也迟迟加载不出来；第三点会收到运营的一些反馈，一些主播开播了以后，发现自己的人气一直上不去。

这些现象由什么造成的呢？获取视频流时建立网络连接方面有一些在客户端上层的耗时，另外直播间业务模块非常的多，在界面初始也会有一些耗时。针对与拉取视频流方面我们的思路就是在直播间大厅预先解析房间的视频流地址,从而加快获取视频流数据的速度。然后在上层我们会对直播间很多UI模块采用常见的冷加热方式。这使用户点击的时候能够非常快速进入到直播间看到视频。

直播间

下面我们介绍一下直播间各个业务模块：

这个是一个典型的直播APP业务模块划分。有音视频模块，还有公聊信息、点赞、分享等，另外还有今年映客3.0版本新上的一个连线的功能，主播可以和用户在小视频窗口上面进行互动，同时支持两个用户和主播进行互动，而且延迟相对比较低。

关于直播间优化，主要从4个方面讲一下。

1、定时器事件调度

2、房间内长连接消息的处理

3、动画展示

4、主播端的体验优化

下图描述的就是定时器一个事件调度，开始不同的开发人员负责不同的房间内业务模块，使用各种各样的定时器做一些请求，通知等等。后来使用统一的定时器，我们按照不同的时间间隔，对于这些事件进行调度处理。

下面会介绍模块优化的过程。第一个公聊消息列表刷新，用户在下方跟主播进行互动，我们遇到了一个问题，在直播间内公聊消息快速刷新会导致主线的CPU占用非常高，引起整体界面交互卡顿，后面就是怎么一步步解决这个问题。

第一，我们使用长连接消息库，默认就是把代理方法的执行设置到主现场。然后在做一些运营活动或者主播人气特别高的时候，大量广播消息就会导致客户端收到消息过多，很容易引起CPU比较高。针对这个问题，我们的思路是将SocketIO 库中的block执行线程设置为非主线程，缓解主线程中CPU的占用问题。

第二，我们主要是针对性能较低机型上面，会根据收到消息的速度进行实时地统计，根据收到的消息数目来动态调整公聊列表的刷新频率。

接下来我们讲一下怎么进行大量礼物动画的流畅展示，因为这是现在直播APP里面一个标配，这一部分我们优化思路就是下面3点。

首先，我们会对业务里面各种各样的礼物进行分类，收到礼物消息的时候我们就用不同优先级队列进行管理。

然后具体到展示上面，对于点赞还有弹幕，我们使用内存池，缓存点赞和弹幕中执行动画view/layer，以重复使用。

第三点，全屏动画，最开始的时候我们尝试着直接用Gif动画。从UI到产品发布，这个时间迭代时期非常短。后来我们上了一些动画试了效果以后，发现动画在CPU消耗方面会特别严重，需要图片的解码包括加载之类的，非常耗性能。

然后我们逐渐对一些全屏动画采用了Core Animation来进行一些改写。这一块也是需要开发人员对这个框架，对动画里面一些使用特别的熟悉。当然，这个也是结合UI，产品一些效果来对动画里面一些参数进行各种各样的调优。

下面讲一下我们是怎么测试这个系统的？我们会分为下面几点。

首先，就是测试环境里面会在服务端配置一些自动的脚本，对于各种各样的礼物进行压力测试，会关注一些性能指标，例如CPU，内存占用等等，包括有没有一些限制方面的问题。

第二块是要和其他的业务模块结合起来进行测试，这一点其实是很多时候往往会被忽略的。可能添加了一些其他业务模块，就会发现整体APP性能不够用。这一点是比较明显的，我们上了美颜功能，还有今年5月份3.0版本的连麦功能的时候，直播间内有三个播放器同时进行工作，一个主播放器，两个小播放器。这个时候如果再有很多的礼物画面进行展示。无论是CPU，GPU压力都是非常大的。

第三点，最终上线以前，我们导入一些线上真实广播消息数据来对这些系统进行压测，看一下整体APP表现形式什么样子。

我们在做直播端体验方面的优化时发现其中非常普遍的一个现象也是很多APP都存在的一个问题，就是一个直播做了很久，好不容易上了一下热门人气非常高了，这个时候APP突然崩溃了怎么办？

这个解决方法说起来比较简单，我们在开始直播的时候保存一些地址，还有直播间的信息。当APP真的是因为性能问题崩溃了以后。会再次启动APP弹出继续直播的按纽，实际上不会对房间内很多的一些业务造成太多的影响。然后，恢复效果其实就是相当于切后台的一个操作。

第二，我们配合后端做的一个优化，在运营时房间内的广告消息压力是非常大的。主要的现象有以下两点，包括礼物持续刷屏，实际上直播体验是非常糟糕的。大家可以看到这一张图，就是前一段时间里约奥运的洪荒之力。

针对这个运营活动的压力，我们主要的解决思路一个是采用服务降级，会在协议上和服务端做一些商定，服务端可以下发很多限制客户端公聊和礼物消息发送频率的一些命令。然后，客户端这一部分我们也会进行一些限制例如点赞及部分礼物的动画展示，尽可能保证主播端的体验。

接下来主要讲下映客在减轻服务端并发请求方面的优化。

关于用户关注关系的拉取。当你进入一个直播间的时候，都需要拉取上面的用户列表中的关注关系，主播结束直播时可能一下子有非常多用户拉取和主播的关注关系。关于这个场景，实际上会给服务端造成非常大的压力。

还有推送消息这一块。当一些明星用户进行开播全量推送时，可能会唤起大量客户端同时拉取大厅直播列表。关于这一方面的解决思路，主要是采取缓存的策略。我们会对用户profile，关注关系等进行缓存，收到直播推送的时候，不立即刷新直播列表，延迟到退出直播间后再启动大厅刷新机制。

最后讲一点，就是客户端首次安装启动的问题，当用户首次下载映客了以后，点击登陆时会出现卡顿，这个问题的原因在于什么呢？当客户端启动的时候需要下载大量的图片资源，包括对于各种各样的礼物资源，还有很多等级资源进行请求。这个过程当中有很多大量的文件操作，这就需要我们对部分资源首先进行内置保证基本的使用，另外对于资源进行一个增量下载变现。

上面就是直播间里面一些优化的点。最后简单讲一下私信消息模块的整体设计，我们没有用第三方，而是用自己的一个整套方案。

私信消息