- Weex如何支撐200w+同時在線的優(yōu)酷貓晚直播？

如圖所示，雙十一直播會場的直播視頻是嵌入到一個天貓電視機熒幕內的。實現(xiàn)方式是在自定義video標簽之上覆蓋一個天貓電視機圖片，使得視頻只從帶圓角的框中露出。?

這個實現(xiàn)方式在iOS端是沒問題的，在Android上卻失效了; 視頻和圖片的層級存在問題，在Android上視頻的四個邊角仍然會透出來，視覺上非常難看。

我們的解決辦法是給自定義播放器組件添加"borderRadius"屬性，將UED設計稿中的電視機圖片圓角值量出來，設置給自定義video標簽，把這個值透傳到Native層，經(jīng)過750px轉換之后，將視頻VideoView在Native端直接切出合適的圓角。

最終，呈現(xiàn)出來的帶圓角視頻畫面與電視機圖片的圓角完美契合，看上去就像是一體的。

懶加載

Weex直播間是默認是豎屏的，但是也可以轉屏幕進入橫屏狀態(tài)。最開始進入Weex直播間時，舊邏輯是同時初始化豎屏下的布局和橫屏下的布局，耗時比較長。我們的修改是進入直播間時只初始化豎屏下需要的組件，將橫屏下需要的組件延遲加載，真正需要時才創(chuàng)建和初始化。

優(yōu)化冗余布局

優(yōu)化減少Layout層級，將設置Visibility為gone的冗余View全部刪除。

此外，Weex直播會場頁也做了大量的層級/View精簡的動作，兩者結合起來最終使得加載體驗有了很大的提高。

飄贊動畫優(yōu)化

直播間的點贊圖標是一個Native封裝的Weex Component，當用戶手動點擊或者收到其他用戶的點贊推送時，點在圖標會飄出若干個紅心或者服務端下發(fā)的其他圖片。

粗略一看點贊功能實現(xiàn)的沒有什么問題，但是在晚會預演的高并發(fā)條件下問題就暴露出來了，由于用戶量太大，點贊推送消息太多，Android端的點贊動畫會變得非?？D。

我們的解決辦法是做了一個Orange開關，在較低性能的機器上減少或者屏蔽飄贊動畫；收到點贊消息推送后，不再立即飄出點贊動畫，而是點贊數(shù)大于某個閾值，或者大于某個時間間隔才飄出動畫，減少端上的渲染壓力。

此外，我們注意到飄贊動畫是飄出顯示區(qū)域之后直接銷毀，需要飄出新動畫時再創(chuàng)建新的圖片，我們有考慮引入對象池的技術預先分配一些動畫幀并復用，但是由于時間關系未能發(fā)布到線上。

1?zcache將Weex bundle JS，圖片等靜態(tài)資源通過zcache推送到客戶端上。

（1） 減輕了貓晚當天，客戶端請求服務端拉取資源的壓力

（2）由于待請求的資源就在本地，大大提高了頁面渲染的速度

（3） 提高了頁面加載成功率

2?請求合并由于某些mtop接口功能龐雜，Weex和Native代碼都要請求，且調用時序無法確定。我們封裝了一個Mtop Weex module，兼顧mtop請求和DataPool的功能，Weex和Native代碼都通過這個module來發(fā)出mtop請求；當某個請求發(fā)出之后，短期內對同一個接口的重復請求會被緩存; 第一個請求數(shù)據(jù)返回之后，結果會通知給所有被緩存的mtop請求方。通過這個小小的優(yōu)化，我們將服務端QPS壓力降低了十多萬。

3?貓晚當天，只請求最低限度的服務端接口，不再請求諸如“直播間預告訂閱”之類的非必要接口。

最終，優(yōu)酷的雙11直播取得較好的成績：

1.助力天貓雙11，引導點擊用戶655萬。

2.貓晚直播同時在線達209萬。

我們在直播會場的關鍵路徑和優(yōu)酷直播播放器均加上了埋點信息, 根據(jù)統(tǒng)計信息：