導語 | 任何技術優化都依托于業務的發展，随着QQ會員增值業務的重心轉移到手Q移動端，對H5頁面不僅要求加載更快，還需承載豐富多彩的運營活動，同時由于每個頁面都意味着KPI收入，任何可能導緻頁面功能不可用的發布行為都是不可接受的。

本文主要介紹QQ會員的前端開發團隊在手Q的hybrid模式下對H5頁面的性能優化、組件化和持續集成方面的實踐。

随着移動化浪潮的來臨，QQ增值業務的重心從PC端PCQQ轉移到移動端手機QQ；作為前端開發，我們的工作内容也轉移到基于手機QQ的hybrid模式下H5開發工作。

什麼是QQ會員？QQ會員是宇宙第一大包月業務，大部分的會員用戶都很年輕。大家可以猜一下哪個年齡段的QQ會員用戶最多？小學、初中、高中、大學還是白領？所以如果你還不是QQ會員，說明你已經老了 :)

個性張揚是年輕的代名詞，QQ會員用戶在好友列表中的名字是紅色，而且排名靠前，這些都達成了用戶的炫耀心理，就連發紅包時都擁有右圖中的專屬的皮膚。

同時QQ會員還有左圖中的QQ等級加速更快等特權，買電影票、定外賣還能打折。

其實手機QQ在承擔即時通訊等社交功能的同時，還承載着QQ會員數十億的營收重任，其中大部分的營收都來自于内嵌在手Q中的H5頁面，因此保證H5頁面的高質量，是我們的工作重點。

保證H5頁面的高質量，我們有以下三個挑戰：

• 第一、如何讓H5打開更快？雅虎的一項研究表明，頁面打開每慢400毫秒，将帶來5%-9%的用戶流失；讓頁面更快呈現給用戶是前端工程師們的不懈追求，在hybrid模式下借助于終端的能力我們有了更大的想象空間！

• 第二、如何讓H5開發更快？好的産品是運營出來的，沃爾瑪每周都有打折，電商有6.18和雙11雙12，同樣QQ會員也需要有持續的H5運營活動以保持用戶的活躍和留存，而H5組件化是我們提高開發效率的手段。

• 第三、如何保證H5頁面持續高質量。手機QQ一兩個月發布一個版本，但是H5頁面每天都有發布，随着H5邏輯越來越複雜，比如不同身份用戶（非會員、會員）在不同時間點（到期前和到期後）進入頁面時看到的内容都不一樣；如何不依賴成本很高的人工測試來保證H5頁面的功能持續可用？

首先介紹下我們基于hybrid的sonic方案是如何實現頁面在1秒左右打開的。

1、要打開頁面，在PC端需要先打開一個浏覽器（chrome或者火狐），在android或者IOS應用中必須先有一個webview（圖中橙色部分）；出于性能考慮手Q并未在後台常駐一個webview進程，所以要打開頁面需要先初始化webview。

2、在之前版本的手Q中我們時常可以看到類似左邊的白屏，雖然加上了賣萌的文案“别鬧，加載是件正經事”讓用戶感覺萌萌哒，但這掩蓋不了曾經webview初始化慢的事實。雖然經過幾個版本叠代優化，客戶端耗時已經大大降低，但是還需要近900毫秒。好像距離一秒的目标很近了。

3、但是webview初始化完成後，再調用loadUrl接口獲取目标URL的HTML内容并進行渲染（圖中藍色部分）；由于我們的web層基于PHP語言來實現，一個web請求需要新建一個子進程去查詢若幹個後台服務，這裡的耗時至少需要200毫秒。算一下終端加後台的耗時加起來已經超過一秒了。。雖然沒有人能跑的比博爾特更快，但是我們還是有方法來讓我們的頁面打開更快。

第1個優化是把串行改為并行！我們把終端webview初始化工作并行為兩個線程（圖中兩個橙色塊）：webview主線程處理主要的初始化工作，而登錄态獲取、業務插件初始化等工作放在webview子線程，這樣終端的耗時就從之前的兩部分的耗時之和變成了兩部分耗時的最大值。同樣在後台我們也新建了一個proxy來代理後台所有服務的查詢工作（右側綠色塊），由proxy來并行發起對其他後台服務的查詢，proxy的耗時取決于最慢的那個後台服務接口的耗時。

第2個優化是網絡耗時的優化。電影英雄中有段對白：劍術的最高境界是心中無劍，手中亦無劍。減少網絡耗時最有效的優化方法莫過于不進行網絡請求，也就是Cache。

1、雖然浏覽器本身有緩存功能，可以通過設置靜态文件的緩存時間來減少請求數，但是我們經過數據驗證，發現移動端浏覽器緩存有時候并不可靠，緩存還未過期也有可能被清掉重新請求。

2、H5标準中也有一個localstorage特性，我們通過擴展seajs的緩存插件實現在localstorage中緩存JS文件，加快了HTML依賴的JS的加載速度。但是HTML本身仍然需要走網絡請求。

