本文主要講述京東門(mén)詳業(yè)務(wù)在支撐過(guò)程中遇到的困境，面對(duì)問(wèn)題我們?cè)谛侍嵘?、質(zhì)量保障等方向的探索和實(shí)踐，在此將實(shí)踐過(guò)程中問(wèn)題解決的思路和方案與大家一起分享，也希望能給大家?guī)?lái)一些新的啟發(fā)

一、背景

1.1、京東門(mén)詳介紹

1.1.1、京東門(mén)詳業(yè)務(wù)

門(mén)店詳情頁(yè)簡(jiǎn)稱門(mén)詳，門(mén)詳業(yè)務(wù)包含門(mén)店詳情、列表、湊單、搜索、到店等頁(yè)面，最早于2020年在京東主站APP上線，最初是作為京東到家線下優(yōu)質(zhì)商家以線下店模式入駐京東主站，用戶可以在門(mén)詳內(nèi)一站式完成門(mén)店信息查看、商品瀏覽、配送時(shí)效確認(rèn)、領(lǐng)券、加車(chē)、下單等完整購(gòu)物流程。后續(xù)隨著業(yè)務(wù)的發(fā)展，門(mén)詳陸續(xù)承接了天選、小時(shí)購(gòu)、藥急送、前置倉(cāng)等更多的業(yè)務(wù)模式場(chǎng)景，逐漸形成了以即時(shí)零售為特性，覆蓋到家、到店場(chǎng)景，承接線上線下的通用綜合型業(yè)務(wù)系統(tǒng)

1.1.2、門(mén)詳業(yè)務(wù)形態(tài)

門(mén)詳業(yè)務(wù)涉及到家門(mén)詳（小時(shí)購(gòu)、藥急送）、到店門(mén)詳（POP、萬(wàn)家）；技術(shù)棧涉及京東小程序[2]、微信小程序[3]、H5、RN；頁(yè)面涉及門(mén)店首頁(yè)、湊單、搜索、評(píng)價(jià)、資質(zhì)、列表等20+

1.2、門(mén)詳業(yè)務(wù)支持過(guò)程中面臨的痛點(diǎn)

• 京東app和微信小程序兩端門(mén)詳功能差異較大
• 因歷史原因面臨同時(shí)維護(hù)京東app和京購(gòu)小程序兩套門(mén)詳業(yè)務(wù)需求
• 業(yè)務(wù)規(guī)劃需求量巨大，雙端需求迭代頻繁，研發(fā)資源緊張無(wú)法短時(shí)間消化
• 雙端業(yè)務(wù)場(chǎng)景及不同的技術(shù)棧對(duì)質(zhì)量保障帶來(lái)較大挑戰(zhàn)

1.3、京購(gòu)小程序業(yè)務(wù)方對(duì)門(mén)詳?shù)脑V求

• 期望將京購(gòu)小程序門(mén)詳功能對(duì)齊京東app
• 新需求迭代希望快速同步到微信域
• 期望研發(fā)需求吞吐量增加，可以快速消化更多的需求

二、技術(shù)方案

2.1、前期方案調(diào)研

前期技術(shù)方案調(diào)研方面，我們也了解了當(dāng)前流行的各種多端框架像RN、Flutter、Taro、uni-app等，并從多端支持度、開(kāi)發(fā)生態(tài)、前端框架支持情況、學(xué)習(xí)成本等各方面進(jìn)行了調(diào)研對(duì)比；由于要支持京東APP及微信小程序，所以優(yōu)先考慮支持小程序的多端框架像Taro3[1]、uni-app[10]、mpvue[11]、chameleon[12]、WePY[13]等；結(jié)合對(duì)前端框架兼容情況、京東小程序[2]的支持度及團(tuán)隊(duì)自身情況（團(tuán)隊(duì)對(duì)React比較熟悉）等因素，綜合考慮最終決定采用Taro框架來(lái)進(jìn)行多端化重構(gòu)。

2.2、技術(shù)方案制定及實(shí)踐

2.2.1、思考需要解決的問(wèn)題

