背景

體驗(yàn)評(píng)分 Audits 是微信開(kāi)發(fā)者工具內(nèi)置的一項(xiàng)功能，會(huì)在小程序運(yùn)行過(guò)程中實(shí)時(shí)檢查，分析出一些可能導(dǎo)致體驗(yàn)不好的地方，并且定位出哪里有問(wèn)題，以及給出一些優(yōu)化建議。

京喜小程序作為京東戰(zhàn)略級(jí)業(yè)務(wù)，擁有千萬(wàn)級(jí)別的流量入口，經(jīng)過(guò)長(zhǎng)時(shí)間的業(yè)務(wù)迭代，代碼邏輯已經(jīng)十分復(fù)雜臃腫，有迫切的性能優(yōu)化需求。因此，結(jié)合體驗(yàn)評(píng)分功能，以京喜首頁(yè)做試點(diǎn)，我們進(jìn)行了一次體驗(yàn)評(píng)分的優(yōu)化實(shí)踐。目的是探索小程序體驗(yàn)評(píng)分的指標(biāo)原則：拿到100分的小程序應(yīng)該是什么樣子的；同時(shí)希望借此給項(xiàng)目?jī)?yōu)化提供更多思路。

我會(huì)按照「了解首頁(yè)評(píng)分現(xiàn)狀，分析扣分項(xiàng)規(guī)則，解決扣分項(xiàng)」這個(gè)思路來(lái)介紹，就讓我們開(kāi)始吧～

京喜首頁(yè)評(píng)分現(xiàn)狀

打開(kāi)小程序開(kāi)發(fā)者工具-調(diào)試器-Audits，點(diǎn)擊運(yùn)行，操作頁(yè)面滾一滾點(diǎn)一點(diǎn)，然后點(diǎn)擊結(jié)束。

評(píng)分結(jié)果會(huì)根據(jù)評(píng)測(cè)頁(yè)面內(nèi)容差異、操作習(xí)慣、有無(wú)緩存有一定浮動(dòng)，下圖是京喜首頁(yè)的一次評(píng)分：總分68，性能、體驗(yàn)、最佳實(shí)踐都有扣分，合計(jì)8項(xiàng)扣分項(xiàng)，后面我們來(lái)逐條分析這些扣分項(xiàng)。

扣分項(xiàng)分析和優(yōu)化

1、使用了過(guò)大的 WXML 節(jié)點(diǎn)數(shù)目

得分標(biāo)準(zhǔn)：頁(yè)面 WXML 節(jié)點(diǎn)少于 1000 個(gè)，節(jié)點(diǎn)樹(shù)深度少于 30 層，子節(jié)點(diǎn)數(shù)不大于 60 個(gè)。

頁(yè)面節(jié)點(diǎn)指標(biāo)的意義在于，過(guò)大的節(jié)點(diǎn)數(shù)，過(guò)多過(guò)深的節(jié)點(diǎn)組成，都會(huì)增加內(nèi)存使用，樣式重排時(shí)間更長(zhǎng)，影響體驗(yàn)。

現(xiàn)有節(jié)點(diǎn)2500+，想要進(jìn)行優(yōu)化，首先需要了解頁(yè)面各個(gè)模塊的節(jié)點(diǎn)數(shù)分布。

如何統(tǒng)計(jì)每個(gè)模塊的節(jié)點(diǎn)數(shù)呢？可以使用「控制變量法」，利用性能評(píng)測(cè)工具中，節(jié)點(diǎn)數(shù)超過(guò)1000時(shí)會(huì)列出節(jié)點(diǎn)總數(shù)的能力，我們可以在總指標(biāo)超過(guò)1000的情況下，每次隱藏一個(gè)模塊：

? 目標(biāo)模塊節(jié)點(diǎn)數(shù) = 原總節(jié)點(diǎn)數(shù) - 當(dāng)前節(jié)點(diǎn)數(shù)

（實(shí)測(cè)節(jié)點(diǎn)數(shù)會(huì)有小范圍浮動(dòng)，可以測(cè)3次取平均值）

首頁(yè)的模塊分析圖如下：

? （第一屏） （第二屏）

簡(jiǎn)化數(shù)據(jù)如下：

觀察列表可以得到兩個(gè)信息：首頁(yè)分為展示狀態(tài)互斥的第一屏和第二屏；列表模塊的節(jié)點(diǎn)數(shù)是大頭。

因此，我們得到優(yōu)化的兩個(gè)方向：

