本文主要講述京東門詳業務在支撐過程中遇到的困境，面對問題我們在效率提升、質量保障等方向的探索和實踐，在此將實踐過程中問題解決的思路和方案與大家一起分享，也希望能給大家帶來一些新的啟發 ...

本文主要講述京東門詳業務在支撐過程中遇到的困境，面對問題我們在效率提升、質量保障等方向的探索和實踐，在此將實踐過程中問題解決的思路和方案與大家一起分享，也希望能給大家帶來一些新的啟發

一、背景

1.1、京東門詳介紹

1.1.1、京東門詳業務

門店詳情頁簡稱門詳，門詳業務包含門店詳情、列表、湊單、搜索、到店等頁面，最早於2020年在京東主站APP上線，最初是作為京東到家線下優質商家以線下店模式入駐京東主站，用戶可以在門詳內一站式完成門店信息查看、商品瀏覽、配送時效確認、領券、加車、下單等完整購物流程。後續隨著業務的發展，門詳陸續承接了天選、小時購、藥急送、前置倉等更多的業務模式場景，逐漸形成了以即時零售為特性，覆蓋到家、到店場景，承接線上線下的通用綜合型業務系統

1.1.2、門詳業務形態

門詳業務涉及到家門詳（小時購、藥急送）、到店門詳（POP、萬家）；技術棧涉及京東小程式[2]、微信小程式[3]、H5、RN；頁面涉及門店首頁、湊單、搜索、評價、資質、列表等20+

1.2、門詳業務支持過程中面臨的痛點

京東app和微信小程式兩端門詳功能差異較大
因歷史原因面臨同時維護京東app和京購小程式兩套門詳業務需求
業務規劃需求量巨大，雙端需求迭代頻繁，研發資源緊張無法短時間消化
雙端業務場景及不同的技術棧對質量保障帶來較大挑戰

1.3、京購小程式業務方對門詳的訴求

期望將京購小程式門詳功能對齊京東app
新需求迭代希望快速同步到微信域
期望研發需求吞吐量增加，可以快速消化更多的需求

二、技術方案

2.1、前期方案調研

前期技術方案調研方面，我們也瞭解了當前流行的各種多端框架像RN、Flutter、Taro、uni-app等，並從多端支持度、開發生態、前端框架支持情況、學習成本等各方面進行了調研對比；由於要支持京東APP及微信小程式，所以優先考慮支持小程式的多端框架像Taro3[1]、uni-app[10]、mpvue[11]、chameleon[12]、WePY[13]等；結合對前端框架相容情況、京東小程式[2]的支持度及團隊自身情況（團隊對React比較熟悉）等因素，綜合考慮最終決定採用Taro框架來進行多端化重構。

2.2、技術方案制定及實踐

2.2.1、思考需要解決的問題

如何更好的支持京東小程式、微信小程式、H5等多端需求？
如何在改造過程中避免新需求重覆開發？
如何縮短研發交付周期？
如何才能在開發過程中提高效率？
如何在快速迭代過程中保障研發質量？
如何靈活支持更多的業務場景？
如何保障頁面性能？

2.2.2、制定解決方案

2.2.2.1、門詳業務多端化解決方案

整個方案通過前端、服務端、平臺共同構建一套完整的多端化、樓層化解決方案，服務端基於PaaS化架構將門詳功能拆分為多個領域服務、領域模型及擴展點，前端基於iPaas樓層、組件標準制定門詳多端化、樓層化方案，管理平臺通過奧德修斯（小程式交易數字化平臺）與黃流數字化平臺、iHub平臺能力打通，進行業務、頁面、樓層、組件、數據等管理及上線發佈，以下是整體解決方案全景圖

2.2.2.2、門詳前端技術框架

前端基於Taro3[1] + React[8] + Recoil[7]為技術底座，將門詳業務按照基礎功能和基礎組件原則拆分出網路、地址、埋點、優惠券、商卡、購物車等等50+功能點，頁面標準在iPaas頁面協議上增加了門詳渲染引擎部分，通過iHub平臺管理樓層及代碼，最終由頁面容器進行渲染，以下基於門詳面臨的痛點在門詳多端化過程中的架構圖及我們在實施過程中的一些方案

2.2.3、技術方案實施過程

1）業務功能歸類及樓層和組件拆分

門詳首頁按照結構拆分成頁頭、列表、頁尾、彈層等部分，按照樓層拆分成頁面頭部、門店信息、會員樓層、優惠促銷、商品列表、結算條、購物車等12+樓層組件

2）多端適配過程中的差異處理

