存量用戶運營企業微信的「用戶端小程序」優化方案

企業微信端產品「C端用戶小程序」，是一款服務於vivo線下代理、門店和導購，幫助導購鏈接用戶，快速與用戶進行溝通的工具。基於「C端小程序」的PU/UV量較爲龐大，爲了更加極致的用戶體驗，因此提高小程序性能優化是必然。

1、業務現狀

1.1 存量用戶運營企業微信「用戶端小程序」

存量用戶運營企業微信「用戶端小程序」主要是服務於vivo代理、線下門店和導購，幫助導購鏈接用戶的工具。

• 用戶羣：vivo線下用戶。
• 主要功能：vivo新機預售，新用戶註冊。

看下「用戶端小程序」的「新用戶註冊」，「新機預售」的頁面，以下：

vivo新用戶註冊 

 

vivo新機預售

1.2 性能數據

一圖勝千言，看下存量用戶運營「用戶端小程序」在沒作優化以前，從「小程序數據助手」中獲取到的「代碼包下載量，打開耗時分佈，網絡請求延遲，網絡流量消耗」等數據。以下：

從圖中咱們能夠看到，下載小程序代碼包主要集中在2-5秒，此外，部分http請求接口的時間延遲很長，會影響到總體頁面的渲染效果。因而可知，存量用戶運營「用戶端小程序」還有很大的優化空間。

2、性能指標

2.1 怎麼定義高性能？

單純的快是不行的。咱們不該該單純考慮速度指標而忽略用戶的感知體驗，而應該全方位衡量用戶在使用過程當中能感知到的與應用加載相關的每一個節點。

2.2 性能指標關鍵術語

FCP：白屏加載結束

FMP：首屏渲染完成

TTI：全部內容加載完成

2.3 咱們優化須要達到的指標

小程序官方指標：

1. 首屏時間不超過 5 秒。
2. 渲染時間不超過 500ms。
3. 每秒調用 setData 的次數不超過 20 次。
4. setData 的數據在 JSON.stringify 後不超過 256kb。
5. 頁面 WXML 節點少於 1000 個，節點樹深度少於 30 層，子節點數不大於 60 個。
6. 全部網絡請求都在 1 秒內返回結果。

存量用戶運營」用戶端小程序「須要達到的指標：

1. 首屏時間不超過 2.5 秒。
2. setData 的數據量不超過 100kb。
3. 全部網絡請求都在 1 秒內返回結果。
4. 組件滑動、長列表滾動無卡頓感。

 

3、小程序的一些基本概念

3.1 小程序底層框架

小程序的最終渲染載體依然是瀏覽器內核，而不是原生客戶端。啓用了雙線程模型：

1. 視圖層：也就是webview線程，負責啓用不一樣的 webview 來渲染不一樣的小程序頁面。
2. 邏輯層：一個單獨的線程執行 JS 代碼，能夠控制視圖層的邏輯。

 

3.2 小程序的啓動步驟

1. 準備運行環境。

• 在小程序啓動前，微信會先啓動雙線程環境，並在線程中完成小程序基礎庫的初始化和預執行。

小程序基礎庫包括 WebView 基礎庫和 AppService 基礎庫，前者注入到視圖層中，後者注入到邏輯層中，分別爲所在層級提供其運行所需的基礎框架能力。

2. 下載小程序代碼包。

3. 加載小程序代碼包。

• 在此階段，主包內的全部頁面 JS 文件及其依賴文件都會被自動執行。

在頁面註冊過程當中，基礎庫會調用頁面 JS 文件的 Page 構造器方法，來記錄頁面的基礎信息（包括初始數據、方法等）。

4. 初始化小程序首頁。 

• 在小程序代碼包加載完以後，基礎庫會根據啓動路徑找到首頁，根據首頁的基礎信息初始化一個頁面實例，並把信息傳遞給視圖層，視圖層會結合 WXML 結構、WXSS 樣式和初始數據來渲染界面。

3.3 小程序開發工具——體驗評分工具audits

(ps:小程序開發者工具的評分插件audits能夠對小程序的性能，使用體驗，實踐，UI樣式，http請求等多個維度進行綜合評分，建議小程序開發者在項目開發中使用。)

4、小程序優化技術方案

4.1 針對小程序啓動太慢的方案

方案1：無用的文件，函數，wxss樣式剔除，不須要的import砍掉。

方案2：減小代碼包中的靜態資源文件。

除了部分圖片必須放在代碼包（譬如網絡異常提示）以外，建議開發者把圖片、視頻等靜態資源都放在 CDN 上。

方案3：邏輯後移，精簡業務邏輯。

儘可能把業務邏輯寫在後端，若是一旦出現線上問題，小程序發版須要騰訊審覈，然後端能夠及時發佈代碼。

方案4：分包加載與分包預下載。

• 可參考小程序開放平臺文檔
• 獨立分包
• 分包預下載

方案5：部分頁面h5化。

