活動可視化搭建系統——你的KPI被我承包了

前言

對於C端業務偏多的公司來講，在增加、運營等各方同窗的摧殘下永遠繞不過去的一個坑就是大量的H5頁面開發，它多是一個下載、需求告知、產品介紹、營銷活動等頁面。此類需求都有幾個明顯的缺點：

• 開發性價比極低、上線時間緊，每次須要指派單獨同窗支持。
• 溝通成本高，而業務邏輯高度類似。
• 高頻次的需求

有句話怎麼說來着，世界是"懶人"創造的，當咱們煩透了無休止的重複工做時，一些"偷懶"的想法就會蹦出來。對研發而言咱們不想花費過多的時間在此類簡單重複的工做上；對運營而言他們須要活動更快的迭代、發版，脫離研發的排期等限制；於公司而言節省人力成本就是節省財務成本，更大的提升效率就能夠支撐配合更多增加營銷策略。

因此從技術賦能業務的角度出發，一套可視化活動編輯系統是每一箇中大型公司必備的生產利器。

首先讓咱們來挑幾個表明性的頁面簡單分析一下...

以下圖：

先從頁面上作個分析：

• 圖一、3都屬於簡單的引流下載頁

• 圖二、4屬於普通活動頁

• 圖5無任何交互邏輯，只是單純的一個靜態告知頁

• 圖6從頁面結構和業務邏輯來講，屬於複雜活動頁

接下來拋開UI細節層面不談，對頁面進行一個拆解

• 圖一、3 組合方式 （ 背景圖 + 按鈕 + [ ios、安卓 ]下載連接 ）

• 圖二、4 組合方式 （ 背景 + 按鈕 + 活動規則 + 領券邏輯 ）

• 圖5 組合方式 （ 背景 + 活動規則 ）

• 圖6 組合方式 （ 背景 + 業務模塊 + 活動規則 ）

綜上分析可見，每一個頁面由多個小模塊構成，能夠是基礎UI組件，也能夠是一個複雜的業務組件，且組合方式多種多樣，能夠預想到當咱們將這些不一樣組件像組件庫那樣整合在一塊兒且能夠在頁面進行可視化的編輯操做時，不一樣的組件不一樣的排列便可生成一個全新的活動，就像積木同樣擁有無限種可能，開發效率將會大大提升，本文將這兩個月鼓搗lego活動可視化搭建系統（如下簡稱lego）從0到1的心路歷程整理出來供各位有相關需求的小夥伴參考，也歡迎大神交流指正。

核心方案

Lego採用Vue框架開發，經過對組件物料進行拆分再統一管理，造成一個可編輯的組件庫。JSON schema 來定義組件JSON規範，配合Vue的動態組件特性來實現動態的頁面渲染。動態表單用於根據不一樣組件特性生成對應配置表單。最後打包並優化多頁面，每一個頁面單獨配置域名，一個負責內部編輯、一個負責對外展現。經過活動id獲取對應活動JSON數據動態渲染在活動展現頁面。

渲染流程： 多頁面流程： 關於最後的活動頁面展現除了多頁面外其實還有特別多種方案可選，選擇最合適本身業務的就好，後邊內容會細說這幾種展現方案。

關鍵詞：JSON schema、動態渲染、動態表單、組件管理、多頁面

技術方案

動態渲染

is

如何將不一樣的組件打散後再從新拼裝並渲染在頁面上是整個技術方案最核心的點，好在Vue提供了動態渲染組件方案，經過內置組件conpontent，渲染一個「元組件」爲動態組件並根據 is 的值，來決定哪一個組件被渲染。

props

大部分組件的可配置項無非就樣式、連接、事件、文案這幾種，咱們將它們抽離成一個config對象，經過props的方式傳遞給子組件用於渲染樣式或者加一些點擊事件等，好比bind綁定傳進來的style樣式，固然在這以前必定要定好基礎config的規範。

渲染函數

因爲一些業務的緣由，Lego除基礎組件外其它部分開放的自由度並不算高，因此props的方案目前能夠知足咱們的需求，但若是你想開放更高的自由度，釋放系統的徹底編程能力，好比配置一些點擊事件，事件執行交互等等。那能夠試試Render渲染函數。根據官網對它的描述，它比模板要更接近編譯器。而它的可配置對象足夠你肆意發揮了。