• 如何更好的支持京東小程序、微信小程序、H5等多端需求？
• 如何在改造過(guò)程中避免新需求重復(fù)開(kāi)發(fā)？
• 如何縮短研發(fā)交付周期？
• 如何才能在開(kāi)發(fā)過(guò)程中提高效率？
• 如何在快速迭代過(guò)程中保障研發(fā)質(zhì)量？
• 如何靈活支持更多的業(yè)務(wù)場(chǎng)景？
• 如何保障頁(yè)面性能？

2.2.2、制定解決方案

2.2.2.1、門(mén)詳業(yè)務(wù)多端化解決方案

整個(gè)方案通過(guò)前端、服務(wù)端、平臺(tái)共同構(gòu)建一套完整的多端化、樓層化解決方案，服務(wù)端基于PaaS化架構(gòu)將門(mén)詳功能拆分為多個(gè)領(lǐng)域服務(wù)、領(lǐng)域模型及擴(kuò)展點(diǎn)，前端基于iPaas樓層、組件標(biāo)準(zhǔn)制定門(mén)詳多端化、樓層化方案，管理平臺(tái)通過(guò)奧德修斯（小程序交易數(shù)字化平臺(tái)）與黃流數(shù)字化平臺(tái)、iHub平臺(tái)能力打通，進(jìn)行業(yè)務(wù)、頁(yè)面、樓層、組件、數(shù)據(jù)等管理及上線發(fā)布，以下是整體解決方案全景圖

2.2.2.2、門(mén)詳前端技術(shù)框架

前端基于Taro3[1] + React[8] + Recoil[7]為技術(shù)底座，將門(mén)詳業(yè)務(wù)按照基礎(chǔ)功能和基礎(chǔ)組件原則拆分出網(wǎng)絡(luò)、地址、埋點(diǎn)、優(yōu)惠券、商卡、購(gòu)物車(chē)等等50+功能點(diǎn)，頁(yè)面標(biāo)準(zhǔn)在iPaas頁(yè)面協(xié)議上增加了門(mén)詳渲染引擎部分，通過(guò)iHub平臺(tái)管理樓層及代碼，最終由頁(yè)面容器進(jìn)行渲染，以下基于門(mén)詳面臨的痛點(diǎn)在門(mén)詳多端化過(guò)程中的架構(gòu)圖及我們?cè)趯?shí)施過(guò)程中的一些方案

2.2.3、技術(shù)方案實(shí)施過(guò)程

1）業(yè)務(wù)功能歸類(lèi)及樓層和組件拆分

門(mén)詳首頁(yè)按照結(jié)構(gòu)拆分成頁(yè)頭、列表、頁(yè)尾、彈層等部分，按照樓層拆分成頁(yè)面頭部、門(mén)店信息、會(huì)員樓層、優(yōu)惠促銷(xiāo)、商品列表、結(jié)算條、購(gòu)物車(chē)等12+樓層組件

2）多端適配過(guò)程中的差異處理

雖然多端化框架已經(jīng)幫我我們解決了跨平臺(tái)開(kāi)發(fā)場(chǎng)景，但不同平臺(tái)之間由于底層原理及基礎(chǔ)能力實(shí)現(xiàn)方式的差異，仍然存在一些需要按照特定平臺(tái)進(jìn)行適配處理的工作量，我們首先梳理門(mén)詳中使用到的小程序平臺(tái)40+底層能力，列舉并對(duì)比多端平臺(tái)上的功能差異，針對(duì)平臺(tái)差異制定中間適配層將API統(tǒng)一規(guī)范化（eg：登錄、地址、埋點(diǎn)、路由、系統(tǒng)信息等）

3）開(kāi)發(fā)過(guò)程中的提效方式

• 組件化：組件封裝分兩層，底層是最小單元的功能組件，上層是最小可復(fù)用業(yè)務(wù)組件原則封裝，有效的減少了相同和相似代碼的冗余，同時(shí)也會(huì)定期通過(guò)工具jscpd[4]進(jìn)行代碼審計(jì)進(jìn)一步找出相似代碼片段進(jìn)行優(yōu)化

• 樓層化：組合相關(guān)業(yè)務(wù)組件提升能力最大復(fù)用度，例如：門(mén)店信息樓層、優(yōu)惠促銷(xiāo)樓層等等，并且樓層組件按照頁(yè)面schema協(xié)議開(kāi)發(fā)，支持部分能力可定制化

