前言

出于多端投放和開放生態的考慮，閑魚開始接入整個阿里小程序體系。閑魚在9月份迅速上線了第一個小程序魚塘小程序，由于剛接觸不熟悉小程序體系，整體性能上有比較大的優化空間，主要表現在以下問題：

• 小程序加載慢，低端 Android 機（Android vivo Y67）上首屏時間接近6s
• 滾動卡頓，在 iPhone 7P 上滾動幀率平均在 40fps 左右
• 滾動多屏數據之后 Tab 點擊切換慢，在 iPhone 7P 上切換 Tab 等待時間 3-5 秒，瞬時幀率低于 30fps
  小程序由于其邏輯和渲染分離的架構特點，除傳統 H5 優化手段之外還有其他不同點。本篇文章主要分析小程序構架對渲染的影響，以及魚塘小程序下具體優化手段。

小程序架構

在分析具體優化 Case 之前我們先看下小程序架構，先要了解架構才能清楚如何去優化具體的業務代碼。阿里小程序采用支付寶小程序的架構，這里引用一張支付寶小程序頁面生命周期圖。

目前市場上所有小程序都采用邏輯（worker）和渲染（webview）分離的方式。這樣帶來的好處是：

能夠滿足對于外部應用管控的訴求，由于業務邏輯沒有運行在 webview 上，所以無法通過瀏覽器的API直接操作渲染動作，意味著不能通過腳本做一些動態化操作。所有渲染相關操作都是通過 axml 來定義，外部應用進行更改都需要通過平臺審核。

多個頁面可以共享同一個 JS 運行環境，整個小程序生命周期可以共享全局應用上下文，接近 App 的開發體驗。

頁面渲染與業務邏輯分開執行，不會出現 JS 邏輯執行導致渲染卡住的情況，有利于提升整體渲染性能。

但是這樣也會造成一個顯而易見的問題，頁面性能強依賴 webview 和 worker 的通信效率：

webview 和 worker 之間的通信是異步的。這意味著當我們調用 setData 時，數據變更不會立即體現到頁面渲染上，而是需要從 worker 異步傳輸到 webview 。

數據傳輸時需要序列化為字符串，然后通過 evaluateJavascript 方式傳輸，數據大小會影響傳輸性能。

小程序邏輯和渲染分離的架構造成它與傳統 H5 性能優化方式上的一些差異。小程序性能優化可以參考看下官方推薦的一些性能優化建議，簡單來講需要特別注意 setData 操作的頻次和傳輸數據，接下來我們結合魚塘小程序具體案例一塊探討下。

業務層優化

魚塘小程序是一個類似興趣圈子下的內容聚合場景，用戶在這里可以無限加載瀏覽內容，還會點擊 Tab 切換瀏覽不同維度的內容。我們需要重點考慮小程序加載流暢度、滾動順滑度以及 Tab 點擊切換時候界面響應速度。之前版本的魚塘小程序在低端 Android 機（Android vivo Y67）上首屏時間接近6s，在 iPhone 7P 上滾動幀率平均在 34fps - 60fps，點擊 Tab 切換瞬時幀率在 30fps 左右，下面針對幾個具體 Case 討論解決方案。

加載慢

『BEFORE』

『AFTER』

問題表現

從打開小程序到最終渲染出來經歷了短暫的白屏

原因分析

加載整體耗時包括小程序容器初始化、數據請求以及請求結果返回到渲染，需要針對每個時期做優化

優化手段

• 引入小程序實例保活機制，降低小程序啟動耗時
• 將數據請求提前至 page.onLoad 中，請求階段加入閑魚 Loading 提示，通過交互減少用戶焦慮感
• 首屏數據離線化，在首屏數據到達前預渲染，在容器測請求提前至與小程序實例啟動并行或更前
• 將首屏數據進行拆分，初始化只 setData 可見視圖對應的數據

滾動卡頓

『BEFORE』

『AFTER』

問題表現

頁面滾動掉幀感明顯，粘手度低

原因分析