雖然多端化框架已經幫我我們解決了跨平臺開發場景，但不同平臺之間由於底層原理及基礎能力實現方式的差異，仍然存在一些需要按照特定平臺進行適配處理的工作量，我們首先梳理門詳中使用到的小程式平臺40+底層能力，列舉並對比多端平臺上的功能差異，針對平臺差異制定中間適配層將API統一規範化（eg：登錄、地址、埋點、路由、系統信息等）

3）開發過程中的提效方式

組件化：組件封裝分兩層，底層是最小單元的功能組件，上層是最小可復用業務組件原則封裝，有效的減少了相同和相似代碼的冗餘，同時也會定期通過工具jscpd[4]進行代碼審計進一步找出相似代碼片段進行優化

樓層化：組合相關業務組件提升能力最大復用度，例如：門店信息樓層、優惠促銷樓層等等，並且樓層組件按照頁面schema協議開發，支持部分能力可定製化
MVVM模式：利用react hook[6]方式將原有頁面中的邏輯及數據處理提練到View Mode層，使邏輯和UI之間清晰分離易於維護，還可以顯著提高代碼重用機會

4）改造過程中新需求處理

舊門詳採用的京東小程式原生語言開發，新門詳採用Taro+React開發，在新門詳未全量發佈前新需求是需要雙端支持的，這樣也就意味著相同需求會開發兩次，經過探索我們通過混合開發模式[9]將Taro組件打包成小程式可以直接引用的原生組件，解決了新舊工程重覆開發問題

2.3、門詳小程式性能優化

門詳在公測階段也暴露了一些性能問題，我們按照場景劃分為兩類：體驗性能、啟動性能，下麵在這裡和大家一起分享下相關案例及解決思路，希望能給有相似困境的小伙伴一些新的思路

2.3.1、體驗性能優化

門詳首頁用戶操作比較頻繁的就是分類切換、列表滑動等功能，也是用戶反饋卡頓較為多的部分，下麵針對以上兩類問題進行相關案例分析：

2.3.1.1、商品列表渲染性能優化

在門詳多端化改造後，我們通過問卷調研方式收集用戶體驗反饋，發現部分用戶反饋在滾動商品列表時存在卡頓的現象。我們利用Taro的debug環境日誌進行分析，發現分頁載入時setData體積不斷增大，耗時不斷增長

debug環境日誌：

setData耗時走勢曲線：

經排查後發現是列表分頁渲染時數據量較大導致丟幀。為瞭解決大範圍渲染及重覆渲染問題，將原有的商品列表二維數組數據結構優化為鏈表+遞歸方式進行分層嵌套平鋪渲染，數據上減少多層級計算、視圖上將分頁載入渲染控制在單頁內，以下為優化後的列表效果：

列表效果：

setData耗時走勢曲線：

優化前後分屏數據渲染耗時對比：

上圖左側為列表優化前效果，可以看到分頁載入請求數據時的卡頓體感比較明顯，尤其是隨著數據量的增大，卡頓時間越來越長。右側為優化後效果，在載入十幾頁之後依然保持高效的渲染性能。經過上述優化後每屏數據渲染耗時均維持在200ms左右，在分頁數據載入較多的情況下渲染依然保持高效。

2.3.1.2、分類切換時列表渲染邏輯優化

在前置倉的業務支撐過程中，發現在某些特殊場景下切換分類時等待時間較長，用戶體驗較差。經分析發現在分類列表載入數據時前端處理邏輯是在商品不滿一屏時自動載入下一頁數據，補全商品列表讓用戶可以看到更多的商品數據，而在介面進行輪詢請求時導致用戶等待時間較長

上圖左側為優化前分類切換時商品載入的邏輯，為了減少用戶等待時長對分類渲染邏輯進行優化（如圖右側），調整分類點擊後的處理邏輯，只請求當前分類下數據，不再進行跨一級分類介面請求。分類渲染耗時從n(介面請求次數)*250(介面請求耗時)+200ms(前端渲染耗時)減少到250ms+200ms。

2.3.2、啟動性能優化

我們針對門詳小程式啟動過程進行分析，整理啟動的每個環節及對應的耗時數據，制定優化方案，優化主要方向如下：

