一、引言

本文將會從整體上介紹 vivo 商城在前端維度的多端統一探索和實踐。

從多端價值、為什麼要做多端統一、如何滿足多端業務需求、實踐與創新，簡潔直白的闡述我們在多端統一上所做的一切。

二、多端探索為vivo商城帶來了哪些價值

多端的價值可以從技術架構升級和人力資源釋放兩個方面體現。

1、技術架構全面升級

從

到

 

我們實現了技術架構方案的統一。透過統一，極大的降低了開發成本、維護成本。同時具備高複用、高效率。

2、釋放大量人力資源

技術架構方案的統一，對業務的橫向擴張提供了強大的技術支援和可實現保障。

下圖是使用新的技術架構後的開發人力投入比。

 

 

從上圖可以看出，透過技術架構的升級，釋放了可觀的開發資源。讓釋放的開發資源去做更多有價值的事情。

三、我們為什麼要做多端統一

大家可能會有疑問，那就是多端統一是什麼？

這裡我先賣個關子，先不談統一，我們來說說多端一詞。多端是什麼呢？想必大家都能說個八九不離十。

關於多端，我畫了個圖，如下所示：

從上圖可以看到，線下、pc、wap、APP、微信公眾號、微信小程式等，每一個都可以稱為一個端。知道了多端的含義，現在，我們再回頭看多端統一。

完整的多端統一，要包含以下幾個方面的統一

• 大前端【前端+客戶端】的多端統一
• 服務端的多端統一
• 業務的多端統一

這裡，我們只討論前端的多端統一。

從 PC 瀏覽器，到移動端瀏覽器、到 APP 內嵌，再到各個小程式，再到服務端、客戶端。繁榮的生態，猶如百家爭鳴，百花齊放。然而，繁榮的背後，對前端工程師的挑戰，則與日俱增。

我們承接的端越來越多，新的端不斷的出現，如小程式、快應用等。前端工程師陷入瞭如下套娃陷阱：

1. 現有程式碼、新程式碼要適配新的端開發場景
2. 已經適配新的端開發場景的程式碼成為了現有程式碼
3. 現有程式碼、新程式碼要適配新的端開發場景
4. 迴圈...

我們希望解決這種問題，希望做到一套技術架構方案【程式碼】，可以覆蓋現在的端和未來的端。

通俗點說，我們希望做到如下圖所示的能力：

在這種前端開發背景下，多端統一出現了。它是前端的一個未來趨勢，它也是解決上面套娃陷阱的一劑良藥。

四、如何滿足日益增加的多端業務需求

隨著時間的推移，各小程式端業務被逐漸重視起來，尤其是 vivo 商城微信小程式。

業務方的述求有兩點，如下所示：

第一點：讓現有 vivo 商城微信小程式的核心功能和商城 H5 功能保持一致。

第二點：後續版本迭代，小程式端和 H5 端同步進行。

而現實是： 現有的商城微信小程式，其版本迭代已經較大的落後商城 H5 版本了。

我們用新老版本的小程式購買流程影片做對比，讓大家有個較為直觀的感受。

老版商城小程式： 影片>>

新版商城小程式： 影片>>

從上面兩個影片可以看出兩者的差異，我們面臨的挑戰很大。

根據業務方的述求，我們需要做的事情在解決上面兩點的情況下，增加一點，共有三點，如下所示：

• 第一點：在最短的時間內，將商城 H5 的基本功能和流程在微信小程式上實現出來
• 第二點：在後續小程式端和 H5 端版本功能同步迭代時，做到高複用，高效率。
• 第三點：提前考慮未來其他端業務場景的落地，做好擴充套件性、多端複用性。

在業務驅動下，我們進行了技術調研、demo 驗證、mvp 驗證。最終在綜合考慮下，採用了 uni-app 多端架構來解決上面兩個難點。

這裡提一下，業務驅動的良好模式，大概如下圖所示：

透過業務來推動技術的最佳化和改變，在反覆應用的過程中，實時反饋改進，最後回報給業務。在這個過程中，技術和業務形成了良性閉環。

NOW. 剩下的事情，就是落地實踐了。

五、我們的多端做了哪些實踐和創新

