架构
直播系统源码的业务逻辑不复杂,使用基本的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字段。客户端、服务器都对核心逻辑收到的消息,进行一次校验。
总结
时间有限,大多数核心逻辑没有深入介绍。感兴趣的可以在评论区交流。
声明:本文由云豹科技转发自落影博客,如有侵权请联系作者删除