京東小程式包壓縮（將jdapkg文件進行zip壓縮，文件大小從8.6MB降低到3.4MB）
門詳小程式模版包復用（避免多個小程式冷啟動下載多次）
門詳小程式模版包內置進APP（減少小程式包下載耗時）
APP啟動時進行小程式模版包預載入（減少小程式冷啟動耗時）
小程式引擎載入耗時優化（前置預熱小程式引擎）
小程式引擎啟動主線程卡頓優化（邏輯層與渲染層並行處理）
小程式代碼構建包.jdapkg優化（引擎公共代碼抽離）
小程式信息介面由同步改為非同步（線上平均耗時減少158ms）
小程式網路庫超時時間及重試機制優化
門詳主介面耗時優化（非首屏必要數據非同步化）
門詳業務代碼包瘦身(代碼優化、分包等，包大小從3.4MB降低到648KB)

使用公共模版包，多個商家共用一個代碼包，減少重覆下載

優化前門詳小程式平均啟動耗時2227.7ms，經以上優化措施實施後，整體啟動耗時減少到954ms，啟動速度提升57.6%，在門詳小程式啟動優化過程中我們也得到了京東小程式引擎團隊的大力支持，也藉此機會表示衷心的感謝！

2.4、ISV共建方案及質量保障探索

2.4.1、為什麼要進行共建探索呢？

對於業務側大量的需求涌入，且有一部分並非門詳通用功能屬於特殊場景的個性化需求，而在研發資源緊缺的情況我們也在思考如何才能提升需求的吞吐量，為了更好的支撐業務，在與業務深度交流後發現部分業務側也有自己的研發團隊，可以自主個性化需求開發，雙方溝通後達成共識在保障系統穩定性的同時，我們在樓層化的基礎上對系統進行改進支持黃流ISV平臺接入，將部分獨立樓層開放給業務側自主接入，具體共建流程如下：

經過系統ISV方案改造探索後門詳的個性化需求等待時長明顯縮短，對比前兩個季度個性化需求整體承接量增長30%以上，在需求大量增長的同時也是對系統和新架構的考驗，為保證系統穩定性我們對共建需求的接入、開發、上線等進行了共建流程規範制定及相關性能、質量等約束

2.4.2、如何保障研發質量？

多團隊多人協作過程中我們也發現了一些問題，為了避免一些常規問題在此我們制定了相關的開發規範，併在整個需求開發上線過程中增加一些必要的校驗環節，具體細節如下：

統一標準規範制定（目錄結構規範、git 分支規範、代碼編寫規範、開發規範、文件規範、上線規範等）
需求評審後開發前進行前後端技術方案評審
利用工具（ESLint）進行代碼規範掃描及語法規範檢查
上線前進行code review及影響範圍預估
上線中checklist（重要流程、核心功能、特殊場景）檢查
上線後灰度切量且觀察監控、異常、客訴等系統
兜底方案支持線上頁面、功能等一鍵降級

三、技術沉澱與業務賦能

3.1、技術改造過程中的能力沉澱

多端化樓層化開發框架，支持ISV方式接入共建
規範頁面可編排樓層化協議，支持部分能力可動態配置
標準化樓層組件開發模版，減少組件開發配置過程
基礎功能庫沉澱基礎API 16個、基礎組件25個、業務組件50+、打包插件3個
自研多端調試工具（nuclear）、發表公眾號文章2篇、已進入國家專利局審核階段專利2篇
構建工具cola-cli、cola-server
小程式標準化門詳賦能SDK

3.2、多端化帶來的收益

基礎能力賦能新業務（前置倉門詳、到店商詳、POP門詳等）開發效率提升40%以上
京東app上的門詳新需求95%+的功能是可以直接復用到微信小程式、H5端，在有限的研發資源下大幅提升了多端需求吞吐量
經過4個月的多端化改造後補齊了京購小程式中門詳業務滯後2年多的需求
小程式賦能20+（eg：京購小程式、京東超市小程式、小時購等）

門詳多端化樓層化過程中沉澱的開發框架、基礎功能庫、通用開發模版，也在到店門詳、到店商詳、pop門詳等業務中得到了較好的實踐

3.3、前置倉門詳快速支撐

在京東app前置倉二期建設過程中小程式門詳組件及功能復用率達到95%+，基於多端化框架能力在2天內完成將前置倉門詳賦能到京購小程式，業務側提出期望將前置倉門詳能力可以引入到京東超市小程式（微信），基於前期門詳多端化能力建設僅用2小時就完成了置倉門詳能力賦能京東超市小程式（微信），也是在這個過程中我們將門詳多端化和樓層化能力與奧德修斯平臺鑒權、模型管理、數據管理、可視化、配置化等能力相結合，通過腳手架與平臺結合方式為業務方提供一鍵構建一站式賦能服務，通過這種標準化的方式既支持了京東超市小程式需求同時也擴充了黃流SDK中的標準化門詳能力，一鍵觸發5分鐘既可完成整個黃流SDK賦能包的構建