一、背景介紹與痛點(diǎn)分析

vivo游戲是vivo用戶玩游戲的平臺(tái)，其主要產(chǎn)品形態(tài)是vivo游戲中心以及vivo游戲內(nèi)置懸浮球，它為用戶提供了找游戲，玩好游戲，找人一起玩游戲的價(jià)值。vivo游戲中心是vivo游戲的核心流量入口，因此游戲中心首頁就承擔(dān)了非常重要的角色。首頁的風(fēng)格延續(xù)了好幾年，基礎(chǔ)樣式幾乎沒有什么變化，強(qiáng)調(diào)分發(fā)。隨著時(shí)間的發(fā)展，各種問題就慢慢突顯出來了。

1.從2020年開始，互聯(lián)網(wǎng)流量見頂，分發(fā)提升困難，需要探索新方向，而應(yīng)對(duì)新需求的時(shí)候研發(fā)周期過長。從需求評(píng)審到功能上線，灰度到全量，需要耗時(shí)一個(gè)月以上，運(yùn)營效果往往低于預(yù)期。

2.核心用戶的關(guān)注點(diǎn)不同。MOBA玩家看畫面和平衡，傳奇玩家看游戲人數(shù)，消消樂玩家看玩法，且用戶對(duì)游戲福利活動(dòng)的需求也是非常強(qiáng)烈。首頁列表中，重點(diǎn)信息無法突出，也無法給用戶帶來強(qiáng)烈的下載沖動(dòng)。

3.任何一個(gè)游戲都是有生命周期的。在不同的階段，突出的重點(diǎn)是不一樣的。預(yù)約的時(shí)候可能突出這個(gè)游戲的畫風(fēng)和畫質(zhì)，重點(diǎn)更新的時(shí)候可能突出的是新玩法。游戲中心首頁沒有相關(guān)的位置或者手段來突出這些信息。

4.無法快速響應(yīng)運(yùn)營或者開發(fā)者訴求。如果運(yùn)營需要更換首頁跳轉(zhuǎn)的二級(jí)落地頁，或者響應(yīng)開發(fā)者訴求搭建一個(gè)特殊專區(qū)的時(shí)候，都是需要開發(fā)的，現(xiàn)有功能無法快速支撐。

這幾個(gè)問題是表層的問題，透過現(xiàn)象看本質(zhì)，我們可以歸納出，游戲中心缺少了兩項(xiàng)基礎(chǔ)能力。一方面，游戲中心缺少靈活多樣，且能動(dòng)態(tài)調(diào)整的組件化能力；另一方面，游戲中心缺少可視化，快速搭建頁面的能力?；谝陨贤袋c(diǎn)，結(jié)合行業(yè)前沿知識(shí)，筆者所在團(tuán)隊(duì)商量決定，利用低代碼思想，打破原有秩序，重新搭建新平臺(tái)。

二、如何建設(shè)游戲中心低代碼平臺(tái)

大家可能會(huì)好奇，低代碼平臺(tái)一般都是通用性比較強(qiáng)的平臺(tái)，怎么能和業(yè)務(wù)屬性如此鮮明的游戲中心結(jié)合呢？那接下來筆者為大家一一道來。

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

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

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

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

圖1

那么元組件是怎么定義的呢？在后臺(tái)，我們可以新增一個(gè)元組件，填寫完卡片編號(hào)名稱描述等信息后，再上傳圖片保存。這里的元組件卡片編號(hào)作為該組件的唯一標(biāo)識(shí)，是有相應(yīng)的業(yè)務(wù)含義，由該編號(hào)確定當(dāng)前組件展示數(shù)據(jù)的格式，即通過編號(hào)確定處理數(shù)據(jù)的流程類。上傳圖片主要方面運(yùn)營配置頁面。因?yàn)樵陧撁娲罱ㄟ^程中，運(yùn)營配置多個(gè)組件的時(shí)候，后臺(tái)會(huì)實(shí)時(shí)顯現(xiàn)客戶端的效果。展示的組件圖片就是在此處上傳的。

圖2

配置完元組件的基礎(chǔ)信息后，在元組件配置管理的左邊，如圖3，通過編輯schema，右邊就會(huì)出現(xiàn)當(dāng)前元組件能夠配置的標(biāo)題，跳轉(zhuǎn)鏈接，行數(shù)以及單行游戲的個(gè)數(shù)。這些配置是運(yùn)營在配置組件的時(shí)候可以動(dòng)態(tài)配置的；配置完這些數(shù)據(jù)后，在頁面管理后臺(tái)，添加該類組件的時(shí)候，紅框中出現(xiàn)的就是我們能夠配置的基礎(chǔ)屬性了，如圖4。到這一步，元組件的配置就完成了。

圖3

圖4

接下來就是數(shù)據(jù)源的配置。在運(yùn)營點(diǎn)擊數(shù)據(jù)選擇的時(shí)候（圖5），彈出的就是動(dòng)態(tài)數(shù)據(jù)的配置，那這些數(shù)據(jù)是怎么來的呢？

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

