建站
咨詢
售后
建站咨詢
新聞中心
一、背景介紹與痛點分析
vivo游戲是vivo用戶玩游戲的平臺，其主要產(chǎn)品形態(tài)是vivo游戲中心以及vivo游戲內(nèi)置懸浮球，它為用戶提供了找游戲，玩好游戲，找人一起玩游戲的價值。vivo游戲中心是vivo游戲的核心流量入口，因此游戲中心首頁就承擔了非常重要的角色。首頁的風格延續(xù)了好幾年，基礎樣式幾乎沒有什么變化，強調(diào)分發(fā)。隨著時間的發(fā)展，各種問題就慢慢突顯出來了。
雙塔ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
1.從2020年開始，互聯(lián)網(wǎng)流量見頂，分發(fā)提升困難，需要探索新方向，而應對新需求的時候研發(fā)周期過長。從需求評審到功能上線，灰度到全量，需要耗時一個月以上，運營效果往往低于預期。
2.核心用戶的關注點不同。MOBA玩家看畫面和平衡，傳奇玩家看游戲人數(shù)，消消樂玩家看玩法，且用戶對游戲福利活動的需求也是非常強烈。首頁列表中，重點信息無法突出，也無法給用戶帶來強烈的下載沖動。
3.任何一個游戲都是有生命周期的。在不同的階段，突出的重點是不一樣的。預約的時候可能突出這個游戲的畫風和畫質(zhì)，重點更新的時候可能突出的是新玩法。游戲中心首頁沒有相關的位置或者手段來突出這些信息。
4.無法快速響應運營或者開發(fā)者訴求。如果運營需要更換首頁跳轉(zhuǎn)的二級落地頁，或者響應開發(fā)者訴求搭建一個特殊專區(qū)的時候，都是需要開發(fā)的，現(xiàn)有功能無法快速支撐。
這幾個問題是表層的問題，透過現(xiàn)象看本質(zhì)，我們可以歸納出，游戲中心缺少了兩項基礎能力。一方面，游戲中心缺少靈活多樣，且能動態(tài)調(diào)整的組件化能力；另一方面，游戲中心缺少可視化，快速搭建頁面的能力?；谝陨贤袋c，結(jié)合行業(yè)前沿知識，筆者所在團隊商量決定，利用低代碼思想，打破原有秩序，重新搭建新平臺。
二、如何建設游戲中心低代碼平臺
大家可能會好奇，低代碼平臺一般都是通用性比較強的平臺，怎么能和業(yè)務屬性如此鮮明的游戲中心結(jié)合呢？那接下來筆者為大家一一道來。
低代碼平臺離不開組件化設計，那什么是組件化設計呢？組件化設計是指針對相同或者不同功能，性能，規(guī)格的產(chǎn)品，進行功能分析，設計出一系列的功能組件。通過組件的多樣選擇將產(chǎn)品客制化，以滿足不同的市場需求。由此可以推出，游戲中心組件化設計就是針對游戲中心進行功能分析，設計出一系列功能組件，通過組件的多樣化選擇，快速搭建出不同的頁面，以滿足不同用戶的需求。
那么，我們是怎么來定義游戲中心的組件呢？
在原有系統(tǒng)的基礎上，結(jié)合游戲中心app各個位置的形態(tài)以及未來定位，把游戲中心首頁按照橫向劃分，每一行細化為一個組件。雖然大家可能不太了解游戲中心，但是對于市面上大部分分發(fā)類的產(chǎn)品來說，它們每個頁面里面的UI樣式是系列化的，比如視頻樣式，圖片樣式等，變化比較多的是內(nèi)容，所以我們可以以行來定義組件。另一方面，組件粒度的粗細，和組件的靈活性成反向關系，但是和運營的配置能力成正向關系，即組件粒度越細，越基礎，那么組件的靈活度就越高，運營的配置配置成本也越高。所以，選擇什么粒度的基礎組件，是需要結(jié)合實際業(yè)務需求，綜合分析后確定的。不是粒度越細越好，也不是粒度越粗越好。
確定好組件的粒度后，我們通過一個例子來詳解拆分一下組件的構成。大家請看圖1，這是一個專題組件。其形式為左上是標題，右上是跳轉(zhuǎn)二級頁的按鈕，多個游戲橫向并列成一行，最下面是安裝按鈕。將這種組合形式抽象為一個多游戲并列（1*4）展示的基礎模板，基礎模板同時也叫元組件，那么就可以把這類基礎模板命名為專題元組件。運營希望該元組件可以配置標題，跳轉(zhuǎn)鏈接，行數(shù)和展示游戲個數(shù)。這些是靜態(tài)的基礎配置。同時，專題組件需要配置一個數(shù)據(jù)源，這個數(shù)據(jù)源決定專題里面游戲的內(nèi)容和展示順序，這個數(shù)據(jù)可以是運營配置的或者實時推薦的。例如，在推薦場景下，用戶發(fā)起請求的時候，可以由推薦實時返回，那么這就是動態(tài)數(shù)據(jù)。Banner同理。因此可以認為：組件是由元組件和數(shù)據(jù)構成的。
圖1
那么元組件是怎么定義的呢？在后臺，我們可以新增一個元組件，填寫完卡片編號名稱描述等信息后，再上傳圖片保存。這里的元組件卡片編號作為該組件的唯一標識，是有相應的業(yè)務含義，由該編號確定當前組件展示數(shù)據(jù)的格式，即通過編號確定處理數(shù)據(jù)的流程類。上傳圖片主要方面運營配置頁面。因為在頁面搭建過程中，運營配置多個組件的時候，后臺會實時顯現(xiàn)客戶端的效果。展示的組件圖片就是在此處上傳的。
圖2
配置完元組件的基礎信息后，在元組件配置管理的左邊，如圖3，通過編輯schema，右邊就會出現(xiàn)當前元組件能夠配置的標題，跳轉(zhuǎn)鏈接，行數(shù)以及單行游戲的個數(shù)。這些配置是運營在配置組件的時候可以動態(tài)配置的；配置完這些數(shù)據(jù)后，在頁面管理后臺，添加該類組件的時候，紅框中出現(xiàn)的就是我們能夠配置的基礎屬性了，如圖4。到這一步，元組件的配置就完成了。
圖3
圖4
接下來就是數(shù)據(jù)源的配置。在運營點擊數(shù)據(jù)選擇的時候（圖5），彈出的就是動態(tài)數(shù)據(jù)的配置，那這些數(shù)據(jù)是怎么來的呢？
我們需要從兩個維度來看數(shù)據(jù)：第一個，數(shù)據(jù)有哪些；第二個，數(shù)據(jù)怎么交互。我們從兩個角度來看數(shù)據(jù)有哪些。從數(shù)據(jù)類型角度劃分，有運營配置數(shù)據(jù)和系統(tǒng)自動數(shù)據(jù)。運營配置數(shù)據(jù)為運營人員為了達到某一個目的而手動配置或者干預的數(shù)據(jù)，而系統(tǒng)自動數(shù)據(jù)為從系統(tǒng)某一個源自動獲取的數(shù)據(jù)，不需要人工介入。從數(shù)據(jù)來源劃分，有內(nèi)部數(shù)據(jù)和外部數(shù)據(jù)。通過不同的數(shù)據(jù)類型和來源，我們切分為不同的調(diào)用方式，這樣能最大限度地保證系統(tǒng)的擴展性和維護性。
隨著業(yè)務的發(fā)展，平臺會不斷吸取其他業(yè)務數(shù)據(jù)，來豐富當前業(yè)務的形態(tài)，但是獲取外部數(shù)據(jù)的方式只有兩種：http和dubbo協(xié)議。通過這兩個協(xié)議的配合，能夠標準化獲取外部數(shù)據(jù)。我們說完了元組件和數(shù)據(jù)，那么他們是怎么綁定的呢？在后臺數(shù)據(jù)管理中，我們會按照某個運營目的，來確定一個組件的應用場景，比如專題組件的應用場景就是為用戶推薦某一類型的游戲集合。通過定義組件的應用場景，我們把元組件和數(shù)據(jù)綁定在一起。
整體過程如下：
- 確定組件的應用場景名和編號；
- 選擇一個或者多個元組件；
- 確定數(shù)據(jù)源類型，調(diào)用類型和數(shù)據(jù)業(yè)務方；
- 確定調(diào)用的http和dubbo接口。通過http接口，可以生成運營能夠配置的數(shù)據(jù)，即點擊選擇后彈出的列表，點擊選擇后，即可將數(shù)據(jù)綁定到組件上，如圖5；在用戶調(diào)用流程中，通過dubbo接口，利用后臺配置的數(shù)據(jù)，可以請求獲取到更加詳細的數(shù)據(jù)。
此時一個組件就配置完成了。
圖5
在前臺數(shù)據(jù)的調(diào)用方式中，使用了阿里的QLExpress。QLExpress由阿里的電商業(yè)務規(guī)則、表達式（布爾組合）、特殊數(shù)學公式計算（高精度）、語法分析、腳本二次定制等強需求而設計的一門動態(tài)腳本引擎解析工具。它的特性優(yōu)勢和運行原理可以在GitHub上找到，在此不贅述，感興趣的同學可以自行搜索。利用其弱類型腳本的特性，將運營配置的數(shù)據(jù)轉(zhuǎn)換成調(diào)用外部接口的參數(shù)，通過dubbo泛化調(diào)用技術，獲取到具體的數(shù)據(jù)。同時，還是利用弱類型腳本的特性，轉(zhuǎn)換返回結(jié)果，控制業(yè)務邏輯和數(shù)據(jù)范圍。采用QLExpress和dubbo泛化調(diào)用的方式，可以減少代碼開發(fā)，增加數(shù)據(jù)靈活性。
最后，來了解一下整個頁面的配置過程。前面講述到，元組件是最基礎的組件，通過元組件，我們配置一些基礎信息，并關聯(lián)一些動態(tài)數(shù)據(jù)，構成了一個組件。通過把多個組件拖拽到頁面上，就可以實現(xiàn)運營配置生成頁面的效果。同時，頁面也可以直接拖拽已經(jīng)配置好的組件，這就是一個組件被多個頁面引用的情況，實現(xiàn)了組件級的復用。在頁面之上，我們還引入了方案的概念。方案，即多個頁面的集合。通過頁面的組合，首頁可以實現(xiàn)多個頁面的展示，既能展示游戲中心的門戶，又能個性化運營。
如圖6，從下到上，通過數(shù)據(jù)和元組件，可以構成一個組件，通過多個組件的選擇，可以構成一個頁面，多個頁面構成一個方案。如圖7，從上到下，通過多層實驗框架，確定需要展示給用戶的方案。接下來，通過dmp用戶畫像，確定展示個性化的頁面。每一個頁面都是由若干個組件構成的。每個組件是由元組件和數(shù)據(jù)構成。
圖6
圖7
三、成果展示
羅馬不是一天建成的，游戲中心低代碼平臺也不是一蹴而就的。平臺20年就上線了，由于缺少運營場景，功能也不是很完善，能夠帶來的效益微乎其微，甚至內(nèi)部也產(chǎn)生過質(zhì)疑，是不是不值得花這么多的時間精力建設平臺，但經(jīng)過時間的沉淀，游戲中心低代碼平臺的效果愈發(fā)明顯。
首先，研發(fā)流程和原先不一樣了。當我們在新增/修改組件的時候，客戶端同學通過flutter等動態(tài)化技術，完成新組件的開發(fā)修改，并且在后臺上傳flutter的更新包或者差分包。
服務器同學需要在后臺配置元組件的信息，配置組件應用場景，綁定元組件和數(shù)據(jù)關系，就可以生成運營可以配置的組件。運營配置完組件，頁面，方案，點檢完畢審核通過后就可以上線了，如圖8。
圖8
其次，研發(fā)效率提升了。大家注意到，最大的一個變化是，客戶端不需要發(fā)版了。在一些特殊場景下，服務器也不需要開發(fā)。對比原先的研發(fā)流程，效率發(fā)生了質(zhì)的飛越。針對不同的角色，提升的效率是不一樣的；對于客戶端來說功能全量上線周期可縮短15天以上，有較高的容錯性，對于服務器來說，開發(fā)效率提升4倍以上，對于測試來說，無需回歸老版本，測試效率提升30%-50%；對于運營來說，可視化的操作降低30%的學習成本，提升10%的配置效率。
最后，項目周期縮短了。原先如果運營做一個功能，首先得把需求提給產(chǎn)品（其實在提需求之前，還有一個需求討論的過程，非需求評審），再進行需求評審，評審完畢后需要根據(jù)各個需求的優(yōu)先級進行排序。而此類需求由于效果不明顯，且論證數(shù)據(jù)不好收集，往往其優(yōu)先等級就比較低。需求評審完畢后，還需要策劃評審，概要設計評審等等諸多流程，上線完畢還需要灰度一周，有了上線報告之后才可以全量。但是，有了低代碼平臺后，流程就沒有這么復雜了。最簡單的流程，無需更改組件，運營自己就能操作。還有一些簡單的場景，服務器修改配置就能完成組件的修改。最復雜的就是全新場景，但由于之前的基礎在，開發(fā)效率也是非常的高。整體流程至少可以縮短為原來的1/4。接下來用一個例子來說明一下。
圖9
圖10
四、未來展望
游戲中心低代碼平臺的建設標準，和通常意義上低代碼平臺的建設存在差異。游戲中心低代碼平臺由“游戲中心業(yè)務”衍生，慢慢演變到可以適配vivo生態(tài)內(nèi)分發(fā)類app的終端解決方案。這符合我們的業(yè)務發(fā)展，也為低代碼的演變提供了養(yǎng)分。通過不斷的適配和演變，我們希望能夠?qū)⒌痛a的解決方案普惠安卓生態(tài)。因此，在未來的建設思路上，我們的目標是能夠解放生產(chǎn)力，提升用戶體驗，做最好用的安卓低代碼平臺。
五、總結(jié)
低代碼的概念最近很火，爭議也很大。有人認為以后“人人都是程序員”，也有人認為是新瓶裝舊酒。但作為技術人，最重要的還是通過技術解決業(yè)務問題，驅(qū)動業(yè)務發(fā)展。游戲中心低代碼平臺旨在提高開發(fā)效率，幫助業(yè)務取得更好的結(jié)果。未來，我們也會投入更多的精力優(yōu)化系統(tǒng)，不斷為用戶創(chuàng)造驚喜，為行業(yè)帶來革新。
本文標題：vivo游戲中心低代碼平臺的提效秘訣
新聞來源：http://m.fisionsoft.com.cn/article/coieihg.html