• MVVM模式：利用react hook[6]方式將原有頁(yè)面中的邏輯及數(shù)據(jù)處理提練到View Mode層，使邏輯和UI之間清晰分離易于維護(hù)，還可以顯著提高代碼重用機(jī)會(huì)

4）改造過(guò)程中新需求處理

舊門(mén)詳采用的京東小程序原生語(yǔ)言開(kāi)發(fā)，新門(mén)詳采用Taro+React開(kāi)發(fā)，在新門(mén)詳未全量發(fā)布前新需求是需要雙端支持的，這樣也就意味著相同需求會(huì)開(kāi)發(fā)兩次，經(jīng)過(guò)探索我們通過(guò)混合開(kāi)發(fā)模式[9]將Taro組件打包成小程序可以直接引用的原生組件，解決了新舊工程重復(fù)開(kāi)發(fā)問(wèn)題

2.3、門(mén)詳小程序性能優(yōu)化

門(mén)詳在公測(cè)階段也暴露了一些性能問(wèn)題，我們按照?qǐng)鼍皠澐譃閮深?lèi)：體驗(yàn)性能、啟動(dòng)性能，下面在這里和大家一起分享下相關(guān)案例及解決思路，希望能給有相似困境的小伙伴一些新的思路

2.3.1、體驗(yàn)性能優(yōu)化

門(mén)詳首頁(yè)用戶操作比較頻繁的就是分類(lèi)切換、列表滑動(dòng)等功能，也是用戶反饋卡頓較為多的部分，下面針對(duì)以上兩類(lèi)問(wèn)題進(jìn)行相關(guān)案例分析：

2.3.1.1、商品列表渲染性能優(yōu)化

在門(mén)詳多端化改造后，我們通過(guò)問(wèn)卷調(diào)研方式收集用戶體驗(yàn)反饋，發(fā)現(xiàn)部分用戶反饋在滾動(dòng)商品列表時(shí)存在卡頓的現(xiàn)象。我們利用Taro的debug環(huán)境日志進(jìn)行分析，發(fā)現(xiàn)分頁(yè)加載時(shí)setData體積不斷增大，耗時(shí)不斷增長(zhǎng)

debug環(huán)境日志：

setData耗時(shí)走勢(shì)曲線：

經(jīng)排查后發(fā)現(xiàn)是列表分頁(yè)渲染時(shí)數(shù)據(jù)量較大導(dǎo)致丟幀。為了解決大范圍渲染及重復(fù)渲染問(wèn)題，將原有的商品列表二維數(shù)組數(shù)據(jù)結(jié)構(gòu)優(yōu)化為鏈表+遞歸方式進(jìn)行分層嵌套平鋪渲染，數(shù)據(jù)上減少多層級(jí)計(jì)算、視圖上將分頁(yè)加載渲染控制在單頁(yè)內(nèi)，以下為優(yōu)化后的列表效果：

列表效果：

setData耗時(shí)走勢(shì)曲線：

優(yōu)化前后分屏數(shù)據(jù)渲染耗時(shí)對(duì)比：

上圖左側(cè)為列表優(yōu)化前效果，可以看到分頁(yè)加載請(qǐng)求數(shù)據(jù)時(shí)的卡頓體感比較明顯，尤其是隨著數(shù)據(jù)量的增大，卡頓時(shí)間越來(lái)越長(zhǎng)。右側(cè)為優(yōu)化后效果，在加載十幾頁(yè)之后依然保持高效的渲染性能。經(jīng)過(guò)上述優(yōu)化后每屏數(shù)據(jù)渲染耗時(shí)均維持在200ms左右，在分頁(yè)數(shù)據(jù)加載較多的情況下渲染依然保持高效。

2.3.1.2、分類(lèi)切換時(shí)列表渲染邏輯優(yōu)化

