自我介紹

我是騰訊的楊春文，老東家在百度，目前在深圳騰訊，做的主要產(chǎn)品是web相關(guān)。我本身做NOW直播，所以會(huì)講基于騰訊云的直播小程序，然后是小程序終端開發(fā)，總結(jié)一些經(jīng)驗(yàn)點(diǎn)，更注重于開發(fā)者和一線工程師所關(guān)注的包括性能等等的開發(fā)經(jīng)驗(yàn)。

基于騰訊云簡(jiǎn)單的構(gòu)建直播應(yīng)用

不管是小程序app，解決視頻卡頓和視頻處理，需要考慮很多的算法，以及視頻層面的技術(shù)，需要投入很多的時(shí)間、財(cái)力、人力。自己做視頻應(yīng)用，某個(gè)直播用戶開發(fā)黃色的小視頻怎么辦？需要請(qǐng)這方面算法領(lǐng)域的工程師做服務(wù)資源，而卡頓與性能、安全層面，由騰訊云來解決。騰訊云相當(dāng)于發(fā)電廠，自己的工廠拿發(fā)電廠的電來生產(chǎn)我的產(chǎn)品，服務(wù)我的用戶就夠。

最低成本構(gòu)建直播的小程序

從小程序?qū)用娣治觯词侵鞑ザ撕陀^眾端。對(duì)于小程序開發(fā)者來說，主要的核心就是兩個(gè)，推流與拉流，不需要建視頻來轉(zhuǎn)碼、傳輸，因?yàn)榉浅Ｂ闊?/p>

基于騰訊云有以下幾步，第一步需要申請(qǐng)騰訊云的直播服務(wù)，申請(qǐng)成本非常低，是配置化的事情。申請(qǐng)基于騰訊云的直播服務(wù)，會(huì)用加密等等給開發(fā)者應(yīng)用層，自己構(gòu)建應(yīng)用，需要自己搭建后臺(tái)。騰訊云提供線程代碼，拿代碼部署后臺(tái)，通過后臺(tái)生成開播地址，即主播端用的地址，以及觀眾端用的地址，這兩個(gè)地址可以實(shí)現(xiàn)開播以及觀看的體驗(yàn)過程。

如何生成開播地址以及播放地址？

例如在主播端需要有開播的地址，主播端的小程序通過地址，把視頻推送到騰訊云里面，主要的基礎(chǔ)服務(wù)在騰訊云這邊，編碼、解碼、傳輸是通過騰訊云來做的。主播端通過url的地址推送到騰訊云，地址會(huì)有問題，有主播推流的地址，開發(fā)者構(gòu)建的小程序。如果開發(fā)者拿到開播地址通過小程序把的視頻流推送到這里面來，就存在地址有很多個(gè)終端，把視頻存進(jìn)來肯定會(huì)有問題。

如何做到主播端只有開發(fā)者的合法性呢？

騰訊云申請(qǐng)直播服務(wù)以后，騰訊云給簽名KEY，上面的服務(wù)器就是開發(fā)者自己的服務(wù)器，通過服務(wù)器，例如主播打開直播間，其實(shí)就是直播間的房間號(hào)，推流的地址主要跟房間一樣的地址，肯定會(huì)存在風(fēng)險(xiǎn)，有人拿地址傳輸，就需要騰訊云官方給簽名的key，拿到房間號(hào)等的推流的url進(jìn)行簽名，給小程序這端。只有主播拿到簽名后的地址才能把視頻的流推到視頻端，如果是別人拿到開發(fā)者的地址，沒有辦法對(duì)地址做簽名，可能用推流的地址推到騰訊云，這時(shí)騰訊云不會(huì)接受的。過程會(huì)防止倒推流。如果過程需要團(tuán)隊(duì)，需要很龐大的團(tuán)隊(duì)，通過騰訊云給的服務(wù)，很簡(jiǎn)單的搭建應(yīng)用。右邊是觀看的地址，原理跟主播端是一樣的，這里面最核心的最重要的是騰訊云給的簽名Key，只要簽名key不丟給其他的開發(fā)者，就沒有辦法進(jìn)行簽名。

最簡(jiǎn)單的一種方式需要自己部署自己后臺(tái)，甚至今晚回去就可以開發(fā)直播出來，開發(fā)者自己測(cè)試可以在騰訊云控制后臺(tái)，實(shí)時(shí)推流的地址或者拉流的地址，放到小程序的兩端實(shí)現(xiàn)觀看。如果做龐大的應(yīng)用，可以做地址分發(fā)的邏輯，才需要做的第三步。包括代碼的部署，還有自己的業(yè)務(wù)，有游戲直播，有美女直播等，需要開發(fā)者自己業(yè)務(wù)后端進(jìn)行處理，音視頻的處理交給騰訊云，卡頓與涉黃交給騰訊云處理。舉個(gè)例子，我自己家里養(yǎng)小寵物，我自己到家里面簡(jiǎn)單部署監(jiān)控，我自己家里的小狗小貓，非常容易實(shí)現(xiàn)，時(shí)間和技術(shù)的成本都非常低。

