H5 前端性能測(cè)試實(shí)踐

khs1994 發(fā)布于2019-06-21 16:47 / 888人閱讀

摘要：四總結(jié)前端性能測(cè)試方案當(dāng)然，前端性能不僅僅表現(xiàn)在白屏卡頓問題，也有可能是手機(jī)過度發(fā)熱等等。從用戶核心體驗(yàn)出發(fā)，我們認(rèn)為，前端性能最重要的參考標(biāo)準(zhǔn)就是要以最輕量的方式，給用戶最好的體驗(yàn)。

H5 頁面發(fā)版靈活，輕量，又具有跨平臺(tái)的特性，在業(yè)務(wù)上有很多應(yīng)用場(chǎng)景。但是同時(shí)對(duì)比 App，H5 的性能表現(xiàn)總是要遜色一籌，比如頁面打開往往會(huì)出現(xiàn)白屏，滑動(dòng)列表等交互場(chǎng)景下也不如 Native 頁面流暢。針對(duì)這些白屏、卡慢之類的問題，我們測(cè)試該從哪些方面去展開測(cè)試分析和數(shù)據(jù)對(duì)比呢？接下來筆者分享一些 H5 前端測(cè)試實(shí)踐的經(jīng)驗(yàn)，拋磚引玉，希望大家一起談?wù)摚黄鹜诰蚋嘤袃r(jià)值的課題。

一、開篇：H5 頁面加載過程淺析

如下圖所示，是精選平臺(tái)打開 H5 頁面的幾個(gè)過程截圖。

圖一到圖四可以簡單分類，圖一是 App 負(fù)責(zé)做的事情，主要是初始化 Webview 上下文；后面三張圖則是一個(gè)H5頁面加載的過程。其中，App 這個(gè)階段的耗時(shí)，主要是 Native 代碼的耗時(shí)，這里先不展開討論，我們重點(diǎn)放在后面幾個(gè)階段。第四個(gè)圖是用戶直觀看到的第一屏頁面，我們通常稱為首屏。

1）加載網(wǎng)絡(luò)請(qǐng)求

這個(gè)過程主要是 Webview 拿到 H5 頁面 url 之后，調(diào)用 loadUrl 方法，開始去網(wǎng)絡(luò)上請(qǐng)求第一個(gè)資源文件。這個(gè)階段主要包含 dns 解析、建立網(wǎng)絡(luò)鏈接、數(shù)據(jù)傳輸?shù)暮臅r(shí)。

2）html 解析

Webview 拿到 html 返回后，需要從上至下解析 html 中的標(biāo)簽和內(nèi)容，識(shí)別外鏈資源、計(jì)算頁面框架的布局，并渲染繪制出來。在這個(gè)過程中會(huì)構(gòu)建出負(fù)責(zé)頁面結(jié)構(gòu)的 DOM Tree 和負(fù)責(zé)頁面布局展示的 Render Tree，如下圖所示：

3）外鏈資源加載

這部分主要是從網(wǎng)絡(luò)上加載外鏈的 css、圖片和 js 等，再重新填充到 html 中。之后重新進(jìn)行一次 layout 布局計(jì)算和頁面渲染繪制，此時(shí)看到的才是有完整內(nèi)容的頁面。如下圖所示，頁面需要等圖片和 css 加載出來后才能展示，js 也是外鏈資源，不過一般來說，只要放在 html 底部加載，就不會(huì)阻塞頁面的渲染和展示。

二、實(shí)例分析：白屏問題

前面我們已經(jīng)了解了 H5 頁面加載過程，接下來如果遇到白屏，我們自然會(huì)問，怎么才能知道頁面當(dāng)前處在哪個(gè)階段，每個(gè)階段耗時(shí)多長，以及整體首屏加載的耗時(shí)呢？

首先看下通過 PC Chrome 模擬 H5 頁面的情況。Chrome Devtool 提供的 Performance 工具，可以錄制頁面從第一個(gè)請(qǐng)求到加載完成的所有事件，通過這種方式可以很詳細(xì)的看到各階段做的事情和具體的耗時(shí)。

