一、背景介紹與痛點分析

vivo游戲是vivo用戶玩游戲的平臺，其主要產品形態是vivo游戲中心以及vivo游戲內置懸浮球，它為用戶提供了找游戲，玩好游戲，找人一起玩游戲的價值。vivo游戲中心是vivo游戲的核心流量入口，因此游戲中心首頁就承擔了非常重要的角色。首頁的風格延續了好幾年，基礎樣式幾乎沒有什么變化，強調分發。隨著時間的發展，各種問題就慢慢突顯出來了。

1.從2020年開始，互聯網流量見頂，分發提升困難，需要探索新方向，而應對新需求的時候研發周期過長。從需求評審到功能上線，灰度到全量，需要耗時一個月以上，運營效果往往低于預期。

2.核心用戶的關注點不同。MOBA玩家看畫面和平衡，傳奇玩家看游戲人數，消消樂玩家看玩法，且用戶對游戲福利活動的需求也是非常強烈。首頁列表中，重點信息無法突出，也無法給用戶帶來強烈的下載沖動。

3.任何一個游戲都是有生命周期的。在不同的階段，突出的重點是不一樣的。預約的時候可能突出這個游戲的畫風和畫質，重點更新的時候可能突出的是新玩法。游戲中心首頁沒有相關的位置或者手段來突出這些信息。

4.無法快速響應運營或者開發者訴求。如果運營需要更換首頁跳轉的二級落地頁，或者響應開發者訴求搭建一個特殊專區的時候，都是需要開發的，現有功能無法快速支撐。

這幾個問題是表層的問題，透過現象看本質，我們可以歸納出，游戲中心缺少了兩項基礎能力。一方面，游戲中心缺少靈活多樣，且能動態調整的組件化能力；另一方面，游戲中心缺少可視化，快速搭建頁面的能力。基于以上痛點，結合行業前沿知識，筆者所在團隊商量決定，利用低代碼思想，打破原有秩序，重新搭建新平臺。

二、如何建設游戲中心低代碼平臺

大家可能會好奇，低代碼平臺一般都是通用性比較強的平臺，怎么能和業務屬性如此鮮明的游戲中心結合呢？那接下來筆者為大家一一道來。

低代碼平臺離不開組件化設計，那什么是組件化設計呢？組件化設計是指針對相同或者不同功能，性能，規格的產品，進行功能分析，設計出一系列的功能組件。通過組件的多樣選擇將產品客制化，以滿足不同的市場需求。由此可以推出，游戲中心組件化設計就是針對游戲中心進行功能分析，設計出一系列功能組件，通過組件的多樣化選擇，快速搭建出不同的頁面，以滿足不同用戶的需求。

那么，我們是怎么來定義游戲中心的組件呢？

在原有系統的基礎上，結合游戲中心app各個位置的形態以及未來定位，把游戲中心首頁按照橫向劃分，每一行細化為一個組件。雖然大家可能不太了解游戲中心，但是對于市面上大部分分發類的產品來說，它們每個頁面里面的UI樣式是系列化的，比如視頻樣式，圖片樣式等，變化比較多的是內容，所以我們可以以行來定義組件。另一方面，組件粒度的粗細，和組件的靈活性成反向關系，但是和運營的配置能力成正向關系，即組件粒度越細，越基礎，那么組件的靈活度就越高，運營的配置配置成本也越高。所以，選擇什么粒度的基礎組件，是需要結合實際業務需求，綜合分析后確定的。不是粒度越細越好，也不是粒度越粗越好。

確定好組件的粒度后，我們通過一個例子來詳解拆分一下組件的構成。大家請看圖1，這是一個專題組件。其形式為左上是標題，右上是跳轉二級頁的按鈕，多個游戲橫向并列成一行，最下面是安裝按鈕。將這種組合形式抽象為一個多游戲并列（1*4）展示的基礎模板，基礎模板同時也叫元組件，那么就可以把這類基礎模板命名為專題元組件。運營希望該元組件可以配置標題，跳轉鏈接，行數和展示游戲個數。這些是靜態的基礎配置。同時，專題組件需要配置一個數據源，這個數據源決定專題里面游戲的內容和展示順序，這個數據可以是運營配置的或者實時推薦的。例如，在推薦場景下，用戶發起請求的時候，可以由推薦實時返回，那么這就是動態數據。Banner同理。因此可以認為：組件是由元組件和數據構成的。

