一、背景

vivo遊戲中心是一款垂類的應用商店，為用户提供了多元化遊戲的下載渠道。隨着遊戲中心手遊品類的豐富，各品類用户的量級也不斷增加，不同遊戲偏好的用户核心關注點也不同，從預約、測試、首發、更新到維護，不同遊戲生命週期節點的運營需要突出的重點不同。

針對上述不同業務場景，運營人員為了服務好廣大的vivo遊戲用户，需要進行精細化運營，以不同的視覺樣式呈現給不同用户。比如，針對獨立遊戲品類的用户，平台如果提供了活動，攻略等內容的透出，能夠促進用户更多的下載和消費。活動、攻略等內容以不同視覺樣式呈現，運營需要通過實驗的方式來驗證效果，以確定最終的投放方案。這些需求都需要重新開發。受限於遊戲中心APP較長的發版時間，運營的預期效果往往不佳。

因此，我們希望系統具備以下能力：通過不同視覺樣式的抽象與複用，快速靈活的對頁面進行佈局調整，對不同的人羣投放，最終以實驗的方式來確定最佳的投放方案。

怎麼樣才能實現這些系統功能呢？答案就是模塊化。下面為大家介紹一下游戲中心的模塊化實踐。  

二、什麼是模塊化

所謂模塊化，其實它是一種模塊化的設計思想，即指能針對相同或不同功能、性能、規格的產品，進行功能分析，並設計出一系列的功能模塊。

透過模塊的多樣選擇將產品客製化，可以滿足市場許多不同的需求。那麼遊戲中心模塊化就是針對遊戲中心相同或者不同功能的視覺樣式，進行業務場景分析，並設計出一系列的功能模塊。通過模塊的多樣選擇，快速靈活的搭建出不同的頁面，來滿足不同用户的需求。

模塊化有三個能力：組件化，配置化和實驗化。

• 組件化，即將頁面layout拆分成多個組件，對這些組件進行抽象，進而達到複用的目的。組件是UI樣式和數據的組合，組件化將UI樣式切分成一些獨立的，可複用的區域。
• 配置化，即通過不同組件的拼接，可以快速搭建出各種頁面。組件是構成頁面的基本單位，因此每個頁面都是由若干個組件構成的。組件是抽象的，對外輸出是統一，可以根據不同的需求靈活的調整順序和位置。
• 實驗化，即通過多層試驗框架和DMP系統，快速的將不同的頁面投放到不同特徵的用户手機上，以達到多版本運營的目的。多層實驗框架是vivo內部實現的ABtest框架，DMP系統即數據管理平台，可以把它簡單理解成一個數據池子，用來接收來自各方的數據，然後再經過融合、處理和優化後再使用這些數據。

大家可以看到，三個功能分別對應了三個概念。組件化對應了組件，配置化對應了頁面，實驗化對應了方案。它們是包含的關係，即一個方案包含了若干個頁面，而一個頁面也包含了若干個組件。

模塊化之前，遊戲中心的首頁是由頂部的廣告banner，導航欄，遊戲列表和穿插組件構成的。穿插組件即為橫向插入在遊戲列表中用於運營推廣的由視覺樣式和數據組成的廣告。從穿插組件的定義來看，其實就是組件化的概念，只是當時把組件化和遊戲列表做了相應的區分。穿插組件的視覺樣式比較單一，只有專題、視頻、熱詞、活動、論壇等。如圖1中，小編推薦，熱遊驛站，搶先推薦是1*4的遊戲專題穿插，類似九宮格（八個熱搜詞）為熱詞穿插。

（圖1：模塊化前）

穿插組件按照一定的規律穿插在遊戲列表的任何位置，但是廣告banner和導航欄是固定的，整個頁面佈局混亂，形態固定，不易變更。假如把最頂部的banner挪到小編推薦的下方，只能通過發版解決。將專題右上角的“更多”改成“換一換”，或者將遊戲列表中某些遊戲改為其內容的介紹，也需要通過發版解決。

模塊化之後，利用組件化能力，既可以靈活的調整順序，也可以動態更改組件的視覺樣式，即使是遊戲列表，也是可以動態配置。利用多個組件的順序排列，可以快速搭建出一個頁面。

通過ABtest框架和DMP系統，不同的頁面，以投放方案的方式，能夠快速呈現給對應的人羣，進行多版本的運營。圖1和2是模塊化前後首頁推薦的對比圖，雖然從大的樣式的沒有太大的改變，但是模塊化之前的樣式相對單一，而模塊化之後遊戲列表中排列了單遊戲大圖、金剛位、小喇叭、專題、新遊預約、下載榜等組件。