其中兩個(gè)最關(guān)鍵的首屏耗時(shí)指標(biāo)：domContentLoaded（首屏頁面可見）和onLoad（首屏加載完成）的耗時(shí)，除了圖示的方法，還可以通過在 console 里打印全局變量window.performance.timing，拿到時(shí)間戳并計(jì)算得到。

但實(shí)際我們要的是移動(dòng)設(shè)備的真機(jī)數(shù)據(jù)，這個(gè)才能真實(shí)反應(yīng)頁面性能和用戶體驗(yàn)。想要獲取 H5 真機(jī)耗時(shí)，一種方式是 js 代碼進(jìn)行上報(bào)；另一種是對(duì)于 Android 設(shè)備，可以用 remote-debug 的方式遠(yuǎn)程調(diào)試真機(jī)頁面。只需要保證 webview 調(diào)試開關(guān)打開 & 與 PC USB 連接且開啟 USB 調(diào)試，就可以在 PC Chrome 訪問 chrome://inspect 來獲取調(diào)試對(duì)象。之后參考 PC Chrome 模擬 H5 的方法即可拿到數(shù)據(jù)。

對(duì)于傳統(tǒng)頁面而言，實(shí)際分析發(fā)現(xiàn)大部分耗時(shí)還是在移動(dòng)網(wǎng)絡(luò)請(qǐng)求這部分，所以最直接有效的方式就是對(duì)頁面進(jìn)行直出改造，也就是改變先加載 html、再加載 css 等數(shù)據(jù)的情況，先在后端（比如 nodejs）并行加載首屏依賴的所有 css、js 和后臺(tái)接口數(shù)據(jù)，拼裝好一個(gè)完成的最終要呈現(xiàn)的 html 再回給前端，達(dá)到秒開的效果。

三、實(shí)例分析：卡慢問題

有時(shí)候用戶在頁面交互的過程中會(huì)遇到卡慢，比如上下滑動(dòng)列表、左右切換或者輪播等。這個(gè)過程無非也是執(zhí)行 js、請(qǐng)求資源、計(jì)算新的頁面布局并渲染繪制這幾件事。通過 Performance 分析就會(huì)發(fā)現(xiàn)，卡慢其實(shí)并不全是很多人認(rèn)為的“移送設(shè)備性能就是差”，有時(shí)候其實(shí)是假性卡頓。

比如下面這個(gè)就是熱區(qū)過小的問題：

真卡的情況，往往腳本報(bào)錯(cuò)占了很大比重，直觀表現(xiàn)就是頁面是卡死，而不是變慢。其他的諸如內(nèi)存問題，通常表現(xiàn)是頁面越來越卡，因?yàn)槭褂脮r(shí)間越長，資源消耗越大。比如頁面使用了比較復(fù)雜的 canvas 動(dòng)畫、比較耗性能的 iframe 元素，或者直播流媒體，這種情況下容易出現(xiàn)內(nèi)存泄漏。

下面這個(gè)就是 dom 節(jié)點(diǎn)引發(fā)的內(nèi)存泄漏,不使用的 commentList 列表沒有釋放，越積越多到長度幾萬個(gè)的時(shí)候開始卡頓。

四、總結(jié)：H5 前端性能測(cè)試方案

當(dāng)然，前端性能不僅僅表現(xiàn)在白屏、卡頓問題，也有可能是手機(jī)過度發(fā)熱等等。從用戶核心體驗(yàn)出發(fā)，我們認(rèn)為，H5 前端性能最重要的參考標(biāo)準(zhǔn)就是：要以最輕量的方式，給用戶最好的體驗(yàn)。從這個(gè)方向出發(fā)，我們積累了一些測(cè)試經(jīng)驗(yàn)，其中最重要的必過項(xiàng)是首屏速度（不僅提升用戶體驗(yàn)，還可以提升業(yè)務(wù)的轉(zhuǎn)化率），其次流暢度、流量和 CPU 等，某些場(chǎng)景下也是需要重點(diǎn)考量的點(diǎn)。