• 頁(yè)面元素按需加載，不展示時(shí)不渲染
• 長(zhǎng)列表減少元素個(gè)數(shù)

第一個(gè)優(yōu)化項(xiàng)可以通過(guò)變量控制組件顯示隱藏，按需加載卸載。

第二個(gè)優(yōu)化項(xiàng)首先想到的是減少列表接口分頁(yè)數(shù)值，比如一次請(qǐng)求20條數(shù)據(jù)改為請(qǐng)求5條。但是如果接口不支持自定義分頁(yè)，還可以實(shí)現(xiàn)更小的分頁(yè)拉取嗎？

那就自己寫(xiě)一個(gè)分頁(yè)方法的代理吧～

思路如下：

上方為原始請(qǐng)求，每次20條數(shù)據(jù)，下方為代理請(qǐng)求的實(shí)現(xiàn)，每次返回5條?；疑摼€(xiàn)框是真實(shí)的請(qǐng)求數(shù)據(jù)動(dòng)作，通過(guò)維護(hù)一個(gè)全量數(shù)據(jù)，需要哪頁(yè)取哪頁(yè)，這是示例代碼：

通過(guò)以上兩個(gè)優(yōu)化，可以成功的把首頁(yè)的頁(yè)面節(jié)點(diǎn)數(shù)瘦身一下了，最后我們成功達(dá)到 wxml 節(jié)點(diǎn)總數(shù)不大于1000的目標(biāo)。

2、存在圖片太大而有效顯示區(qū)域較小

得分標(biāo)準(zhǔn)：圖片寬高乘積 <= 實(shí)際顯示寬高乘積 * (設(shè)備像素比 ^ 2)

簡(jiǎn)單理解是圖片尺寸太大而展示尺寸太小，導(dǎo)致浪費(fèi)網(wǎng)絡(luò)請(qǐng)求時(shí)間和內(nèi)存資源。

解決方案：cdn服務(wù)商一般都支持通過(guò)參數(shù)獲取不同尺寸的圖片，前端可以包裝一個(gè)公共方法，根據(jù)頁(yè)面元素尺寸拉取合適大小的圖片。

此外，補(bǔ)充一下圖片體積的內(nèi)容，除了關(guān)注圖片尺寸，具體的體積大小其實(shí)更值得關(guān)注，有以下兩個(gè)點(diǎn)可以了解下：

• 圖片類(lèi)型的選擇大有文章，jpg/png/gif 還有 webp 應(yīng)該怎么選呢？先放一張 google 的圖

  

  這張圖里未考慮 webp，加上 webp 其他類(lèi)型競(jìng)爭(zhēng)力瞬間不足了，移動(dòng)端 androd 支持率基本可用，可以考慮根據(jù)設(shè)備類(lèi)型漸進(jìn)式使用：

  

• 利用一些壓縮技術(shù)對(duì)圖片進(jìn)行壓縮，壓縮尺寸可觀，但對(duì)圖片顯示質(zhì)量影響甚微。

3、存在可點(diǎn)擊元素的響應(yīng)區(qū)域過(guò)小

得分標(biāo)準(zhǔn)：可點(diǎn)擊元素的寬高都不小于 20px

移動(dòng)端操作全靠手指，過(guò)小的交互區(qū)域會(huì)帶來(lái)不好的體驗(yàn)，可以通過(guò)增大元素響應(yīng)熱區(qū)的方式來(lái)優(yōu)化，以下方式都可以：

• padding
• 透明的border
• box-shadow

4、對(duì)網(wǎng)絡(luò)請(qǐng)求做必要的緩存

得分標(biāo)準(zhǔn)：3 分鐘以?xún)?nèi)同一個(gè)url請(qǐng)求不出現(xiàn)兩次回包大于 128KB 且一模一樣的內(nèi)容

這一項(xiàng)的理由是，發(fā)起網(wǎng)絡(luò)請(qǐng)求總會(huì)讓用戶(hù)等待，可能造成不好的體驗(yàn)，應(yīng)盡量避免多余的請(qǐng)求，比如對(duì)同樣的請(qǐng)求進(jìn)行緩存。

優(yōu)化方式：

• 善用小程序的 storage 能力，做好更新和過(guò)期管理后，盡可能緩存請(qǐng)求到的數(shù)據(jù)。
• 針對(duì)確實(shí)需要多次請(qǐng)求的日志類(lèi)接口，可以通過(guò)在參數(shù)內(nèi)添加隨機(jī)數(shù)或者時(shí)間戳的方式進(jìn)行區(qū)分，避免誤判。