（圖2：模塊化後）

不同的組件可以滿足不同的業務場景。例如單遊戲大圖組件，輔以推薦，可以快速推廣新遊和熱遊，滿足了不同用户對不同遊戲節點的需求；新遊預約組件可以從更多角度滿足用户對於單款遊戲提前訂閲內容或關注其實時動態的需求。

三、怎麼實現模塊化

從前面的介紹大家可以看到，模塊化通過組件化的方式快速搭建頁面並將其投放給不同標籤的人羣，功能強大且配置靈活，為我們省去了不少的開發成本，那麼我們的底層是怎麼實現的呢？

3.1 模型抽象和統一

根據組件佈局，我們可以將組件抽象成兩部分：視覺樣式和數據；視覺樣式可以簡單理解為UI樣式，即呈現在用户面前的展現形式，我們可以將視覺樣式簡單概括為模板。

模板定義了當前組件最基礎的形式，比如當前組件是滑塊的形式，還是固定的形式；模板上還定義了一些可變的樣式，即定義了當前模板哪些位置是可以通過配置來完成的，比如模板的長寬高、組合樣式（2*2,1*4）、包含列表的個數等，能夠動態配置的程度依賴模板的定義。

所謂的數據，按照來源分為推薦數據和人工排期數據。推薦數據來自算法和大數據，而人工排期，則是運營在後台配置的。由於推薦數據背後的邏輯比較複雜，本文只討論人工排期數據。人工排期是一個四維數據。除了數據本身的“業務性”之外，它是有時效性的，遊戲中心的廣告位展示都是有時間限制的，比如遊戲中心首頁頂部banner，今天和昨天展示的是不一樣的；其次，它是有“空間性”的，即不同的用户可能看到的數據是不一樣的；另外，它是有動作性的，即點擊後產生的事件。比如點擊某個組件，可以是彈出一個懸浮窗，或者切換到到另外一個頁面。

因此，模塊化可以簡單理解為模板和人工排期的組合。通俗點理解，組件其實像一個類，每個頁面上不同的組件即為組件的對象，對象會實例化一些數據和行為。通過組件化的方式，我們不僅解決了端側和服務端的耦合，同時還實現了組件在不同頁面的複用。

排期數據的組成分為三個層次（即素材、推廣物料以及排期）。最底層數據當然就是圖片，視頻，推薦語，評論等，當然遊戲信息中也會包含遊戲icon，背景圖以及簡單的視頻，但是此處的圖片並不是指遊戲icon，而是比icon更精緻，用來宣傳廣告的素材圖片，這類數據我們統稱為素材。由素材組成了上層的推廣物料。

什麼是推廣物料呢？推廣物料其實就是基於某種目的，按照一定的形式來展示的內容集合。比如banner，其實就是一張圖片加上其背後的關聯的內容構成，圖片是為了吸引用户點擊，目的是為了推廣背後關聯的內容。推廣物料加上時間空間和動作屬性就變成了排期。素材，推廣物料和排期都進行了統一的抽象。

如下圖3，推廣物料有Banner、專題、活動、網頁等；排期有膠囊banner、遊情報，種草機、重磅更新等；如種草機就是網頁（內容鏈接）加上時間組成的；整個結構呈現一個倒金字塔結構。

（圖3）

原先遊戲中心每個資源位的排期數據都是放在不同的地方，比如頂部banner排期，網遊banner排期都有各自的表來保存。在這樣的情況下，數據庫表的數量可能會比較多，對統一拓展來説就更加複雜。假如我需要對頂部banner和網遊banner都要增加對不同人羣（DMP系統）展示不同數據的時候，通常需要在每一張表中都增加一個DMP的字段來表示當前排期需要展示給用户的標籤id。

模塊化之後，我們將遊戲中心所有的資源位都當成一個個模塊，也就是都可以看成是排期數據，我們只需要兩張表就可以做到排期三維數據的展示：排期數據表以及排期關聯的具體素材表。因此我們在設計排期表的時候, 將素材信息(如圖4中的material\_id和material\_type)數據保存在排期表中, 將DMP或者其他統一的信息也保存在排期表中, 這樣做的好處就是對所有的排期都能生效統一的流程。

（圖4）

3.2 後台業務流程統一化和可視化

