簡述

店鋪瀏覽閉環(huán)之后，因各端數(shù)據(jù)與渲染割裂導(dǎo)致代碼無法復(fù)用，從而引起研發(fā)成本增加；同時多年以來技術(shù)棧未升級且不統(tǒng)一導(dǎo)致嚴(yán)重落后于競品店鋪，對于ISV開放化的支持程度也停滯不前。針對這一系列的問題，店鋪研發(fā)團隊發(fā)起了多端融合降本提效項目，下定決心將多端渲染全部升級重寫，從底層能力上解決了以上所有問題，使店鋪瀏覽從原有的重復(fù)開發(fā)1.0時代，步入了全新的一套代碼多端復(fù)用2.0新時代。

背景

店鋪團隊為京東幾十萬商家提供頁面快速搭建以及在不同APP、M站、京購小程序上展示的能力，同時也引入了ISV服務(wù)商為商家提供定制樓層開發(fā)，助力商家提高商品銷售轉(zhuǎn)化率，其次ISV模板銷售每年也能為京東帶來上百萬的附加收入。

多年以來，商家店鋪裝修端以及各瀏覽端一直是由不同的團隊維護(hù)，在2021年上半年，由于業(yè)務(wù)調(diào)整全部閉環(huán)到智鋪團隊。閉環(huán)初期，我們對各端業(yè)務(wù)現(xiàn)狀進(jìn)行了梳理，發(fā)現(xiàn)了幾個比較大的問題。一是各瀏覽端展示效果不一致，APP端、M站及京購店鋪在頁面功能上有不一致的情況。二是是各個系統(tǒng)技術(shù)棧不統(tǒng)一，在服務(wù)端還有C語言開發(fā)的應(yīng)用，在前端方面，技術(shù)棧也是多種多樣，造成這些系統(tǒng)的維護(hù)成本也很高。如果一個需求要在所有端上展示，那么就需要在每個端上去開發(fā)，壓力非常大，同時測試及上線成本也很高。三是業(yè)務(wù)閉環(huán)之后，人力資源沒有增加，相當(dāng)于原有的資源在只開發(fā)裝修端業(yè)務(wù)的情況下，現(xiàn)在需要再承接3個瀏覽端的業(yè)務(wù)需求。

同時在渲染技術(shù)方面，競品店鋪已經(jīng)全面改用自研小程序渲染，無論是需求開發(fā)效率，還是ISV模板開發(fā)效率，都較京東店鋪RN開發(fā)技術(shù)高很多。同時隨著競品APP各業(yè)務(wù)小程序基建能力的全面鋪開，其他業(yè)務(wù)也能很容易的展示到競品店鋪中。而京東店鋪APP端因為是RN技術(shù)渲染，樓層之間無法插入外部樓層。

因此，從業(yè)務(wù)現(xiàn)狀方面考慮，店鋪的多端融合勢在必行，需要實現(xiàn)一套代碼在各終端都能展示。其次，在店鋪渲染技術(shù)方面，也需要放棄RN，和競品店鋪的技術(shù)對齊。只有這樣才能提升團隊的開發(fā)效率，以及ISV服務(wù)商的開發(fā)效率，同時擴展店鋪接入其他業(yè)務(wù)的基建能力。

現(xiàn)有各端渲染流程

為解決商家更換模板之后，可以實時在APP端生效的問題。智鋪裝修系統(tǒng)當(dāng)前采用的是“XML模板轉(zhuǎn)JSON動態(tài)下發(fā)方案”，每一套模板的結(jié)構(gòu)和樣式，都是通過XML進(jìn)行定義。商家在裝修店鋪之后，服務(wù)端會把裝修的數(shù)據(jù)和XML定義的樣式，解析成JSON格式下發(fā)給各展示端。這樣做最大的優(yōu)勢是APP端不用去集成跟版，線上可以隨時更換不同的模板樣式。但是這樣也產(chǎn)生了一個很大的問題，因為M站和小程序是可以支持Js模板渲染的，但現(xiàn)在也只能去解析這套JSON數(shù)據(jù)才能拿到模板進(jìn)行渲染。

同時由于之前瀏覽端維護(hù)團隊不一致，各個團隊的服務(wù)端拿到這份JSON數(shù)據(jù)后，又進(jìn)行了二次封裝，這樣的直接結(jié)果，就是接口數(shù)據(jù)格式完全不統(tǒng)一。其次每個團隊的前端，也分別開發(fā)了解析庫去解析這套JSON數(shù)據(jù)，所以這些解析庫也完全不能復(fù)用。

其次，因為應(yīng)用獨立、支持的端也多，因此部署的上線工程也很多。

方案需要解決的問題