布局之痛

自己團(tuán)隊(duì)做直播應(yīng)用的時(shí)候，所遇到的問題，第一是yy直播，第二個(gè)是映客，小程序里面做性能。最外層的組件播放器，其他的元素可以通過嵌在整個(gè)視頻里面，消息、圖象、右下角點(diǎn)贊都可以放在里面，如果是早期，只能實(shí)現(xiàn)左右兩邊的效果，視頻和其他分開，其實(shí)不符合這一類型的應(yīng)用場(chǎng)景，就非常的弱。通過官方實(shí)現(xiàn)的組件來給實(shí)現(xiàn)，官方提供的一種方案例如左下角的消息，隨著用戶發(fā)的評(píng)論，有動(dòng)態(tài)的滾動(dòng)過程，通過的方式，可以實(shí)現(xiàn)滾動(dòng)，官方給提供scrol的，使用是比較痛苦的，包括右邊點(diǎn)贊的動(dòng)畫，比較炫的效果也是比較難實(shí)現(xiàn)的。

怎么實(shí)現(xiàn)呢？可能會(huì)這種使用canvas，原生的組件，用canvas來實(shí)現(xiàn)動(dòng)態(tài)動(dòng)態(tài)的效果。例如包括的動(dòng)畫，點(diǎn)贊動(dòng)畫的星，有大小的變化，包括星形，傾斜的角度，出現(xiàn)大致的代碼，用canvas實(shí)現(xiàn)也遇到很大的問題——canvas實(shí)現(xiàn)主要是把放在小程序里面，就能夠感受得到手機(jī)的發(fā)熱，問題都很嚴(yán)重，怎么解決問題呢？目前客戶端實(shí)現(xiàn)的canvas和web實(shí)現(xiàn)的canvas在性能上面是有差異的。包括開發(fā)者一起來推動(dòng)官方改進(jìn)性能，以及開發(fā)體驗(yàn)上面的問題。

SetData優(yōu)化

setdata優(yōu)化分為邏輯層和視圖層，分別是WXML和WXSS，如果在右上角的邏輯層處理消耗比較多時(shí)間，就避免了渲染的線層和邏輯處理的線層產(chǎn)生的沖突，往往的情況在h5上面都是很糾結(jié)的性能處理問題，小程序提供方案，在性能和在體驗(yàn)上面給予幫助。

邏輯的處理層就是以JS代碼，js最后可能生成的虛擬道，前端開發(fā)的同學(xué)可能知道，虛擬道是webview的過程，最后通過js產(chǎn)生到這里，左邊這塊是小程序的代碼，其實(shí)我這兒不是官方的代碼，為闡述原理，左邊是小程序代碼最終運(yùn)行的效果，在webview的操作每一字setdata都會(huì)產(chǎn)生webview的操作。

頻繁SetData等于頻繁DOM操作，超大數(shù)據(jù)SetData，如果DOM操作非常的緊密，uai會(huì)有延遲。一次SetData過程非常慢，小程序進(jìn)入后臺(tái)關(guān)閉的時(shí)候，小程序并沒有把線程銷毀，其實(shí)小程序還存在的微信小程序里面，如果開發(fā)者隱藏操作，其實(shí)背后是在運(yùn)行的，這種情況下肯定是消耗開發(fā)者的機(jī)器資源，界面有問題，顯示有延遲，手機(jī)發(fā)熱非常嚴(yán)重，這是在平時(shí)的開發(fā)過程當(dāng)中都會(huì)遇到問題。

主要做的就是避免這三種問題，避免頻繁的DOM操作的例子，不停滾動(dòng)的評(píng)論，以及彈幕的消息，第一版來做，一次返回多條消息，滾動(dòng)展示的一面顯示一條一條SetData，每一次SetData操作就會(huì)產(chǎn)生dom操作，這是非常消耗成本的。一次拉多條，一次渲染多條，在小程序端做滾動(dòng)，完成體驗(yàn)上面的權(quán)衡。

還例如直播利用，可能會(huì)打開首頁，首頁上面有直播列表，是實(shí)時(shí)更新的，還有隱藏的操作，不斷的請(qǐng)求數(shù)據(jù)，不停的刷新列表，不停的進(jìn)行隱藏式的操作，會(huì)對(duì)前面的直播間的的處理，也會(huì)造成沖突，除前頁面簽到后界面，推薦更新，推薦更新就是不停的渲染后臺(tái)的數(shù)據(jù)，如果跳到直播間，前面的數(shù)據(jù)還在后臺(tái)刷，隱藏的頁面不停的更新數(shù)據(jù)，過程會(huì)造成很大的性能消耗。

大圖片之殤

前面說到小程序渲染層，通過webview的方式存在，會(huì)存在圖片的問題，如果大圖片動(dòng)不動(dòng)一兩兆，在整個(gè)系統(tǒng)里面會(huì)有問題，占內(nèi)存。如果微信里面有上千個(gè)小程序，那怎么辦？其實(shí)微信里面不存在的情況，微信小程序會(huì)定期的銷毀，打開每小程序，每小程序都占內(nèi)存，會(huì)把更老的銷毀，如果小程序，如果圖片特別的多，占用的內(nèi)存特別多，可能就成為優(yōu)先被銷毀的要程序。