如此複雜的業務流程，肯定少不了後台的配合。素材，推廣物料和排期的統一後，我們也將後台的配置流程標準化。

具體的配置流程如圖5，6。圖5偏向於後台的配置流程，是自下而上的配置。而圖6是為了方便大家理解，是自上而下的結構。用户層面展示的是某個具體的方案，方案由若干個頁面組成，但是會根據用户的畫像具體展示，即配置的頁面個數不一定是展示的頁面個數。頁面由若干個組件組成，組件由模板和數據組成....一層層往下分解，可以整體理解模塊化的結構組成。

（圖5）

（圖6）

模塊化之前，配置首頁banner排期，需要到首頁banner的tab欄下，在全部banner排期裏面加入相關的排期，然後在首頁banner排期裏面挑選全部banner排期裏面的數據，而配置其他頁面的banner排期呢，也是需要在類似的目錄結構中做相關操作，彼此之間的banner是割裂的，無法通用；對於運營來講，配置工作量也增加了不少。

模塊化之後，操作變得非常簡單了。在組件層面，通過數據庫配置，我們可以將模板的信息事先保存在數據庫中。在數據層面，我們把所有的banner數據統一保存在推廣物料管理並綁定到排期中，做到複用。在業務組件管理頁面中，根據組件應用場景來選擇模板，之後配置對應的排期數據。

如圖7，當前重磅更新場景關聯的是人工排期（如果關聯的是推薦，則是推薦對應的code），配置好樣式後整個業務組件也就配置完成了。然後在頁面管理中將你想要配置的組件添加到某個頁面中，設置好對應的DMP。配置好組件後，在後台頁面上可以滾動進行整體頁面效果預覽。

（圖7）

如圖8。最後可以將頁面複用到不同的投放方案中，運營後台通過審核流和上線點檢後，最終顯示在用户界面端。當前配置流程自下而上，邏輯清晰，符合運營的配置習慣。

（圖8）

3.3 前端業務流程抽象與統一

目前，遊戲中心首頁和新遊專區改造成了模塊化頁面。首頁是遊戲中心非常重要的分發渠道，模塊化要求頁面形式多種多樣，同時假如模塊化改造不被用户認可的時候也要能夠動態回退。

因此首頁模塊化頁面會有三種類型：

• 純模塊化頁面，
• 穿插模塊化頁面和
• H5模塊化頁面

所謂純模塊化頁面，即頁面中的所有元素都是由組件化數據構成。所謂穿插模塊化頁面，其頁面結構為按照一定規律在遊戲列表中穿插了若干個組件，和模塊化之前的頁面組織結構是一模一樣的，只是後台的實現方式不一樣。

穿插模塊化頁面中的列表還有兩種不同的形式，分為遊戲列表和混合數據流列表。穿插頁面可以在一個屏幕中最大效率的展示遊戲。

最後的H5模塊化頁面，可以認為由H5組件所構成的頁面，由我司的悟空建站提供頁面。通過多層試驗框架和DMP獲取不同方案以及不同頁面的流程不在此處贅述。這裏我們講一講整個流程中最為複雜的穿插頁面流程，以及我們怎麼在如此複雜的流程中抽象和設計。

（圖9）

3.3.1 流程統一

從上圖（大家無需過分關注流程圖裏面各個步驟的業務邏輯，流程圖只是為了展示原來流程的複雜度）我們可以看出來，用户請求開始，需要經過N個步驟。這麼冗長的步驟，如果寫在一個service，那麼就會造成邏輯混亂，維護性不高和擴展性差的效果，因此我們可以分而治之。圖9中，我們用不同的顏色來區分步驟，可以做一個簡單的流程歸納。

歸納後的流程如下圖所示。我們可以把提交異步線程池進行歸納，可以理解為獲取組件列表和混合數據列表為兩個步驟。

（圖10）

我們再進行歸納和抽象後，整個模塊化的頁面獲取流程就可以簡化為四個步驟：初始化階段、獲取組件列表階段、構建階段和合並階段，如圖；

（圖11）

在《金字塔原理》一書中曾説過，讀者在閲讀文章的時候，必須閲讀理解每一句話，並且尋找每句話之間的聯繫，前前後後反覆思考。如果你的文章結構呈現金字塔形，文章的思路自金字塔頂部開始逐漸向下展開，那麼讀者肯定會覺得你的文章比較容易讀懂。這一現象體現了人類思維的基本規律，那麼閲讀代碼其實也是一樣的邏輯。好的代碼即是一段業務邏輯的註釋，通過閲讀代碼能夠大概判斷主要的業務流程。在構建階段, 可以通過組合不同的策略來獲取不同的排期數據。策略和組件解耦，當新增策略的時候，無需改動原有的業務邏輯。此處不同的策略也可以採用工廠模式的方法來獲取。