有句名言是這樣說的： 實踐是檢驗真理的唯一標準。誠然，成功者的背後，有你看不見的努力和堅持。

1、實踐

在實踐過程中，要考慮的因素很多，列舉如下：

1. 現有小程式的原生程式碼如何轉成多端專案寫法，保證轉換程式碼可讀、可控。
2. 現有小程式的部分功能邏輯需要完整保留，甚至是小程式原生 api 和邏輯，這些和多端專案如何共存。
3. 如何將 H5 的程式碼邏輯最大程度的複用到多端專案中。
4. 如何優雅將 H5 的各種元件、設計模式、工程化、工具方法適配到多端專案中。
5. 等等...

那麼我們是如何處理這些因素的呢？

我們可以用一張圖整體概括下，如下圖所示：

 

下面就介紹下我們是如何處理這些因素的。

2、程式碼轉換

現有小程式的原生程式碼如何轉成多端專案寫法，保證轉換程式碼可讀、可控？

我們使用的是開源轉換器 miniprogram-to-uniapp 來做的轉換，然後再透過人工，去解決轉換過程中不匹配的問題。解決方案就是這麼樸實無華，也許大家覺得方案很簡單，但是選擇這個解決方案的背後，我們做了詳細的評估，包括和該開源轉換器的作者進行了微信交流。在和作者溝通交流的過程中，我們知道了該轉換器的過去、現在和未來，在當時的情況下，這是一個合適且正確的解決方案。

3、程式碼共存

現有小程式的部分功能邏輯需要完整保留，甚至是小程式原生 api 和邏輯，這些和多端專案如何共存？

我們透過對專案進行合理的目錄劃分，來達到天然的隔離，如下圖所示：

 

我們把一些現在還不能適配多端的程式碼，統一放到 platforms 目錄下。同時，我們會使用條件編譯來將現在還不能轉換成多端的平臺隔離開。如下圖所示：

4、複用和適配 h5

複用講究的是一個懶字，能直接複用的就果斷複用，不要做二次調整，保證和 H5 高度一致。

適配講究的是一個以不變應萬變，我們不需要改動 H5 的程式碼，我們只需要為他們做一個適配層，如適配 H5 路由，一些不相容的元件，甚至說適配 window.location 都可以。

從上面介紹的解決方案中，我們可以體會到，處理這些因素的核心秘訣就是下面兩句話：

第一句： 因地制宜，找到平衡。

第二句： 提高複用，降低改動。

5、創新

有句話是這樣說的： 平凡中孕育著偉大。放在這裡，我們換個說法，那就是  實踐中孕育著創新。

在實踐的過程中，我們解決了很多問題。在解決問題的過程中，我們做出了一些令人高興的創新。

• vuex 創新

這個創新來源於一個問題，這個問題的背景如下：

商城 H5 商品詳情頁用  vuex 管理資料，在將 vuex 移到小程式商品詳情頁中時，發現一個現象，如下動圖所示：

從上面動圖中，我們發現，在使用 vuex 時 ，我們從 A 商品的詳情頁中點選 B 商品，進入 B 商品詳情頁。這時，我們點選左上角返回 A 商品詳情頁，會發現，此時商品詳情頁已經變成 B 商品，也就是說，A 商品的資料已經沒了。

這是一個非常大的問題，經過排查，發現原因如下：

vuex 的 namespace 預設是一個，無法自動新增 namespace 。當在小程式頁面裡面使用 vuex 進行資料管理時，由於小程式頁面資料機制，在點選返回時，頁面資料使用的是同一個 vuex 的資料，從而導致了上面出現的現象。

這裡，有人可能要說，在 onShow 生命週期裡面，重新整理資料，不就解決了嗎。其實不然，在這種場景下，進行資料重新整理是非常不合理的。

那麼該如何解決呢？

我們知道，小程式頁面資料在使用 vuex 後，多次進入同一個頁面後，返回會有展示問題。隨後，組內進行了討論，綜合權衡後，確定繼續用 vuex ，透過給 vuex 加一個適配層來解決這個問題。

隨後，組內進行了討論，綜合權衡後，確定繼續用 vuex 。透過給 vuex 加一個適配層來解決這個問題。

首先我們看下，在給 vuex 加一個適配層後，進行上面的操作，會是什麼現象。

