为何小程序上线了，他们的内心却留下遗憾？
前言
出于多端投放和開放生態(tài)的考慮，閑魚開始接入整個阿里小程序體系。閑魚在9月份迅速上線了第一個小程序魚塘小程序，由于剛接觸不熟悉小程序體系，整體性能上有比較大的優(yōu)化空間，主要表現(xiàn)在以下問題：
- 小程序加載慢，低端 Android 機（Android vivo Y67）上首屏?xí)r間接近6s
- 滾動卡頓，在 iPhone 7P 上滾動幀率平均在 40fps 左右
- 滾動多屏數(shù)據(jù)之后 Tab 點擊切換慢，在 iPhone 7P 上切換 Tab 等待時間 3-5 秒，瞬時幀率低于 30fps
小程序由于其邏輯和渲染分離的架構(gòu)特點，除傳統(tǒng) H5 優(yōu)化手段之外還有其他不同點。本篇文章主要分析小程序構(gòu)架對渲染的影響，以及魚塘小程序下具體優(yōu)化手段。
小程序架構(gòu)
在分析具體優(yōu)化 Case 之前我們先看下小程序架構(gòu)，先要了解架構(gòu)才能清楚如何去優(yōu)化具體的業(yè)務(wù)代碼。阿里小程序采用支付寶小程序的架構(gòu)，這里引用一張支付寶小程序頁面生命周期圖。
目前市場上所有小程序都采用邏輯（worker）和渲染（webview）分離的方式。這樣帶來的好處是：
但是這樣也會造成一個顯而易見的問題，頁面性能強依賴 webview 和 worker 的通信效率：
小程序邏輯和渲染分離的架構(gòu)造成它與傳統(tǒng) H5 性能優(yōu)化方式上的一些差異。小程序性能優(yōu)化可以參考看下官方推薦的一些性能優(yōu)化建議，簡單來講需要特別注意 setData 操作的頻次和傳輸數(shù)據(jù)，接下來我們結(jié)合魚塘小程序具體案例一塊探討下。
業(yè)務(wù)層優(yōu)化
魚塘小程序是一個類似興趣圈子下的內(nèi)容聚合場景，用戶在這里可以無限加載瀏覽內(nèi)容，還會點擊 Tab 切換瀏覽不同維度的內(nèi)容。我們需要重點考慮小程序加載流暢度、滾動順滑度以及 Tab 點擊切換時候界面響應(yīng)速度。之前版本的魚塘小程序在低端 Android 機（Android vivo Y67）上首屏?xí)r間接近6s，在 iPhone 7P 上滾動幀率平均在 34fps - 60fps，點擊 Tab 切換瞬時幀率在 30fps 左右，下面針對幾個具體 Case 討論解決方案。
加載慢
『BEFORE』
『AFTER』
問題表現(xiàn)
從打開小程序到最終渲染出來經(jīng)歷了短暫的白屏
原因分析
加載整體耗時包括小程序容器初始化、數(shù)據(jù)請求以及請求結(jié)果返回到渲染，需要針對每個時期做優(yōu)化
優(yōu)化手段
- 引入小程序?qū)嵗；顧C制，降低小程序啟動耗時
- 將數(shù)據(jù)請求提前至 page.onLoad 中，請求階段加入閑魚 Loading 提示，通過交互減少用戶焦慮感
- 首屏數(shù)據(jù)離線化，在首屏數(shù)據(jù)到達前預(yù)渲染，在容器測請求提前至與小程序?qū)嵗龁硬⑿谢蚋?/li>
- 將首屏數(shù)據(jù)進行拆分，初始化只 setData 可見視圖對應(yīng)的數(shù)據(jù)
滾動卡頓
『BEFORE』
『AFTER』
問題表現(xiàn)
頁面滾動掉幀感明顯，粘手度低
原因分析
- 由于需要監(jiān)聽頁面滾動距離觸發(fā)頂部 Bar 顯示，Page 層監(jiān)聽了 onScroll 事件，并在回調(diào)中頻繁的調(diào)用 setData
- 加載下一頁 Feeds 的請求回調(diào)中，解析數(shù)據(jù)時多次調(diào)用 setData
- Feeds 卡片內(nèi)部監(jiān)聽了組件的 onAppear 和 onDisappear 事件，并在回調(diào)中調(diào)用 setData，目的是為了不重復(fù)發(fā)送曝光埋點
優(yōu)化手段
針對小程序 webview 和 worker 通信的機制，我們需要減少 setData 的調(diào)用頻率與傳輸數(shù)據(jù)大小。
- 優(yōu)化了 onScroll 回調(diào)邏輯，改為只有在部分時機（滾動距離在一定范圍內(nèi)）下才會觸發(fā) setData，且只做局部渲染
- 加載下一頁 Feeds 的請求回調(diào)優(yōu)化了數(shù)據(jù)解析邏輯，只調(diào)用一次 setData，并參考官方優(yōu)化建議使用 $spliceData 渲染長列表
- 將 setData 的數(shù)據(jù)大小進行優(yōu)化，只傳輸會影響視圖的相關(guān)數(shù)據(jù)
- 不再監(jiān)聽組件 onAppear 和 onDisappear 事件，改為監(jiān)聽組件的 onFirstAppear 事件，只有第一次 Appear 的時候才執(zhí)行曝光操作
Tab 切換響應(yīng)慢
『BEFORE』
『AFTER』
問題表現(xiàn)
加載幾頁 Feeds 后，切換 Tab 開始出現(xiàn)明顯卡頓，需等待 3-5 秒，部分 Android 機器上更為嚴(yán)重，偶爾會 Crash
原因分析
Tab 切換時在短時間內(nèi)做了太多事情：切換 Tab Current 狀態(tài)、銷毀 Feeds 列表、展示 Loading 動畫、發(fā)起數(shù)據(jù)請求 -> 渲染新列表，這樣高并發(fā)大面積的內(nèi)容更新導(dǎo)致小程序視圖層數(shù)據(jù)消費阻塞，從而產(chǎn)生卡頓感。
優(yōu)化手段
-
將 Tab 切換時的任務(wù)拆解開，分四個階段進行：
- 切換 Tab Current 狀態(tài)，執(zhí)行 Tab 切換動畫
- 在 Tab 切換動畫完成后將頁面滾動到 Tab 剛好 Sticky 住的位置
- 銷毀 Feeds 列表，展示 Loading 動畫
- 發(fā)起數(shù)據(jù)請求 -> 渲染
- 經(jīng)過這樣的拆解，將之前的『高并發(fā)大面積』轉(zhuǎn)換成了『分階段可控制』的更新方式，隨之帶來的就是界面上的流暢
容器層優(yōu)化
小程序容器通過離線緩存、數(shù)據(jù)預(yù)加載、小程序?；畹葯C制來優(yōu)化整體性能。然而在富交互場景中，webview 上的控件渲染會遇到很多性能瓶頸，目前阿里小程序支持在 webview 中內(nèi)嵌 native 組件來提升整體性能，魚塘小程序中有大量視頻內(nèi)容場景，使用的 video 組件就是 native 原生組件。這類組件脫離 webview 線程之外渲染，但是由于是覆蓋在 webview 之上，所以在 webview 內(nèi)無論怎樣修改 z-index 都無法將元素覆蓋在原生組件之上。
為了解決這個問題，小程序框架同學(xué)又設(shè)計了 cover-view ，它可以覆蓋在 native 組件之上，比如視頻上方的播放按鈕就可以用 cover-view 蓋上去。最終線上魚塘小程序通過同層渲染 video 組件之后用戶側(cè)體驗有比較大的提升。
總結(jié)與展望
經(jīng)過優(yōu)化之后，目前線上魚塘小程序相比之前版本有顯著提升：
針對這個業(yè)務(wù)場景下的小程序依然有很多可以繼續(xù)優(yōu)化空間，例如我們將每個魚塘實例化獨自小程序，這樣可以針對每個魚塘小程序去進行?；畹?。此外在小程序性能優(yōu)化相關(guān)上，我們認為可以在研發(fā)階段提供一個包含性能告警的容器，通過監(jiān)聽 setData 的調(diào)用頻率與傳輸數(shù)據(jù)大小，對開發(fā)者一些可能會影響性能的代碼寫法進行提示。未來我們會持續(xù)在閑魚小程序生態(tài)建設(shè)上發(fā)力，整合集團研發(fā)資源建立閑魚小程序研發(fā)全鏈路最佳實踐，提供外部服務(wù)商入駐開發(fā)三方小程序的良好體驗。
iPhone 11 Pro、衛(wèi)衣、T恤等你來抽，馬上來試試手氣 https://www.aliyun.com/1111/2019/m-lottery?utm_content=g_1000083877
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的为何小程序上线了，他们的内心却留下遗憾？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 闲鱼推荐，让智能计算从云走向端
- 下一篇： 蚂蚁金服资深总监韩鸿源：企业级数据库平台