針對以上背景以及當(dāng)前各端渲染現(xiàn)狀，店鋪多端融合需要考慮四方面的問題：一是服務(wù)端數(shù)據(jù)必須統(tǒng)一，輸出一套標(biāo)準(zhǔn)的數(shù)據(jù)格式定義。其次，前端需要對多端渲染進(jìn)行統(tǒng)一，實現(xiàn)開發(fā)一套代碼，就可以在不同的端都能使用。再次，當(dāng)前端渲染融合之后，各端店鋪的首頁性能不能降低，不能影響用戶體驗。最后，店鋪多端融合還需要解決ISV開發(fā)樓層模板的效率問題。

由于內(nèi)容較多，下面重點看一下“前端渲染融合方案”，以及各端“首屏性能保障方案”。

前端渲染融合方案

01方案設(shè)計

由于店鋪當(dāng)前使用的是“XML模板轉(zhuǎn)JSON動態(tài)下發(fā)方案”，存在多套解析庫去解析這套數(shù)據(jù)，造成重復(fù)工作量問題。

因此第一套融合方案，就是“APP端解析庫和小程序解析庫并存方案”。在左圖中，針對服務(wù)端下發(fā)的統(tǒng)一數(shù)據(jù)，前端開發(fā)一個統(tǒng)一的解析庫，這個解析庫里面包含2套邏輯，一是通過RN解析庫實現(xiàn)京東APP之間的復(fù)用，再通過JDReact轉(zhuǎn)換成H5統(tǒng)一M站店鋪和裝修端預(yù)覽。另一套邏輯是通過小程序解析來庫實現(xiàn)京購小程序店鋪、以及京東小程序業(yè)務(wù)的統(tǒng)一。

這套方案，對現(xiàn)有APP端業(yè)務(wù)改動量相對較小，屬于半融合方案，因為仍然要維護(hù)兩套解析邏輯，因此只能減少30%—40%的工作量。同時上面分析的幾個問題也并沒有解決，一是H5和小程序也需要解析庫去解析才能拿到模板樣式，效率較低；二是ISV也仍然只能開發(fā)RN模板，效率并沒有得到提升；三是仍然落后于競品店鋪的技術(shù)統(tǒng)一和擴展性。

第二套方案，就是“多端統(tǒng)一去RN方案”，這套方案徹底升級了整個店鋪各端的瀏覽渲染技術(shù)，在上面右圖中，通過京東開源的Taro技術(shù)解決方案，首先開發(fā)一個靜態(tài)資源多端融合工程。在APP端，打出一個H5離線包通過京東平臺業(yè)務(wù)部的JDHybrid解決方案，將離線包預(yù)下載到用戶APP中，當(dāng)用戶打開店鋪時，將離線包資源注入到到店鋪原生頁面webview容器中，減少了頁面和靜態(tài)資源請求，訪問性能得到了極大提升。在M和PC端，通過Taro轉(zhuǎn)換出H5頁面去支持店鋪M站以及PC端的預(yù)覽頁面。在小程序端，直接打出小程序包去支持京購小程序店鋪和京東小程序等業(yè)務(wù)場景。

這套方案完全解決了以上的所有問題，團隊在面臨多端業(yè)務(wù)需求時可減少60-70%的工作量。同時h5和小程序因為直接可以拿到模板樣式，渲染性能也得到了提升；ISV不再開發(fā)低效的RN模板，并且通過多端融合方案，也能實現(xiàn)一套模板在各端上展示；在整體技術(shù)和擴展性方面，也和競品店鋪實現(xiàn)了對齊。

當(dāng)前，APP店鋪頁面已經(jīng)實現(xiàn)原生樓層和webview樓層共同展示。我們也正在開發(fā)將京東小程序也內(nèi)嵌到店鋪首頁中展示，同時增加webview復(fù)用去保障性能，待上線后，店鋪首頁將擁有同時渲染原生+H5+小程序的基建能力，其他業(yè)務(wù)只要遵循這套技術(shù)體系，也能快速的將H5樓層、小程序樓層在店鋪中渲染出來。

02整體方案概覽

整個“多端統(tǒng)一去RN方案” 包含：H5與APP融合、 H5與小程序融合、Nodejs服務(wù)、 ISV跨端開放化這四大主體方案；以及異常、災(zāi)備、性能、監(jiān)控四大擴展方案；

由于方案較多，這里就不細(xì)加描述，如果有對這套方案感興趣的同學(xué)，可以和我們智鋪團隊聯(lián)系交流。

首屏性能保障方案

在各端首屏性能方面，當(dāng)前IOS端和Android端，店鋪原生樓層混合RN樓層的首屏渲染耗時在0.7-1秒左右浮動；M站店鋪耗時在4s左右；京購小程序店鋪在2.5秒左右。因此三端的現(xiàn)有渲染時間就是此次多端融合的參考基準(zhǔn)。

