前言

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

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

小程序架構(gòu)

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

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

1. 能夠滿足對(duì)于外部應(yīng)用管控的訴求，由于業(yè)務(wù)邏輯沒有運(yùn)行在 webview 上，所以無法通過瀏覽器的API直接操作渲染動(dòng)作，意味著不能通過腳本做一些動(dòng)態(tài)化操作。所有渲染相關(guān)操作都是通過 axml 來定義，外部應(yīng)用進(jìn)行更改都需要通過平臺(tái)審核。
2. 多個(gè)頁面可以共享同一個(gè) JS 運(yùn)行環(huán)境，整個(gè)小程序生命周期可以共享全局應(yīng)用上下文，接近 App 的開發(fā)體驗(yàn)。
3. 頁面渲染與業(yè)務(wù)邏輯分開執(zhí)行，不會(huì)出現(xiàn) JS 邏輯執(zhí)行導(dǎo)致渲染卡住的情況，有利于提升整體渲染性能。

但是這樣也會(huì)造成一個(gè)顯而易見的問題，頁面性能強(qiáng)依賴 webview 和 worker 的通信效率：

1. webview 和 worker 之間的通信是異步的。這意味著當(dāng)我們調(diào)用 setData 時(shí)，數(shù)據(jù)變更不會(huì)立即體現(xiàn)到頁面渲染上，而是需要從 worker 異步傳輸?shù)?webview 。
2. 數(shù)據(jù)傳輸時(shí)需要序列化為字符串，然后通過 evaluateJavascript 方式傳輸，數(shù)據(jù)大小會(huì)影響傳輸性能。

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

業(yè)務(wù)層優(yōu)化

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

加載慢

『BEFORE』

『AFTER』

問題表現(xiàn)

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

原因分析

加載整體耗時(shí)包括小程序容器初始化、數(shù)據(jù)請(qǐng)求以及請(qǐng)求結(jié)果返回到渲染，需要針對(duì)每個(gè)時(shí)期做優(yōu)化

優(yōu)化手段

• 引入小程序?qū)嵗；顧C(jī)制，降低小程序啟動(dòng)耗時(shí)
• 將數(shù)據(jù)請(qǐng)求提前至 page.onLoad 中，請(qǐng)求階段加入閑魚 Loading 提示，通過交互減少用戶焦慮感
• 首屏數(shù)據(jù)離線化，在首屏數(shù)據(jù)到達(dá)前預(yù)渲染，在容器測(cè)請(qǐng)求提前至與小程序?qū)嵗龁?dòng)并行或更前
• 將首屏數(shù)據(jù)進(jìn)行拆分，初始化只 setData 可見視圖對(duì)應(yīng)的數(shù)據(jù)

滾動(dòng)卡頓

『BEFORE』

『AFTER』

問題表現(xiàn)

頁面滾動(dòng)掉幀感明顯，粘手度低

原因分析

• 由于需要監(jiān)聽頁面滾動(dòng)距離觸發(fā)頂部 Bar 顯示，Page 層監(jiān)聽了 onScroll 事件，并在回調(diào)中頻繁的調(diào)用 setData
• 加載下一頁 Feeds 的請(qǐng)求回調(diào)中，解析數(shù)據(jù)時(shí)多次調(diào)用 setData
• Feeds 卡片內(nèi)部監(jiān)聽了組件的 onAppear 和 onDisappear 事件，并在回調(diào)中調(diào)用 setData，目的是為了不重復(fù)發(fā)送曝光埋點(diǎn)

優(yōu)化手段

針對(duì)小程序 webview 和 worker 通信的機(jī)制，我們需要減少 setData 的調(diào)用頻率與傳輸數(shù)據(jù)大小。

• 優(yōu)化了 onScroll 回調(diào)邏輯，改為只有在部分時(shí)機(jī)（滾動(dòng)距離在一定范圍內(nèi)）下才會(huì)觸發(fā) setData，且只做局部渲染
• 加載下一頁 Feeds 的請(qǐng)求回調(diào)優(yōu)化了數(shù)據(jù)解析邏輯，只調(diào)用一次 setData，并參考官方優(yōu)化建議使用 $spliceData 渲染長(zhǎng)列表
• 將 setData 的數(shù)據(jù)大小進(jìn)行優(yōu)化，只傳輸會(huì)影響視圖的相關(guān)數(shù)據(jù)
• 不再監(jiān)聽組件 onAppear 和 onDisappear 事件，改為監(jiān)聽組件的 onFirstAppear 事件，只有第一次 Appear 的時(shí)候才執(zhí)行曝光操作

