第八章 交互技術，8.3 2016雙11前端突破(做者：天貓前端團隊)

8.3 2016雙11前端突破

前言

2016 年天貓前端相比去年有了很是多不一樣維度的突破，主要能夠分爲四大類大類：

1. 穩定性、監控

2. 極致的性能優化

3. 業務創新 / 平臺建設

4. 技術創新 / 互動

 

 

1. 穩定性、監控

 

商品到每一個用戶瀏覽的每一個環節都有監控，尤爲在針對消費者體驗上的 TES，讓前端在消費者真實瀏覽的過程中也可以有更進一步的分析在不一樣環境下消費者實際的體驗。以及從服務器 Wormhole 渲染層進行了一系列的穩定性、監控。

 

1.1 Wormhole雙11會場穩定性保障

Wormhole承載了2016天貓，淘寶等BU的雙11會場頁面渲染職能，整個體系鏈路橫跨了前端開發、存儲、渲染、CDN等不一樣的領域，在雙11活動中系統可訪問性變得尤其重要。爲了確保雙11會場頁面可以在各類極端場景下還可以順利打開，wormhole作了很是多的穩定性容災方案。包括去除單點依賴、HTTPS防劫持，動態調節CPU利用率、數據鏈路OSS依賴容災以及集羣徹底沒法服務後的終極打底方案等。

 

1.1.1 異地多活模式

Wormhole 是一個CDN前置的無狀態靜態頁面渲染服務，從簡單和維護成本角度出發，沒有接入集團的單元化部署策略，而是採用異地多機房部署的模式，藉助CDN回源策略實現異地多活。

 

1.1.2 HTTPS改造防劫持0-0

爲了不用戶訪問鏈路被IDC劫持，Wormhole 完成了全HTTPS的改造，包括從CDN到用戶端以及從CDN回渲染源站的鏈路，實現完整的HTTPS 訪問鏈路，避免中間被劫持，形成用戶訪問故障。1源站負載動態調節

在雙11的場景下，爲了保證0點時刻用戶端可以及時訪問到最新的頁面（活動發佈、價格透出、秒殺等），CDN的緩存和用戶端緩存都要求即時實效，在瞬間產生大量的回源請求，給 Wormhole 渲染源站帶來短期的高負載，在保證渲染實時性的同時，Wormhole 根據當前系統的負載動態的使用歷史渲染緩存（本地磁盤、遠程OSS），來下降應用的渲染負載，保障服務的穩定性。

 

1.1.3 數據鏈路OSS依賴容災

Wormhole 依賴阿里集團的OSS做爲數據存儲服務，包括模塊、頁面以及投放數據，以儘量簡單的架構來保障服務的可擴展性，提高可維護性。對於OSS的依賴，Wormhole 提供了兩層穩定性保障：

1. OSS異地主備部署，避免單點故障；
2. OSS數據本地內存、磁盤容災備份，在OSS故障異常時，能夠直接使用本地緩存數據提供服務，保障總體服務的可用性；

 

1.1.4 頁面終極打底方案

爲了不在 Wormhole 渲染服務異常的狀況，咱們針對渲染的結果也作了兩層的容災策略，即

1. 渲染結果本地磁盤容災；
2. 遠程OSS 容災。

在應用異常時，能夠經過本地Tengine的容錯設置，讀取本地磁盤的渲染結果提供服務，或者在極端嚴重的狀況下，經過切換CDN回源的方式，將CDN總體回源到災備OSS，使用歷史渲染頁面繼續提供服務。

 

1.2 TES技術體驗平臺

TES技術體驗平臺，致力於提供讓技術及業務同窗都能準確及直接觀察、瞭解及分析業務前臺頁面狀態的能力。從穩定性、性能、體驗三個維度來全面掌握業務的運行及使用狀況，同時從多維度定義一套符合用戶實際體驗的指標體系，來描述一個頁面的使用運行狀態。

 

1.2.1 突破傳統

縱觀在前端領域，都會存在性能監控及頁面監控等多類系統，但存在幾個未考慮或不足的問題：

1.  頁面加載性能只是頁面「好壞」的一個維度，缺少對頁面體驗的關注，缺乏能夠衡量用戶真實體驗的指標
2.  只能反應單頁面問題，沒法以業務的視角查看整個業務、整條鏈路的體驗和質量
3.  徹底面向開發者，非技術的業務同窗沒法經過簡單的方式去了解本身業務的使用狀態
4.  缺乏對一個業務從穩定性、性能及體驗的綜合性可量化評分體系