圖1

那么元組件是怎么定義的呢？在后臺，我們可以新增一個元組件，填寫完卡片編號名稱描述等信息后，再上傳圖片保存。這里的元組件卡片編號作為該組件的唯一標識，是有相應的業務含義，由該編號確定當前組件展示數據的格式，即通過編號確定處理數據的流程類。上傳圖片主要方面運營配置頁面。因為在頁面搭建過程中，運營配置多個組件的時候，后臺會實時顯現客戶端的效果。展示的組件圖片就是在此處上傳的。

圖2

配置完元組件的基礎信息后，在元組件配置管理的左邊，如圖3，通過編輯schema，右邊就會出現當前元組件能夠配置的標題，跳轉鏈接，行數以及單行游戲的個數。這些配置是運營在配置組件的時候可以動態配置的；配置完這些數據后，在頁面管理后臺，添加該類組件的時候，紅框中出現的就是我們能夠配置的基礎屬性了，如圖4。到這一步，元組件的配置就完成了。

圖3

圖4

接下來就是數據源的配置。在運營點擊數據選擇的時候（圖5），彈出的就是動態數據的配置，那這些數據是怎么來的呢？

我們需要從兩個維度來看數據：第一個，數據有哪些；第二個，數據怎么交互。我們從兩個角度來看數據有哪些。從數據類型角度劃分，有運營配置數據和系統自動數據。運營配置數據為運營人員為了達到某一個目的而手動配置或者干預的數據，而系統自動數據為從系統某一個源自動獲取的數據，不需要人工介入。從數據來源劃分，有內部數據和外部數據。通過不同的數據類型和來源，我們切分為不同的調用方式，這樣能最大限度地保證系統的擴展性和維護性。

隨著業務的發展，平臺會不斷吸取其他業務數據，來豐富當前業務的形態，但是獲取外部數據的方式只有兩種：http和dubbo協議。通過這兩個協議的配合，能夠標準化獲取外部數據。我們說完了元組件和數據，那么他們是怎么綁定的呢？在后臺數據管理中，我們會按照某個運營目的，來確定一個組件的應用場景，比如專題組件的應用場景就是為用戶推薦某一類型的游戲集合。通過定義組件的應用場景，我們把元組件和數據綁定在一起。

整體過程如下：

1. 確定組件的應用場景名和編號；
2. 選擇一個或者多個元組件；
3. 確定數據源類型，調用類型和數據業務方；
4. 確定調用的http和dubbo接口。通過http接口，可以生成運營能夠配置的數據，即點擊選擇后彈出的列表，點擊選擇后，即可將數據綁定到組件上，如圖5；在用戶調用流程中，通過dubbo接口，利用后臺配置的數據，可以請求獲取到更加詳細的數據。

此時一個組件就配置完成了。

圖5

在前臺數據的調用方式中，使用了阿里的QLExpress。QLExpress由阿里的電商業務規則、表達式（布爾組合）、特殊數學公式計算（高精度）、語法分析、腳本二次定制等強需求而設計的一門動態腳本引擎解析工具。它的特性優勢和運行原理可以在GitHub上找到，在此不贅述，感興趣的同學可以自行搜索。利用其弱類型腳本的特性，將運營配置的數據轉換成調用外部接口的參數，通過dubbo泛化調用技術，獲取到具體的數據。同時，還是利用弱類型腳本的特性，轉換返回結果，控制業務邏輯和數據范圍。采用QLExpress和dubbo泛化調用的方式，可以減少代碼開發，增加數據靈活性。

