凹凸技術揭祕：618 大促解析

導語

2021 年 618 已經圓滿下線，平臺下單金額創新高，達到了 3056 億。做爲大促線的主要前端承接團隊，今年負責了 16 個會場的開發。本文將從會場創新功能、技術框架以及協做方式這三方面來揭祕，如何在短期內開發完 2021 年多會場、高要求的 618 大促，化解禿頭危機。

不同的 618

1. Taro3 應用：拉通 H5 和小程序

近幾年小程序因爲在用戶觸達、用戶留存方面的優點愈來愈受重視，團隊也接觸過須要在小程序中開發的會場（非 H5 形式），而 Taro 的優點正是用同一套代碼打包出多端運行的程序，這符合咱們對小程序開發的需求。考慮到往後的業務渠道，咱們在 2021 年 Q1 完成了 Taro3 技術棧在會場的落地。在這個過程當中，咱們遇到了 2 個白屏問題：安卓低版本瀏覽器白屏以及主購小程序白屏。

• 安卓低版本瀏覽器白屏

產生這個現象，通常是因爲低版本瀏覽器對高階語法的兼容性不夠致使的，在將頁面不斷簡化後發現普通一個空白項目也會白屏。最終將問題肯定在 Web Components 的使用上。因爲目前會場主要渠道爲 H5 形式，在和 Taro 開發團隊反饋討論後，針對 H5 的應用，把 Web Components 實現的基礎組件，替換爲 React 組件；在小程序中不作修改。Dom 節點以下圖所示：

目前最新版本 Taro 已經同步該功能，使用者不須要特殊處理。一套項目代碼，解決 H5 頁面開發和小程序開發，節省一倍開發量。

• 京東購物小程序對H5連接hash路由的特殊處理致使白屏

Taro3 打包 H5 時會添加默認 hash 路由，在通天塔（活動發佈平臺）發佈活動時沒法使用 history 路由，同時京東購物小程序和京喜小程序在 WebView 處理連接時會添加一些參數以及 hash 參數，從而致使小程序中 H5 頁面路徑錯亂。解決方案有三個：

1. 和小程序提需開白名單
2. 修改H5的連接地址增長「omitH5Params」
3. 更改Taro3路由設置

因爲大促會場個數多達 16 個，採用方案 1 和方案 2 須要統計各個會場以及渠道的連接，風險很大。所以和 Taro 開發團隊討論，最終實現了方案 3 的效果，新增路由配置鉤子，針對 H5 進行單獨的路由設置，經過通天塔默認的連接便可在小程序中訪問會場。減小了開發和運營維護成本。

最終項目關鍵配置以下：

router: {
      forcePath : '/',
      customRoutes: {
        [`/pages/${process.env.TASK_DIR_NAME}/index`]: '/'
      }
    }
複製代碼

2. 容災服務：用戶體驗的保障

大促會場在線時長 1 個月左右，訪問 PV 上億，對頁面安全性要求很是高。對於數據異常狀況，前端處理的方式有兩種：

• 請求異常時跳轉簡單版通天塔頁面
• 監控請求，異常時採用內置數據兜底

從用戶體驗上考慮，兩個方案各有優缺點。方案一優勢在於能展現實時的商品、廣告組信息，缺點爲頁面結構和預期不一樣，缺乏交互引導；方案二優勢在於和正常時頁面結構一致，缺點在於數據爲固化，不能及時跟進運營策略調整。爲此咱們對容災進行了總體流程設計：

今年咱們採用了兼顧方案1、二的新版容災服務，由客戶端（各會場）各自配置監控的接口（一般是首屏數據拉取接口），以及備份數據的間隔時間（通用爲 1 小時），由服務器來進行去個性化數據的請求備份至 OSS 服務器，從而實現如下效果：

• 不存在頁面跳轉，保證用戶體驗符合預期；
• 跟隨運營策略動態更新，兜底數據間隔 1 小時（可配置）備份一次。

在 618 專場期、高潮期，咱們統計了容災服務的曝光，以下圖所示（數據敏感性暫不提供具體值）：

3. 智能 UI：有效提高轉化率

隨着精細化運營策略的深刻，以及智能化應用的普及度，會場中商品 BI 已經不能知足用戶訴求。今年加入了「智能 UI」的概念。根據構建用戶設計畫像，一樣的商品信息/會場入口，經過前端呈現不一樣設計風格的樣式。如上圖所示。

針對前端來講，需求能夠簡化爲：頁面加載時，經過請求後端接口下發的用戶設計畫像，決定商品/店鋪的 UI 樣式。