在前置倉(cāng)的業(yè)務(wù)支撐過(guò)程中，發(fā)現(xiàn)在某些特殊場(chǎng)景下切換分類(lèi)時(shí)等待時(shí)間較長(zhǎng)，用戶體驗(yàn)較差。經(jīng)分析發(fā)現(xiàn)在分類(lèi)列表加載數(shù)據(jù)時(shí)前端處理邏輯是在商品不滿一屏?xí)r自動(dòng)加載下一頁(yè)數(shù)據(jù)，補(bǔ)全商品列表讓用戶可以看到更多的商品數(shù)據(jù)，而在接口進(jìn)行輪詢請(qǐng)求時(shí)導(dǎo)致用戶等待時(shí)間較長(zhǎng)

上圖左側(cè)為優(yōu)化前分類(lèi)切換時(shí)商品加載的邏輯，為了減少用戶等待時(shí)長(zhǎng)對(duì)分類(lèi)渲染邏輯進(jìn)行優(yōu)化（如圖右側(cè)），調(diào)整分類(lèi)點(diǎn)擊后的處理邏輯，只請(qǐng)求當(dāng)前分類(lèi)下數(shù)據(jù)，不再進(jìn)行跨一級(jí)分類(lèi)接口請(qǐng)求。分類(lèi)渲染耗時(shí)從n(接口請(qǐng)求次數(shù))*250(接口請(qǐng)求耗時(shí))+200ms(前端渲染耗時(shí))減少到250ms+200ms。

2.3.2、啟動(dòng)性能優(yōu)化

我們針對(duì)門(mén)詳小程序啟動(dòng)過(guò)程進(jìn)行分析，整理啟動(dòng)的每個(gè)環(huán)節(jié)及對(duì)應(yīng)的耗時(shí)數(shù)據(jù)，制定優(yōu)化方案，優(yōu)化主要方向如下：

• 京東小程序包壓縮（將jdapkg文件進(jìn)行zip壓縮，文件大小從8.6MB降低到3.4MB）
• 門(mén)詳小程序模版包復(fù)用（避免多個(gè)小程序冷啟動(dòng)下載多次）
• 門(mén)詳小程序模版包內(nèi)置進(jìn)APP（減少小程序包下載耗時(shí)）
• APP啟動(dòng)時(shí)進(jìn)行小程序模版包預(yù)加載（減少小程序冷啟動(dòng)耗時(shí)）
• 小程序引擎加載耗時(shí)優(yōu)化（前置預(yù)熱小程序引擎）
• 小程序引擎啟動(dòng)主線程卡頓優(yōu)化（邏輯層與渲染層并行處理）
• 小程序代碼構(gòu)建包.jdapkg優(yōu)化（引擎公共代碼抽離）
• 小程序信息接口由同步改為異步（線上平均耗時(shí)減少158ms）
• 小程序網(wǎng)絡(luò)庫(kù)超時(shí)時(shí)間及重試機(jī)制優(yōu)化
• 門(mén)詳主接口耗時(shí)優(yōu)化（非首屏必要數(shù)據(jù)異步化）
• 門(mén)詳業(yè)務(wù)代碼包瘦身(代碼優(yōu)化、分包等，包大小從3.4MB降低到648KB)

使用公共模版包，多個(gè)商家共用一個(gè)代碼包，減少重復(fù)下載

優(yōu)化前門(mén)詳小程序平均啟動(dòng)耗時(shí)2227.7ms，經(jīng)以上優(yōu)化措施實(shí)施后，整體啟動(dòng)耗時(shí)減少到954ms，啟動(dòng)速度提升57.6%，在門(mén)詳小程序啟動(dòng)優(yōu)化過(guò)程中我們也得到了京東小程序引擎團(tuán)隊(duì)的大力支持，也借此機(jī)會(huì)表示衷心的感謝！

2.4、ISV共建方案及質(zhì)量保障探索

2.4.1、為什么要進(jìn)行共建探索呢？

對(duì)于業(yè)務(wù)側(cè)大量的需求涌入，且有一部分并非門(mén)詳通用功能屬于特殊場(chǎng)景的個(gè)性化需求，而在研發(fā)資源緊缺的情況我們也在思考如何才能提升需求的吞吐量，為了更好的支撐業(yè)務(wù)，在與業(yè)務(wù)深度交流后發(fā)現(xiàn)部分業(yè)務(wù)側(cè)也有自己的研發(fā)團(tuán)隊(duì)，可以自主個(gè)性化需求開(kāi)發(fā)，雙方溝通后達(dá)成共識(shí)在保障系統(tǒng)穩(wěn)定性的同時(shí)，我們?cè)跇菍踊幕A(chǔ)上對(duì)系統(tǒng)進(jìn)行改進(jìn)支持黃流ISV平臺(tái)接入，將部分獨(dú)立樓層開(kāi)放給業(yè)務(wù)側(cè)自主接入，具體共建流程如下：

