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

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

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

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

懶加載

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

優(yōu)化冗余布局

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

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

飄贊動畫優(yōu)化

直播間的點(diǎn)贊圖標(biāo)是一個(gè)Native封裝的Weex Component，當(dāng)用戶手動點(diǎn)擊或者收到其他用戶的點(diǎn)贊推送時(shí)，點(diǎn)在圖標(biāo)會飄出若干個(gè)紅心或者服務(wù)端下發(fā)的其他圖片。

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

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

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

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

（1） 減輕了貓晚當(dāng)天，客戶端請求服務(wù)端拉取資源的壓力

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

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

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

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

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

1.助力天貓雙11，引導(dǎo)點(diǎn)擊用戶655萬。

2.貓晚直播同時(shí)在線達(dá)209萬。

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