版本记录

版本号	时间
V1.0	2018.11.25 星期日

前言

最近在两家公司任职做的都是直播相关的业务，音视频的门槛现在是越来越低，很多的三方视频云等都支持直播相关的业务，从推流拉流到美颜、滤镜、贴纸甚至人体识别等都有很多的第三方公司支持。但是，好一点的公司还是自己研发自己的视频云SDK，这样可以不受三方束缚，定制性也更好些，相信看过我写过的文章的人，发现了我写过和直播相关的技术，这里我另起一个模块和大家继续分享直播相关技术，感兴趣的就给个赞支持一下。感兴趣看上面几篇文章。
1. 直播技术（一） —— 移动直播连麦几种处理方案（一）
2. 直播技术（二） —— 直播间的上下切换（一）

PK功能

现在很多的直播平台类APP都有PK的功能，这里首先要和大家说下：

PK之前一定要先连麦，根据产品业务逻辑
- 第一，如果用户当前正在连麦聊天什么的，可以在连麦基础上向对方发起PK邀请。
- 第二，如果用户在直播间内部没有进行任何连麦，那么可以点击PK按钮直接发起PK，这个时候也是向对方发起PK邀请，如果对方同意要首先连麦，然后在走PK相关的逻辑。

PK流程

1. PK的邀请

都什么用户可以发起PK？

首先，主播和主播之间可以发起PK，其次，主播和用户之间也可以发起PK，但是用户和用户之间不能发起PK，因为用户和用户之间不能连麦，不能连麦那么一定就不能发起PK。而且用户和用户之间连麦也没有意义，毕竟秀场是给大家看的，两个用户之间连麦，是只有他们自己可以看见，那有什么意义？不会给平台带来任何流量和利好。

PK发起方首先要找到目标，也就是通过产品内部途径找到向谁发起PK，找到以后是将邀请PK接口请求服务器，接下来就是服务器的处理。

2. PK接收方处理

在上面服务器接收到PK要求的接口请求以后，会向目标用户发送消息，这个走的是消息，可以称为PK邀请消息。这里在目标用户端就要弹窗指示是否接受邀请。这里就需要用户进行操作了。

如果用户拒绝了，那么也是将这个拒绝发送给服务器，这里有个超时问题，如果用户什么都不操作，这时候服务端需要设置一个超时时间，规定时间内没有任何操作和反馈，默认就是拒绝了，然后服务器以消息的形式告诉邀请方对方已拒绝不能PK。
如果用户同意了，那么也是发给服务器，然后服务器以消息的形式发给发起方，表示对放以接收PK邀请了。

这里还需要做的一个就是服务器需要给看播端用户发送准备PK的ready消息，告诉看播端两个PK方马上可以开始PK了。

3. PK中逻辑处理

这个就和产品的功能定义有很大关系了。

倒计时处理：一般都有倒计时，这里需要说明的是这个倒计时不能以本地时间为准，一定要以接口或者消息的服务器绝对时间为准，因为本地可以调整时间，造成了显示PK时间的异常。
机型影响：PK开始以后，就需要将在一个直播间内部拉两路流，这个对手机和网络要求不低，不过经过测试5s以上的手机还可以，所以影响并不大，但是由于耗能太高，可能手机会掉电严重和发热，不过都在可以接受范围之内。
异常处理：PK中不可能完全没有意外，受网络和PK方用户等影响出现异常甚至终端是很正常的，需要我们进行额外的处理，处理的时候走的也都是消息。收到异常的消息就需要走终端PK的相关逻辑。一般都包括哪些异常情况呢？
- PK双方连麦中断（这个就包含很多情况，可能是app异常crash，也可能是断网等）
- 主播踢人（这个要看具体产品需求了，很多产品主播是可以踢人的）

4. PK结束

PK结束以后，不同的产品定义是不同的，有的产品是直接回到了原先正常的直播间，还有的产品是为了趣味性增加了惩罚时间等等。

PK结束以后PK双方要向服务器发送接口请求，返回PK的结果，这个要以服务器结果为准，返回结果以后要显示对应的结果。

看播端要收到PK结束的消息，然后看播端也要请求相同的结果并展示。这个时候PK结束了，如果没有惩罚那么就直接走PK结束的逻辑了，如果有惩罚截断，就需要根据产品的定义走惩罚逻辑，这个和业务是强相关的。

总结

对于PK没什么难的，主要是把握住PK流程，什么时候干什么事，把握住消息和接口的相关处理，处理好异常情况，其他的就没什么了。

PK比较麻烦的是走一遍流程比较长，特别是修改bug和QA测试的时候，走一遍流程很繁琐，特别是偶现的异常问题，并不好排查。

后记

本篇主要讲述的是PK的流程，由于保密等原因，只能简单的说下，具体其他的需要工程实践自己去体会和总结，感兴趣的给个赞或者关注~~~

直播技术（三） —— 直播间的PK流程（一）