經(jīng)過(guò)系統(tǒng)ISV方案改造探索后門(mén)詳?shù)膫€(gè)性化需求等待時(shí)長(zhǎng)明顯縮短，對(duì)比前兩個(gè)季度個(gè)性化需求整體承接量增長(zhǎng)30%以上，在需求大量增長(zhǎng)的同時(shí)也是對(duì)系統(tǒng)和新架構(gòu)的考驗(yàn)，為保證系統(tǒng)穩(wěn)定性我們對(duì)共建需求的接入、開(kāi)發(fā)、上線等進(jìn)行了共建流程規(guī)范制定及相關(guān)性能、質(zhì)量等約束

2.4.2、如何保障研發(fā)質(zhì)量？

多團(tuán)隊(duì)多人協(xié)作過(guò)程中我們也發(fā)現(xiàn)了一些問(wèn)題，為了避免一些常規(guī)問(wèn)題在此我們制定了相關(guān)的開(kāi)發(fā)規(guī)范，并在整個(gè)需求開(kāi)發(fā)上線過(guò)程中增加一些必要的校驗(yàn)環(huán)節(jié)，具體細(xì)節(jié)如下：

• 統(tǒng)一標(biāo)準(zhǔn)規(guī)范制定（目錄結(jié)構(gòu)規(guī)范、git 分支規(guī)范、代碼編寫(xiě)規(guī)范、開(kāi)發(fā)規(guī)范、文件規(guī)范、上線規(guī)范等）
• 需求評(píng)審后開(kāi)發(fā)前進(jìn)行前后端技術(shù)方案評(píng)審
• 利用工具（ESLint）進(jìn)行代碼規(guī)范掃描及語(yǔ)法規(guī)范檢查
• 上線前進(jìn)行code review及影響范圍預(yù)估
• 上線中checklist（重要流程、核心功能、特殊場(chǎng)景）檢查
• 上線后灰度切量且觀察監(jiān)控、異常、客訴等系統(tǒng)
• 兜底方案支持線上頁(yè)面、功能等一鍵降級(jí)

三、技術(shù)沉淀與業(yè)務(wù)賦能

3.1、技術(shù)改造過(guò)程中的能力沉淀

• 多端化樓層化開(kāi)發(fā)框架，支持ISV方式接入共建
• 規(guī)范頁(yè)面可編排樓層化協(xié)議，支持部分能力可動(dòng)態(tài)配置
• 標(biāo)準(zhǔn)化樓層組件開(kāi)發(fā)模版，減少組件開(kāi)發(fā)配置過(guò)程
• 基礎(chǔ)功能庫(kù)沉淀基礎(chǔ)API 16個(gè)、基礎(chǔ)組件25個(gè)、業(yè)務(wù)組件50+、打包插件3個(gè)
• 自研多端調(diào)試工具（nuclear）、發(fā)表公眾號(hào)文章2篇、已進(jìn)入國(guó)家專(zhuān)利局審核階段專(zhuān)利2篇
• 構(gòu)建工具cola-cli、cola-server
• 小程序標(biāo)準(zhǔn)化門(mén)詳賦能SDK

3.2、多端化帶來(lái)的收益

• 基礎(chǔ)能力賦能新業(yè)務(wù)（前置倉(cāng)門(mén)詳、到店商詳、POP門(mén)詳?shù)龋╅_(kāi)發(fā)效率提升40%以上
• 京東app上的門(mén)詳新需求95%+的功能是可以直接復(fù)用到微信小程序、H5端，在有限的研發(fā)資源下大幅提升了多端需求吞吐量
• 經(jīng)過(guò)4個(gè)月的多端化改造后補(bǔ)齊了京購(gòu)小程序中門(mén)詳業(yè)務(wù)滯后2年多的需求
• 小程序賦能20+（eg：京購(gòu)小程序、京東超市小程序、小時(shí)購(gòu)等）

