前言
做直播APP也有一段时间，自身是多年直播观众，总结下这段时间研发的收获以及业务介绍。
1.功能介绍
直播APP的常用业务如下。
。1、聊天
私聊、聊天室、点亮、推送、黑名单等；
。2、礼物
普通礼物、豪华礼物、红包、排行榜、第三方充值、内购、礼物动态更新、提现等；
。3、直播列表
关注、热门、最新、分类直播用户列表等；
。4、自己直播
录制、推流、解码、播放、美颜、心跳、后台切换、主播对管理员操作、管理员对用户等；
。5、房间逻辑
创建房间、进入房间、退出房间、关闭房间、切换房间、房间管理员设置、房间用户列表等；
。6、用户逻辑
普通登陆、第三方登陆、注册、搜索、修改个人信息、关注列表、粉丝列表、忘记密码、查看个人信息、收入榜、关注和取关、检索等；
。7、观看直播
聊天信息、滚屏弹幕、礼物显示、加载界面等；
。8、统计
APP业务统计、第三方统计等；
。9、超管
禁播、隐藏、审核等；
2.直播原理
。直播原理：把主播录制的视频，推送到服务器，在由服务器分发给观众观看。
。直播环节：推流端（采集、美颜处理、编码、推流）
。服务端处理（转码、录制、截图、鉴黄）
。播放器（拉流、解码、渲染）
。互动系统（聊天室、礼物系统、赞）
3.直播的实现流程
4.架构设计
业务模块
视图
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 / T0.66 - N0.004；
如果是刚开未满一分钟的主播，x=1.6。
3、HTTP代理篡改get参数
通过HTTP代理工具，篡改移动端发给服务器的get参数。举个例子，用户点的是豪华礼物，通过HTTP代理工具把发送给服务器的请求的礼物ID改为普通礼物的ID。
解决方案：
1、改用HTTPS；
2、添加校验码；
解释下方案2，把所有的get参数，key按照字符串顺序排序，value用"/"串起来，最后再加一串特定的字符，最终对这串值进行MD5，把MD5的串添加到code字段。客户端、服务器都对核心逻辑收到的消息，进行一次校验。