最后，來了解一下整個頁面的配置過程。前面講述到，元組件是最基礎的組件，通過元組件，我們配置一些基礎信息，并關聯一些動態數據，構成了一個組件。通過把多個組件拖拽到頁面上，就可以實現運營配置生成頁面的效果。同時，頁面也可以直接拖拽已經配置好的組件，這就是一個組件被多個頁面引用的情況，實現了組件級的復用。在頁面之上，我們還引入了方案的概念。方案，即多個頁面的集合。通過頁面的組合，首頁可以實現多個頁面的展示，既能展示游戲中心的門戶，又能個性化運營。

如圖6，從下到上，通過數據和元組件，可以構成一個組件，通過多個組件的選擇，可以構成一個頁面，多個頁面構成一個方案。如圖7，從上到下，通過多層實驗框架，確定需要展示給用戶的方案。接下來，通過dmp用戶畫像，確定展示個性化的頁面。每一個頁面都是由若干個組件構成的。每個組件是由元組件和數據構成。

圖6 

圖7

三、成果展示

羅馬不是一天建成的，游戲中心低代碼平臺也不是一蹴而就的。平臺20年就上線了，由于缺少運營場景，功能也不是很完善，能夠帶來的效益微乎其微，甚至內部也產生過質疑，是不是不值得花這么多的時間精力建設平臺，但經過時間的沉淀，游戲中心低代碼平臺的效果愈發明顯。

首先，研發流程和原先不一樣了。當我們在新增/修改組件的時候，客戶端同學通過flutter等動態化技術，完成新組件的開發修改，并且在后臺上傳flutter的更新包或者差分包。

服務器同學需要在后臺配置元組件的信息，配置組件應用場景，綁定元組件和數據關系，就可以生成運營可以配置的組件。運營配置完組件，頁面，方案，點檢完畢審核通過后就可以上線了，如圖8。

圖8

其次，研發效率提升了。大家注意到，最大的一個變化是，客戶端不需要發版了。在一些特殊場景下，服務器也不需要開發。對比原先的研發流程，效率發生了質的飛越。針對不同的角色，提升的效率是不一樣的；對于客戶端來說功能全量上線周期可縮短15天以上，有較高的容錯性，對于服務器來說，開發效率提升4倍以上，對于測試來說，無需回歸老版本，測試效率提升30%-50%；對于運營來說，可視化的操作降低30%的學習成本，提升10%的配置效率。

最后，項目周期縮短了。原先如果運營做一個功能，首先得把需求提給產品（其實在提需求之前，還有一個需求討論的過程，非需求評審），再進行需求評審，評審完畢后需要根據各個需求的優先級進行排序。而此類需求由于效果不明顯，且論證數據不好收集，往往其優先等級就比較低。需求評審完畢后，還需要策劃評審，概要設計評審等等諸多流程，上線完畢還需要灰度一周，有了上線報告之后才可以全量。但是，有了低代碼平臺后，流程就沒有這么復雜了。最簡單的流程，無需更改組件，運營自己就能操作。還有一些簡單的場景，服務器修改配置就能完成組件的修改。最復雜的就是全新場景，但由于之前的基礎在，開發效率也是非常的高。整體流程至少可以縮短為原來的1/4。接下來用一個例子來說明一下。

圖9  

圖10

四、未來展望

游戲中心低代碼平臺的建設標準，和通常意義上低代碼平臺的建設存在差異。游戲中心低代碼平臺由“游戲中心業務”衍生，慢慢演變到可以適配vivo生態內分發類app的終端解決方案。這符合我們的業務發展，也為低代碼的演變提供了養分。通過不斷的適配和演變，我們希望能夠將低代碼的解決方案普惠安卓生態。因此，在未來的建設思路上，我們的目標是能夠解放生產力，提升用戶體驗，做最好用的安卓低代碼平臺。

五、總結

低代碼的概念最近很火，爭議也很大。有人認為以后“人人都是程序員”，也有人認為是新瓶裝舊酒。但作為技術人，最重要的還是通過技術解決業務問題，驅動業務發展。游戲中心低代碼平臺旨在提高開發效率，幫助業務取得更好的結果。未來，我們也會投入更多的精力優化系統，不斷為用戶創造驚喜，為行業帶來革新。