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

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

一、問題與目標

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

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

1. 前端優化的侷限

針對 Web 頁面的耗時優化,在優化思路、方案、服務、工具鏈等方面都已經建設得非常詳細。然而,在客戶端內 Web 頁面這一場景,純前端優化存在以下兩個侷限:

  • 無法規避 WebView 初始化耗時

  • 受限於 WebView 生命週期範圍

從客戶端角度,除了思考優化 WebView 初始化耗時之外,還可以從 “擴展前端生命週期” 的角度出發,思考優化方案。

2. 跨端優化的侷限

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

從減少前端開發工作量的角度來看,需要思考更具通用性、前端感知更小的優化方案。

3. 目標

基於本次優化的背景,本次優化提出以下兩方面的目標:增強通用性、減少前端改造成本。

二、指標設計

在展開優化思路和實施的同時,需要建立衡量優化效果的性能指標。

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

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

(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 並未提供接口獲取上述時間點的值。

三、優化方案和效果

1. 優化方案概述

基於客戶端內 Web 頁面的加載流程,從 “WebView 初始化耗時優化”、“資源加載耗時優化”、“邏輯處理耗時優化” 三個方面,提出了 5 個優化項。

  • TBS (X5 內核) 環境預加載

  • WebView 實例池

  • 主請求並行加載

  • Web 公共資源池

  • 跟膚邏輯優化

各優化項在 Web 頁面加載過程中的生效時機如下:

2. 優化手段說明

(1)WebView 初始化

經過前期分析,WebView 初始化耗時本身的耗時壓縮空間比較有限。因此優化手段主要以初始化邏輯前置爲主。例如,“WebView 實例池” 通過在應用位於後臺、主線程卡頓影響不明顯的時機進行 WebView 預初始化,置換啓動 Web 頁面時的初始化耗時。

(2)客戶端自建緩存

爲了實現前述各項資源加載優化,客戶端需要獨立於 WebView 的緩存機制,自建一個資源緩存。

自建緩存參考客戶端常用的三級緩存機制,基於 WebView 的強生命週期,設計了 “冷-熱緩存循環” 的緩存生命週期。

例如,在 WebView 初始化的同時,自建緩存把頁面需要的資源從文件系統加載到內存;向 WebView 資源攔截回調輸入字節流時,自建緩存一定從內存緩存中輸出,輸出完畢後即可立即從內存緩存中被清除。這一機制可以使內存緩存的淘汰更積極,字節流在內存中停留的時間更短,減少內存佔用。

(3)公共資源內聯

在完成公共資源池開發後,頁面打開耗時出現了負優化的情況。經過分析,確定與資源攔截回調的性能瓶頸有關。

  • 單線程模型導致讀寫性能下降

  • 被攔截資源的數量越多,對性能的影響越容易被放大

因此,爲了減少資源攔截回調的性能影響,從減少攔截次數的角度,引入了公共資源內聯優化。

  • 公共資源加載到熱緩存後,轉換爲對應的 HTML 節點

  • 主請求並行加載完成後,直接在主請求字節流中替換其對應的外聯節點;替換後的新字節流返回 WebView

引入公共資源內聯後,基本抵消了資源攔截回調的性能影響,頁面加載耗時提升 3.2%。

3. 優化效果

QQ 音樂 Android 端內評論頁:

  • 加載耗時降低 26.2% (1932ms → 1426ms)

  • 跳出率降低 

  • 停留時長中位數增加

四、跨端場景的瓶頸與對策

基於在 WebView 場景下的優化過程,推及跨端場景可能存在的類似問題,本文嘗試給出一些跨端場景中可能的性能瓶頸及應對方式。

1. 前終端通信通道效能不足,考慮 “少次多量”

跨平臺方案 (WebView、React Native 等) 普遍存在前終端通信通道效能不足的問題。

  • WebView 通道不支持較大量級數據的傳遞

  • 通信線程多爲單線程,甚至需要在主線程發起或處理通信

  • 對傳遞次數的敏感程度大於對傳遞數據總量的敏感程度

因此,當在跨端場景出現大數據量傳遞時,需要優先考慮當前通信通道的可用性。在需要傳遞數據總量無法壓縮的情況下,如果通道允許,儘量減少傳遞次數,增加單次傳遞的數據量。

“公共資源內聯” 即是這一思路的實踐。

2. 擴展生命週期

前端生命週期有限。客戶端可以利用在前端生命週期以外的時間,進行適當的資源前置和邏輯前置,降低頁面加載耗時。

例如上述優化中的 “公共資源池”、“主請求並行加載” 等,體現了擴展生命週期的思想。除此之外,微信小程序的雙線程模型[1]通過引入 JSCore,增加前端代碼的可執行時長,並通過離線包等手段幫助前端擴展生命週期。

3. 精簡 / 前置公共庫代碼

如果前端頁面共用公共庫,隨着前端業務的複雜化,公共庫的自然膨脹,可能會放大腳本解析與執行的耗時。

針對 Web 頁面,可以通過精簡基礎庫的方式,減少無關代碼的執行;針對 React Native 頁面,可以通過進行分包和實例預加載,讓更多基礎庫代碼在頁面加載前執行,從而降低頁面啓動時執行的代碼量,減少耗時。

五、總結與展望

本文基於客戶端內 Web 頁面的加載特點,針對 WebView 初始化、資源加載和邏輯處理現狀中的問題和瓶頸,設計並實施了 5 個優化項,優化效果比較明顯。並且嘗試對跨端場景的瓶頸與對策進行歸納,嘗試爲後續跨端場景的優化工作提供思路。

未來,團隊還將進一步豐富客戶端與前端的協同性能監控,並允許前端通過更精細化的方式啓動客戶端 Web 頁面框架。遠期,還將嘗試探索 CGI 前置、引入 JSCore 等手段,進一步提升特定場景下的 Web 頁面加載耗時。

參考資料:

[1] 微信小程序的雙線程模型:

https://developers.weixin.qq.com/ebook?action=get_post_info&docid=0000286f908988db00866b85f5640a

看騰訊技術,學雲計算知識,關注雲加社區

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章