01核心保障措施

在IOS端，采用了Hybrid離線包來減少頁面以及靜態(tài)資源的請求時間，并將webview容器初始化放到剛進(jìn)入店鋪的時候就開始，其次將比較耗時圖片放到最后做懶加載請求。通過這些措施，在首屏渲染5個樓層的前提下，用戶能感知的首屏耗時大致在800毫秒左右，整體時間就和線上原生+RN渲染的性能保持一致。這里有2個點可以繼續(xù)優(yōu)化，比如可以將數(shù)據(jù)接口請求放到點擊店鋪的入口時就開始。其次，當(dāng)前服務(wù)端數(shù)據(jù)接口耗時返回的是首頁所有數(shù)據(jù)，如果改成只返回首屏數(shù)據(jù)，或者增加緩存措施，這樣也可以有效降低數(shù)據(jù)請求的耗時，最終也會體現(xiàn)為首屏耗時降低。

在Android端，服務(wù)端數(shù)據(jù)接口請求前置到用戶點擊店鋪入口時就開始，當(dāng)用戶進(jìn)入到店鋪里面時，數(shù)據(jù)請求耗時已經(jīng)減少了接近一半。同時配合Hybrid離線包方案，也將Android端的首屏耗時保持和線上一致。這里也有幾個可以繼續(xù)優(yōu)化的點，比如接口耗時優(yōu)化，以及將webview初始化和靜態(tài)資源注入提前到進(jìn)入店鋪的時候。這樣也能有效的再提升店鋪的訪問性能。

02綜合保障措施

除了上面用到的優(yōu)化措施外，針對不同端也用到了一些優(yōu)化措施，在APP端還采用了靜態(tài)資源文件合并措施，減少當(dāng)離線包加載失敗之后，加載線上H5頁面的性能。以及骨架屏、樓層和圖片懶加載等措施。

在小程序端和M站上，也采用了骨架屏、懶加載，以及H5端的瀏覽器離線緩存等方案來提升頁面性能。

融合收益

01首屏性能提升

經(jīng)過多端融合之后，在IOS端和Android端新首頁的首屏性能，和線上原生+RN的渲染性能基本上持平。M站及京購小程序當(dāng)前還未完全上線，預(yù)估也將有較大的提升。

02ISV開放化能力提升

當(dāng)前店鋪對ISV開放的僅有APP端的RN定制模板，RN受限于技術(shù)本身無法很好的支持三端；同時由于開發(fā)環(huán)境復(fù)雜，調(diào)試?yán)щy等原因極大影響ISV開發(fā)效率。和競品店鋪ISV開發(fā)相比，同一套類似效果的模板平均開發(fā)時間多出1-2倍。而基于多端融合使用的技術(shù)棧Taro規(guī)范來開發(fā)，加上店鋪現(xiàn)在已經(jīng)實現(xiàn)了多端渲染統(tǒng)一基座，ISV僅開發(fā)一套代碼，稍加調(diào)整即可支持三端，同時效率也將有較大的提升。

03人效及其他提升

在人效方面，涉及到多端渲染需求，投入的人力較以前下降56%，工時下降66%。在服務(wù)端也統(tǒng)一了數(shù)據(jù)接口，人力成本下降30%-50%。

同時在技術(shù)專利和文章沉淀方面，也通過了3篇技術(shù)專利，有兩篇也處于編寫階段。其次有4篇技術(shù)文章也在陸續(xù)編寫中。

技術(shù)展望

前端技術(shù)經(jīng)過十幾年的發(fā)展，技術(shù)棧、技術(shù)框架迭代都比較快，而業(yè)務(wù)需要支持的展示端也越來越多，如果每一端都需要去重復(fù)開發(fā)，那么這個人力消耗必然是不能承受的。因此需要均衡各方面的因素，找到一種前端技術(shù)的最佳組合實踐，而這個原則必然是一套代碼，多端適配復(fù)用。

而受限于互聯(lián)網(wǎng)技術(shù)的發(fā)展，各廠商自身利益的取舍，在前端渲染方面，還無法統(tǒng)一成一套標(biāo)準(zhǔn)的技術(shù)棧天生就能在各廠商提供的軟件上面運行。因此才出現(xiàn)了各種奇門遁甲的兼容技術(shù)，無論是開發(fā)規(guī)范兼容、還是底層引擎兼容，還是配置化下發(fā)兼容等等，都是各方追求統(tǒng)一的努力嘗試。

大道至簡，越能讓用戶快速接受，學(xué)習(xí)和使用成本最低的技術(shù)才能永遠(yuǎn)走下去。或許有一天，基于W3C體系的技術(shù)規(guī)范會逐漸被各廠商接受，并得到底層引擎上的適配和兼容。