5、存在短時(shí)間內(nèi)發(fā)起太多的請(qǐng)求

得分標(biāo)準(zhǔn)：通過(guò)wx.request發(fā)起的耗時(shí)超過(guò) 300ms 的請(qǐng)求并發(fā)數(shù)不超過(guò) 10 個(gè)。

不同于上一項(xiàng)，這一項(xiàng)關(guān)注的是接口并發(fā)數(shù)：

• wx.request （HTTP 連接）的最大并發(fā)限制是 10 個(gè)
• wx.connectSocket （WebSocket 連接）的最大并發(fā)限制是 5 個(gè)

優(yōu)化方式：

• 計(jì)算邏輯后移， 接口聚合
• 對(duì)于職責(zé)類(lèi)似的網(wǎng)絡(luò)請(qǐng)求，最好采用節(jié)流的方式，先在一定時(shí)間間隔內(nèi)收集數(shù)據(jù)，再合并到一個(gè)請(qǐng)求體中發(fā)送給服務(wù)端

6、存在未綁定在wxml上的變量

得分標(biāo)準(zhǔn)：setData傳入的所有數(shù)據(jù)都在模板渲染中有相關(guān)依賴(lài)

這一項(xiàng)考察的是 data 冗余的問(wèn)題，小程序設(shè)計(jì)了渲染和邏輯分離的雙線(xiàn)程，兩邊通訊通過(guò) evaluateJavascript 轉(zhuǎn)換字符串再進(jìn)行拼接實(shí)現(xiàn)，需要非常小心兩個(gè)線(xiàn)程之間通訊的數(shù)據(jù)量。因此，未綁定wxml的變量，最好優(yōu)化成不使用 setData。

根據(jù)使用場(chǎng)景，可以做的優(yōu)化有：

• 與頁(yè)面展示無(wú)關(guān)的內(nèi)部變量，可以?huà)燧d在組件實(shí)例上，比如維護(hù)一個(gè) this.privateData 對(duì)象
• 使用小程序新版本支持的「純數(shù)據(jù)字段」：該字段不會(huì)被傳遞到 wxml 內(nèi)，配置正則劃定它的匹配范圍，可以正常使用 setData 方法

但是，如果你像我一樣遇到上面策略無(wú)法覆蓋的場(chǎng)景呢？

• 需要修改舊代碼，配置純數(shù)據(jù)字段的正則影響太大
• 京喜首頁(yè)使用了 Taro 做多端適配，Taro 編譯復(fù)雜邏輯的數(shù)組后會(huì)出現(xiàn)「影子變量」去代理邏輯，原本的數(shù)組變量被架空導(dǎo)致扣分

那么還有一個(gè)終極 hack 的方法：

這樣 list 會(huì)被判斷為有綁定節(jié)點(diǎn)，就不會(huì)扣分了

7、發(fā)起太多的圖片請(qǐng)求

得分標(biāo)準(zhǔn)：同域名耗時(shí)超過(guò) 100ms 的圖片請(qǐng)求并發(fā)數(shù)不超過(guò) 20 個(gè)

最后這一項(xiàng)也是圖片相關(guān)，發(fā)起太多圖片請(qǐng)求會(huì)觸發(fā)瀏覽器并行加載的限制，可能導(dǎo)致圖片加載慢，用戶(hù)一直處于等待中。

優(yōu)化方式：

• 雪碧圖
• 圖片懶加載：小程序 Image 組件支持通過(guò)配置 lazy-load 參數(shù)來(lái)實(shí)現(xiàn)懶加載，具體判定邏輯是圖片進(jìn)入上下三屏就開(kāi)始加載。如果需要更可控的實(shí)現(xiàn)，可以自己構(gòu)建組件來(lái)處理。

總結(jié)

做完這些優(yōu)化，再測(cè)一下體驗(yàn)評(píng)分：

以上就是京喜首頁(yè)在小程序體驗(yàn)評(píng)分優(yōu)化方面進(jìn)行的實(shí)踐內(nèi)容了。

總結(jié)一下，小程序性能評(píng)分可以從指標(biāo)和實(shí)際數(shù)據(jù)上給我們的項(xiàng)目?jī)?yōu)化提供一些建議，本文主要從評(píng)分角度去分析了各種優(yōu)化可能，希望能為各位小程序開(kāi)發(fā)者帶來(lái)參考價(jià)值。

文章轉(zhuǎn)載自：https://segmentfault.com/a/1190000023768105  作者：