版權聲明:本文由況鷹原創文章,轉載請註明出處:
文章原文連接:https://www.qcloud.com/community/article/141html
來源:騰雲閣 https://www.qcloud.com/communityandroid
目前移動端越多越多的網頁開始H5化,一方面能夠減小安裝包體積,另外一方面也方便運營。可是相對於原生界面而言,H5的慢速問題必定被你們所詬病,針對這個問題,目前手Q存在幾種方案,最多見的即是離線包方案,但離線包存在幾個問題:ios
除了上面的缺陷外,對於一些UGC架構的業務,離線包的支持也不是特別好。針對這些問題,業界存在一種基於TCP長鏈接的新方案(WebSo),專一於提升首屏的加載速度。WebSo的思路來源主要是因爲android端在初始化webview和http拉取資源串行執行時都很耗時,以下圖:
web
WebSo基於這一前提,把串行變並行,並利用tcp長鏈接替換掉http,另一個突破是針對html內容的動態性,增長了模板和數據分離,變化頻率較多的數據定義爲data,變化頻率較少的定義爲template,基本實現流程以下圖:
手機QQ針對個別頁面最開始採用的也是WebSo這種方案,不過在灰度過程當中發現數據不理想,尤爲是首次加載及模板變動時數據很是糟糕,仔細分析發現主要的緣由包括下面幾點:緩存
針對這幾點問題,爲了讓用戶的體驗達到更好,增值產品部提出了sonic方案,第二部分咱們來介紹一下具體的sonic實現細節。安全
咱們從兩個場景來介紹具體實現。服務器
第一種場景是用戶首次或者緩存失效時加載頁面,與WebSo同樣,sonic在初始化webview的同時也會並行發起http鏈接,在webview初始化好以後會在內核與http流之間創建橋接,橋接流在不一樣機型不一樣網速狀況下可能有三種不一樣狀態:全內存流、內存流+網絡流、網絡流。在橋接流關閉時,咱們會在終端根據模板數據拆分規則對html進行內容分割,並記錄模板和數據的tags信息,利用這些tags信息,能夠在下次與服務器通訊時進行數據校驗和更新。具體實現思路以下:
網絡
第二種場景是用戶二次進入頁面,經過手Q灰度測試的觀察這種場景的佔比較高,廣泛狀況下會在七成以上。這種場景咱們會優先加載緩存,而且根據http(s)返回碼的同步狀態,進行不一樣的處理。sonic首先會根據cacheoffline作不一樣的智能開關處理;而後根據本地的緩存狀態作不一樣的狀態轉換:若是徹底命中緩存,則不做任何處理;若是發生模板變動,處理邏輯會有點複雜,sonic會根據不一樣機型和網絡環境作智能切換處理,速度較快時會拉取完html流交給內核渲染,速度不快時仍然會創建橋接流,而且會對內容進行拆分;若是發生數據變動,sonic會對數據進行diff處理,和頁面經過js進行通訊進行刷新,這樣作的好處一方面能夠不影響用戶的體驗,另外一方面速度也更快。具體實現思路以下:
爲了達到更好的效果,後續咱們可能還會加入dns的優化,這樣作的好處是減小域名劫持,不過目前的方案已經能達到很是不錯的效果了。架構
下面咱們分別針對vip中心首頁在四個場景的實驗數據來進行對比(android端外網灰度數據基本一致,ios速度很快暫時沒有采用此方案),圖中每行的意義以下:dom
其中active-clickStart通常用來衡量頁面加載時的總時間。
第一種場景是首次啓動web進程、無緩存時的數據,能夠發現首次啓動sonic比WebSo加載耗時減小53%:
第二種場景是非首次啓動web進程、模板更新時的數據,能夠發現sonic比WebSo減小22%: 第三種場景是非首次啓動web進程、模板不變數據更新的數據,sonic比WebSo減小60%: 第四種場景是非首次啓動web進程、徹底命中緩存的數據,sonic和WebSo的數據差不太多: 從實驗和手Q灰度的狀況看,總體而言,sonic在絕大部分場景下已經可以達到很是好的體驗,後續咱們也會繼續進行進一步的優化,爭取達到更好的體驗效果。