如下動圖所示：

從上面的動圖，我們可以發現，在給 vuex 加了一個適配層後。成功的解決了小程式頁面資料在使用 vuex 後，多次進入同一個頁面後，點選返回時，出現的展示問題。

我們是如何解決這個問題的呢？

核心方案： 透過讓 vuex 支援自動擴充套件、自動登出 namespace，來做到更加智慧化的資料流管理方案。

核心架構圖如下所示

 

透過在 store 中自動生成 namespace，保證了同一個頁面進入多次後，每個頁面資料都是保留的。當頁面返回時，透過動態收集父元件的 namespace ，完成了父子元件的 namespace 關聯。

透過上面的技術方案，我們解決了 vuex 在小程式裡面使用時，存在的問題。這裡，核心架構方案已經給出，具體實現，就不再細述了。

6、解耦創新

這個創新來源於一個問題，這個問題的背景如下：

我們現在有普通、 秒殺 、 拼團 商品詳情頁，後面還會有其他商品詳情頁，那麼我們如何複用這些詳情頁裡面的業務元件呢？

面對上面的問題，大家會有以下思考：

• 不同頁面，業務元件內的資料處理是有差別的
• 不同頁面，業務元件內的埋點是不一樣的
• 不同頁面，業務元件內可能存在特定的介面請求

上面的這些思考，大家看過應該是有感觸的，複用業務元件本身就是一件很困難的事情，如果想徹底的解耦更是難上加難。

那麼，我們是如何做到儘可能解耦的呢？

我們做了以下幾點：

1. 在上游保證埋點統一，透過設計元件層面的埋點來達到埋點統一。
2. 在元件層面，對特定介面，進行條件判斷。
3. 將業務元件的資料分解成源資料和派生資料，源資料在 vuex 層面保證一致，派生資料在業務元件內根據實際情況進行相應的適配。
4. 對 vuex 進行改造，讓業務元件和頁面的通訊徹底解耦，業務元件不再需要知道頁面的 vuex 名稱空間。

開發過商城專案的同學應該都清楚已選彈層的邏輯是很複雜的，這裡就拿 已選彈層 業務元件做例子來說下我們是如何去做業務元件複用的。

下面是目前已經複用的已選彈層元件的組成：

1234567891011

├── components │   ├── sku-number │   ├── sku-product │   ├── sku-service │   ├── sku-spec │   └── ... ├── index.js ├── index.scss ├── index.vue ├── mutation-types.js └── track.js

我們將已選彈層元件的資料分為源資料和派生資料，源資料透過 vuex 層面去統一，如下圖所示：

 

我們為每個詳情頁寫一個 vuex ，同時將相同的部分抽離到 common-detail 中。之後，我們在 vuex 中進行處理，保證不同頁面給出的源資料是相同的。這些源資料是要傳到業務元件中的。

如下程式碼所示：

123456789101112131415161718192021

// 這是已選彈層業務元件 // 透過 @vivo/smartx 解耦元件和頁面的通訊 import  { mapState, mapGetters, mapMutations, mapActions } from  '@vivo/smartx'  // 獲取源資料 computed: {    ...mapState([      'spuInfo' ,      'skuInfo'    ]),    ...mapGetters([      'price' ,      'pageType'    ]), }  methods: {    fn() {      // 策略模式    } }

透過上面的處理，就可以將類似的業務元件很好的從不同頁面中解耦出來，從而提高程式碼的複用性、可維護性以及可擴充套件性。

這種解耦業務元件的思想就在於：

不必刻意將資料與檢視徹底分離，透過源資料和派生資料,平衡好變和不變的資料，再透過自研的 @vivo/smartx 將變到不變變成孤島，將不變到變變成孤島。

每一次創新，都是一次考驗，它總是不經意間給你出難點，然後逼迫你，去突破自己，從而創造出更好的東西，迴圈往復。

最後，多端架構的 vivo 官方商城微信小程式已經上線了。大家可以點選 vivo官方商城體驗一下哦。

六、總結

本文我們一起回顧了， vivo 商城微信小程式的多端統一之路。從業務需要，存在價值，到技術實踐與創新，我們希望用技術讓多端之路能夠更加平坦。

vivo 官網商城前端團隊