五星門店小程序性能優化實踐

一、背景介紹

1.1 業務介紹

五星門店小程序主要服務於五星線下門店交易場景，目前已有79個城市267家門店（包括超級體驗店、城旗店、京東Mall等）在使用，用戶可以通過小程序便捷地查看和購買門店的商品。五星門店小程序已實現基於Taro跨端解決方案的一碼多端能力，一套代碼可以在京東App以及微信小程序中運行，大幅提升了研發效率，可以更快更好地支持門店業務快速發展。

1.2 現狀分析

隨着業務高速發展，目前線下門店的數量仍然在不斷擴張，未來會有更多的用戶使用五星門店小程序。作爲線下門店核心交易工具，爲了能夠更好得服務更多的門店和用戶，快速瞭解一線的使用情況，給用戶更好的體驗，我們建立了以下機制：

（1）日常溝通羣與門店導購和運營人員保持密切聯繫，及時獲取用戶反饋，爲產研團隊提供有價值的一線參考。

（2）我們還通過團隊內部的日常體驗走查機制，主動發現問題，並由產研側推動優化小程序的體驗性能。

無論是一線反饋還是內部走查，都爲我們提供最真實、最有價值的問題參考，讓我們能夠從真實用戶角度出發去優化小程序。

二、具體行動

2.1 結果概覽

本次小程序優化主要集中在以下三方面：js報錯率、頁面渲染速度和包體積，整體優化結果如下所示：

（1）針對js報錯率，優化前平均一週js錯誤數1374次，錯誤人數694人，優化後平均一週js錯誤數260次，錯誤人數129人，優化前後平均一週js錯誤人數和錯誤次數降低約81%。

（2）針對小程序黃金流程的頁面渲染優化，不同機型在渲染速度上均有不同程度的提升，我們以iPhone14Pro、iphone14、onePlus9、華爲Nova8以及紅米手機五種測試機型作爲參考：

▪ 商詳頁優化前後渲染速度平均提升28%；

▪ 購物車優化前後渲染速度平均提升20%；

▪ 結算頁優化前後渲染速度平均提升25.4%；

（3）針對包體積優化，抽離主包中冗餘的代碼和頁面，並且因商詳頁面訪問人數和訪問次數排在Top1，將商詳頁面從子包中移到主包，提升商詳頁面的訪問速度，從而使得小程序日均切換耗時對比優化前下降17.95%，總包由5.92MB降低到5.32MB，縮小將近10.14%，主包由1.53MB縮小1.26MB，縮小將近17.65%。

2.2 實踐分析

2.2.1 日常體驗走查機制





 

 

▪ 制定走查原則和評估標準：首先，依據行業大廠內優秀實踐和《尼爾森十大可用性原則》，結合五星門店的業務場景進行提煉和細化標準，根據頁面影響範圍和與核心指標的相關性，劃分核心頁面和非核心頁面制定具體的檢查項，形成針對性的走查。以無阻礙瀏覽、可順暢操作爲目標，將問題嚴重程度分爲4個評估標準：致命、嚴重、一般、輕微，研發組負責收集、定義問題，並給出嚴重程度評估，然後與負責的主產品一起協定解決優先級，最終由項目組決定最終負責人及解決排期。

▪ 確定走查的時間和頻率：在產品開發的不同階段進行走查，如設計初稿完成後、開發中期和最終階段，同時確認走查業務場景，整理好走查的物料。

▪ 制定走查的參與人員：可包括前端開發工程師、設計師、產品經理等相關角色，以確保多角度考慮產品的使用。

▪ 記錄並整理問題：通過實際操作產品，檢查各個方面的問題，以文檔、截圖或錄屏等方式記錄問題，同時對問題進行嚴重程度分析和優先級整理，確保準確描述和分類。

▪ 提出改進建議：針對每個問題，研發定義問題嚴重程度，與產品協定解決優先級，提出具體的修復方案、優化建議等。

▪ 問題追蹤和驗證：將問題和改進建議記錄在項目管理工具中，跟蹤問題解決進度，並進行驗證，確保解決問題。

通過以上的原則、標準和流程，可以有效地進行產品體驗走查，提升產品的用戶體驗質量。自2023年以來，我們已完成：小程序整體流程場景、日常掃碼進場體驗場景、黃金流程體驗場景、武漢掃碼場景、首頁升級體驗場景、商詳升級體驗場景等6場體驗走查，提出的數十個優化建議已經在優化迭代中落地。

2.2.2 日常優化迭代機制

針對大促備戰緊張、日常需求複雜、量大、迭代快速的情況，我們與產品、測試等項目組成員商議後共同制定了日常優化迭代機制。自2022年以來，我們已完成48個版本體驗優化。我們是如何與需求並行推動落地的呢？

（1）優化項來源收集：

1）前期主要通過用戶動線梳理和業務說明，前端小組成員進行週會或日常走查並記錄表格

2）後續擴大範圍至項目組全體成員內部體驗走查

3）大促期間與客服、用戶、導購建立的線上和線下等體驗溝通提升羣組。

