商家店鋪多端融合技術實踐

語言: CN / TW / HK

關鍵字: 店鋪、多端融合、webview、Taro、JDHybrid、效能優化、ISV開放

簡述

店鋪瀏覽閉環之後,因各端資料與渲染割裂導致程式碼無法複用,從而引起研發成本增加;同時多年以來技術棧未升級且不統一導致嚴重落後於競品店鋪,對於ISV開放化的支援程度也停滯不前。針對這一系列的問題,店鋪研發團隊發起了多端融合降本提效專案,下定決心將多端渲染全部升級重寫,從底層能力上解決了以上所有問題,使店鋪瀏覽從原有的重複開發1.0時代,步入了全新的一套程式碼多端複用2.0新時代。

背景

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

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

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

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

現有各端渲染流程

為解決商家更換模板之後,可以實時在APP端生效的問題。智鋪裝修系統當前採用的是“XML模板轉JSON動態下發方案”,每一套模板的結構和樣式,都是通過XML進行定義。商家在裝修店鋪之後,服務端會把裝修的資料和XML定義的樣式,解析成JSON格式下發給各展示端。這樣做最大的優勢是APP端不用去整合跟版,線上可以隨時更換不同的模板樣式。但是這樣也產生了一個很大的問題,因為M站和小程式是可以支援Js模板渲染的,但現在也只能去解析這套JSON資料才能拿到模板進行渲染。

同時由於之前瀏覽端維護團隊不一致,各個團隊的服務端拿到這份JSON資料後,又進行了二次封裝,這樣的直接結果,就是介面資料格式完全不統一。其次每個團隊的前端,也分別開發瞭解析庫去解析這套JSON資料,所以這些解析庫也完全不能複用。

其次,因為應用獨立、支援的端也多,因此部署的上線工程也很多。

方案需要解決的問題

針對以上背景以及當前各端渲染現狀,店鋪多端融合需要考慮四方面的問題:一是服務端資料必須統一,輸出一套標準的資料格式定義。其次,前端需要對多端渲染進行統一,實現開發一套程式碼,就可以在不同的端都能使用。再次,當前端渲染融合之後,各端店鋪的首頁效能不能降低,不能影響使用者體驗。最後,店鋪多端融合還需要解決ISV開發樓層模板的效率問題。

由於內容較多,下面重點看一下“前端渲染融合方案”,以及各端“首屏效能保障方案”。

前端渲染融合方案

0 1

方案設計

由於店鋪當前使用的是“XML模板轉JSON動態下發方案”,存在多套解析庫去解析這套資料,造成重複工作量問題。

因此第一套融合方案,就是“APP端解析庫和小程式解析庫並存方案”。在左圖中,針對服務端下發的統一資料,前端開發一個統一的解析庫,這個解析庫裡面包含2套邏輯,一是通過RN解析庫實現京東APP之間的複用,再通過JDReact轉換成H5統一M站店鋪和裝修端預覽。另一套邏輯是通過小程式解析來庫實現京購小程式店鋪、以及京東小程式業務的統一。

這套方案,對現有APP端業務改動量相對較小,屬於半融合方案,因為仍然要維護兩套解析邏輯,因此只能減少30%—40%的工作量。同時上面分析的幾個問題也並沒有解決,一是H5和小程式也需要解析庫去解析才能拿到模板樣式,效率較低;二是ISV也仍然只能開發RN模板,效率並沒有得到提升;三是仍然落後於競品店鋪的技術統一和擴充套件性。

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

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

當前,APP店鋪頁面已經實現原生樓層和webview樓層共同展示。我們也正在開發將京東小程式也內嵌到店鋪首頁中展示,同時增加webview複用去保障效能,待上線後,店鋪首頁將擁有同時渲染原生+H5+小程式的基建能力,其他業務只要遵循這套技術體系,也能快速的將H5樓層、小程式樓層在店鋪中渲染出來。

0 2

整體方案概覽

整個“多端統一去RN方案” 包含:H5與APP融合、 H5與小程式融合、Nodejs服務、 ISV跨端開放化這四大主體方案;以及異常、災備、效能、監控四大擴充套件方案;

