基于腾讯云简单的构建直播应用
不管是小程序 app,解决视频卡顿和视频处理,需要考虑很多的算法,以及视频层面的技术,需要投入很多的时间、财力、人力。自己做视频应用,某个直播用户开发黄色的小视频怎么办?需要请这方面算法领域的工程师做服务资源,而卡顿与性能、安全层面,由腾讯云来解决。腾讯云相当于发电厂,自己的工厂拿发电厂的电来生产我的产品,服务我的用户就够。
最低成本构建直播的小程序
从小程序层面分析,即是主播端和观众端。对于小程序开发者来说,主要的核心就是两个,推流与拉流,不需要建视频来转码、传输,因为非常麻烦。
基于腾讯云有以下几步,第一步需要申请腾讯云的直播服务,申请成本非常低,是配置化的事情。申请基于腾讯云的直播服务,会用加密等等给开发者应用层,自己构建应用,需要自己搭建后台。腾讯云提供线程代码,拿代码部署后台,通过后台生成开播地址,即主播端用的地址,以及观众端用的地址,这两个地址可以实现开播以及观看的体验过程。
如何生成开播地址以及播放地址?
例如在主播端需要有开播的地址,主播端的小程序通过地址,把视频推送到腾讯云里面,主要的基础服务在腾讯云这边,编码、解码、传输是通过腾讯云来做的。主播端通过 url 的地址推送到腾讯云,地址会有问题,有主播推流的地址,开发者构建的小程序。如果开发者拿到开播地址通过小程序把的视频流推送到这里面来,就存在地址有很多个终端,把视频存进来肯定会有问题。
如何做到主播端只有开发者的合法性呢?
腾讯云申请直播服务以后,腾讯云给签名 KEY,上面的服务器就是开发者自己的服务器,通过服务器,例如主播打开直播间,其实就是直播间的房间号,推流的地址主要跟房间一样的地址,肯定会存在风险,有人拿地址传输,就需要腾讯云官方给签名的 key,拿到房间号等的推流的 url 进行签名,给小程序这端。只有主播拿到签名后的地址才能把视频的流推到视频端,如果是别人拿到开发者的地址,没有办法对地址做签名,可能用推流的地址推到腾讯云,这时腾讯云不会接受的。过程会防止倒推流。如果过程需要团队,需要很庞大的团队,通过腾讯云给的服务,很简单的搭建应用。右边是观看的地址,原理跟主播端是一样的,这里面最核心的最重要的是腾讯云给的签名 Key,只要签名 key 不丢给其他的开发者,就没有办法进行签名。
最简单的一种方式需要自己部署自己后台,甚至今晚回去就可以开发直播出来,开发者自己测试可以在腾讯云控制后台,实时推流的地址或者拉流的地址,放到小程序的两端实现观看。如果做庞大的应用,可以做地址分发的逻辑,才需要做的第三步。包括代码的部署,还有自己的业务,有游戏直播,有美女直播等,需要开发者自己业务后端进行处理,音视频的处理交给腾讯云,卡顿与涉黄交给腾讯云处理。举个例子,我自己家里养小宠物,我自己到家里面简单部署监控,我自己家里的小狗小猫,非常容易实现,时间和技术的成本都非常低。
布局之痛
自己团队做直播应用的时候,所遇到的问题,第一是 yy 直播,第二个是映客,小程序里面做性能。最外层的组件播放器,其他的元素可以通过嵌在整个视频里面,消息、图象、右下角点赞都可以放在里面,如果是早期,只能实现左右两边的效果,视频和其他分开,其实不符合这一类型的应用场景,就非常的弱。通过官方实现的组件来给实现,官方提供的一种方案例如左下角的消息,随着用户发的评论,有动态的滚动过程,通过的方式,可以实现滚动,官方给提供 scrol 的,使用是比较痛苦的,包括右边点赞的动画,比较炫的效果也是比较难实现的。
怎么实现呢?可能会这种使用 canvas,原生的组件,用 canvas 来实现动态动态的效果。例如包括的动画,点赞动画的星,有大小的变化,包括星形,倾斜的角度,出现大致的代码,用 canvas 实现也遇到很大的问题——canvas 实现主要是把放在小程序里面,就能够感受得到手机的发热,问题都很严重,怎么解决问题呢?目前客户端实现的 canvas 和 web 实现的 canvas 在性能上面是有差异的。包括开发者一起来推动官方改进性能,以及开发体验上面的问题。
SetData 优化
setdata 优化分为逻辑层和视图层,分别是 WXML 和 WXSS,如果在右上角的逻辑层处理消耗比较多时间,就避免了渲染的线层和逻辑处理的线层产生的冲突,往往的情况在 h5 上面都是很纠结的性能处理问题,小程序提供方案,在性能和在体验上面给予帮助。
逻辑的处理层就是以 JS 代码,js 最后可能生成的虚拟道,前端开发的同学可能知道,虚拟道是 webview 的过程,最后通过 js 产生到这里,左边这块是小程序的代码,其实我这儿不是官方的代码,为阐述原理,左边是小程序代码最终运行的效果,在 webview 的操作每一字 setdata 都会产生 webview 的操作。
频繁 SetData 等于频繁 DOM 操作,超大数据 SetData,如果 DOM 操作非常的紧密,uai 会有延迟。一次 SetData 过程非常慢,小程序进入后台关闭的时候,小程序并没有把线程销毁,其实小程序还存在的微信小程序里面,如果开发者隐藏操作,其实背后是在运行的,这种情况下肯定是消耗开发者的机器资源,界面有问题,显示有延迟,手机发热非常严重,这是在平时的开发过程当中都会遇到问题。
主要做的就是避免这三种问题,避免频繁的 DOM 操作的例子,不停滚动的评论,以及弹幕的消息,第一版来做,一次返回多条消息,滚动展示的一面显示一条一条 SetData,每一次 SetData 操作就会产生 dom 操作,这是非常消耗成本的。一次拉多条,一次渲染多条,在小程序端做滚动,完成体验上面的权衡。
还例如直播利用,可能会打开首页,首页上面有直播列表,是实时更新的,还有隐藏的操作,不断的请求数据,不停的刷新列表,不停的进行隐藏式的操作,会对前面的直播间的的处理,也会造成冲突,除前页面签到后界面,推荐更新,推荐更新就是不停的渲染后台的数据,如果跳到直播间,前面的数据还在后台刷,隐藏的页面不停的更新数据,过程会造成很大的性能消耗。
大图片之殇
前面说到小程序渲染层,通过 webview 的方式存在,会存在图片的问题,如果大图片动不动一两兆,在整个系统里面会有问题,占内存。如果微信里面有上千个小程序,那怎么办?其实微信里面不存在的情况,微信小程序会定期的销毁,打开每小程序,每小程序都占内存,会把更老的销毁,如果小程序,如果图片特别的多,占用的内存特别多,可能就成为优先被销毁的要程序。
大的图片会造成页面之间切换快慢的问题,例如切到页面,如果没有图片,可能切换的过程是 100 多毫秒,中间放一张大的图片进去,变成 300 多毫秒,后面的图片不停的增多,切换的时间也在不停的多,小程序里面大图片造成切换卡顿慢的问题,还有内存占用过多,会存在被销毁的风险。
如果确实需要大图片,我建议大家不要定期的去销毁,例如图片,只要在的区域里面才不会销毁,若不在区域里面就会销毁,如果一直存在对性能的消耗很大。
预加载
数据预加载的过程,页面切换过程比较消耗时间,例如切换到下一个页面,还需要拉数据、做渲染,过程从 A 页面到 B 页面,然后再到数据,中间 A 切换到 B,这里面有一段时间的消耗,可能有几百毫秒,这段时间有消耗,为什么不利用这段时间做改善的事情呢?
A 页面切到 B 页面的过程当中,在 B 页面加载的过程中,直接从本地数据里面取到数据,不需要再发请求拉数据,在 B 页面里面进行切换以及的数据的处理和拉取,避免中间时间的消耗等等延迟的问题。
Q/A
Q:官方并没有给详细的解释。完成之后图片依旧无法生成,官方没有给详细的参数,最后是鼠标悬浮的时候才可以,官方文档需要完善的同时能不能对应,能不能有留言板给大家提供一些经验?
A:在开发者工具上明明可以的,为什么到真机上不行?给开发的 api 上面,给开发的代码上可能是一模一样的,但是实现上有差别的,真机上面的现象和开发者工具,因为开发者工具也是 web,在真机上就不是 web,这里面肯定有差异,也是遇到的问题,目前推荐官方来解决能够提供给 web 组件的,如果用其他的我觉得成很高,也没有必要,对本身的业务非常重要,也在极力地催,希望能够解决,目前来说,开发者说的问题还没有完全解决,只是不停的慢慢地解决,而且官方有重视,有意识提升的体验以及性能。
Q:想问一下杨老师,拉流到推流这边的问题。
A:拉流这边提供 3 种协议,ATMK 的延迟最低的,只有一到两秒,性能好可能在一秒内,但是存在的稳定性,还有其他受干扰的情况比较多;FLV 的延迟多一到两秒,但是的稳定性,包括并发性能等等方面是最稳定的,也是最好的;HIS 的延迟非常大,可能接近大几秒,以目前团队所折中的优势,以及劣势之后,主要选择 FLV 的格式来做,大概的延迟在 2 秒以内。目前小程序引发的量没有那么多,实际只有一秒多,非常的快,可能多并发,大型的应用,可能会有差别,但是我觉得的能力,腾讯云建设的非常好。
Q:微信小程序的开发应该有 10 兆左右,关于建模和打包以后的解决方案麻烦您讲一下。
杨春文:大概意思就是开发者们的包比较大,传不上去。开发小程序的建议是太大肯定会影响开发者整个包下载的过程,程序启动以后也会非常的慢,如果开发者是近 10 兆的包,非常大,小程序里面,主要建议,包里面主要放代码,开发者图片的资源尽量不要放包里面,例如做开发的都知道,我代码的体积非常小的,可能只占整个代码的百分之几,但是图片资源没有办法压缩到那么多的,没有办法压的太小,尽量少存图片,开发者说的我理解可能是库,开发者可以考虑一下,小程序不存在我的包里面,在应用里面动态的拉取库完成开发。不放在我的包里面,某库可能是 JS,JS 能不能做异步加载的形式,库不用放在小程序加载里面,因为体积比较大。
作者介绍:
杨春文,目前在深圳腾讯,做的主要产品是 web 相关。因为做 NOW 直播,所以会讲基于腾讯云的直播小程序,然后是小程序终端开发,总结一些经验点,更注重于开发者和一线工程师所关注的包括性能等等的开发经验。
本文转载自公众号云加社区(ID:QcloudCommunity)。
原文链接:
https://mp.weixin.qq.com/s/Pv9Xqg6vfPUp6FdjWQ605g
评论