zoukankan      html  css  js  c++  java
  • 杨春文:小程序在直播产品中的技术应用

    欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~

    本文首发在云+社区,未经许可,不得转载。

    自我介绍

    我是腾讯的杨春文,老东家在百度,目前在深圳腾讯,做的主要产品是web相关。我本身做NOW直播,所以会讲基于腾讯云的直播小程序,然后是小程序终端开发,总结一些经验点,更注重于开发者和一线工程师所关注的包括性能等等的开发经验。

    基于腾讯云简单的构建直播应用

    不管是小程序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能不能做异步加载的形式,库不用放在小程序加载里面,因为体积比较大。

    更多分享资料,请戳下面的链接:

    杨春文:小程序在直播产品中的技术应用.pdf

    问答
    小程序可以实现哪些音视频解决方案?
    相关阅读
    邹伟:如何开发一款小游戏
    朱展:腾讯云小程序解决方案
    刘翌:如何利用小程序技术解决企业销售难题

    此文已由作者授权腾讯云+社区发布,原文链接:https://cloud.tencent.com/developer/article/1117720?fromSource=waitui

  • 相关阅读:
    一往直前!贪心法
    Longest subarray of target sum
    动态规划-最长公共子序列/最长公共子串
    Short Encoding of Words
    Spiral Matrix
    Longest Repeating Character Replacement
    伤怀之美
    宁静是一种生产力
    POJ 2524 Ubiquitous Religions 【并查集】
    POJ 1611 The Suspects【并查集】
  • 原文地址:https://www.cnblogs.com/qcloud1001/p/9013368.html
Copyright © 2011-2022 走看看