架构

直播系统源码的业务逻辑不复杂，使用基本的MVC框架即可。

• 部分Controller的业务逻辑较多，独立的业务可以拆分出去作为一个单独的Catagory；
• Model的数据变化采用event（notification）的形式通知，便于做多处数据绑定；
• Model之间的相互独立，如果由业务需要，需要交换Model的数据，由Controller代为处理；
• HTTPService为AFNetworking封装，回调Model以Block块为主，特殊的业务逻辑以event（notification）的形式通知；
  

视图

1、GiftView

显示礼物，管理小礼物与豪华礼物动画； 核心： 小礼物连击效果， 队列存储豪华礼物消息，播放完毕回调。 小礼物用CAAnimation动画和UIView Block动画； 豪华礼物用CAAnimation动画和UIView Block动画+ GCD协调；

2、MessageView

显示聊天消息，弹幕消息。 核心： 聊天tableView，用 NSMutableAttributedString显示富文本； - (CGRect)boundingRectWithSize:options: attributes:context:计算高度并缓存；直播系统源码的弹幕消息用队列存储弹幕，UIViewBlock动画循环播放，最多同时显示条数限制；

3、RoomTableView

显示直播系统源码房间列表 核心： MJRefresh做上下拉刷新， 以时间为轴；

4、ChatView

直播系统源码聊天界面， 直播间内半屏显示，直播间外全屏显示； 核心： 用第三方聊天界面，直播间内用 addChildViewController的方式，直接加载第三方ViewController；

控制器

1、ChatViewController

第三方聊天控制器做基类，自定义业务逻辑，包括私聊送礼物、广告屏蔽等，包括ChatListViewController和ChatDetailViewController。

2、WatchLiveViewController

观看直播控制器，包括LivePlayer（视频流播放器），房间业务逻辑相关，接受聊天消息转发给MessageView，切换前后台（APP生命周期）控制；

3、PushLiveViewController

推流直播控制器，包括推流相关逻辑，直播定时器，房间业务逻辑相关，聊天消息转发给MessageView，主播离开、切换后台等控制；

数据层

1、LiveRoom

房间的数据结构，存储房间信息，包括管理员、主播ID、房间推流、拉流地址、房间用户列表等等；

2、LiveUser

直播的用户数据结构，包括昵称、头像、ID、等级、榜单等；

3、ChatUser/Message

聊天的用户数据结构，包括头像、昵称、ID等，Message是消息类型，包括直播间普通的Message、（节省流量）打包用的QueueMessage，私聊聊天的TextMessage、PhotoMessage等；

服务层

1、IMService

IM功能，提供私聊，直播间消息广播等。

2、LiveService

推流和拉流功能，提供录制、推送视频流到服务器，拉取视频流和播放视频；

3、LoginService

直播系统源码登陆功能，手机号码登陆，第三方（QQ、微信、新浪）登陆；

4、IAPService

内购功能，苹果内购；

5、PayService

第三方支付，微信支付和支付宝支付；

6、PushService

推送功能，聊天消息推送，直播开播推送，活动推送等；

7、AnalysisService

统计功能，APP自身统计上传到服务器，第三方统计；

Pod库

1、AFNetworking

负责所有Http请求，业务层会封装Manager；

2、GPUImage

采集视频，并对视频流进行美颜处理；

3、RMStore

苹果内购支持；

4、SDWebImage

负责加载图片，包括头像、礼物图片等；

业务问题分析

1、聊天室消息过多

产品运营一段时间后，消息量不断攀升，最高到100billion，后来IM方优化后，量级稳定在10billion，但是消息量仍旧过大。 通过对消息历史记录进行数据分析，发现瓶颈在enter和exit消息，占比为84%。 分析：在线用户交多，频繁进出房的动作导致需要不断发送enter和exit消息，可以预计，当房间内人数越来越多之后，将会有更多的进出房消息，同时增长速度为 平方级别。 总结：直播系统源码和服务器之间的实时消息过多，同时都是密集操作。 解决方案： 人数较多的房间，等级小于一定级别（ 服务器下发）则不发送进出房消息； 级别较高的用户进入房间时，会在 进房消息携带数据以同步房间信息；

2、房间活跃度计算

设有活跃度（礼物G、聊天M） 、 在线人数N、 直播时间T G为本次直播收到的Y币数 M为本次直播发出的消息数 N为本次直播在线人数 T为本次直播的分钟数 本次直播的成本为N * k1 + M * k2，k1为带宽成本常数，k2为IM成本常数。 聊天成本暂不考虑，那么成本为N * k1。

视频带宽的价格20元/M每个月，用户观看的速度为150k/s左右，那么每个用户高峰成本为7元每个月，每日成本为2.3元。用户人均每日观看2小时，那么每分钟的成本为0.02元。 我们的最高在线/活跃人数是0.18，那么一个普通用户每分钟的期望成本k1 = 0.18*0.02 = 0.004元。

我们的每分钟收入为x = G / T * 0.66 - N * 0.004 对于一个已经在直播的主播，如果x 大于0，那么属于为直播系统源码赚钱主播，可以放在列表前面。

预计： 按照目前的水平，假设一个1000人观看的主播，每天2个小时的直播，收入应该在10000Y币。 每小时应该有5000Y币，每分钟应该有84个Y币。我们的收入有5.6元。 那么对于一个新开直播的主播，她的预设x值为1.6。

总结： 每分钟按照收入x排序, 如果是已经开播的主播，x = G / T * 0.66 - N * 0.004； 如果是刚开未满一分钟的主播，x=1.6。

3、HTTP代理篡改get参数

通过HTTP代理工具，篡改直播系统源码给服务器的get参数。举个例子，用户点的是豪华礼物，通过HTTP代理工具把发送给服务器的请求的礼物ID改为普通礼物的ID。 解决方案： 1、改用HTTPS； 2、添加校验码； 解释下方案2，把所有的get参数，key按照字符串顺序排序，value用"/"串起来，最后再加一串特定的字符，最终对这串值进行MD5，把MD5的串添加到code字段。客户端、服务器都对核心逻辑收到的消息，进行一次校验。

总结

时间有限，大多数核心逻辑没有深入介绍。感兴趣的可以在评论区交流。

声明：本文由云豹科技转发自落影博客，如有侵权请联系作者删除