3、其實手Q也實現了一套離線包機制，用來緩存HTML和圖片、CSS、JS等文件，但是隻能緩存靜态不變的内容，比如剛開始介紹QQ會員時的會員個性化紅包頁面就利用了離線包的能力。然而我們的頁面有很多用戶數據（比如會員身份、會員成長值、QQ等級成長速度等）需要實時查詢，再加上終端複雜的離線包校驗機制耗時很多，我們新建了HTML Cache機制，在終端緩存了整個HTML。

4、有了緩存之後，webview主線程先發起1.1的loadUrl操作展示本地HTML緩存給用戶，同時發起1.2的HTTP請求去獲取最新的數據内容，如果有變更則通過第3步的jsbridge回調進行頁面刷新，同時終端會異步進行第4步的更新本地的HTML Cache。

5、如果頁面沒有變化，網絡耗時僅為加載本地HTML文件的IO時間，這個時間幾乎為0；如果頁面有變化，由于這裡提前并行發起了http請求，網絡耗時也比上一頁中串行的HTTP直連要少很多。

6、這裡還有一個問題，就是如果緩存的HTML内容和最新的内容不一緻，我們需要刷新整個頁面嗎？答案是否定。大家注意下這裡第2步返回内容可能是HTML，也有可能是JSON，下一頁會介紹為什麼。

1、我們将HTML拆分為兩部分：模闆和數據塊。一個數據塊對應一段HTML片段（上圖中藍色字部分），用注釋語句包裹起來；而數據塊以外的部分為模闆，一般情況模闆的内容比較固定，dom結構、内聯的樣式等很少變動。

2、比如圖中有三個數據塊：key1，key2和key3，分别對應這個頁面從上到下三個紅框框住的部分。

3、剛才有講到并行HTTP請求回來的内容可能是HTML，也可能是JSON；我們的策略是如果是首次訪問本地沒有緩存或者緩存被清理則返回完整的HTML；如果模闆未變化隻是數據塊有變化，比如總成長值加了2點，從76660加到76662，或者生活福利模塊更換了2個廣告位，隻需要返回JSON即可，由jsbridge觸發頁面回調來替換DOM節點實現頁面的局部刷新。

3、以上兩個優化點需要終端和頁面按照統一規則緊密配合，我們通過擴展HTTP協議來實現。

1、我們擴展了4個HTTP協議頭，2個請求頭和2個返回頭。

2、accept-diff表明終端是否支持增量更新的能力，一般傳true，對于老版本的手Q，無法攜帶該頭部，後台将會始終返回完整的HTML；template-tag代表終端本地緩存的HTML的SHA1摘要值；

3、template-change代表服務端模闆是否有變更，模闆和數據塊均無變更返回304，模闆無變更僅部分數據塊有變更時為false，首次和模闆變更時都是true；cache-offline是後台告訴終端如何進行頁面刷新和本地HTML緩存更新，如果為true代表刷新頁面并更新緩存，如果為store，代表僅更新緩存不刷新頁面。

下面我們從整個流程上來看一下。

第一種場景是用戶首次或者緩存失效時加載頁面，用戶點擊終端入口後，在初始化webview的同時并行發起http鍊接，在webview初始化好之後會在内核和http流之間建立橋接。内核在讀取完畢之後終端根據模闆數據拆分規則對html進行内容分割，并記錄模闆和數據的tags信息，異步HTML為模闆和數據用于下次與服務器通信實時更新。

1、第二種場景是用戶二次進入頁面，這種情況的占比七成以上。webview優先加載HTML緩存，并且根據http(s)返回碼的同步狀态，進行不同的處理。

2、如果status為200，且返回的是JSON，說明隻有數據變更，終端會對數據進行diff處理，和頁面通過js通信進行局部刷新。

3、如果發生模闆變更，處理邏輯會有點複雜，終端根據在不同機型和網絡環境下做智能切換處理，速度較快時會拉取完HTML流交給内核渲染，速度不快時仍然會建立橋接流，并且也會對HTML進行拆分；

4、如果status為304說明完全命中緩存，則不作任何處理；

1、左邊的效果是最初頁面局部刷新時的表現，我們可以看到加載本地緩存的HTML後很快看到了整個頁面，然後成長值發生了變動，然後又更新了兩個廣告運營位。但是這裡的體驗還是有點問題的，加載圖片需要時間，導緻頁面的閃動很明顯。

2、我們又改進了下，先将圖片下載完，再去局部更新這兩個廣告運營位，最終實現了右邊比較平滑的效果。

另外一個圖片的優化是圖片自适應。

網頁中的流量大頭是圖片，圖片加載消耗了很多時間。我們實現了對于同一張圖片，終端看一根據用戶不同的手機分辨率返回不同規格的圖片，而這一切不需要做任何代碼修改，完全透明接入。

比如如果你是iPhone 7S，CDN返回750像素的高清大圖，如果你還在用iPhone 4S，CDN返回480像素的一般清晰度的小圖，這樣在保證體驗的同時減少了加載的圖片大小，頁面更快展現給用戶。