TES吸收了基礎性能及監控系統的功能，同時提供了體驗維度的監控及數據展示，分別從FPS、CPU、電量使用等可能影響體驗的因素進行監控和彙總。提供全局實時監控能力，監控頁面的穩定性，如資源加載、接口異常、JS報錯及crash等。豐富性能展現維度。

 

1.2.2 業務歸一

TES平臺的設計是從業務的角度出發，當頁面發佈上線後 TES 自動能分析及概括頁面所屬的業務，同時從垂直業務及活動進行分類，方便開發及業務同窗進行查看對應業務的運行狀況。

 

雙11期間經過TES系統實時發現多處線上圖片連接、資源鏈接以及接口穩定性等問題，同時提供了多端的監控埋點，統計分析接口數據打底以及鏈路狀況等。

 

1.2.3 加載性能

雙11會場在客戶端內以WEEX狀態呈現，同時支持WEB瀏覽器訪問，從總體能夠觀察到雙11全部頁面的總體性能的狀況，是否達標，同時從在對單個頁面有較詳細的性能分析。

1.2.4 體驗性能

目前全部的頁面監控對體驗都沒有比較好的採集以及評估方式，目前TES會結合各種影響體驗的因素，如FPS、大圖大資源、CPU執行狀況以及耗電量等，同時後續會完善更多合理的指標來完善體驗指標的整理，目前以FPS數值爲主。

 

2. 極致的性能優化

從H5到React Native，再到Weex，阿里在性能、體驗優化的道路上嘗試了各類方案，從去年雙11到今年雙11，在底層上咱們完成了許多重要優化，保障雙11的秒開目標。

 

2.1 目標

頁面加載時間pageLoad

天貓Mobile性能優化的核心衡量指標是pageLoad，它是一個webview實現的相似JS的onload的事件，在iOS下對應webViewDidFinishLoad，在android下對應onPageFinished。

onload和pageLoad的差別主要是在onload事件裏同步執行的js、加載的資源都會被計入到pageLoad內，而onload事件裏執行代碼一般就是特地作了懶加載處理，咱們能夠在onload裏包一層setTimeout來解決：

 

window.addEventListener('load', ()=>{

  setTimeout(()=>{

    //load assets\data...

  }, 0)

})

 

天貓pageLoad目標經歷了多個階段，從15年2月以前的2s到15年5月的1.5s，一直到目前的1s。

 

2.2 首屏可交互時間

pageLoad和onload同樣都是一個瀏覽器實現的通用事件，和onload同樣事件促發不等於頁面真實加載完成。咱們須要又一個能夠衡量用戶真實感覺的首屏渲染時間指標，最終選擇了基於代碼埋點，代碼中加入埋點並上報，在模塊加載容器上添加setter來監聽模塊加載狀態變化的方案儘量減小對業務的侵入，且不受模塊刪減、調整影響，模塊的大體寫法以下：

 

class Module{

  constructor(){

    ...//數據加載 & 渲染

    this.readyState = 'rendered'; //標識該模塊已經渲染完成

    ...//事件綁定

    this.readyState = 'complete'; //標識該模塊已經處於可交互狀態

  }

}

 

2.3 體驗指標FPS

除了以上2個描述加載速度的指標之外，咱們還實現了一個FPS指標，用戶衡量頁面的滾動流暢性。對於FPS的統計方案和業界一致，根據requestAnimationFrame之間的時間差值來計算。

由於用戶瀏覽的過程會持續滾動，而埋點上報的數據量有限，咱們選擇在客戶端完成統計計算，上報計算後的統計學指標的方案，包括：最小值、最大值、均值、衆數和中位數，而上報的時機選在了每一次頁面離開的時候，實現上結合了visibilitychange和pagehide這2個事件，保證覆蓋各個移動端環境。

 

2.4 底層優化點

2.4.1 HTTP2

HTTP2能夠帶來多路複用、頭部壓縮、服務端推送能力、請求優先級控制等優勢。這一年咱們完成了阿里CDN和統一接入層的HTTP2部署，同時在客戶端優化了HTTP2的命中率，目前天貓核心域名的HTTP2命中率已經達到97%+，再加上咱們完成了大範圍的域名收斂，整個頁面的域名收斂到了5個之內，更好得發揮了HTTP2多路複用的優點，最終HTTP2帶來的性能收益在250ms+。

