自我介紹

我是騰訊的楊春文，老東家在百度，目前在深圳騰訊，做的主要產品是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能不能做異步加載的形式，庫不用放在小程序加載里面，因為體積比較大。