（2）確定走查範圍：優先優化黃流頁面，其次是其他訪問人數較多、業務較重要的頁面。

（3）確定走查方式：以視覺瀏覽、交互操作維度，多場景體驗業務邏輯，來捕獲問題。

（4）統計走查內容：根據錯誤嚴重程度排序，並組會同步產品、測試及其他相關人員，優先解決線上緊急重要優化項，其次進行日常版本迭代。

（5）嚴格按照日常項目流程開發和上線：利用項目外時間與業務、產品、測試等相關人員針對走查修復內容達成一致，最終共同進行排期、開發、測試、checkList和上線。

2.2.3 性能/質量優化

2.2.3.1 js異常報錯解決

（1）統計報錯信息，減少數據干擾因素，確定樣本範圍、報錯範圍、報錯優先級

▪ 數據整理篩選：篩選報錯信息，排除干擾數據，確立樣本與報錯範圍，劃分優先級。

▪ 統計分析結果：12月11日對JS數據進行梳理，發現報錯隨訪問量和新需求增加。由於12.1-12.11期間數據穩定，我們進行了專項統計。

▪ 優化重點排序：按報錯頻率和頁面重要性，優先處理啓動頁、首頁、商詳、購物車、結算頁、訂單頁、分類搜索、門店預約及活動等關鍵頁面。

▪ 錯誤分類及排序：錯誤主要分爲：業務代碼錯誤、插件錯誤、基礎庫錯誤等。優先解決業務代碼錯誤，因爲直接影響用戶體驗，可能導致程序中斷、功能異常、數據丟失、兼容性問題。再處理插件和基礎庫錯誤，以提升用戶體驗。其次是插件錯誤和基礎庫錯誤較少，因爲很難排查錯誤來源和信息，需要外部依賴方（京東小程序、微信小程序）官方解決和迭代

▪ 確定版本迭代優先級：優先優化線上版本，逐步擴展至體驗版和開發版。

（2） 確定項目中JS報錯的類型，進行迭代方式優化上線，並制定後續避免措施

▪ 報錯類型：聚焦TypeError、ReferenceError和AsyncError，主要涉及變量操作和使用、函數的聲明和定義、異步錯誤處理和捕獲。

▪ 原因分析：業務迭代快，日常關注不足。

▪ 優化行動：12月14日優化後，報錯率降至千分之五。

▪ 後續策略：持續迭代優化，加強內部審覈、互相的checkList，預防同類問題。

2.2.3.2 縮包實踐

（1）使用打包工具（webpackChain）來分析包體積的構成。





 



（2）優化大模塊common（公共邏輯）及vendors（第三方庫公共依賴）的步驟如下：

1）刪除歷史遺留無用模塊。

2）整合和提煉組件及公共方法代碼，刪除重複代碼。

3）按需引入第三方庫，並在保證業務正常運轉的前提下將第三方庫替換爲原生方法，若無法替代則使用體積最小版本。

4）靜態資源優化：媒體資源較多的在本地存儲或以Base64形式儲存，本次調整爲CDN引入。



（3）後續措施：

1）使用EOS平臺檢測代碼重複率，及時整合和提煉代碼。

2）獨立引用第三方庫，並使用最小體積版本。

3）優先統一使用CDN引入靜態資源，儘量縮減存儲在本地或使用Base64形式。

2.2.3.3 頁面渲染速度優化

（1） 商詳頁面，經過優化後平均渲染速度提升約28%，左側圖均爲優化後，右側圖均爲優化前。

iPhone14：

 





 

對於商詳切出小程序再切入小程序的情況，在優化之前，商詳會重新刷新接口，導致頁面會出現短暫抖動。在優化之後，商詳保持原有數據不重新刷新接口，使得頁面能夠保持穩定







 

One9Plus：

 





 

紅米：

 





 

分析商詳現狀： 頁面滑動卡頓、首次進入商詳白屏時間長、每次進入商詳（無論是首次進入還是由上一級頁面返回）都會請求商詳接口，導致即使頁面有數據也會有loading出現，並且在彈窗彈出的情況下，由上一級頁面返回商詳時彈窗會閃現一下等。

根據現狀，從以下幾個方面進行優化：

1）整體佈局

優化前：商詳頁面最外層是 ScrollView 標籤，藉助ScrollY屬性的設置實現頁面滾動。經調研發現ScrollView更適合局部滾動，如果採用ScrollView實現頁面級滾動，滾動性能會比較差，頁面上下快速頻繁滾動會卡頓。

優化後：去掉最外層的ScrollView標籤，給最外層的View標籤設置100%屏幕高度，內層元素高度由內容撐開，利用內容超出一屏高度產生的系統默認滾動特性實現頁面滾動。滾動到某一指定位置由 scrollIntoView 更改爲 Taro.pageScrollTo 實現（比如商詳的返回頂部功能，切換頂部tab滾動到相應區域）。

2）組件優化

優化前：子組件直接在父組件中引用，並且組件中沒有使用memo，useMemo，useCallBack等能提升性能的鉤子函數。