2.4.2 HTTPDNS

域名解析在移動端是一個很是耗時的過程，且根據網絡狀況波動很大，手淘貓客對此作了優化：由服務端下發一份域名和ip的對應關係，而後客戶端直接經過ip訪問，跳過域名解析的過程，在這套現成技術上，咱們完成了天貓核心域名的下發，同時完成域名收斂，保證頁面用到的域名均在HTTPDNS執行列表之中，最終性能提高100ms+。

2.4.3 自動化的預加載

手淘貓客提供了2種預加載方案zcache和packageApp，目前用的主要是zcache，由於平臺默認提供的是人肉的發佈流程，致使線上使用率很低，即便用了也難以堅持長期更新，爲此咱們開發了一套自動化的預加載策略：按頁面訪問流量進行排序，自動預加載前N個頁面用到的資源，大體流程以下：

 

2.5 現階段成果

2.5.1 Weex

在技術上Weex整個頁面只有一個bundle.js，全部的數據都異步獲取，經過預加載技術將bundle.js提早下發到客戶端之後，除了數據之外整個加載過程就再也不存在任何assets加載，雙11會場中基於Weex的會場佔比：99%+，總體秒開率在90%以上：

◦ Weex 主會場秒開率

     ◦ 秒開率峯值（00:00）：總體 96.9%（278.8ms）、iOS 99.4%（146.4ms）、Android 93.4%（411.1ms）

     ◦ 秒開率均值：總體 94.4%（367.6ms）、iOS 99.0%（177.0ms）、Android 91.8%（473.3ms）
 

◦ Weex 全部會場秒開率

     ◦ 秒開率峯值（00:49）：總體 92.4%（490.7ms）、iOS 97.4%（291.6ms）、Android 87.5%（689.8ms）

     ◦ 秒開率均值：總體 83.9%（651.9ms）、iOS 94.5%（368.0ms）、Android 78.6%（797.4ms）

 

2.5.2 H5

天貓H5頁面主要分爲2種模式，一種是靜態頁面+異步數據，另一種是服務端同步渲染：

1. 對於第一種模式，運用的頁面較少，以天貓首頁爲例，落地各個優化點之後秒開率達到90%+，pageLoad均值在800ms+。

2. 對於絕大部分服務端同步渲染的頁面，目前優化後的pageLoad極限在1.1s左右，和同步渲染的首屏內容的複雜度正相關，在1.1s~1.6s之間波動。

 

3. 業務創新 / 平臺建設

面對日益複雜的業務上透過產品化的方式解決當前的問題，從過去靜態化千人一面的貨架形式走向千人千面的個性化，商品個性化到樓層個性化，全網單統一投放到區域定投等，結合現有平臺方式解決更復雜的業務問題。

 

3.1 區域化服務

各個行業統一區域化邏輯，造成一套通用的可擴展的區域化服務，包括區域優惠、區域庫存、區域定投等，而這些能力都依賴城市定位，因此咱們要作的第一步就是統一各個行業的定位邏輯，這裏的統一包含幾個層面：

3.1.1 定位邏輯的統一

定位的判斷來源主要包括如下幾個：用戶選擇、ip、默認收貨地址、gps、打底城市，須要統一這幾個判斷來源的組合規則和順序，統一後的規則以下圖所示:

3.1.2 雙11業務落地

區域化底層能力之上，實現了斑馬平臺級的模塊區域定投功能，運營能夠針對任意一個模塊開啓區域定投，並在雙11會場中投入使用，業務流程以下：

 

3.2 簡單高效的個性化產品方案

 

一個模塊是完整的最小業務粒度單位，一般用一個模塊來展示一批相關聯的商品，如『國際食品』會場的『早餐拍檔』就是一個模塊，爲用戶展示麥片、奶粉等早餐相關商品。

因爲是否個性化並不是由開發者決定，所以最好的方式就是透過共通的組件來處理數據，增大複用性，大體流程圖以下：

 

固然，這只是數據流通的基本原理，要實現以上功能，還有如下細節須要處理：

1. 去重問題，同頁面使用多個模塊可是內容不能重複。
2. 合併請求，優化性能。
3. 容災打底方案，任何請求都有由於網絡抖動、延遲、接口錯誤所形成掛掉的狀況。

 

