vivo 官網資源包適配多場景的應用
本文介紹了資源包的概念及使用場景，同時對資源包的幾種使用方案進行對比。通過本文，大家可以快速掌握資源包的使用方法，解決單一配置滿足多場景、多樣式的問題。
一、業務背景
隨著官網項目的業務深入發展，單純的配置已經滿足不了各種複雜場景的需求了，靠適配各種場景的需求只會讓配置後台越來越複雜。而且有些特殊場景是需要在特殊時間觸發，並且需要運營人員做到快速配置，無需發版，配置正確的地步。資源包的出現就是為了解決上述場景的。它能配置一次，無需發版，支援預覽，並且適合所有特殊場景的樣式。這種能力已經在我們官網運用的很好了。
二、什麼是資源包？
包含網頁、JS、CSS 和圖片影片等靜態資源的文件，並具有一定目錄規則的壓縮包，可以通過後台配置，快速上線更換，無需版本發布。下圖所展示的是一個Demo的資源包目錄。
三、為什麼要使用資源包
最開始我們開發完一個功能，即使設計時考慮的比較通用，但是在一些特殊節日的時候總有樣式上面的偏差，功能無法滿足，緊急情況只能發版解決。所以出現了資源包的解決方案，這種方案只需要前端按照一定的規則開發一個完整的資源包，在後端進行資源包的解析。
前端能立馬看到整個頁面樣式，做到配置一次，快速上線的目的。這種方式對大部分場景比較適用，但是對於需要動態獲取數據、用戶分流的頁面不太適用，資源包大多都是靜態頁面。所以在使用資源包的前提下需要自己去評估下業務場景。
3.1 資源包使用場景
- 解決一套配置只適配一種樣式的局限性，滿足了多頁面多樣式的隨時更新的需求。
- 滿足特殊活動前端展示特殊樣式的需求，比如各種節日的主題，特殊活動的內容，手機360度模型。
- 可以作為各個場景的兜底數據，並且在重構的時候可以解決新舊數據的兼容性問題。
圖一：
圖二：
圖一和圖二是兩種不同的資源包，圖一是X50 Pro+的360度模型，圖二是X50 Pro+的靜態宣傳頁面，兩種不同的資源包達到了給用戶展示不同的效果目的，其實在後台就一個配置入口。
可見這種方式非常靈活的展示了不同的需求。
四、怎麼使用資源包
4.1 整體流程
不同的資源包有不同的規則目錄，解析規則也不一樣，所以後台有統一的資源包解析適配器，對應到不同的解析方法，然後經過一系列的解析操作（主要是JS、CSS、圖片、影片、JSon文件官網規則適配邏輯和相對路徑的替換）之後把主頁面內容入庫和入快取。最後把上傳的資源包解壓後上傳到
靜態資源伺服器上面。資源壓縮包上傳到靜態伺服器我們這邊嘗試了三種方案，分別如下：
4.2 方案一：本地解壓
本地解壓是在本機器完成資源包的解壓工作，把資源包所有文件解壓到本機的規定的目錄，然後解析壓縮完的主網頁，替換網頁中所有的引用靜態資源的路徑。
下圖展示了本地解壓方案
本地解壓主要是把製作好的靜態資源zip包上傳上去，規定好解壓路徑，通過Zip的工具類對zip包進行解壓，解壓好的文件上傳到本地，本地解析主要是對解壓好的文件中主文件比如"index.html"進行解析，解析的主要工作是按照一定規則通過jsoup去操作HTML 文件，篩選一些我們需要的樣式、頁面並且替換靜態資源的路徑，改為上傳到你本地路徑。前端直接獲取服務端返回的數據進行渲染成你資源包的頁面。
本地解壓方案評估
-
優勢：
- 解壓資源包和解析資源包的速度比較快。
- 資源包文件能完美解壓全文件數據，丟失的概率會小很多。
-
劣勢：
- 文件存儲本地，影響本地的存儲容量，不好統一管理。
- 文件存儲本地，影響後續系統的容器化。
- 文件安全性，容易造成違規文件社交性散播。
4.3 方案二：本地解壓+雲上傳
本地解壓如同第一種方案，之後會把解壓後的所有文件上傳到OSS伺服器上面。同樣去解析主文件"index.html"。後續步驟類似第一種方案。
本地解壓+雲上傳方案評估
-
優勢
- 文件具備統一管理，可支援在線刪除，編排的能力。
- 文件安全性，上傳到OSS存儲伺服器上面的文件具備時效性，具備安全性。
-
劣勢
- 文件上傳的速度最終會導致靜態資源包上傳的速度，跟網路IO強相關。
- 文件整體性差，其中有一份文件沒有上傳上去，不支援回滾，導致整個資源包不可用。
4.4 方案三：雲解壓
如何確保資源包的整體性？思路：上傳一個完成的資源包到雲伺服器，然後在線解壓？
靜態資源包會直接上傳到文件服務系統，上傳的這個動作是一個事件，觸發了綁定該事件的函數進行在線解壓，然後從文件系統拉取解壓後的文件進行以上方案的解析。
-
優勢
- 保證文件的安全性和整體性，可以設置文件的訪問許可權，保證文件上傳時候的不丟失問題。
- 通過Serverless技術保證上傳的速度、並發量。
-
劣勢
- 雲函數的支援性比較差，不是很通用。
- 資源包的大小會影響上傳和解壓效率。
引申：Serverless 的計算產品-雲函數
- 雲函數提供了一種直接在雲上運行、無狀態的、短暫的、由事件觸發的程式碼能力。
- 雲函數的運行是由事件驅動，在有事件的到來，雲函數就會啟動運行，而且是按需啟動，不會佔用很多資源。一次HTTP請求，一次文件上傳，一次資料庫修改，一個動作都能作為一個事件。
每次請求都會觸發一個解壓雲函數的事件驅動，解壓函數會啟動一個實例來執行腳本，完成本次請求的解壓工作，具體的解壓腳本程式碼本文暫不做闡述。
當用戶上傳zip包到規定的bucket目錄下的時候會觸發雲函數，雲函數會啟動一個實例來執行腳本，幫用戶完成壓縮包的解壓。
五、資源包帶來的好處
資源包這種方案在我們團隊已經使用非常的成熟了，解決適配各種不同的樣式配置，包括官網首頁、官網產品詳情頁等不同的頁面。現在系統運行比較穩定，我們這套解決方案也是比較成熟的。
運營同學只要在一個入口上傳不同類型的資源包，能完成各種樣式、各種規則的頁面配置，真正達到單一配置，多套樣式的功能的實現。
這套機制不僅提升了我們運營同學的50%的運營效率，更為我們解決了大促、節假日特殊樣式的配置場景。
六、資源包的弊端
- 資源包的製作不可控，不同製作者製作出來的資源包帶來的適配成本、對接成本、測試成本都是很大的。
- 資源包還是比較重量級的，一些動效、圖片、適配資源比較大，對後台資源佔用比較多，功能要求比較高。
七、未來展望
上述方案當然不是最優的方案，是這種場景下的的一種常用的解決方案，當然有更好的解決方案。未來我們考慮把常用配置項做成元組件形式，然後通過元組件之間的任意組合形成我們最終配置的頁面。
運營只需要拖拽其中的元組件，自己想怎麼組合就怎麼組合，節日的組合成為一份頁面，大促的組合也可以成為一份頁面，很自由。這種隨意組合的方式你可以稱之為lowcode模式，這也是我們未來想做的東西。
八、寫在最後
本文討論了使用資源包的大體思路以及一些關鍵技術點的解決方案，各種不同方案對比。目前官網正在應用第三種方案，但是需要具備Serverless這種能力，我們在探索期間尋求了運維同學的幫助，編寫在線解壓函數的腳本遠遠沒有上述來的簡單。由於本篇限制並沒有對Serverless的技術進行詳細介紹，有興趣的同學可以深入了解這方面的知識。
作者：vivo 官網商城開發團隊
