序言
推拉流这里暂不涉及了，这里主要说一下直播的一些逻辑流程的难点。
直播架构-层级划分
为了更方便的实现和管理代码，个人把直播划分为3个层级
1、直播层：用于实现推流和拉流以及回调的监听；
2、交互层：用于弹幕发送和功能按钮的点击；
3、礼物展示层：用于礼物动画的展示，且在最上层。
直播层
开启直播
1、一进入直播模块就获取用户直播信息，在点击开启直播时进行判断：如果还不是认证主播，就进行实名认证；如果是认证主播，再获取主播相关信息。
2、调开启直播接口，通知服务器开启直播，并调用开启和进入直播间接口，通知服务器进入直播间，查看是否用相机、麦克风权限，然后开始推流。
3、推流过程中要监听几种推流状态：
1）打开摄像头失败；
2）打开麦克风失败；
3）网络波动状态；
4）断网状态（重连服务器）；
5）断网后多次重连服务器失败状态（主播退出直播界面至列表界面）；
6）推流成功状态（加载动画结束，客户端设置用户为开播状态）。
关闭直播
1、调关闭直播接口，通知服务器关闭直播，并调用关闭和退出直播间接口，通知服务器退出直播间。然后停止推流。
2、进入结算界面。
观看直播
1、观众通过后台获取拉流地址播放直播画面；
2、监听播放事件回调，做相应UI操作。
交互层（即时通讯）
交互层负责所有的用户交互，是整个直播模块的难点，也是客户端要实现的最复杂的部分，交互有很多（看产品￣_,￣ ），比较典型或复杂的有：
1、聊天弹幕的发送，礼物的发送；
2、守护席的争夺；
3、观众与主播连麦；
4、主播与主播的PK。
为什么要括弧个即时通讯呢，因为交互层这个层级就是和即时通讯紧密联系在一起的，无时无刻都在即时通讯！先举个守护席的例子吧。
注：使用即时通讯时的字段两端要统一。
守护席
守护席的状态要分两个视角：抢占视角与观看视角。
抢占视角：抢占细节就不详述了，主要说流程。抢占观众在点击抢占后发送请求给服务器，成功后改变自身UI，然后发送即时通讯（注明抢占字段的即使消息）给聊天室里的其他人。其他人通过即时通讯回调解析抢占消息刷新抢占UI。
观看视角：其他观众收到通知，解析为有人获得守护席通知，改变守护席UI。
弹幕聊天
字段需求：个人产品的需求是需要展示人物等级，用户名根据等级改变颜色且可点击。所以这里即时通讯就要传递用户名、等级、发言内容等字段。
发送者视角：发送者发送一条即时通讯消息，消息发送给聊天室里的所有用户。消息发送成功后在自己聊天列表添加一条消息。
接收者视角：接收者在接收到消息后，解析为聊天消息，在聊天列表添加一条消息。
观众与主播连麦
需求是最多支持三个连麦。那么这里就要记录主播连麦观众信息数组，这样可以更方便的管理主播的连麦观众。因为连麦也有即时性的特性，所以也用即时通讯实现。
先理清身份，连麦有三个身份：主播方、连麦观众方与普通观众方。
连麦观众方：发起连麦，等待主播同意；同意并获取主播拉流后跳转推流界面进行推流并小窗口展示播放主播画面。（注：这里推流和拉流的监听依旧要做好）。这里发起连麦会有几种拒绝状态：1.主播手动拒绝；2.请求超时；3.主播占线中；4.主播连麦人数已满；5.主播在PK中；6.主播连麦功能关闭。
主播方：收到连麦请求，同意后发送带有自己底链路拉流地址给连麦观众，并展示播放器，但没有画面；待收到连麦观众低链路拉流地址后播放，并做混流处理。同样要做好播放监听。
普通观众方：普通观众基本不要做什么，播放的是混流地址。
主播与主播的PK
个人认为主播与主播之间的PK相对于连麦要简单些。
这里也是三个角色：发起PK主播方、接收PK主播方与双方普通观众方。
发起PK主播方：发起PK，并发送自己低链路拉流地址；等待接收PK主播方同意，同意后，改变自己推流画面UI，并播放接收PK主播拉流地址，并做混流处理。也有几种拒绝状态：1.主播手动拒绝；2.请求超时；3.直播占线中；4.直播在PK中；5.主播在连麦中；6.主播PK功能关闭。
接收PK主播方：接收PK请求，同意后发送自己低链路拉流地址给发起PK主播，并改变自己推流UI和播放发起PK主播低链路拉流地址的小窗口，并要做好混流处理。
双方普通观众方：普通观众基本不要做什么，播放的是混流地址。
礼物展会层
礼物展示层主要展示礼物特效。这一块涉及到即时通讯、礼物编码设计和支付功能（内购）。在容我三思而后作。
拓展
重复登录
被踢方：收到重复登录回调，要么杀死app，要么通知直播模块底层控制器。获取导航栏控制器数组最后一个控制器（当前控制器），回退至根控制器。
登陆方：一进入直播模块就获取主播信息，如果是正在直播状态，就弹出是否继续直播提示框。是就直接跳转直播推流画面。
结语
· 直播还有很多知识点，这只是冰山中的一角。
