楊春文：小程序在直播產品中的技術應用

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文首發在雲+社區，未經許可，不得轉載。

自我介紹

我是騰訊的楊春文，老東家在百度，目前在深圳騰訊，作的主要產品是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