優化後：合理使用React.memo, 商詳頁面比較複雜，子組件較多，父組件的渲染會導致子組件跟着一起渲染，React.memo可以做淺層比較，防止出現不必要的重複渲染。子組件使用CustomWrapper標籤包裹，它可以將包裹的組件與頁面隔離，子組件渲染時不會更新整個頁面，由page.setData變爲component.setData。

3）圖片預加載

優化前：商詳banner圖片是進入頁面之後從服務端請求回來的，有一定的延遲。

優化後：在小程序中，從調用 Taro.navigateTo 等路由跳轉 API 到小程序頁面觸發 onLoad，中間會有一定延時(約300ms左右)，此時利用Taro.preload在跳轉前做一些預處理的邏輯，比如提前加載banner圖片等，無需等待接口返回數據，提升商詳頁的banner渲染速度。

4）數據請求時機優化

優化前： 商詳的數據請求邏輯在useDidShow中執行，每次進入商詳（無論是首次進入還是上一級頁面返回）都會調用接口，導致出現頻繁的loading效果，並且彈窗彈出的時候會閃一下。

優化後：商詳數據請求邏輯放在useEffect中，只有新進入商詳會執行，由上一級頁面返回商詳時無需調用接口，減少了頻繁的loading，大大提升了用戶進入商詳頁的體驗。



（2） 購物車頁面，優化前後渲染速度平均提升約20%，左側圖均爲優化後，右側圖均爲優化前。

iPhone14：







 



One9Plus：







 

紅米：









 



購物車現狀分析顯示，購物車查車接口一次性返回全量數據，導致頁面在商品數量超過30條時出現渲染慢和長時間白屏的問題，同時在操作購物車時也會出現卡頓等現象。爲了解決上述問題，購物車優化主要集中在以下兩點：

1）數據切割處理

優化前：全量數據直接傳遞給組件進行渲染，導致數據量大時渲染速度極慢。

優化後：原始數據切割成兩部分，首先渲染前四條數據（大概能佔滿首屏），剩餘數據利用setTimeout的特性進行異步處理，不會阻塞前四條數據的渲染，從而提升首屏的渲染速度。

2）調整父子組件之間數據傳遞的時機

優化前：父組件拿到原始數據之後直接傳入子組件，在子組件內按照需要的數據結構進行處理。





 

優化後：根據父組件優先子組件渲染的原則，將原始數據處理的部分移至父組件，將處理後的數據傳遞給子組件。自此，子組件在接收到數據後可以直接進行渲染，節省了原本用於子組件數據處理的時間，從而在一定程度上提升頁面的渲染速度。





 



（3）結算頁面，優化後渲染速度平均提升約25.4%。左側圖均爲優化後，右側圖均爲優化前。

iPhone14Pro：







 

One9Plus：







 

華爲Nova8：







 

分析結算現狀： 進入頁面時，由於接口之間存在依賴關係，需要請求多個接口，導致頁面渲染時間較長，並且在渲染完成後會出現頁面抖動現象。根據現狀，結算頁的優化主要包括以下三點：

1）優化網絡請求：

優化前：存在多個接口依賴，導致多次請求。

優化後：整合服務層接口，將多個接口合併爲一個主接口，減少網絡通信次數。

2）優化數據結構，減少setData使用頻率：

優化前：接口過於分散，相互依賴，導致頻繁的setData調用，降低性能。

優化後：接口整合後數據體量較大，採用遞歸方式將主體數據拆解，減少遍歷過程，減少setData的使用頻率，避免setData數據量變大，從而縮短頁面的渲染耗時。

3）組件更新優化：

優化前：子組件直接在父組件中引用，且未使用CustomWrapper。

優化後：合理使用CustomWrapper，通過將子組件使用CustomWrapper標籤包裹，實現子組件渲染時局部更新，由page.setData變爲component.setData，減少全局更新，提高性能。

三、未來展望

以上是我們近一年來對五星門店小程序性能體驗優化所做的一個階段性成果的總結，整體性能得到顯著提升。對於研發人員來說，提升用戶體驗是一項需要長期堅持的工作，作爲技術同學，我們需要具備工匠精神，在接下來的一年中，我們將繼續在小程序性能體驗優化方面努力，給用戶近乎原生應用的操做體驗，主要會從以下幾個方面入手：

（1）用戶體驗

▪ 持續跟進門店導購的反饋，結合現有的走查和迭代機制，不斷優化小程序體驗問題。

▪ 繼續執行日常體驗走查和日常優化迭代機制，主動發現並解決問題。

（2）性能提升

▪ 項目框架升級：第一波框架升級預計在2024年3月份完成，完成升級之後能夠進一步提升編譯速度，提升開發效率。

▪ 繼續縮小包體積：隨着後續需求的增加，包體積勢必會增大，爲滿足小程序限制的包體積大小，我們需要進一步縮小優化包體積。

（3）質量保障

▪ 維持低js報錯率：在日常開發中注重代碼的可讀性以及健壯性，注意臨界點的邏輯判斷等，關注監控平臺的信息反饋並及時響應，將js異常扼殺在搖籃裏。

▪ 打開率：持續提升小程序打開率，降低對用戶和業務的影響。