隨著業(yè)務(wù)的發(fā)展，平臺(tái)會(huì)不斷吸取其他業(yè)務(wù)數(shù)據(jù)，來豐富當(dāng)前業(yè)務(wù)的形態(tài)，但是獲取外部數(shù)據(jù)的方式只有兩種：http和dubbo協(xié)議。通過這兩個(gè)協(xié)議的配合，能夠標(biāo)準(zhǔn)化獲取外部數(shù)據(jù)。我們說完了元組件和數(shù)據(jù)，那么他們是怎么綁定的呢？在后臺(tái)數(shù)據(jù)管理中，我們會(huì)按照某個(gè)運(yùn)營目的，來確定一個(gè)組件的應(yīng)用場(chǎng)景，比如專題組件的應(yīng)用場(chǎng)景就是為用戶推薦某一類型的游戲集合。通過定義組件的應(yīng)用場(chǎng)景，我們把元組件和數(shù)據(jù)綁定在一起。

整體過程如下：

1. 確定組件的應(yīng)用場(chǎng)景名和編號(hào)；
2. 選擇一個(gè)或者多個(gè)元組件；
3. 確定數(shù)據(jù)源類型，調(diào)用類型和數(shù)據(jù)業(yè)務(wù)方；
4. 確定調(diào)用的http和dubbo接口。通過http接口，可以生成運(yùn)營能夠配置的數(shù)據(jù)，即點(diǎn)擊選擇后彈出的列表，點(diǎn)擊選擇后，即可將數(shù)據(jù)綁定到組件上，如圖5；在用戶調(diào)用流程中，通過dubbo接口，利用后臺(tái)配置的數(shù)據(jù)，可以請(qǐng)求獲取到更加詳細(xì)的數(shù)據(jù)。

此時(shí)一個(gè)組件就配置完成了。

圖5

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

最后，來了解一下整個(gè)頁面的配置過程。前面講述到，元組件是最基礎(chǔ)的組件，通過元組件，我們配置一些基礎(chǔ)信息，并關(guān)聯(lián)一些動(dòng)態(tài)數(shù)據(jù)，構(gòu)成了一個(gè)組件。通過把多個(gè)組件拖拽到頁面上，就可以實(shí)現(xiàn)運(yùn)營配置生成頁面的效果。同時(shí)，頁面也可以直接拖拽已經(jīng)配置好的組件，這就是一個(gè)組件被多個(gè)頁面引用的情況，實(shí)現(xiàn)了組件級(jí)的復(fù)用。在頁面之上，我們還引入了方案的概念。方案，即多個(gè)頁面的集合。通過頁面的組合，首頁可以實(shí)現(xiàn)多個(gè)頁面的展示，既能展示游戲中心的門戶，又能個(gè)性化運(yùn)營。

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

圖6 

圖7

三、成果展示

羅馬不是一天建成的，游戲中心低代碼平臺(tái)也不是一蹴而就的。平臺(tái)20年就上線了，由于缺少運(yùn)營場(chǎng)景，功能也不是很完善，能夠帶來的效益微乎其微，甚至內(nèi)部也產(chǎn)生過質(zhì)疑，是不是不值得花這么多的時(shí)間精力建設(shè)平臺(tái)，但經(jīng)過時(shí)間的沉淀，游戲中心低代碼平臺(tái)的效果愈發(fā)明顯。

首先，研發(fā)流程和原先不一樣了。當(dāng)我們?cè)谛略?修改組件的時(shí)候，客戶端同學(xué)通過flutter等動(dòng)態(tài)化技術(shù)，完成新組件的開發(fā)修改，并且在后臺(tái)上傳flutter的更新包或者差分包。

服務(wù)器同學(xué)需要在后臺(tái)配置元組件的信息，配置組件應(yīng)用場(chǎng)景，綁定元組件和數(shù)據(jù)關(guān)系，就可以生成運(yùn)營可以配置的組件。運(yùn)營配置完組件，頁面，方案，點(diǎn)檢完畢審核通過后就可以上線了，如圖8。

圖8

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

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

圖9  

圖10

四、未來展望

游戲中心低代碼平臺(tái)的建設(shè)標(biāo)準(zhǔn)，和通常意義上低代碼平臺(tái)的建設(shè)存在差異。游戲中心低代碼平臺(tái)由“游戲中心業(yè)務(wù)”衍生，慢慢演變到可以適配vivo生態(tài)內(nèi)分發(fā)類app的終端解決方案。這符合我們的業(yè)務(wù)發(fā)展，也為低代碼的演變提供了養(yǎng)分。通過不斷的適配和演變，我們希望能夠?qū)⒌痛a的解決方案普惠安卓生態(tài)。因此，在未來的建設(shè)思路上，我們的目標(biāo)是能夠解放生產(chǎn)力，提升用戶體驗(yàn)，做最好用的安卓低代碼平臺(tái)。

五、總結(jié)

低代碼的概念最近很火，爭(zhēng)議也很大。有人認(rèn)為以后“人人都是程序員”，也有人認(rèn)為是新瓶裝舊酒。但作為技術(shù)人，最重要的還是通過技術(shù)解決業(yè)務(wù)問題，驅(qū)動(dòng)業(yè)務(wù)發(fā)展。游戲中心低代碼平臺(tái)旨在提高開發(fā)效率，幫助業(yè)務(wù)取得更好的結(jié)果。未來，我們也會(huì)投入更多的精力優(yōu)化系統(tǒng)，不斷為用戶創(chuàng)造驚喜，為行業(yè)帶來革新。