研发直播APP的收获-iOS

前言

做直播APP也有一段时间，自身是多年直播观众，总结下这段时间研发的收获以及业务介绍。

欢迎关注文集-直播Live：

• 直播APP的性能优化-礼物篇
• 使用VideoToolbox硬编码H.264
• 使用VideoToolbox硬解码H.264
• 使用AudioToolbox编码AAC
• 使用AudioToolbox播放AAC
• HLS点播实现（H.264和AAC码流）
• HLS推流的实现（iOS和OS X系统）

功能介绍

直播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字段。客户端、服务器都对核心逻辑收到的消息，进行一次校验。

总结

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

• GPUImage文集是闲暇之余阅读GPUImage源码的收获；
• OpenGL ES文集同样是闲暇之余学习OpenGL ES的总结；

GPUImage仅是目前iOS用到的图像处理库，OpenGL ES是自己为下一波热潮的预热。