門(mén)詳多端化樓層化過(guò)程中沉淀的開(kāi)發(fā)框架、基礎(chǔ)功能庫(kù)、通用開(kāi)發(fā)模版，也在到店門(mén)詳、到店商詳、pop門(mén)詳?shù)葮I(yè)務(wù)中得到了較好的實(shí)踐

3.3、前置倉(cāng)門(mén)詳快速支撐

在京東app前置倉(cāng)二期建設(shè)過(guò)程中小程序門(mén)詳組件及功能復(fù)用率達(dá)到95%+，基于多端化框架能力在2天內(nèi)完成將前置倉(cāng)門(mén)詳賦能到京購(gòu)小程序，業(yè)務(wù)側(cè)提出期望將前置倉(cāng)門(mén)詳能力可以引入到京東超市小程序（微信），基于前期門(mén)詳多端化能力建設(shè)僅用2小時(shí)就完成了置倉(cāng)門(mén)詳能力賦能京東超市小程序（微信），也是在這個(gè)過(guò)程中我們將門(mén)詳多端化和樓層化能力與奧德修斯平臺(tái)鑒權(quán)、模型管理、數(shù)據(jù)管理、可視化、配置化等能力相結(jié)合，通過(guò)腳手架與平臺(tái)結(jié)合方式為業(yè)務(wù)方提供一鍵構(gòu)建一站式賦能服務(wù)，通過(guò)這種標(biāo)準(zhǔn)化的方式既支持了京東超市小程序需求同時(shí)也擴(kuò)充了黃流SDK中的標(biāo)準(zhǔn)化門(mén)詳能力，一鍵觸發(fā)5分鐘既可完成整個(gè)黃流SDK賦能包的構(gòu)建

四、未來(lái)展望

隨著門(mén)詳業(yè)務(wù)涉及的場(chǎng)景日益增多，通用的樓層組件逐漸也無(wú)法滿足所有差異化場(chǎng)景，然而全部樓層都放入公共模版包中無(wú)疑是對(duì)小程序包大小的考驗(yàn)，基于一碼多端框架和我們自研的小程序發(fā)布系統(tǒng)思考，可以將門(mén)詳批量小程序進(jìn)行分類(lèi)管理，構(gòu)建時(shí)按類(lèi)型按需構(gòu)建，將一個(gè)公共模版包拆分成多個(gè)模版，可按照差異化方式分別構(gòu)建發(fā)布

在京東前端技術(shù)域iPaas2.0搭建平臺(tái)建設(shè)逐漸完善同時(shí)，門(mén)詳業(yè)務(wù)得益于多端化、樓層化框架，也為門(mén)詳小程序支持多端可視化搭建邁出了前進(jìn)的一步，為更多業(yè)務(wù)場(chǎng)景提供標(biāo)準(zhǔn)化門(mén)詳

參考資料

[1]Taro3：https://taro-docs.jd.com/docs/

[2]京東小程序：https://mp-docs.jd.com/doc/dev/framework/-1

[3]微信小程序：https://developers.weixin.qq.com/miniprogram/dev/framework/

[4]jscpd：https://github.com/kucherenko/jscpd

[5]狀態(tài)管理庫(kù)對(duì)比：https://cloud.tencent.com/developer/article/1685891

[6]React hook：https://react.docschina.org/learn#using-hooks

[7]Recoil：https://www.recoiljs.cn/docs/introduction/getting-started

[8]React：https://react.docschina.org/learn

[9]原生項(xiàng)目使用Taro：https://taro-docs.jd.com/docs/taro-in-miniapp

[10]uni-app：https://github.com/dcloudio/uni-app

[11]mpvue：https://github.com/Meituan-Dianping/mpvue

[12]chameleon：https://github.com/didi/chameleon

[13]WePY：https://github.com/Tencent/wepy

作者：京東零售 徐宏偉

來(lái)源：京東云開(kāi)發(fā)者社區(qū)文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-652632.html

到了這里，關(guān)于京東門(mén)詳一碼多端探索與實(shí)踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！