• 功能實現

  做爲典型的 SPA 項目，頁面會在加載完 index.html 和主腳本後纔會開始請求頁面數據並由 js 渲染出來，以下圖所示：

  爲了防止頁面二次渲染，咱們能夠在請求頁面數據的同時並行請求智能 UI 接口，以下圖所示：

• 實現效果

  以主會場底部 feeds 以及店鋪入口爲例，實際頁面效果以下：

  從交互同窗對活動覆盤的數據來看，智能 UI 策略對樓層的點擊率、轉化率都獲得了有效驗證。

4. 下拉刷新：頁面刷新的另外一種方式

在京東購物 app 首頁，經過下拉操做能夠觸發頁面刷新，甚至在於某些特殊日子（好比 618 大促），下拉能夠觸發 xView 來投放會場入口，因而可知用戶已經被培養出下拉操做的習慣。可是在會場中，若是須要更新頁面數據（好比秒殺商品），只能返回上級頁面從新打開。

因爲大促會場是經過 WebView 來呈現的，在和負責團隊溝通後，2021 年 618 第一次在會場中上線了「下拉刷新」功能。

• 功能實現

  首先咱們須要經過導航欄統一配置協議設置 WebView 支持下拉刷新，同時設置在下拉刷新開始時調用的函數名，最後咱們只須要在回調函數中寫下咱們頁面刷新邏輯便可。

• 實現效果

5. VR 轉盤：酷炫的 Z 世代

對於崇尚個性，拒絕跟風，對於新鮮事物都有較強的獵奇以及嘗試心態的 Z 世代人羣，大牌制燥廠從運營策略、設計風格到動效呈現上都作出了相應的調整。VR 轉盤就是一個典型案例。

咱們先來看一張視覺設計時的對照圖，能夠看到你們對於實現精準性的要求是至關高的：

• 功能實現

輪盤的處理主要考慮到三部分：初始化、轉動過程當中、中止轉動。

• 初始化：處理圓形繪圖（每一個卡片高度設置、居中，以及旋轉角度），設置各狀態初始值，包括圓心座標、觸摸起點座標、轉動前角度、轉動狀態、鎖等。
• 轉動中：
  • 觸摸時：記錄當前輪盤角度以及開始座標、釋放鎖
  • 滑動過程時：判斷是否橫向滑動，設置狀態，計算滑動角度以及當前item索引，輪盤動畫處理。
  • 中止轉動時：判斷當前操做是否足以轉動（以1/2個卡片角度爲標準），釋放鎖，設置轉動狀態，觸發輪盤迴調。

• 實現效果

小結

2021 年 618 中還有不少新穎的交互形式（好比全渠道的 AB 頁、Z 世代的詞條選擇等等）、和往年大促相比取得更高點擊、轉化率的模塊（好比：百億購物金系列、事業部樓層優化等）。能夠參考設計同窗整理的戰報。

精彩交互展現：

開發揭祕

1. 技術框架

從加入京東來以來，經歷了最初的 gulp + ejs、再到後來的 Webpack + Vue/React、 如今的 Taro3，咱們迭代的最終的目標有如下 4 個：

• 更極致的性能
• 更快的開發效率
• 更低的維護成本
• 穩定的複用和迭代

首先經過底層基礎配置和 EUI 組件庫的支持，接着在中間層封裝經常使用的工具庫，配合不一樣業務模塊之間的組合，最終完成會場的開發工做；而這一系列分工、組合的基礎，離不開良好的團隊規範的實施；在完成本職的前端工做以外，團隊也會思考未來的技術方向（智能化）以及更好的用戶體驗（容災）。具體以下圖所示：

2. 高效的協做方式

開發週期短且工做量大的項目必然會遇到團隊協做的場景，目前咱們常常處理 3 類狀況：

• 多人協做同一頁面，好比大牌制燥廠和場景頁
• 多人協做同會場不一樣時期頁面，好比主會場4個時期
• 同一組件在不一樣會場中的複用，好比百億購物金在大促會場的貫通

所以，高效的協做方式、合理的分支組織、科學的版本迭代變得尤其重要。

• 代碼分支規範

開發項目時基於產品需求來作代碼分支管理，原則上一個分支對應一個需求。項目在開發週期存在一個開發分支dev，全部的功能分支都基於開發分支dev來建立，並以feature-xxx的形式來命名 。

當功能模塊開發完成後，再將該功能分支合併到開發分支dev

若是分支dev在合併了某個功能分支以後出現了問題，咱們也能夠很快的回退到合併分以前的節點，甚至檢出問題分支，從而確保開發分支的可靠性和易維護性

