最近一段时间离职在家，在浪了一个月以后，觉得应该收一收心，总结一下之前做直播的一些看法和经验，这里也只谈比较有代表性的直播间内部，网上有许多直播间架构的经验，但是几乎都偏向于推拉流，我想总结一下其它部分的经验，和大家交流一下，这里假设你已经拥有了比较稳定的推拉流 和 im 系统。

作者：性能篇

1. 
   每当发生了内存泄漏，它会自动弹框提示，这个第三方其实只是包装了一下FaceBook检测内存泄漏的工具从而可以达到自动检测内存泄漏，只要pods进来其它都不用去操作，要注意一点的是 MLeaksFinder 目前能自动检测 UIViewController 和 UIView 对象的内存泄露，而且也可以扩展以检测其它类型的对像，所以要把直播间内比较重要的但是 不是view类的主动添加到检测中，具体方法请查看它的文档。

2. 使用instruments
   在编程过程中，我们不用一直在测试性能，程序流畅就是最好的证明，需要时不时关注 xcode 的上的 cpu 和 内存占用情况，cpu 长时间维持在 20 % 左右就会导致手机很热，如果达到100+% 手机直接卡住，推流 比较占用cpu，所以直播时会导致手机烫，如果发现cpu 较高，要使用 timeprofile 来检测代码执行时间，同时 内存也可能无限增长，内存的无限增长在程序外表基本看不出来异常，当增长到几百或者1000+M 后就会被苹果干掉，非常推荐使用instruments 来进行cpu 和内存的检测，这里推荐两篇 instruments 的

礼物篇

礼物大约分为三类，一个是点赞，一个是连发礼物，还有一个是全屏大礼物

1. 点赞消息几乎是点击量最大的一种类型，为了减轻业务服务器压力，我们只有第一条点赞消息会调用 业务服务器接口，以便业务服务器发送广播 谁谁谁点亮了❤️，其余点赞的消息都是客户端直接调用im 服务器 来发送消息，而且不会点一次就发一次，会导致im服务器压力过大，要判断距离上一次一定时间以后，才会调用发送点赞消息的方法，但是每点击一次就会在点击人的屏幕上产生一个效果。

2. 连发礼物我们没有做成队列模式，就是如果当前屏幕连发礼物占满，其它人发连发礼物就不会显示了，原因是连发礼物金额小，数量多，记录会占用很多资源，必要时服务器也可能抛弃一些连发礼物的消息

3. 全屏礼物，目前我们的全屏礼物还是采用播放gif 的方式，这种方式会使内存在短时间内剧增，也会增加cpu压力，但是如果ui做的好，效果会很美观。全屏礼物采取可配置的方式，在初次登录时要下载礼物资源，所以可能在初次登录时会有些礼物显示不出，未来可能会使用animation 和 图片结合的方式来显示全屏礼物。这样会减小内存，减小初次下载量，提升性能，但是可能需要一个较为全面的配置文件，在初次登陆时随着资源一起下载。
   全屏礼物是一定需要队列的，这个队列原理是 将收到的消息存到数组中，动画结束后读取数组中的下一个礼物进行动画，但是动画结束的判断方法最好用一个定时器来根据动画进行时间来判断，尽量不要使用动画结束的回调，因为进入后台或者其它情况会导致动画提前回调 但是finish 为 false。

消息列表篇

消息列表里包含了个种消息，点赞，关注，文字，礼物 等等。。。。
消息列表是一个tableview 里面的cell 较为复杂，高度一定要缓存，不然每次reload tableview，cpu都可能飙到100%，在接受到消息的时候最好直接计算好cell 的高度存在model里面，在接受消息的位置最好开启另一个线程，因为消息可能短时间非常多，这样可以减轻主线程压力。
消息列表的滚动到底部的时机可以根据手机来进行区分，iphone7 每次接到消息直接滚动到底没什么压力，iPhone5 可以采取 定时 或者 定消息数量的方式 来滚动到底部

定时器管理篇

一个直播间需要用到定时器的地方非常多，可能是记录主播直播时间，给服务器发送心跳，礼物队列管理，定时更新列表数据，等等等等，所以最好写一个直播间内定时器管理类，尽量减少定时器数量，避免定时器导致的内存泄漏问题,下图是来自映客刘凯的采访

架构篇

我个人比较喜欢mvc 架构，但是直播间内部相对复杂，我在交互view（交互view 指的是显示礼物以及消息等，可以隐藏的view）上使用了mvvm的结构，因为交互view上需要调用各种接口，接收各种消息，处理各种逻辑，十分复杂，如果使用mvc 可能会导致类中代码过多，mvc 的代码在不太复杂的逻辑中都比较清晰，所以整个工程中只有这个交互view 使用了 mvvm 的架构，我觉得使用架构不一定要一用到底，根据自己的业务逻辑选择合适的就好。而且我的项目中也没有倒入RAC 配合mvvm 使用，因为mvvm 只用了一个类，使用RAC 反而会减少代码可读性。

下面简单介绍一下图中的结构

• vc 上的四个绿色的管理类 可以深入到 各个view中进行操作，这样可以减少耦合性
• 推拉流管理类 是对于推拉流sdk 的又一层适合自己业务的封装，避免更换sdk 后代码改动过大。
• 系统监听管理类 中主要是对于 进入后台，来电等系统监听进行处理
• 定时器管理类 为了减少定时器数量，就在vc中 建立公共的定时器管理类
• 直播间结构 最底部是一个实现无限滚动的scrollView，也可以用collectionView，我觉的scrollView 方便一些，原理参照无限滚动banner图，但是尽量不要用改变contentoffset 的方式来跳转，最好用改变 scollview上view 的frame来实现，因为需要在didScroll 方法里判断是否要离开一个房间而进入另一个房间，如果采用改变offset的方法会导致更多的回调didScorll方法，产生不必要的bug。
• dataController 内部负责调用 开始直播接口，进入房间接口，发送消息等各种接口，还负责接收直播间内所有的消息，然后通过控制交互view 来展示各种效果，礼物，弹幕，更新消息列表等。

嵌入游戏篇

前段时间我们某个直播平台中加入了一些棋牌和休闲的小游戏，游戏部分可以做成一个完整的mvc 结构的项目，在最复杂的游戏view中依然采用了了mvvm 的结构，和直播间结构类似。游戏中的大部分逻辑和直播间无关，类似于下注，开牌等逻辑，所以要将游戏和直播间作为两个生态系统，有交集的部分 可以建一个类作为中间者来协调游戏和直播间的逻辑。

横竖屏切换

点击切换的按钮时发送通知，因为可能有很多view 要改变布局，可以给每个需要改变的view 中 增加catagory 来 负责布局。

目前能想到的差不多就这些，下面推荐一些值得参考的文章