移動端本地 H5 秒開方案探索與實現

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

企業微信移動端項目中有需求要展現數據趨勢的可視化圖表，通過調研，最終決定以單頁面 H5 來完成，對 APP 裏的一些使用 H5 實現的功能模塊，通常體驗都比原生差，那麼怎麼提升h5加載速度？優化 h5 體驗？

適用場景：須要快速迭代、客戶端難實現的、用做展現的功能模塊，例如可視化圖表。

1、爲何 H5 體驗糟糕

爲何打開一個 H5 頁面會有一長段白屏時間？由於它作了不少事情，大概是：

初始化 webview -> 請求頁面 -> 下載數據 -> 解析HTML -> 請求 js/css 資源 -> dom 渲染 -> 解析 JS 執行 -> JS 請求數據 -> 解析渲染 -> 下載渲染圖片

通常頁面在 dom 渲染後才能展現，能夠發現，H5 首屏渲染白屏問題的緣由關鍵在於，如何優化減小從請求下載頁面到渲染之間這段時間的耗時。

2、如何優化

上述打開一個頁面的過程有不少優化點，包括前端和客戶端，常規的前端和後端的性能優化已有前輩們總結過最佳實踐，主要的是：

• 下降請求量：合併資源，減小 HTTP 請求數，minify / gzip 壓縮，webP，lazyLoad。
• 加快請求速度：預解析DNS，減小域名數，並行加載，CDN 分發。
• 緩存：HTTP 協議緩存請求，離線緩存 manifest，離線數據緩存 localStorage。
• 渲染：JS/CSS優化，加載順序，服務端渲染模板直出。

通常狀況下，咱們只要對照這個列表，對比差別就基本能搞定絕大部分前端性能問題了。不過咱們在裏面仔細再分析下，對首屏啓動速度影響最大的就是網絡請求，包括請求 HTML、css、image 等靜態資源和展現數據的請求。

那麼將 H5 相關頁面和資源打包到客戶端中，而後客戶端將展現數據傳給頁面，經過webView加載展現，這樣幾乎不須要網絡請求，webview 只要渲染頁面，執行js便可，這樣體驗豈不是很完美？

3、具體怎麼實現？

總體思路看起來比較清晰，可是其中有幾個關鍵問題須要解決：

3.1 本地H5頁面如何和native通訊：

本地 H5 頁面如何和 native 通訊的方式基本有三種：jsapi、URL Scheme 和 字符串替換。具體不一樣方式適合使用場景有所不一樣：

jsapi ：客戶端提供接口，注入 API讓 Javascript調用，直接執行相應Native代碼，適用於須要經過交互，進行數據請求的場景

URL Scheme ： Web 端發送 URL Scheme 請求，以後 Native 攔截到請求並根據 URL Scheme 及所帶的參數進行相關操做。適用於進行頁面跳轉的場景。

字符串替換： 客戶端讀取本地 H5後，經過對 H5 中的約定的標記位進行字符串替換，而後加載展現頁面。適用於沒有複雜交互，只經過頁面渲染數據的場景。

3.2 如何開發調試和維護

開發本地 H5 模塊，很容易想到在本地經過模擬數據開發，而後將 H5 給到各客戶端打包後進行聯調。然而這樣的方案實現起來十分繁瑣，緣由是 H5 資源給到客戶端打包時很分散，不統一，管理困難。

那麼咱們改進一下，將使用本地 H5 實現模塊的頁面創建一個統一 git 倉庫，IOS 和 android 客戶端經過git submodule 將本地 H5 的git 外鏈到項目中，這樣客戶端中的資源就能夠統一管理，解放了每次都手動繁瑣的替換打包工做。

