直播的风口 你不会就out了 如何快速简易开发直播app
会持续更新直播有关的资料 正在做直播或对直播有兴趣的可加直播开发交流群:183331015 欢迎前来探讨交流
本文仅转载 落影loyinglin 作者
前言
做直播APP也有一段时间,自身是多年直播观众,总结下这段时间研发的收获以及业务介绍。
直播APP的性能优化-礼物篇
功能介绍
直播APP的常用业务如下。
1、聊天
私聊、聊天室、点亮、推送、黑名单等;
2、礼物
普通礼物、豪华礼物、红包、排行榜、第三方充值、内购、礼物动态更新、提现等;
3、直播列表
关注、热门、最新、分类直播用户列表等;
4、自己直播
录制、推流、解码、播放、美颜、心跳、后台切换、主播对管理员操作、管理员对用户等;
5、房间逻辑
创建房间、进入房间、退出房间、关闭房间、切换房间、房间管理员设置、房间用户列表等;
6、用户逻辑
普通登陆、第三方登陆、注册、搜索、修改个人信息、关注列表、粉丝列表、忘记密码、查看个人信息、收入榜、关注和取关、检索等;
7、观看直播
聊天信息、滚屏弹幕、礼物显示、加载界面等;
8、统计
APP业务统计、第三方统计等;
9、超管
禁播、隐藏、审核等;
架构
直播APP的业务逻辑不复杂,使用基本的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字段。客户端、服务器都对核心逻辑收到的消息,进行一次校验。