Tab 切換響應(yīng)慢

『BEFORE』

『AFTER』

問題表現(xiàn)

加載幾頁 Feeds 后，切換 Tab 開始出現(xiàn)明顯卡頓，需等待 3-5 秒，部分 Android 機(jī)器上更為嚴(yán)重，偶爾會(huì) Crash

原因分析

Tab 切換時(shí)在短時(shí)間內(nèi)做了太多事情：切換 Tab Current 狀態(tài)、銷毀 Feeds 列表、展示 Loading 動(dòng)畫、發(fā)起數(shù)據(jù)請(qǐng)求 -> 渲染新列表，這樣高并發(fā)大面積的內(nèi)容更新導(dǎo)致小程序視圖層數(shù)據(jù)消費(fèi)阻塞，從而產(chǎn)生卡頓感。

優(yōu)化手段

• 將 Tab 切換時(shí)的任務(wù)拆解開，分四個(gè)階段進(jìn)行：

  • 切換 Tab Current 狀態(tài)，執(zhí)行 Tab 切換動(dòng)畫
  • 在 Tab 切換動(dòng)畫完成后將頁面滾動(dòng)到 Tab 剛好 Sticky 住的位置
  • 銷毀 Feeds 列表，展示 Loading 動(dòng)畫
  • 發(fā)起數(shù)據(jù)請(qǐng)求 -> 渲染
• 經(jīng)過這樣的拆解，將之前的『高并發(fā)大面積』轉(zhuǎn)換成了『分階段可控制』的更新方式，隨之帶來的就是界面上的流暢

容器層優(yōu)化

小程序容器通過離線緩存、數(shù)據(jù)預(yù)加載、小程序?；畹葯C(jī)制來優(yōu)化整體性能。然而在富交互場(chǎng)景中，webview 上的控件渲染會(huì)遇到很多性能瓶頸，目前阿里小程序支持在 webview 中內(nèi)嵌 native 組件來提升整體性能，魚塘小程序中有大量視頻內(nèi)容場(chǎng)景，使用的 video 組件就是 native 原生組件。這類組件脫離 webview 線程之外渲染，但是由于是覆蓋在 webview 之上，所以在 webview 內(nèi)無論怎樣修改 z-index 都無法將元素覆蓋在原生組件之上。

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

總結(jié)與展望

經(jīng)過優(yōu)化之后，目前線上魚塘小程序相比之前版本有顯著提升：

針對(duì)這個(gè)業(yè)務(wù)場(chǎng)景下的小程序依然有很多可以繼續(xù)優(yōu)化空間，例如我們將每個(gè)魚塘實(shí)例化獨(dú)自小程序，這樣可以針對(duì)每個(gè)魚塘小程序去進(jìn)行?；畹取４送庠谛〕绦蛐阅軆?yōu)化相關(guān)上，我們認(rèn)為可以在研發(fā)階段提供一個(gè)包含性能告警的容器，通過監(jiān)聽 setData 的調(diào)用頻率與傳輸數(shù)據(jù)大小，對(duì)開發(fā)者一些可能會(huì)影響性能的代碼寫法進(jìn)行提示。未來我們會(huì)持續(xù)在閑魚小程序生態(tài)建設(shè)上發(fā)力，整合集團(tuán)研發(fā)資源建立閑魚小程序研發(fā)全鏈路最佳實(shí)踐，提供外部服務(wù)商入駐開發(fā)三方小程序的良好體驗(yàn)。

iPhone 11 Pro、衛(wèi)衣、T恤等你來抽，馬上來試試手氣 https://www.aliyun.com/1111/2...

本文作者：閑魚技術(shù)-頌晨、玉縝

閱讀原文

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請(qǐng)及時(shí)與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會(huì)在5工作日內(nèi)聯(lián)系您，一經(jīng)查實(shí)，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://jstctz.cn/25261.html