上個月在前端早讀課做了一次關於“可視化運營頁面生成系統”的live，本篇文章是這次live的文字記錄。
在電商領域，活動運營扮演着極為重要的角色，一場成功的運營活動甚至可以為公司創造數千億的成交額。所以，服務好運營同學，是技術團隊必須要做好的重中之重。縱觀轉轉發展的幾年時間內，隨着公司規模增長，運營團隊成員呈現急速擴充趨勢。相對的，技術側資源緊張的弊端則日益凸顯，如何用極少的人力hold住大量的運營需求，相信不止轉轉，每一個高速增長中企業都有着類似的訴求。
而本場live中，我們將會從運營活動的基本特性出發, 透過實際應用案例，推斷出活動頁面生成系統的核心需求，最后引申出一套維護成本低，可持續"自我進化“的活動頁面生成系統，因為這個叫法過於拗口，所以下面我們將簡稱為可視化系統
首先明確一點，這套系統是服務於公司內的運營同學幫助他們提高產出效率的工具。注意，“公司內”這一點非常之重要，因為他給定了一個子集。
- 大家看第一條，類比於大家都熟悉的標准的運營模型AAARR(獲取用戶, 提高活躍度, 提高留存率，獲取收入，自傳播)，因為我們作為一個逐漸打磨產品的創業公司，現階段運營其實是用戶獲取，激發活躍，提高轉化率這三個方面的，這就是我們的子集，換言之裂變玩法，自傳播這塊就暫時不需要投入太多精力去做。
- 第二點，最快速度，最低成本，質量尚可，眾所眾知，大部分運營活動經常卡某個時間點上線或者追熱點，而且持續時間很短，所以投入太多資源打磨產品是沒有必要也不現實的。
- 第三點，多端投放，渠道投放進行引流，所以其實這種需求對於運營這塊快速兼容各種app是有很高要求的，因為瞬時峰值很大，所以結構要設計的盡可能簡單，這點咱們放在后面的部分詳細談。
- 然后第四點，也是最重要的部分，公司方向慢變量，運營效果快變量。借用何帆老師在變量里面提到的變量的觀點，快變量很好理解啊，今天我們發放了一筆優惠券，4毛100塊，過了兩天發現運營搞得特別好，全國人民都知道這事了，但是花的錢太多了，怎么辦？動態的需要調整。金額，中獎幾率，法律條款，文案，甚至圖片顏色，一位富有經驗的運營同學需要時時的監控數據的變化並進行快速調整，而且常常半夜守在公司，所以大家在碰到運營汪低三下四的求着改文案的時候，也千萬要體諒一下他們。
公司發展慢變量，這個就厲害了，他是指公司戰略層面進行調整， 持續增長，變現能力，一切經營活動都是緊扣一個主題進行的。如果想在一個階段內支撐好某個旋律，就一定要有快速跟進甚至打好提前量的思維。有人說這個是不是太虛了。好，讓我們來看一組數據。
左邊的圖是周末統計出來的我們可視化平台上面的組件使用情況，最內圈上面的兩種顏色是我特別追加上去的，較淺的代表2017-2018年上半年紅包發放組件占整體活動頁面的比例，大概是40%-50%之間，而18年下半年急降至不足20%，相反，對於商品展示流組件的需求大大提升。這是由於公司戰略由拉新用戶逐漸傾斜於訂單轉化率的大格局導致的，如果前瞻性的定制了大量紅包組件的功能，最后的結果可能是很糟的，中台面臨的最尷尬問題，辛辛苦苦做出來東西但是沒人用。這種滋味並不好受。
眼尖的同學已經注意到了，除了說明公司大戰略變化對於可視化平台組件需求的影響，這張圖片還有幾個更有趣的數據，紅包組件，圖片組件，商品組件在該平台的使用率分別達到了79%， 71%和20%。而這三個高頻組件組織在一起使用率高達72%。換言之，這三個組件提供了可視化平台3/4的能力。如果您是一個小型電商公司，開發好這三種組件混搭布局的方案足以解放大半研發成本。
還是想象不出來？讓我們看下實際樣例。
看着各種花哨的頁面，但其實本質上面就是三種組件組合成的專題頁面，看吧，在電商領域，做好了這三個組件，你的可視化系統已經能夠生存下來了。
好，講了一些業務層面的東西，現在足以支撐起我們做技術上的選型與判斷了，我們思考一個最核心的問題，可視化系統的技術難點究竟在哪？像axure一樣的自由布局方案？事件流編輯器？組件的協同工作？談到可視化編輯大家第一反應一定是上面印象。但是相對的，復雜的技術對於研發投入，維護成本似乎不低。甚至對使用者來說門檻也顯得比較高，借用業界的一句靈魂拷問來說：不會寫前端的人就會用sketch了嗎？。而且，而且業務迭代頻繁，接口不統一，各種問題都會讓情況變的復雜。公司在變，時代在變，設計一套系統以不變應萬變，難。
所以，我們決定做的簡單一點，做一個專注於頁面生成發布，組件粗粒度編輯器（就像前面提到的三種組件），同時，通過持續迭代和自定義組件賦予她無窮的可能性。面向運營，也擁抱開發者。
生存還遠遠不夠，回顧一下標題，持續迭代的的電商可視化運營頁面生成系統。是的，我們不但要生存下去，還要迭代，發展起來。所以我們提出了在這三大組件上面的漸進式開發策略，下沉到各個業務線上，一步一步的迭代出各種垂類組件。還是有點抽象？沒關系，咱們再具體一點。
左邊是我們的雙十一預熱抽獎頁面，這是一個典型的與業務同學一同混合開發專題活動，在第一次迭代過程應用了圖片組件，商品流組件和自制抽獎。而后分別定制了推薦組件和秒殺組件進行替換。抽獎組件最開始是全部內容接口寫死的，但隨着之后的活動我們開發了接口的配置項，獎項配置，皮膚配置等等。這個過程是全程持續交付的。運營同學可以通過我們的可視化編輯器隨時調整，所以在我們的方案里，可視化平台的核心也是一個組件化交付平台。
下面開始基本就是干貨了，我將重點講一下我們的可視化平台魔方系統，工作原理及架構圖，可視化仿真器以及插件系統。
首先來看下我們的主界面，分成預覽區域和編輯區域兩部分。魔方的特色在於左側預覽區域采用了“仿真器”的設計結構，能夠做到邏輯，樣式100%與發布后的專題保持一致，並且不需要額外的代碼，而且最重要的一點在於，她不借助與任何后端服務。
然后編輯區域則是中規中矩的組件樹，頁面級別設置，和組件設置。
說完了主界面，讓我們看下整體的架構，其實這套系統和編譯器結構稍稍有點類似，簡單的可以划分成預覽編輯層，頁面生成層和組件層三個部分。每個專題在編輯時會生成一個json文件用以描述該專題的配置信息，然后生成層讀入這個json文件，通過webpack打包成一個完整的靜態頁面，是的，魔方系統從穩定性方面考慮，並沒有借助任何ssr或后端模板技術，純粹是通過webpack進行打包構建的。組件層則是通過npm安裝在服務器上，供動態加載器和專題生成器調用，這兩塊我們一會再詳細說。而最下層的核心技術棧則提供了整體的編譯腳本和統一版本的第三方依賴。
好，讓我們看下仿真器這塊，說仿真之前，其實我們需要先解釋一下頁面生成了什么、第一段代碼其實就是生成器的核心渲染邏輯簡化版，返回一個組件列表並且注入相應的數據。在生成層的邏輯中，我們以在生成模板執行構建命令，利用環境變量將專題json讀入，通過分析生成下面左側的代碼，通過宏替換注入模板，最后通過webpack構建打包成最終產物。
而仿真器則是在一個iframe中內置了一個空的模板, 通過父層向iframe注入js(動態加載庫)，並修改全局widgetsMap，右下所示。最后通過setState重新渲染頁面。整個過程是無需后端參與的。
關於動態加載庫，可以類比code split技術想象成需要哪個組件就請求哪段代碼，這里篇幅有限，暫時不展開談論，感興趣的可以關注大轉轉FE進行互動討論。
對於分享及其他native拓展能力來說，各個app提供的API並不相同，甚至在某些容器中沒有相應的功能，為了讓模擬器正常工作，我們需要一種抹平多端差異的公共庫，使得各端不會拋出錯誤。
說完了模擬器，我們想聊一下組件系統，前文說過，可視化平台的核心也是一個組件化交付平台。如果開發一個組件的門檻過高就會導致開發者拋棄這套系統。所以我們設計的一個組件將是下面的樣子。
我們的組件分成兩個部分，即組件實體和配置項，在最初的組件開發過程中，不需要任何配置項，魔方組件就是一個普通的react組件，上手的成本非常低。而隨着版本迭代，越來越多的配置項進去，我們提供了一套簡潔的api用於快速增加配置項。關於配置項這里，我們也嘗試過采用json來描述，最后從靈活性上面來看略微不滿足需求。而且可拓展性不足。
魔方提供了一套內置的api用以輕松的完成某些動作，我總結了一下大概如上6類。
為了讓開發人員方便的進行定制組件的調試，我們又設計了一套組件開發的sdk工具集，大概包括下面四個方面，第一：第三方庫集合，包含全部魔方組件依賴的第三方庫，在初始化一次后，任何組件編譯過程中不會重新安裝。第二，面向開發者透明的構建腳本生成器，用以進行組件的本地化測試構建。第三，一個簡易的編輯模擬器，用於開發時測試Config到Preview的數據流動。最后，還有一個用於快速創建項目的組件腳手架。
在組件管理這塊，我們采用monorepo+安裝時構建的策略來處理組件包的。組件管理的最讓人頭疼的地方在於組件所依賴的其他第三方npm包的管理，利用monorepo來組織代碼可以使結構更加清晰，權限明確，全部組件共享構建腳本使得底層優化更加可控，安裝時構建更可以確保第三方組件不會重復或多版本引用。
關於第三方的依賴的打包，我們采用一種多層的優化策略，按重要程度划分成4個類型，金字塔最上面的是必要且穩定的一類，比如react，antd，這種是通過dllplugin打包成一個js，所有的專題均引用這一個js。其次是部分組件依賴的，組件構建時extrenal掉，當專題生成時打包進專題內，比如無限滾動插件。還有一種會頻繁更新，采用外鏈直接引用的方式，而其他未知組件，是禁止添加到項目源碼中的。
說了這么多實現細節，再說點我們的夢想，從最開始的架構圖其實可以看出，魔方的本質是可視化生成json，然后讀取json生成靜態頁面，實際通過描述甚至可以組裝成native頁面，微信小城序，產出存在着各種的可能。我們也會陸續嘗試向這個方向探索，然后回顧一下我們的仿真器，我認為可以在生成頁面時進行預渲染提升速度，最后就是隨着公司規模擴大現在看起來單機構建效率不足，所以我們會考慮利用分布式構建來提升效率。
好了，總結一下本次live的觀點：
- 運營活動有很多特征，比如我們的電商公司：圖片，商品流和紅包是運營的核心要素。
- 運營活動千變萬化，以不變應萬變很難，所以讓可視化系統保持生命力的關鍵是持續迭代和支持插件。
- 魔方的工作方式是通過可視化編輯器生成json，通過json注入模板生成靜態頁面。
- 開放插件及定制能力需要完善的配套系統。
- 插件系統棘手的難點在於第三方依賴的管理。