3.3 模塊間個性化

以上模塊內個性化效果仍是有限，若能在模塊順序個性化可以達到更好的效果，以下圖所示：

 

 

4. 技術創新 / 互動

4.1 Weex

1754 張雙11會場頁面中（統計了天貓和淘寶），Weex 頁面數爲 1747 佔比 99.6%。手淘 iOS/Android 分別有 83.5%/78.3% 版本（UV）啓用了 Weex 會場，手貓 iOS/Android 分別爲 91.7%/87.9% 版本（UV）。Weex 覆蓋了包括主會場、分會場、分分會場、人羣會場 等在內幾乎全部的雙11會場業務。

 

4.2 業務支撐

雙11的會場結構大體爲：會場框架（框架 + 主會場、所有會場、必搶、清單、個人雙11）、分會場、其餘會場（分分會場、人羣會場等）。

 

4.3 會場框架

Weex 支撐雙11業務首要解決的是會場框架及其交互形式：

1. 交互主流程：

     1. 非 push 方式（框架Tab 切換）：主會場 - 所有會場 - 必搶 - 清單 - 個人雙11

     2. push 方式：主會場 - 分會場 - 主會場

2. iOS 考慮到內存開銷，需嚴控打開的主分會場weex頁面，定爲 n 級可配，默認爲 5；同時 iOS 會場框架爲單實例，也是出於內存的考慮；Android 連續打開 30 級以上 Weex 頁面，未見內存異常增加，無需特殊方案

圖 - 會場框架交互

 

4.4 穩定性保障

Weex 的首要挑戰就是穩定性，或者說保障 Weex 會場最大限度不降級。

 

4.5 會場壓測

* 壓測場景

    1. 5個200 坑位的普通會場頁面，1 全景圖會場頁面，1 曝光埋點壓測頁面，1 直播會場頁面

    2.頁面中提供連接，可以按順序進行 push 跳轉

* 壓測方案 

    1. 主鏈路（首頁->店鋪->詳情->購物車）作一遍操做，讓內存緩存佔滿，記下內存值 M0

    2. 進入Weex 頁面，滑動到底部，滑動到頂部，記下 M1；點擊跳轉按鈕，跳轉到下一個頁面

    3. 重複步驟 2，讓全部的頁面進行壓棧；全景圖->p1p2p3p4->直播->p1p2p3p4->UT

* 壓測結果：iOS 經過，Android 經過

    1. 測試過程手淘手貓均未出現由於壓棧致使的 Crash，穩定性能夠保證；

    2. Android低端機壓棧過多會致使體驗較差，以後也會引入相似 iOS VC 層級控制；

 

4.6 穩定性數據

2016.11.11，Weex 在手淘中的 Crash 佔比狀況：

• iOS 1.46%（TOP7）
• Android Java Crash 0.85%（TOP13）、Native Crash 1.72%（TOP8）

 

 

5. 雙向互動&AR跨屏的天貓雙11晚會前端技術

2016年的天貓雙11晚會互動與往年同樣是由天貓互動技術團隊負責開發，在去年紅黑PK的經典玩法的基礎之上增長雙向AB劇與AR跨屏搶新衣的兩個玩法，同時增長了舔屏版和後臺揭祕版兩個場景。對於前端技術的挑戰就是須要讓呈現的效果『更實時、更真實』，玩法和場景上的增長也要求開發團隊『更高效』。

 

5.1 更實時（時間表）

    本次晚會升級了先後端的數據傳輸方式，以輪訓爲打底，經過powermessage和關鍵幀技術使數據更輕量準確的實現先後端通信，來實現複雜的高實時性互動。

1. powermessage

    經過powermessage技術，創建客戶端與後端的長連接，待後端數據有增量變化時，通知前端作出相應的互動狀態變動，這樣作的好處是減小輪訓帶來的壓力，實時性高。

2. 關鍵幀技術

    傳統的，咱們經過人工切節目表的方案，來實現流內容與前端頁面的實時同步，必然會有少量偏差，經過關鍵幀技術，OBS推流時，在流中增長一段加強信息SEI，播放器底層捕獲後，以通知形式拋給iOS和Android層，客戶端這層獲取對應的字符串，組織成json經過argoWebView提供的hybird接口傳遞給前端，便可實現由流內容觸發前端互動操做，達到可控的、精準的實時操做。 

 