• 由于需要監聽頁面滾動距離觸發頂部 Bar 顯示，Page 層監聽了 onScroll 事件，并在回調中頻繁的調用 setData
• 加載下一頁 Feeds 的請求回調中，解析數據時多次調用 setData
• Feeds 卡片內部監聽了組件的 onAppear 和 onDisappear 事件，并在回調中調用 setData，目的是為了不重復發送曝光埋點

優化手段

針對小程序 webview 和 worker 通信的機制，我們需要減少 setData 的調用頻率與傳輸數據大小。

• 優化了 onScroll 回調邏輯，改為只有在部分時機（滾動距離在一定范圍內）下才會觸發 setData，且只做局部渲染
• 加載下一頁 Feeds 的請求回調優化了數據解析邏輯，只調用一次 setData，并參考官方優化建議使用 $spliceData 渲染長列表
• 將 setData 的數據大小進行優化，只傳輸會影響視圖的相關數據
• 不再監聽組件 onAppear 和 onDisappear 事件，改為監聽組件的 onFirstAppear 事件，只有第一次 Appear 的時候才執行曝光操作

Tab 切換響應慢

『BEFORE』

『AFTER』

問題表現

加載幾頁 Feeds 后，切換 Tab 開始出現明顯卡頓，需等待 3-5 秒，部分 Android 機器上更為嚴重，偶爾會 Crash

原因分析

Tab 切換時在短時間內做了太多事情：切換 Tab Current 狀態、銷毀 Feeds 列表、展示 Loading 動畫、發起數據請求 -> 渲染新列表，這樣高并發大面積的內容更新導致小程序視圖層數據消費阻塞，從而產生卡頓感。

優化手段

• 將 Tab 切換時的任務拆解開，分四個階段進行：

  • 切換 Tab Current 狀態，執行 Tab 切換動畫
  • 在 Tab 切換動畫完成后將頁面滾動到 Tab 剛好 Sticky 住的位置
  • 銷毀 Feeds 列表，展示 Loading 動畫
  • 發起數據請求 -> 渲染
• 經過這樣的拆解，將之前的『高并發大面積』轉換成了『分階段可控制』的更新方式，隨之帶來的就是界面上的流暢

容器層優化

小程序容器通過離線緩存、數據預加載、小程序保活等機制來優化整體性能。然而在富交互場景中，webview 上的控件渲染會遇到很多性能瓶頸，目前阿里小程序支持在 webview 中內嵌 native 組件來提升整體性能，魚塘小程序中有大量視頻內容場景，使用的 video 組件就是 native 原生組件。這類組件脫離 webview 線程之外渲染，但是由于是覆蓋在 webview 之上，所以在 webview 內無論怎樣修改 z-index 都無法將元素覆蓋在原生組件之上。

為了解決這個問題，小程序框架同學又設計了 cover-view ，它可以覆蓋在 native 組件之上，比如視頻上方的播放按鈕就可以用 cover-view 蓋上去。最終線上魚塘小程序通過同層渲染 video 組件之后用戶側體驗有比較大的提升。

總結與展望

經過優化之后，目前線上魚塘小程序相比之前版本有顯著提升：

針對這個業務場景下的小程序依然有很多可以繼續優化空間，例如我們將每個魚塘實例化獨自小程序，這樣可以針對每個魚塘小程序去進行保活等。此外在小程序性能優化相關上，我們認為可以在研發階段提供一個包含性能告警的容器，通過監聽 setData 的調用頻率與傳輸數據大小，對開發者一些可能會影響性能的代碼寫法進行提示。未來我們會持續在閑魚小程序生態建設上發力，整合集團研發資源建立閑魚小程序研發全鏈路最佳實踐，提供外部服務商入駐開發三方小程序的良好體驗。

iPhone 11 Pro、衛衣、T恤等你來抽，馬上來試試手氣 https://www.aliyun.com/1111/2019/m-lottery?utm_content=g_1000083877

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的为何小程序上线了，他们的内心却留下遗憾？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。