這個項目内部代号sonic，意思是希望頁面加載速度可以像音速一樣快。最終我們也實現了占比70%右側2個場景，局部刷新和完全cache時總耗時1秒左右，而且首次訪問時的總耗時也低于之前最左邊的HTTP直連。

我們除了讓H5頁面加載更快，還需要讓H5頁面開發更快以滿足活動運營的需求。

首先我們看一下什麼是運營活動？

1、左邊第一個活動新遊戲即将發布，在預約頁面提前預約的用戶在遊戲發布後下載完成後可以免費領取福利；

2、左邊第三個活動，QQ會員可以免費領取一張美團的優惠券；

4、最右邊的活動，QQ會員玩天天酷跑遊戲可以免費抽獎獲取遊戲道具；

1、運營活動有四個要求：一般1-2天需要完成開發測試和上線、不同活動可能有相同的功能邏輯，一般會投入大量推廣資源所以對頁面的質量要求比較高，大量資源推廣時并發訪問用戶多對性能要求比較高。

2、我們的思路是必須盡可能減少開發環節和開發人力，最小化功能邏輯實現顆粒化可複用，對前端代碼和後端服務要求穩定可靠，必須持續的前端性能優化。

3、我們的解決方案是構建一個組件化的活動開發平台，内部代号ET

1、第一：減少一切可以減少的環節。一般H5頁面的開發流程是交互-設計-重構-開發，我們和交互、設計人員制定好運營活動的交互設計規範，比如統一彈窗樣式，從而減少了交互環節；利用H5的新特性canvas自動對設計稿進行切圖，又省掉了重構環節。

2、第二：組件化開發。開發人員隻需要開發組件，組件可以在不同活動中複用。運營人員隻需要拖拽組件、配置資源，最後由執行引擎生成包含活動邏輯的HTML頁面，自動發布外網即可。

一個組件由HTML片段，CSS樣式和JS邏輯構成；開發人員完成組件開發之後，運營人員像拼積木一樣，拖動幾個組件組合在一起，就可以生成運營活動頁面。

同時ET平台實現了一整套發布回滾流程支持，自動對接頁面性能測試工具，可以對運營頁面的性能進行自動化測試，最後也會給大家分享下如何進行性能自動化測試的。

該平台上線後，月均上線活動達到300個以上，但全職開發人員投入僅1人。

保證H5頁面功能正常，并且讓H5頁面打開更快，不是一錘子買賣，需要可持續。H5頁面的質量不能僅僅靠測試人員的手工測試來保證，我們需要一套自動化解決方案。

1、說到質量标準，IOS9001是我們耳熟能詳的國際質量标準，但是H5頁面的質量标準是什麼？

2、PC時代，我們知道performance api就能比較全面的透視整個頁面請求過程的耗時，在hybrid模式下，我們對H5頁面高質量的定義是頁面功能的高可用和頁面加載速度更快。

3、功能高可用需要webview不會crash，頁面能夠正常打開并且業務邏輯符合預期；頁面加載速度更細化，終端耗時、網絡耗時、頁面耗時，同時需要關注總耗時大于5秒以上的慢用戶占比。

1、頁面功能可用性的自動化測試，我們構建于騰訊内部自研的自動化測試工具QTA。該工具不僅可以識别android和ios終端的控件，也可以識别web的dom控件，通過對點擊事件進行模拟，将實際的返回值同期望值比較以确認用例是否通過。

2、測試人員使用python語言編寫自動化測試腳本上傳到SVN，由分布式任務管理系統分配可供測試的手機模拟器或真實的手機，測試人員可以手工或者設置定時任務自動執行測試計劃。

3、同時我們将web發布系統和任務管理系統進行打通，每次發布前自動進行功能自動化測試，隻有在預發布環境的通過率達标才能繼續發布，這樣就保證了頻繁變更時H5頁面的功能依然正常。

1、頁面性能自動化測試我們參考了很多現有的工具，比如yslow，雅虎前端優化軍規以及谷歌的pagespeed，但是發現這些對hybrid模式支持的都不是很好，尤其是我們基于手Q環境下有更多的個性化的東西。

2、我們選擇了自研H5頁面性能自動化測試工具，簡稱為WPT，web performance test。參考了yahoo軍規，結合終端環境特性和H5業務特性，對H5頁面加載的全流程進行發布前測試和發布後回歸。

簡單回顧下，我們通過H5頁面和終端的深度融合實現了H5頁面的快速加載，同時通過組件化實現了H5頁面的快速開發，使用自動化工具實現了H5頁面變更時的持續的高可用和高性能，最終實現了高質量的H5的架構實踐。

作者：翟偉，QQ個性化業務前端團隊leader，曾參與過超級QQ和QQ會員的前端開發工作，目前負責手機QQ個性裝扮的開發工作，擁有近10年的項目架構和實踐經驗，專注于手機QQ的hybrid模式下H5優化和持續集成方向。