佈局方案

可視化佈局的方案拋開大廠不談，根據公司人員配比，建議大部分中小公司只須要如下兩種方案的一種便可。根據不一樣的優缺點來選擇最適合你的方案，若是條件容許也能夠兩者結合實現。

抽屜式

自上而下順序排列，能夠更換組件位置，但不能實現元素定位，沒有層級概念，遇到複雜佈局或者須要疊放元素時不夠靈活，若是須要實現複雜頁面的效果則須要引入複合UI組件的概念，它須要大量現成的UI組件。優勢是將可操做程度限定在了一個可控的範圍內，對非設計人員來講只須要經過現有UI組件進行拼裝便可生成一個美觀度較高的頁面，lego即採用的是此方案。

自由式

徹底可隨意拖拽元素位置，自由度高，只需幾個基礎UI組件便可，存在層級概念，可任意疊放拼裝，在無成品UI組件的狀況下diy出複雜頁面。但頁面不可控，對操做人員的美感要求更高。更適合UI同窗操做使用。下圖只是一個複雜佈局的例子，關注佈局便可先不要管業務邏輯如何實現。

關於自由度

結合佈局方案聊一下關於可編輯自由度的問題，編輯自由度應該綜合實際狀況進行考量。

對於lego而言，UI同窗僅參與組件設計的工做而不會去使用此係統去編輯發佈活動，而當UI同窗不直接參與最後的拼裝上線時，高自由度的編輯操做對咱們而言實際上是個雞肋，直接開放高自由度給運營人員，因爲存在層級疊放且可自由拖拽，這樣就會有可能面臨着大量的不可控的頁面樣式，即便在編輯完後UI同窗對頁面效果把關，但相較於改起來的時間成本和活動質量來講是得不償失的。並且高自由度帶來的是更多的技術的考量和實現成本，嵌套組件的層級規則、拖拽方案、組件定位等等….因此當你的團隊技術實力和你能獲得支持的資源不是那麼充分時，也許抽屜式的半自由度方案更加適合你。

半自由度從佈局方案到組件的可配置項上來講開放程度有限，組件方面針對基礎UI組件開放相對高的配置編輯項，同時積累大量的成品UI組件可選。在編輯時不須要考慮太細節的樣式問題，保證頁面質量。

當開發人力和資源和部門協同、工做流程都到位且規範的狀況下，兩種方式結合實際上是最佳的方案。能夠提供不一樣模式來供不一樣人員使用，甚至能夠實如今線編輯器來供研發人員直接進行代碼調整。

組件分類

Lego將組件分爲了兩大類：UI組件、業務組件

UI組件細分爲基礎組件和複合組件，UI組件僅用來作靜態展現用。原則是自身不包含任何業務邏輯，因爲採用半開放的佈局方案，對於複雜樣式來講咱們又基於基礎組件封裝了不少不一樣功能不一樣用處的複合型UI組件用以知足更復雜頁面的需求。好比不一樣主題的標題、按鈕、均可以單獨封裝出來直接用於拼裝。

業務組件是指那些和服務端有交互的有業務邏輯在裏的組件，屬於獨立的功能模塊，能夠理解成每一個業務組件都是一個單獨的活動，好比購卡、抽獎、分享等等。lego針對業務組件的惟一原則就是不在系統內提供業務相關可配置入口，僅開放基礎樣式配置，如大小、主題色等。將權限回收至研發手中，每一個業務組件在營銷後臺中配置數據，經過不一樣活動id進行區分渲染。由於每一個業務組件發佈前都通過了QA的完整測試流程，能夠最大程度保證活動的穩定性，而不至於影響到業務。

配置項

每一個組件根據自身特性擁有着不一樣的配置項，在選中組件後展現對應的配置表單是經過動態表單完成的，Lego系統使用了IView的組件庫，每一個組件除自身屬性外還會對應一份配置對象，經過匹配配置對象來描述這個表單的結構，最後仍是經過compontent對錶單組件進行循環渲染。

通訊

