h5直播

最新推荐文章于 2020-07-13 20:02:32 发布

weixin_30374009

最新推荐文章于 2020-07-13 20:02:32 发布

阅读量121

点赞数

文章标签：网络前端后端 ViewUI

原文链接：http://www.cnblogs.com/yzadd/p/6473736.html

版权

直播开发之旅

　　① 状态控制：
　　目前我们先考虑直播的三种状态：直播前，直播中，结束。

　　针对每个状态我们肯定会有不同的显示，这三种状态可以是三个页面，相互切换，或者一个页面，控制页面相关隐藏和显示。可是我们怎么知道，当前主播已经切换成某种状态了呢？通过轮询吗？当然不是，轮询肯定是可以实现的。不过我们用websocket，因为我们已经提前准备了websocket，所以我们可以通过服务端的推送websocket广播，当获取到的直播状态和当前状态不同，便进行相应切换。

　　但是有时候可能因为暂时的网络原因或者其他原因，websocket的广播消息，我们并没有获取到。所以可以让websocket间隔性的广播直播状态。

　　② 评论消息监听：
　　我们也通过websocket拉取评论消息，这里主要的问题在服务端压力上，有可能用户评论量很大的时候，服务器压力过大，出现断连的情况。也可能是用户网络断开，造成的断连。一方面后端通过他们的优化来提高承载力，一方面前端和后端进行配合优化。我们每次连接websocket服务器的时候，前端会通过接口，拿到当前承载量最小的服务器地址进行连接。 websocket如果断连了的话，是不会获得任何消息的，所以保证功能可以使用，我们还会针对websocket进行心跳检测（检查是否断开连接）。

　　③ 心跳重连
　　因为websocket可能会存在断开连接的情况，而这时候是不会触发任何事件的，所以我们不知道它是否断开了。那么我们设置一种消息类型，由前端发送给服务端，服务端如果返回了数据，就说明连接正常。如果连接断开了，我们再次去请求后端接口，拿到当前承载量最小的服务器地址，进行重连。设置一个间隔时间比如10秒，最后一次获取到服务器的消息后，如果10秒内没再收到消息，就进行一次检查，如果10秒内收到了，便重置这个时间。之前的博客写过比较详细的心跳检测：《初探和实现websocket心跳重连》

　　④ video
　　关于video，总结起来我们要解决的那些问题，或者有些不能解决的问题，归根到底是一个问题：兼容。兼容问题又可以分为两种：标签事件的兼容问题和浏览器表现的兼容问题。

　　先说video的事件兼容问题，之前测试过这一块，总之比较稳定和兼容性好点的事件如下图片圈出来的：

对，你没看错，目前对我来说好像就timeupdate比较靠谱，总之确实兼容性很差，这样会导致对video的可控性变得很低。

　　接着是浏览器的表现兼容问题，比如：在微信和QQ的内置浏览器里，播放视频会自动全屏，video标签也是永远浮在页面最上层，你根本控制不了。浮在最上层不只是X5浏览器，还有些手机只带的浏览器。视频源出现问题的表现，播放按钮的问题，都有不同。这些都是脱离我们代码本身，浏览器的设置，所以从代码层面上我们是没法解决的。之前出现这些问题的时候，当然我也会看下相关直播的公司的页面，看他们是怎么解决的。比如在微信这个流量大口他们有没有实现看起来实现不了的功能。实际结果是，这些厂家应该是微信有合作，进行了相关定制的。而我们本不是专门做直播的，所以没必要投入这种成本。

　　定制合作这个只是猜测，还不能百分百肯定，如果有谁知道，感谢告知一声!

⑤ 评论展示
　　本来我们想实现如下图的样式：

但是由于上面提到的问题，video浮在页面最上层，dom无法浮在video的上层。那么我们的评论就无法展示在上图的位置，所以无奈只有放到video下方去。根据我们的业务需求不同，目前只有这样，能勉强接受。

　　⑥ video推流监听
　　在文章最开始我们提到，推流会有一些不可控的情况，主播关闭摄像头，推送断流等，客户端断网。这个时候在H5端的表现就是卡住，肯定会卡住。一旦卡住之后，就算推流又重新开始了，video依然会卡在那里，不会有任何重新播放的样子。如果推流重新开始，用户自己点击控制条的暂停，再点击播放，又可以正常播放了。可我们不可能让用户一直点，因为你也不知道推流什么时候重新开始，或者什么时候不再

是断网状态。通过点击控制条的暂停，再点击播放便可以播放的规律，我们可以自己检查当前的状态，再用JS控制video暂停，再播放

var video = document.getElementById('video');
video.pause();
video.play();

　如何检查当前是卡住的状态呢？这里就用到我开始说的比较可靠的timeupdate事件。一旦用户是播放状态，监听timeupdate，通过对比currentTime轮询着来检查当前是否卡住。

var checkTime = null;
var checkLastTime = null;
var check = setInterval(function(){
    if(checkTime != null){
        if(video.paused){
            //如果是暂停状态
        }
        if(checkTime == checkLastTime || (checkTime== 0 && checkLastTime==0)){
            if(!video.paused){//如果是暂停状态，就忽略
                showTip('主播离开一会儿'); //提示一下用户
                video.pause();
                video.src = video.src;//重置src，否则ios不会再次播放
                video.play();
            }

        }
    }
    checkLastTime = checkTime;
}, 10000);

video.addEventListener('timeupdate', function(e){
    //每次play()都会触发一次timeupdate,所以需要加个条件判断
    if(checkTime != checkLastTime) hideShowTip();//隐藏上面主播离开的提示
    checkTime = e.target.currentTime;
});
但是这样仍然会有一些问题，比如当前检测到视频卡住了，JS控制重新播放，而当前还是没有获取到推流的话。浏览器会先loading获取视频，最后会失败显示下图的信息。我们的检查会轮询执行，所以下面的情况会一直循环，直到视频正常播放。

这样确实有点影响体验，但是目前无解。

　　如果用户不是全屏播放，页面下方会有提示用户等待。

　　如果是全屏那么就看不到提示，不过用户这个时候可能会关闭全屏，返回到页面上，这样仍然可以看到提示。

结语：

　　以上就是我所遇到的h5直播开发里，比较核心的地方。开发过程中有很多地方，感觉受到了充满“恶意”限制，需要用一些比较特别的方法去处理或者妥协。这一点对于下游的我们也是无可奈何，过程中，还是很有乐趣的，虽然最终效果并不是很好，但从指缝中，争取到的结果，很可贵。