QQ音樂Android客戶端Web頁面通用性能優化實踐

時間 2020-07-17

原文原文鏈接

QQ音樂 Android 客戶端的 Web 頁面日均 PV 達到千萬量級，然而頁面的打開耗時與 Native 頁面相距甚遠，須要系統性優化。本文將介紹 QQ 音樂 Android 客戶端在進行 Web 頁面通用性能優化過程當中的問題、思路、方案和效果，並嘗試對跨端場景的常見瓶頸和對策進行概括。文章做者：關岳，QQ音樂客戶端開發工程師。

1、問題與目標

做爲一款注重於內容運營的應用程序，QQ 音樂 Android 客戶端的 Web 頁面日均 PV 達到千萬量級，評論頁、MV 頁等核心頁面均有 Web 頁面參與，或徹底由 Web 實現。前端

客戶端內 Web 頁面的打開耗時與 Native 頁面相距甚遠，須要系統性優化。然而，現有的前端和跨端優化方案，存在必定侷限性。web

1. 前端優化的侷限

針對 Web 頁面的耗時優化，在優化思路、方案、服務、工具鏈等方面都已經建設得很是詳細。然而，在客戶端內 Web 頁面這一場景，純前端優化存在如下兩個侷限：小程序

沒法規避 WebView 初始化耗時
受限於 WebView 生命週期範圍

從客戶端角度，除了思考優化 WebView 初始化耗時以外，還能夠從「擴展前端生命週期」的角度出發，思考優化方案。微信小程序

2. 跨端優化的侷限

現有跨端優化方案，包括離線包、VasSonic 等，爲了達到最好的優化效果，均須要前端終端共同參與改造。這致使存量頁面的邏輯改造增長，對線上頁面不夠友好，引入額外的成本和風險。在前端開發資源不足時，這些優化的開展存在必定難度。緩存

從減小前端開發工做量的角度來看，須要思考更具通用性、前端感知更小的優化方案。性能優化

3. 目標

基於本次優化的背景，本次優化提出如下兩方面的目標：加強通用性、減小前端改形成本。微信

2、指標設計

在展開優化思路和實施的同時，須要創建衡量優化效果的性能指標。框架

1. 客戶端現有性能指標數據

接下來基於客戶端內 Web 頁面加載過程，描述客戶端現有性能指標表明的時機。dom

（1）客戶端 WebView 回調

基於 Android WebView 的過程監控回調和頁面框架能力，能夠實現的性能監控包括：前端優化

其中， onMainFrameFinished 取第一個非主請求 (HTML) 的資源被攔截的時機。對於絕大多數頁面來講，此時已經完成主請求 (HTML) 的下載，並已經開始解析；能夠粗略表明主請求流程結束。

（2）W3C Performance Timing

與客戶端回調相比，W3C Performance Timing 提供了更細緻的加載過程信息，可是不包含 WebView 開始初始化的時間點。下圖中僅列出部分：

2. 各端單獨採集的侷限

（1）前端採集的侷限

沒法獨立獲取 WebView 開始初始化的時間點。
想獲取最精確的加載完成時間點，主要依賴手動埋點。

（2）客戶端採集的侷限

SSR (服務端渲染) 和 CSR (客戶端渲染)，頁面內容可消費的時間點不一致。

對 WebView 頁面加載週期來講：

CSR 頁面需在前端頁面框架加載後再展現數據，內容請求完成並上屏，發生在頁面加載完成以後
SSR 頁面的首次內容上屏可攜帶首屏數據，所以在頁面加載完成以前，頁面內容已經能夠被消費

客戶端回調時機不夠完整或過於「苛刻」，測不許「頁面內容可消費」的時間點。

經過追溯客戶端 onPageFinished 的回調時機，發現對應的 Blink 代碼要求必須知足：頁面解析完畢、沒有正在下載的資源等條件。

按照這個標準，一旦存在某個圖片一直處在加載中，但頁面框架的其餘內容均已處理完畢，onPageFinished 回調也會等待圖片加載完成纔回調，與實際上的「頁面內容可消費」時間點存在差別。

3. 指標設計方案

結合上述分析，能夠肯定：

最準確的頁面加載完成時機來自前端
最準確的 WebView 初始化時機來自客戶端

所以，完善的耗時測量需由客戶端和前端協同完成。

（1）前端側

前端自行完成結束時間點的設置，並從客戶端獲取 WebView 初始化時間點，統計上報打開耗時。

前端經過手動埋點或監聽 DOM 節點數變動，獲取加載完成時間點。
前端統計時調用客戶端提供 JSAPI，獲取以 WebView 初始化時間點做爲起點的耗時。
並由前端完成加載耗時的計算和統計上報。

（2）客戶端側

做爲一個補充方案，客戶端能夠經過 JavaScript 注入獲取上述 W3C Performance Timing 中的 domInteractive 時間點，做爲結束時間點。

前端 domInteractive 時，已完成全部頁面展現必需資源的請求和處理

耗時的差別，能夠體現任何頁面的客戶端通用優化效果

能夠衡量SSR(服務端渲染) 頁面的可消費耗時，和CSR(客戶端渲染)頁面的首幀耗時

webView.evaluateJavascript(

script = 「(function(){return performance.timing.domInteractive;})();」,

callback = { value ->

responseEndDuration = value.toLong() - getOnCreateTimestamp()

}

)

雖然 WebKit 負責維護 Performance Timing 的值，可是 WebView 並未提供接口獲取上述時間點的值。