可是這種方法其實也並不完美，H5 代替原生實現的優點，一個在於開發成本低，另外一個在於 H5 能夠更加快捷的更新迭代，若是打包在客戶端中的H5 頁面就像客戶端同樣，無法快速更新了。很容易想到將 H5 資源給到後臺，客戶端按照業務模塊預下載整個離線包，離線包根據版本作增量更新。這種的方案，就能夠較好的解決上面的問題了。

4、細節優化

解決了上面的問題，本地 H5 確實能夠達到秒開的加載速度，不過要達到和客戶端同樣的體驗，還須要配上一些細節優化：

預加載 webView，預拉取數據

在聯調本地 H5 頁面過程當中，發現首次加載頁面時間比後續打開時間都慢不少，緣由預計是 webView 首次初始化時候須要啓動資源和服務較多，因而嘗試客戶端在預先初始化 webView 方案，果真這樣第一次打開頁面時候就變快了。同時爲了 H5 在第一次打開時能直接展現數據，客戶端在頁面打開前就預拉取數據並緩存，這樣來減小請求數據時間致使的白屏。

屏蔽webview HTML 內容自動識別

在 IOS webView 中默認會自動檢測 HTML 中手機號、email、地址格式並標記。 解決方法：經過添加 meta 頭來禁止默認行爲

<meta name="format-detection" content="telephone=no,email=no,adress=no">

點擊延遲

在WebView中，click一般會有大約300ms的延遲（同時包括連接的點擊，表單的提交，控件的交互等任何用戶點擊行爲）。

解決方法：使用fastclick/touchend通常能夠解決這個問題。

國際化

客戶端內的 H5 也須要國際化，前端國際化方案有不少，一般狀況下都是根據項目框架選擇相應的國際化插件，然而在本地 H5 的頁面中，再引入額外插件會增長客戶端打包大小，略顯冗餘。適合本身的纔是最好的，這裏採用了一種適合輕量級的國際化方案。

1.提取語言文案
2.頁面和 js 中引用提取的文案
3.根據配置切換語言方案

$('.i18n').each(function() {
     var key = $(this).attr('name');
     $(this).html(language[key]);
 });

 var language = getQueryVariable('en') ? i18n.en : i18n.zh

WKWebView 兼容

WKWebView 性能比 UIViewView 性能好不少，因此客戶端開發通常都推薦使用 WKWebView。

可是使用 WKWebView 加載本地的 HTML 時也有一些兼容問題，在 iOS8 不能在 HTML 文件中引用本地的 css 或者 js 或者圖片文件，IOS8 以上的是正常的，能夠引用遠程資源。爲了兼顧兼容性和秒開體驗，因此作降級方案，經過系統版本動態加載JS, IOS8 使用網絡資源，IOS8 以上使用本地資源。

還有在iOS8中，使用一些遠程的 cdn 的 css 或者 js 文件，必須注意在引用標籤上加上 charset屬性，否則 css 和 js 庫將會亂碼

5、最後

從前端優化，到客戶端緩存，到離線包，到更多的細節優化，作到上述這些點，H5 頁面在啓動上差很少能夠媲美原生的體驗了。

總結起來，大致優化思路就是：減小一切網絡請求，作好預加載和緩存，儘可能在用戶打開以前就加載好全部內容。這裏有些優化手段也要根據項目和實際需求來評估，須要跟開發成本和效率權衡。上述討論的僅針對功能模塊類的單頁面 H5 頁面秒開的優化方案，其餘一些交互較複雜的 H5 頁面可能並不適用，還須要視實際狀況和需求而定。

參考文獻

WebView性能、體驗分析與優化
70%以上業務由H5開發，手機QQ Hybrid 的架構如何優化演進？

問答
從小程序webview內嵌的h5頁面跳回小程序怎麼實現？
相關閱讀
iOS 和 H5 交互那些事 （UIWebView、WKWebView 總結篇）
H5調用底層接口的一些知識
快速開發基於 HTML5 網絡拓撲圖應用

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/dev...

歡迎你們前往騰訊雲+社區或關注雲加社區微信公衆號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~