5.2 更真實（AR）

爲了給用戶更奇特的用戶的體驗，實現酷炫的互動營銷手法，晚會的一個亮點就是由AR技術實現的「明星丟衣服」環節，用戶在開電視直播的過程當中，明星在電視端丟出一件衣服，主持人會口播提示用戶使用手淘或者貓客的攝像頭對準屏幕，客戶端經過 AR 識別技術進行識別和定位，識別成功後，用戶在手機上會看到衣服從電視中浮出，砸碎手機屏幕的特效，效果見：

http://download.taobaocdn.com/freedom/29927/pic/p1b1lk13um1h1p15ti1v99utf1scv4.gif

 

5.1.1 技術方案

AR識別功能能夠劃分爲業務層和識別層兩部分，這兩部分具體實現的功能以下：

    1. 業務層：主要包括攝像頭數據展現層和WebView層。攝像頭數據展現層主要負責進行攝像頭數據的展現。WebView層位於整個界面的最上層，負責Markers（識別物）數據的下發以及根據識別層返回的識別物位置信息進行渲染（能夠根據前端的須要進行2D，3D以及各類特效的實現）。

    2. 識別層：基於Markers的位置識別，實時掃描攝像頭中的幀數據以判斷是否命中識別物，若命中則將識別出的3D位置信息返回給上層業務方。

（AR識別方案）

 

5.1.2 識別流程

（手機天貓AR識別流程）

 

5.2 更高效（工具）

    開場動畫、搖一搖、AR丟衣服等多處動畫特效有很是高的要求，素材製做上，給設計師帶來挑戰的同時，也給前端同窗帶來不小困難，即酷炫的動畫過於複雜，若是按照視覺稿一幀一幀還原的話，須要耗費極大的人工成本，並且一旦動畫出現需求變動，對前端來說簡直就是災難。去年設計師使用的是Flash進行開發，前端工程師採用自研的Flash插件導出Hilo動畫，而2016年設計師使用 After Effector(AE) 製做動畫，咱們又經過寫 ExtendScript 腳本導出動畫數據，優化、解析動畫數據後，使用 canvas 來播放動畫，行成了新的AE2Html5的動畫生成工具。

 

6. Webgl大規模應用，天貓雙11推出首個3D版狂歡城

天貓在每一年雙11預熱期都會發布聚集衆多品牌、效果酷炫的狂歡城互動頁面，2016年和往年不同的最大亮點是首次同時推出了2D和3D兩個版本。3D版狂歡城開啓了電商行業首次在大場景下應用Web3D技術。

6.1 設計方案

在作場景展現選擇的時候，咱們首先想到的是3D巡航場景，和多數第一人稱遊戲相似，使用第一人稱的視角在品牌場景中邊逛邊玩，但這種方式面臨品牌透出和性能挑戰。

 

通過屢次簡化場景，保留品牌模型，設計師同窗提出一種近似滾筒的場景——紙片風格的廣告牌方案。這種紙片自帶一些3D感，實際上咱們看到不少2D圖案，由於有透視效果，當咱們審視的角度和設計師設計的視角吻合時，會感受那是3D的。Billboard在現實生活裏也比較常見，好比大型購物地帶，繁華路段等。

 

Billboard的策略很簡單，儘量正對着用戶，正對着人流（流量）。在一些建築的邊界區域，Billboard可以利用多個面達到儘量大的曝光。

 

6.2 技術方案

在技術實現上，CSS3和Canvas也能模擬相似的效果。同時，根據手機淘寶和手機天貓當前的WebView的環境，CSS3的支持會比WebGL好不少，可是在CSS3在處理這種大場景時存在一些沒法迴避的問題——分割貼圖、形狀拼接後的「黑邊」問題、transform的白屏黑屏問題。

 

在底層實現上，WebGL比CSS3更穩定，CSS3更適合一些小場景。另外，在3D表達上，物體的形狀和紋理是咱們最能直接感覺的兩個特徵，形狀就是咱們看到的樣子，紋理就是表面的附着。除了這些光照，環境（霧、雨），反射，材質都能經過和材質表面的顏色作若干次運算，最終經過算出來的RGBA來使物體呈現豐富的外觀。在構建複雜3D物件形狀上，CSS3會顯得捉襟見肘。因此，最後咱們選擇WebGL。