• 公共模塊維護

公共模塊的管理一直是開發中須要重點思考的問題。公共模塊能夠分爲如下兩類：

• 技術層面的公共模塊

對於技術層面的公共模塊，如請求庫、組件庫、工具類等，能夠集成在腳手架裏，項目初始化的時候經過npm的形式來引入。對於同一項目不一樣分期的公共代碼，

好比預加載模塊、容錯組件、底部導航等，一般來講能夠建一個文件夾，好比common，用於存放。

• 業務層面的公共模塊

對於業務層面的公共模塊，可能會隨着開發週期而累積，所以沒法像工具類等模塊提早集成在腳手架裏。好比今年的 618 活動，不少會場都包含了紅包雨、倒計時等功能，這些功能在不一樣會場之間的表現是大同小異的，所以能夠共用同一套代碼便可。

在不一樣項目中引入公共代碼，通常有npm、git submodule、git subtree等方式。它們各有優缺點，好比npm更側重於包的依賴管理，可是沒法作到雙向同步，這就意味着須要有專人去維護這個包，假如我在當前的項目中開發了一個組件，這個組件在別的項目中也可能須要用到，可是我卻沒法將其提高到npm包裏邊，而須要相應的人去作這個事情。又好比git submodule，它的特色是容許在一個項目倉庫中嵌入另外一個子倉庫，可是所嵌入的子倉庫是基於某個commitID，若是其餘開發者在操做子倉庫時沒有按照相應的規範，致使本來的commitID發生變化，則有可能對全部引入了該子倉庫的項目形成影響。

公共模塊管理方式對比

方式	優勢	缺點
npm	方便引入，可在多項目中使用	沒法雙向同步，須要專人維護、專人發包
git submodule	以子倉庫引入，目錄清晰	基於 commitID，commitID 發生變化可能致使子倉庫變化
git subtree	以子倉庫引入，目錄清晰	子倉庫的更新與推送指令相對複雜

git subtree相對來講更符合咱們的需求，它像git submodule同樣容許咱們在當前項目中引入子項目，這個子項目就像其餘的普通目錄同樣直觀，若是發生新增公共模塊或修改功能模塊等變動，只須要像維護其餘倉庫同樣去維護子項目對應的倉庫，再回到當前項目中去同步子項目代碼便可。

• 項目版本迭代

因爲 618 的活動持續時間較長，同一個活動項目可能會分爲預熱期、專場期、高潮期等不一樣分期，每一個分期都有相應的變化，好比新增樓層、新增功能等。若是把預熱期的功能發到了高潮期，或則把高潮期的配置弄成了專場期，則可能致使災難性的問題。

通常來講能夠經過分支來管理不一樣分期的代碼，但這要求開發者要有較強的分支管理能力，並及時同步代碼更新。即使如此，若是發佈項目時切錯了分支，仍會形成嚴重的事故。

爲了不上述狀況，咱們採起了如下措施：

• 不一樣分期對應不一樣入口文件
• 不一樣分期特有功能/樓層存放在分期命名目錄下
• 不一樣分期配置不一樣的發佈指令

以京東金榜活動爲例，京東金榜活動在整個 618 活動期間分爲了專場期和高潮期，咱們在項目中分別用s1和s2目錄來對應專場期和高潮期的入口:

其中，高潮期的簽到樓層和競速樓層與專場期不一樣，所以將這兩個樓層放在s2文件目錄下：

而後經過配置分期對應的活動信息：

經過執行命令yarn deploy -- name=dist stage=1和yarn deploy -- name=dist stage=2來區分相應分期的打包部署操做。

使用以上方式可確保每一個分期對應指定的入口文件和指定的運行命令，儘量的避免了迭代出錯的狀況。

小結

大促會場的開發，意味着短期內大量會場（們）的開發上線，同時大促在線時間長，運營策略必定會動態調整，計劃內的工做量以外，還須要考慮變動的人力預留以及成本。所以一個適合快速迭代、高效開發的技術框架，以及高效的協做方式，是支持咱們完成任務的基礎。

結語

每年的 618 活動對咱們來講都是巨大的挑戰，高效的開發模式、優雅的協同方式、可靠的容災方案是咱們始終追求的目標，咱們也會針對每一次活動的變化不斷去精進技術。咱們相信只有足夠的技術儲備才能爲京東 618 保駕護航，才能成爲京東 618 業績不斷創新高的基石。

以上是咱們研發團隊對 618 活動的開發方式和細節考量，但願能拋磚引玉，共同成長。