首頁的組件展示邏輯是比較複雜的，尤其對於穿插模塊化頁面。正如前文所述，穿插頁面由遊戲列表和業務組件構成，即在一個遊戲列表中，穿插了各個業務組件。數據列表如果是遊戲數據列表， 那麼每個遊戲都是按照一定的比例來排列的，且需要和組件中推廣物料的底層數據是遊戲的去重。比如遊戲按照網遊，單機和獨立遊戲的比例來展示，假如上一個組件展示過當前遊戲，那麼這個遊戲需要被過濾，且補位遊戲也是有一個邏輯，比如網遊被過濾了，那麼取補位遊戲列表中的遊戲，其次用網遊來補，再次用下面的遊戲頂上來。去重邏輯包含兩種，一種是能被之前的遊戲過濾，也能過濾下面的遊戲；另外一種則只能去重下面的遊戲，不會被上面的遊戲去重。

（圖12）

在獲取業務組件中排期數據（如上圖，其中也包含了遊戲信息）的時候，還會有獲取ABTest信息（不同的用户展示不同的遊戲信息），遊戲黑白名單過濾，已安裝過濾，已曝光過濾，額外信息處理，組件數據組裝等過程。每一個排期數據獲取都會用不同的Handler來處理。每一個Handler都有自己的處理邏輯，針對如此多的排期以及他們的擴展，如果沒有一套處理的統一邏輯，那麼簡直是災難。新人在開發新組件中排期數據的時候，可能會遺漏非常多的細節。另外，推廣物料之間其實是有一些通用邏輯，如果不將這些邏輯沉澱到領域模型中，邏輯無法複用，將會散落在各個Handler中，我們以下圖橙色的步驟來詳細説明。

3.3.2 推廣物料的流程統一化

一方面，我們將獲取並處理推廣物料的流程統一化。如下圖所示流程中，其實基本上就包含了所有推廣物料需要處理的步驟邏輯（不重要的步驟已忽略）。統一之後，我們可以將一些通用的邏輯下沉，形成統一的方法調用。比如我們可以根據人工排期，推薦排期等，採用工廠方法的設計模式來屏蔽獲取推廣物料的邏輯。當然我們為了提升性能，對於人工排期數據，利用統一緩存的方式，通用場景code來獲取；接着利用不同過濾策略來過濾掉進入黑灰名單的遊戲或者內容。處理完額外信息之後再用列表的數據將組件中重複的數據給去除。

（圖13）

3.3.3 模型的邏輯抽象與沉澱

另一方面，我們將統一處理組件和推廣物料的邏輯沉澱到對應的領域模型中，如圖；

（圖14）

整個過濾重複數據的流程都是針對組件進行的，那麼在組件層面，會有大量的重複邏輯，比如每個組件需要在最後返回的數據個數處理上，不同的組件返回的個數是不一樣的，那麼這部分邏輯寫在組件這個領域模型中會更加妥當。比如已曝光和已安裝處理，這個邏輯就可以放在組件層面來處理， 當然放置在Handler層處理也是沒有問題的。在推廣物料層面，也有一些通用的邏輯，比如1*4個遊戲組成的專題和2*2個遊戲組成的專題，他們背後都有一套接入推薦系統並兜底的邏輯，也可以沉澱在專題這個領域模型來處理。

四、寫在最後

當前，很多業務開發的同學，尤其在熟悉了業務之後，通常會陷入一個誤區：做業務的基本上就是CRUD，沒有什麼技術含量。但是在開發的過程中，往往又缺乏相應的思考，導致重複開發。那麼如何才能讓業務開發變得更有吸引力和技術含量呢？

遊戲中心模塊化改造過程中，利用組件的抽象和複用，提升了組件化，配置化和實驗化能力，快速的支撐了業務需求，同時通過統一標準流程和利用領域模型知識不斷的完善業務代碼，提升了代碼的維護性和可擴展性。隨着業務的不斷髮展，即使現在非常合理的架構也會變得臃腫，難以擴展，但是如何做好業務的方法論確是不變的。因此做業務開發同學，應該多思考怎麼把業務做深做通用，提升快速實現業務價值的能力。

作者：vivo互聯網服務器團隊—Chen Wenyang