为何小程序上线了,他们的内心却留下遗憾?
前言
出于多端投放和開放生態(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 闲鱼推荐,让智能计算从云走向端
- 下一篇: 蚂蚁金服资深总监韩鸿源:企业级数据库平台