對頁面配置、組件增刪、某個元素的配置項等全部編輯後的變化經過Vuex作統一管理進行通知。須要注意的是不少狀況下只是改變某個對象下的一個屬性，watch監聽不到這種對象屬性變化，而像是某個樣式的其中一個屬性變更是很頻繁的，因此能夠經過添加一個changeStatus的狀態，每次屬性被改變後能夠更改監聽changeStatus的狀態來通知Vuex進行對應更新，但要注意作好防抖。

輸出頁面

當編輯完組件並拼裝好整個頁面後，如何將這個頁面最終暴露給用戶，在這個問題上咱們設計過兩種方案：

A方案：

從公司現有的活動項目新建一個頁面，將組件庫打包發佈到私有npm倉庫進行管理並在此處引入，提供一個獲取活動配置的接口給它，全部的活動都使用這個頁面做爲落地頁，經過不一樣的活動id來獲取不一樣的活動配置信息進行動態渲染。好處是上線方便，只要在lego系統進行發佈後拿到發佈後的活動id進行拼接便可，而無需進行頁面部署。缺點也很明顯，須要等待接口請求成功後才能進行渲染，一旦接口服務報錯線上全部活動所有都會失效，並且渲染速度勢必要比靜態頁面慢。這個方案咱們最終放棄了，由於除了上述問題，最關鍵的阿是從技術方面，咱們的node服務開發經驗較少，從技術方案到架構方面都比較薄弱，並且最開始從設計之初沒有考慮服務併發和數據庫壓力等，一旦像是經過公衆號推送的活動，它承載的的併發是很是很是高的。因此在沒有獲得服務端同窗參與的狀況下沒有輕易採用此方案。

B方案

大致思路同上，仍是經過活動id取配置信息渲染頁面。但把請求node服務拿配置的方式改爲了訪問本地json文件，並在落地頁的歸屬上作了一些調整。步驟以下：

1. 將lego分爲兩部分：編輯系統、落地頁，配置多頁面打包。
2. 優化多頁面打包，作好文件分割，兩部分各自引用自身須要文件，提高頁面加載速度。
3. 兩個頁面分別配置一個域名，一個負責對內編輯，一個暴露對外做爲落地頁展現
4. 每次上線活動打包前將配置數據拉到本地儲存爲json，落地頁訪問本地的靜態資源。

這個方案實現了組件庫和公共方法的公用，同時針對每一個頁面作了分割，實現按需加載，保證頁面性能。將網絡請求node服務改成本地json，解決了併發的性能問題。缺點是當活動愈來愈多的時候，本地的json會愈來愈大，若是不及時清理無用數據，會致使頁面加載愈來愈慢。lego目前採用的是這個方案，後續會再進行優化。

多頁面優化

關於多頁面的優化使用了splitChunk進行文件的分離，將系統端用到的各類資源單獨進行分離。這樣一來每一個頁面只要加載自身須要的便可。

1. 刪除默認配置
2. 單獨導出chunk
3. 指定多入口頁面單獨進行配置chunk

優化後的頁面速度

總結

1. 就這個系統來講還有不少缺陷，但已經能夠落地使用。像是落地頁的方案目前還有明顯缺陷，既配置數據保存在本地在必定程度上會拖慢加載速度。社區裏的SSR服務端渲染方案、每一個活動打包爲單獨靜態頁的方案均可以進行嘗試。但仍是那句話，根據當前團隊的技術實力以及你能動用的資源綜合進行方案的比較，有時候最好的方案不必定適合你如今的狀況。
2. 活動搭建系統在必定意義上能夠解決90%的簡單頁面，但複雜的多頁面聯動的活動仍是沒法作到。
3. 組件的積累纔是重中之重，在物料不豐富的狀況下，開發效率提升有限，而一旦運行一年半載組件庫豐富起來，效率將會肉眼可見的提升。
4. 不要以爲本身的方案必定比別人的差，能夠參考社區的大佬們優秀的技術方案和思路，但要從中找到自身須要的點便可。
5. 堅持獨立思考、重視基礎建設使技術賦能業務是每一個開發人員應有的素質，與公司無關與團隊無關，只要你有想法總會有辦法將方案推進落地，自身的思考和實現的過程當中的經驗積累纔是最寶貴的財富。