由於方案較多,這裡就不細加描述,如果有對這套方案感興趣的同學,可以和我們智鋪團隊聯絡交流。

首屏效能保障方案

在各端首屏效能方面,當前IOS端和Android端,店鋪原生樓層混合RN樓層的首屏渲染耗時在0.7-1秒左右浮動;M站店鋪耗時在4s左右;京購小程式店鋪在2.5秒左右。因此三端的現有渲染時間就是此次多端融合的參考基準。

01

核心保障措施

在IOS端,採用了Hybrid離線包來減少頁面以及靜態資源的請求時間,並將webview容器初始化放到剛進入店鋪的時候就開始,其次將比較耗時圖片放到最後做懶載入請求。通過這些措施,在首屏渲染5個樓層的前提下,使用者能感知的首屏耗時大致在800毫秒左右,整體時間就和線上原生+RN渲染的效能保持一致。這裡有2個點可以繼續優化,比如可以將資料介面請求放到點選店鋪的入口時就開始。其次,當前服務端資料介面耗時返回的是首頁所有資料,如果改成只返回首屏資料,或者增加快取措施,這樣也可以有效降低資料請求的耗時,最終也會體現為首屏耗時降低。

在Android端,服務端資料介面請求前置到使用者點選店鋪入口時就開始,當用戶進入到店鋪裡面時,資料請求耗時已經減少了接近一半。同時配合Hybrid離線包方案,也將Android端的首屏耗時保持和線上一致。這裡也有幾個可以繼續優化的點,比如介面耗時優化,以及將webview初始化和靜態資源注入提前到進入店鋪的時候。這樣也能有效的再提升店鋪的訪問效能。

02

綜合保障措施

除了上面用到的優化措施外,針對不同端也用到了一些優化措施,在APP端還採用了靜態資原始檔合併措施,減少當離線包載入失敗之後,載入線上H5頁面的效能。以及骨架屏、樓層和圖片懶載入等措施。

在小程式端和M站上,也採用了骨架屏、懶載入,以及H5端的瀏覽器離線快取等方案來提升頁面效能。

融合收益

01

首屏效能提升

經過多端融合之後,在IOS端和Android端新首頁的首屏效能,和線上原生+RN的渲染效能基本上持平。M站及京購小程式當前還未完全上線,預估也將有較大的提升。

02

ISV開放化能力提升

當前店鋪對ISV開放的僅有APP端的RN定製模板,RN受限於技術本身無法很好的支援三端;同時由於開發環境複雜,除錯困難等原因極大影響ISV開發效率。和競品店鋪ISV開發相比,同一套類似效果的模板平均開發時間多出1-2倍。而基於多端融合使用的技術棧Taro規範來開發,加上店鋪現在已經實現了多端渲染統一基座,ISV僅開發一套程式碼,稍加調整即可支援三端,同時效率也將有較大的提升。

03

人效及其他提升

在人效方面,涉及到多端渲染需求,投入的人力較以前下降56%,工時下降66%。在服務端也統一了資料介面,人力成本下降30%-50%。

同時在技術專利和文章沉澱方面,也通過了3篇技術專利,有兩篇也處於編寫階段。其次有4篇技術文章也在陸續編寫中。

技術展望

前端技術經過十幾年的發展,技術棧、技術框架迭代都比較快,而業務需要支援的展示端也越來越多,如果每一端都需要去重複開發,那麼這個人力消耗必然是不能承受的。因此需要均衡各方面的因素,找到一種前端技術的最佳組合實踐,而這個原則必然是一套程式碼,多端適配複用。

而受限於網際網路技術的發展,各廠商自身利益的取捨,在前端渲染方面,還無法統一成一套標準的技術棧天生就能在各廠商提供的軟體上面執行。因此才出現了各種奇門遁甲的相容技術,無論是開發規範相容、還是底層引擎相容,還是配置化下發相容等等,都是各方追求統一的努力嘗試。

大道至簡,越能讓使用者快速接受,學習和使用成本最低的技術才能永遠走下去。或許有一天,基於W3C體系的技術規範會逐漸被各廠商接受,並得到底層引擎上的適配和相容。