大的圖片會(huì)造成頁面之間切換快慢的問題，例如切到頁面，如果沒有圖片，可能切換的過程是100多毫秒，中間放一張大的圖片進(jìn)去，變成300多毫秒，后面的圖片不停的增多，切換的時(shí)間也在不停的多，小程序里面大圖片造成切換卡頓慢的問題，還有內(nèi)存占用過多，會(huì)存在被銷毀的風(fēng)險(xiǎn)。

如果確實(shí)需要大圖片，我建議大家不要定期的去銷毀，例如圖片，只要在的區(qū)域里面才不會(huì)銷毀，若不在區(qū)域里面就會(huì)銷毀，如果一直存在對(duì)性能的消耗很大。

預(yù)加載

數(shù)據(jù)預(yù)加載的過程，頁面切換過程比較消耗時(shí)間，例如切換到下一個(gè)頁面，還需要拉數(shù)據(jù)、做渲染，過程從A頁面到B頁面，然后再到數(shù)據(jù)，中間A切換到B，這里面有一段時(shí)間的消耗，可能有幾百毫秒，這段時(shí)間有消耗，為什么不利用這段時(shí)間做改善的事情呢？

A頁面切到B頁面的過程當(dāng)中，在B頁面加載的過程中，直接從本地?cái)?shù)據(jù)里面取到數(shù)據(jù)，不需要再發(fā)請(qǐng)求拉數(shù)據(jù)，在B頁面里面進(jìn)行切換以及的數(shù)據(jù)的處理和拉取，避免中間時(shí)間的消耗等等延遲的問題。

Q/A

Q：官方并沒有給詳細(xì)的解釋。完成之后圖片依舊無法生成，官方?jīng)]有給詳細(xì)的參數(shù)，最后是鼠標(biāo)懸浮的時(shí)候才可以，官方文檔需要完善的同時(shí)能不能對(duì)應(yīng)，能不能有留言板給大家提供一些經(jīng)驗(yàn)？

A：在開發(fā)者工具上明明可以的，為什么到真機(jī)上不行？給開發(fā)的api上面，給開發(fā)的代碼上可能是一模一樣的，但是實(shí)現(xiàn)上有差別的，真機(jī)上面的現(xiàn)象和開發(fā)者工具，因?yàn)殚_發(fā)者工具也是web，在真機(jī)上就不是web，這里面肯定有差異，也是遇到的問題，目前推薦官方來解決能夠提供給web組件的，如果用其他的我覺得成很高，也沒有必要，對(duì)本身的業(yè)務(wù)非常重要，也在極力地催，希望能夠解決，目前來說，開發(fā)者說的問題還沒有完全解決，只是不停的慢慢地解決，而且官方有重視，有意識(shí)提升的體驗(yàn)以及性能。

Q：想問一下楊老師，拉流到推流這邊的問題。

A：拉流這邊提供3種協(xié)議，ATMK的延遲最低的，只有一到兩秒，性能好可能在一秒內(nèi)，但是存在的穩(wěn)定性，還有其他受干擾的情況比較多；FLV的延遲多一到兩秒，但是的穩(wěn)定性，包括并發(fā)性能等等方面是最穩(wěn)定的，也是最好的；HIS的延遲非常大，可能接近大幾秒，以目前團(tuán)隊(duì)所折中的優(yōu)勢(shì)，以及劣勢(shì)之后，主要選擇FLV的格式來做，大概的延遲在2秒以內(nèi)。目前小程序引發(fā)的量沒有那么多，實(shí)際只有一秒多，非常的快，可能多并發(fā)，大型的應(yīng)用，可能會(huì)有差別，但是我覺得的能力，騰訊云建設(shè)的非常好。

Q：微信小程序的開發(fā)應(yīng)該有10兆左右，關(guān)于建模和打包以后的解決方案麻煩您講一下。

楊春文：大概意思就是開發(fā)者們的包比較大，傳不上去。開發(fā)小程序的建議是太大肯定會(huì)影響開發(fā)者整個(gè)包下載的過程，程序啟動(dòng)以后也會(huì)非常的慢，如果開發(fā)者是近10兆的包，非常大，小程序里面，主要建議，包里面主要放代碼，開發(fā)者圖片的資源盡量不要放包里面，例如做開發(fā)的都知道，我代碼的體積非常小的，可能只占整個(gè)代碼的百分之幾，但是圖片資源沒有辦法壓縮到那么多的，沒有辦法壓的太小，盡量少存圖片，開發(fā)者說的我理解可能是庫，開發(fā)者可以考慮一下，小程序不存在我的包里面，在應(yīng)用里面動(dòng)態(tài)的拉取庫完成開發(fā)。不放在我的包里面，某庫可能是JS，JS能不能做異步加載的形式，庫不用放在小程序加載里面，因?yàn)轶w積比較大。