如何“拼”出一個頁面-遊戲中心模組化實踐

一、背景

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