• 小程序提供了 web-view 組件，支持在小程序內訪問h5。若是小程序源碼太大從而影響下載時間，能夠考慮降級處理，把部分頁面 h5 化。
• 具體可參考web-view文檔。

4.2 針對小程序白屏時間過長的方案

小程序的白屏階段：小程序代碼包下載完（也就是啓動界面結束）以後，頁面完成首屏渲染的這一階段，也就是 FMP (首次有效繪製)。

影響白屏的兩個因素：

• 網絡資源加載時間。
• 渲染時間。

方案1：啓用本地緩存。

• 將請求接口中獲取到的數據存儲在storage裏面，部分數據不須要每次發送http請求獲取。

方案2：跳轉頁面時預拉取。

• 通常是在頁面onload的時候去獲取接口數據。
• 能夠在調用wx.navigateTo以前先調用下一個頁面的http接口，將數據存儲在全局的promise裏面，下一個頁面onload的時候，直接從promise獲取數據。

(ps:在A頁面onHide或者onUnload的時候經過promise請求下一個頁面B頁面的http接口，在B頁面onload或者onShow的時候從promise中獲取數據。)

方案3：非關鍵渲染數據延遲請求。

• 將頁面分爲主體模塊(骨架，列表數據)和非主體模塊(彈窗等)。
• 非主體模塊的數據請求能夠延遲加載，使用setTimeout來請求接口。

方案4：分屏渲染。

• 將非主體模塊分屏渲染。
• 以下圖，咱們將A模塊設置爲主體屏，B,C模塊設置爲非主體屏，等A模塊渲染完成後在渲染B,C模塊。

方案5：骨架屏。

• 可使用尺寸穩定的骨架屏，來輔助實現真實模塊佔位和瞬間加載。

方案6：限制http請求數量。

• wx.request （HTTP 鏈接）的最大併發限制是 10 個。
• wx.connectSocket （WebSocket 鏈接）的最大併發限制是 5 個。

方案7：圖片資源優化。

• 使用WebP格式。
• 圖片裁剪，壓縮，雪碧圖
• 圖片懶加載

4.3 提高渲染性能

概念：當調用 wx.navigateTo 打開一個新頁面時，小程序框架會完成如下幾步：

• 準備新的 webview 線程環境，包括基礎庫的初始化。
• 從邏輯層到視圖層的初始數據通訊。
• 視圖層根據邏輯層的數據，結合 WXML 片斷構建出節點樹（包括節點屬性、事件綁定等信息），最終與 WXSS 結合完成頁面渲染。

 

小程序的渲染損耗主要在數據通訊和節點樹建立及更新的流程中，提高渲染性能優化的方向：

1. 下降線程間通訊頻次。
2. 減小線程間通訊的數據量。
3. 減小 WXML 節點數量。

方案1：合併setData調用。

儘量地把屢次setData調用合併成一次。

只把與界面渲染相關的數據放在Data中。

方案2：去掉沒必要要的事件綁定。

沒必要要的click、touch、onPageScroll不要被觸發。

方案3：去掉沒必要要的節點屬性。

組件節點支持附加自定義數據 dataset，當用戶事件被觸發時，視圖層會把事件 target 和 dataset 數據傳輸給邏輯層。以下例：

<view class="tabbar-item" wx:for="{{list}}" wx:key="index"  item="item">
  <view @tap="tabFn" data-index="{{item}}">
  </view>
</view>
 
methods = {
  tabFn (e) {
    const item = e.currentTarget.dataset['item'];
    console.log(item);
  }
};

自定義數據量越大，事件通訊的耗時就會越長，因此儘可能減小自定義數據量，或者不用自定義數據。

4.4 解決小程序內存佔用太高的問題

當小程序佔用系統資源太高，就有可能會被系統銷燬或被微信客戶端主動回收，致使小程序掛掉。

方案1：回收頁面的setTimeout和setInterval計時器。

小程序每個頁面都會獨立一個 webview 線程，但邏輯層是單線程的，也就是全部的 webview 線程共享一個 JS 線程，以致於跳轉頁面，計時器還在跑。

onHide或者onUnload的時候清除計時器。

方案2：避免頻發事件中的重度內存操做。

• onPageScroll 事件回調使用節流。
• 避免 CPU 密集型操做，譬如複雜的計算。
• 避免調用 setData，或減少 setData 的數據量。

5、優化後的結果

5.1 看下audis下的得分

優化以前得分以下：

優化以後得分以下：

因而可知，按照以上步驟作小程序性能優化以後，audis的綜合評分是有一個明顯的進步的。

5.2 優化以後，「小程序數據助手」中的性能數據

6、總結

小程序性能優化和H5優化同樣，是一個根據多樣性用戶場景作持續迭代的過程，也是咱們平常作web開發揮之不去的原則和主題。本文探討了小程序優化的各類場景和方案，但願在之後的項目開發過程當中，可以持續優化，打造出更好的產品。

做者：vivo-Fu Weilang