vivo TWS Air開箱體驗(yàn)：真輕 臻好聽
在vivo S15系列新機(jī)的發(fā)布會(huì)上，vivo的最新款真無線藍(lán)牙耳機(jī)vivo TWS Air也一同發(fā)布，本次就這款耳機(jī)新品給大家?guī)硪粋€(gè)簡(jiǎn)單的分享。外包裝盒上，vivo TWS Air保持了vivo自家產(chǎn)
在全公司針對(duì)業(yè)務(wù)效率提升有嚴(yán)格要求的背景下，游戲技術(shù)中臺(tái)一直在思考，如何提高全球發(fā)行效率？
在游戲技術(shù)中臺(tái)的眾多產(chǎn)品當(dāng)中，SDK是賦能游戲研發(fā)的核心產(chǎn)品之一，其核心能力包括賬號(hào)、交易、合規(guī)（實(shí)名、防沉迷），以及社交、營(yíng)銷等能力。現(xiàn)有的SDK群存在22種類型，在過往的高速發(fā)展和歷史慣性中，SDK群劃分的維度主要有3個(gè)：
不同發(fā)行品牌、地區(qū)、設(shè)備，存在相同定位的API，但是定義和標(biāo)準(zhǔn)不同，導(dǎo)致在不同合作模式（主要分為：獨(dú)家代理、聯(lián)合運(yùn)營(yíng)；獨(dú)家代理簡(jiǎn)稱獨(dú)代，聯(lián)合運(yùn)營(yíng)分為兩種，聯(lián)運(yùn)和UO，UO為Union Operation的縮寫特指在獨(dú)代的前提下，主動(dòng)與第三方下載渠道合作；聯(lián)運(yùn)特指在沒有獨(dú)家代理的前提下，第三方與bilibili的合作。），研發(fā)需要重復(fù)對(duì)接多種類型SDK和服務(wù)端API；
圖片
藍(lán)色部分表示游戲研發(fā)需要感知的SDK和服務(wù)端API類型。
另一方面，發(fā)行技術(shù)中臺(tái)建設(shè)早期秉承業(yè)務(wù)優(yōu)先思維，專注于各領(lǐng)域基礎(chǔ)能力建設(shè)，各系統(tǒng)間缺少聯(lián)動(dòng)依賴運(yùn)營(yíng) SOP 銜接，伴隨發(fā)行游戲數(shù)量增多，效率問題逐步呈現(xiàn)。為解決這些問題，優(yōu)化全球發(fā)行效率，我們期望為研發(fā)提供一站化體驗(yàn)，從聯(lián)動(dòng)性、易用性、自動(dòng)化等多角度優(yōu)化當(dāng)前 SDK 與后臺(tái)系統(tǒng)，故啟動(dòng)了 ONE SDK / API 項(xiàng)目。
當(dāng)我們完成ONE SDK/API項(xiàng)目后，以游戲《Kenny: 和平衛(wèi)士》發(fā)行計(jì)劃為例，從以下3個(gè)維度：“全球發(fā)行平均接入時(shí)間”、“游戲研發(fā)的認(rèn)知范圍”、“游戲研發(fā)重復(fù)開發(fā)次數(shù)”，取得的工作成果現(xiàn)展示如下：
圖片
用5組數(shù)據(jù)度量，以對(duì)比ONE SDK/API價(jià)值
圖片
1、全球發(fā)行平均接入時(shí)間：從優(yōu)化前的60天縮短為15天，效率提升了4倍；
2、游戲研發(fā)的認(rèn)知范圍：從游戲研發(fā)需要認(rèn)知的參數(shù)數(shù)量，以及實(shí)際需要管理參數(shù)兩個(gè)維度度量，其概念認(rèn)知規(guī)模至少降低了90%；
3、游戲研發(fā)重復(fù)開發(fā)次數(shù)：從SDK API接入次數(shù)和服務(wù)端API接入次數(shù)度量，其重復(fù)勞動(dòng)規(guī)模至少降低了75%。
分析
基于以上背景描述，本節(jié)重點(diǎn)描述，我們對(duì)于全球發(fā)行的理解，以及對(duì)于目標(biāo)和行動(dòng)路線的思考過程。
API標(biāo)準(zhǔn)未統(tǒng)一和孤島系統(tǒng)是全球發(fā)行過程中，比較容易識(shí)別的兩個(gè)痛點(diǎn)。圍繞業(yè)務(wù)效率提升這個(gè)大目標(biāo)，從增效這個(gè)角度切入，在本次升級(jí)和實(shí)踐的行動(dòng)路線應(yīng)該是什么樣的？結(jié)合本次實(shí)踐，我們還可以挖掘的內(nèi)容還有哪些？值得在項(xiàng)目初期認(rèn)真思考。
在整體的思考過程中，我們基于SimonO.Sinek的黃金圈法則模型來拆解目標(biāo)，基于目標(biāo)尋找方法，建立行動(dòng)路線。首先，簡(jiǎn)單介紹一下黃金圈法則。
圖片
黃金圈法則是一個(gè)輔助思考和決策的方法，其思考過程主要包括三個(gè)層次：為什么（Why）、方法（How）和行動(dòng)（What）。
在確定以增效為大目標(biāo)的前提下，我們側(cè)重通過架構(gòu)設(shè)計(jì)的優(yōu)化，流程調(diào)整，兩個(gè)方面去提升全球發(fā)行過程效率。參考阿里巴巴對(duì)于研發(fā)效能的定義公式：個(gè)體效率 x 協(xié)同效率 x 價(jià)值 = 研發(fā)效能。MBA知識(shí)庫(kù)，對(duì)于效能和效率的定義有很大的區(qū)別，本文重點(diǎn)把”效“論述為效率。能夠提升研發(fā)效能的影響變量有三個(gè)，其中價(jià)值這一選項(xiàng)，更多的是由業(yè)務(wù)能力范圍決定，本次實(shí)踐中并無業(yè)務(wù)增量，因此不是重點(diǎn)分析討論的方向。基于公式思維，本次實(shí)踐的目標(biāo)可以拆解為兩個(gè)突破方向，提升個(gè)體效率和協(xié)同效率。
接下來需要思考影響個(gè)體效率和協(xié)同效率的方法，即黃金圈法則How的問題。
分析個(gè)體效率，首先需要明確個(gè)體的指向是誰？參與全球發(fā)行這個(gè)過程的主要個(gè)體，主要包括3類：游戲研發(fā)、發(fā)行平臺(tái)運(yùn)營(yíng)、發(fā)行平臺(tái)技術(shù)。這三類個(gè)體的在發(fā)行過程中，影響其個(gè)體效率的主要因素如下：
基于以上三類主要個(gè)體效率影響分析，其中共性部分在于領(lǐng)域知識(shí)的認(rèn)知和解釋成本，其次是架構(gòu)設(shè)計(jì)的些許問題，比如參數(shù)管理分散，導(dǎo)致的不必要復(fù)雜度暴露。這些問題經(jīng)過整合，發(fā)現(xiàn)本質(zhì)是軟件工程領(lǐng)域的大型軟件系統(tǒng)的復(fù)雜度管理難題。
著名的計(jì)算機(jī)科學(xué)家Fred Brooks在《人月神話》中將軟件服務(wù)復(fù)雜度分為兩個(gè)大類：
相對(duì)來說，全球發(fā)行基礎(chǔ)的業(yè)務(wù)能力，比如賬號(hào)、交易、合規(guī)、營(yíng)銷等，可理解為在接入過程中的內(nèi)在復(fù)雜度，對(duì)這些領(lǐng)域知識(shí)的學(xué)習(xí)是必要的認(rèn)知成本。對(duì)于領(lǐng)域知識(shí)的組織和定義方式、文檔設(shè)計(jì)、架構(gòu)設(shè)計(jì)，可理解為系統(tǒng)的外在復(fù)雜度。針對(duì)軟件復(fù)雜度管理的課題，眾多軟件工程領(lǐng)域的大師以及行業(yè)前輩有過精彩的論述，在本節(jié)不做拓展說明。基于復(fù)雜度管理的常見策略，經(jīng)過分析后，我們決定從以下幾個(gè)方面著手控制全球發(fā)行的復(fù)雜度，試圖提升個(gè)體效率。
針對(duì)協(xié)同效率，我們重點(diǎn)從參與全球發(fā)行過程中3類個(gè)體，以及關(guān)聯(lián)個(gè)體的系統(tǒng)和流程處分析可優(yōu)化空間。
圖片
1、游戲研發(fā)與發(fā)行技術(shù)：二者交互連接的產(chǎn)品是對(duì)接文檔、SDK、API，以上產(chǎn)品作為發(fā)行領(lǐng)域知識(shí)的展示窗口，一定程度上影響游戲研發(fā)的接入效率。核心領(lǐng)域術(shù)語的對(duì)齊對(duì)于溝通效率的價(jià)值是顯而易見的。其次、現(xiàn)有的文檔主次和業(yè)務(wù)邏輯表達(dá)不夠清晰直觀，也會(huì)影響研發(fā)對(duì)于SDK和API的理解，這會(huì)帶來多次溝通確認(rèn)，影響效率的同時(shí)，也影響了工作體驗(yàn)和游戲發(fā)行技術(shù)品牌。
2、平臺(tái)技術(shù)與平臺(tái)運(yùn)營(yíng)之間，在全球發(fā)行過程中的連接產(chǎn)品主要集中在3個(gè)方面，全球發(fā)行后臺(tái)游戲入庫(kù)、研發(fā)母包到渠道打包系統(tǒng)、接入?yún)?shù)管理。首先游戲入庫(kù)是一個(gè)復(fù)雜的過程，這一塊的自動(dòng)化還有提升空間。其次、在發(fā)行過程中全球發(fā)行后臺(tái)與渠道打包系統(tǒng)并未完全融合，會(huì)導(dǎo)致存在部分能力的重復(fù)建設(shè)，以及人為連接帶來的工作量。
3、游戲研發(fā)與發(fā)行平臺(tái)運(yùn)營(yíng)之間，主要的連接部分在于接入?yún)?shù)管理、接入答疑、以及項(xiàng)目管理。現(xiàn)階段接入?yún)?shù)類型眾多，在不同的地區(qū)、合規(guī)政策、依賴資源等各種背景疊加下，經(jīng)過整理后，一款待全球發(fā)行的接入?yún)?shù)可能多大300+，這些紛繁復(fù)雜參數(shù)背后的都是基于人力管理。其次、接入過程答疑的主要影響因素在于對(duì)接文檔、SDK、API的設(shè)計(jì)，這也是可以優(yōu)化的方向。
基于以上分析，我們決定從以下幾個(gè)方面著手，提升協(xié)同效率：
a. 多套舊版發(fā)行管理系統(tǒng)聚合統(tǒng)一，基于全球發(fā)行游戲項(xiàng)目與發(fā)行計(jì)劃建設(shè)統(tǒng)一的全球發(fā)行管理系統(tǒng)。
b. 基于全球發(fā)行管理系統(tǒng)，統(tǒng)一、規(guī)范管理發(fā)行計(jì)劃的各類參數(shù)/配置項(xiàng)；
c. 渠道打包系統(tǒng)架構(gòu)升級(jí)，依托參數(shù)統(tǒng)一管理支持Android全球渠道打包，不僅局限于自研游戲在大陸安卓渠道的聯(lián)運(yùn)業(yè)務(wù)。
基于黃金圈法則Why和How的分析，最后我們拆解制定的行動(dòng)路線如下：
圖片
基于以上背景和目標(biāo)，整體項(xiàng)目挑戰(zhàn)將來源于以下4個(gè)方面：
1、標(biāo)準(zhǔn)化：多套異構(gòu)API，如何統(tǒng)一規(guī)格，并降低研發(fā)的理解成本，同時(shí)對(duì)外又保持較高的水準(zhǔn)；
2、自動(dòng)化：如何屏蔽不同地區(qū)、設(shè)備、合作模式下的接入復(fù)雜度，提高接入效率；
3、兼容性：游戲業(yè)務(wù)在過去幾年的高速發(fā)展中，發(fā)行業(yè)務(wù)逐漸搭建了一套功能完善且復(fù)雜度較高的平臺(tái)級(jí)應(yīng)用架構(gòu)。隨著組織的擴(kuò)張與分工的精細(xì)化，對(duì)當(dāng)前平臺(tái)架構(gòu)具有全盤把握者較少，如何做到整體提效的同時(shí)，兼容現(xiàn)有架構(gòu)本身，其難度巨大。
4、影響面：游戲底層模型的變更，幾乎牽涉到發(fā)行技術(shù)中臺(tái)所有的技術(shù)團(tuán)隊(duì)和發(fā)行業(yè)務(wù)團(tuán)隊(duì)；部分新概念的提出，需要達(dá)成平臺(tái)級(jí)的概念共識(shí)。
bilibili多年以來全球發(fā)行的業(yè)務(wù)經(jīng)驗(yàn)，產(chǎn)生了較多的的領(lǐng)域名詞和術(shù)語。如果在發(fā)行平臺(tái)內(nèi)部不能做到核心術(shù)語的統(tǒng)一，這其中的溝通和設(shè)計(jì)復(fù)雜度可想而知，更何況大多數(shù)時(shí)候，我們需要向游戲研發(fā)傳達(dá)相關(guān)概念和設(shè)計(jì)細(xì)節(jié)。即使對(duì)于一個(gè)在bilibili國(guó)內(nèi)發(fā)行平臺(tái)有不少工作經(jīng)驗(yàn)的業(yè)務(wù)研發(fā)同學(xué)，理解什么是”無標(biāo)“和”賬號(hào)域“已是難事，更何況各種概念之間的關(guān)系。因此，整理領(lǐng)域核心術(shù)語，及其之間的邏輯關(guān)系是執(zhí)行的基礎(chǔ)。經(jīng)整理設(shè)計(jì)后的核心概念分層如下圖：
圖片
常見核心概念主要分為4層：
發(fā)行地區(qū)
常見的劃分方式是以物理地區(qū)劃分為主，主要區(qū)為國(guó)內(nèi)大陸地區(qū)、港澳臺(tái)（中國(guó)）、東南亞、歐美等等；
發(fā)行品牌
中國(guó)大陸地區(qū)常用品牌為bilibili、白板、代號(hào)D，港澳臺(tái)和海外常用品牌為代號(hào)K、bilibili、以及白板（也稱“無標(biāo)”）；
下載渠道
全球發(fā)行過程中提供下載能力的渠道，比如：國(guó)內(nèi)bilibili提供安卓游戲下載，Apple Store 提供IOS游戲下載，國(guó)內(nèi)的UO渠道目前有70+，海外重點(diǎn)Google Play，Apple Store，Mycard，One Store等等；
賬號(hào)域
海外架構(gòu)中依賴的概念，賬號(hào)域決定了應(yīng)用部署、數(shù)據(jù)隔離等需求場(chǎng)景，通常和發(fā)行地區(qū)的法律法規(guī)相關(guān)。
Martin Flower在他的演講和著作中，多次強(qiáng)調(diào)命名的重要性，認(rèn)為好的命名是編寫高質(zhì)量軟件的關(guān)鍵因素之一。他認(rèn)為好的命名實(shí)踐應(yīng)該具備的特質(zhì)是：清晰直觀、目的明確、風(fēng)格統(tǒng)一。有些同學(xué)可能會(huì)認(rèn)為這是自然而然的事情，但是對(duì)于一個(gè)演進(jìn)了多年的大型系統(tǒng)來說這絕非必然。統(tǒng)一且直觀命名，符合直覺和經(jīng)驗(yàn)對(duì)于學(xué)習(xí)效率的價(jià)值是巨大的。
圖片
基于以上實(shí)踐特質(zhì)，結(jié)合統(tǒng)一的領(lǐng)域術(shù)語和詞匯，我們建立的URL PATH命名約束簡(jiǎn)潔示意如下：
圖片
最終我們的PATH如下：/one/user/session.verify、/one/trade/order.query、/one/security/censor
圖片
1、明確應(yīng)用邊界：基于領(lǐng)域驅(qū)動(dòng)應(yīng)用分層模型，將原有各子領(lǐng)域單獨(dú)對(duì)外提供服務(wù)的API，統(tǒng)一收斂到領(lǐng)域服務(wù)，對(duì)外通過應(yīng)用服務(wù)暴露API與游戲研發(fā)交互，統(tǒng)一收口。同時(shí)解決部分業(yè)務(wù)需求評(píng)審?fù)瓿珊螅a寫在哪里的問題。
2、統(tǒng)一管理ONE API：統(tǒng)一的ONE API代碼倉(cāng)庫(kù)，對(duì)于接口的定義，直接依賴Jar包，防止在后續(xù)長(zhǎng)期迭代過程中的”走樣“。
ONE SDK設(shè)計(jì)遵循依賴反轉(zhuǎn)（Dependency inversion principle）原則，通過ONE SDK抽象定義全球發(fā)行背景下的API接口。
ONE SDK通過適配層兼容現(xiàn)有的SDK群，達(dá)成能力復(fù)用，同時(shí)實(shí)現(xiàn)ONE SDK與SDK群在過渡期的共存。
1.2.3.1、ONE SDK 分包策略
圖片
1、ONE Android SDK以aar架包，ONE iOS SDK以framework的形式提供給游戲研發(fā)。
2、Android按照各個(gè)業(yè)務(wù)差別劃分為7個(gè)子aar。其中ONE SDK Main Lib和ONE SDK BaseLib為核心組件，包含核心登錄和支付功能，游戲必須接入。剩余的5個(gè)的AAR為選接項(xiàng)。
3、iOS按照業(yè)務(wù)區(qū)別以拆分頭文件的形式將功能劃分為5個(gè)模塊，同樣的ONE SDK Main Lib作為核心組件，包含核心登錄和支付功能，游戲必須接入。其他為選接項(xiàng)。
4、ONE SDK以多aar和多頭文件形式提供，避免游戲接入冗余業(yè)務(wù)組件，降低了SDK項(xiàng)目耦合性，提高了游戲代碼的效率。
5、在實(shí)際使用過程中，游戲可根據(jù)自己的發(fā)行計(jì)劃和實(shí)際需要使用的業(yè)務(wù)功能，選擇接入對(duì)應(yīng)的aar和iOS頭文件到游戲中。
舉個(gè)例子：a 游戲只發(fā)行國(guó)內(nèi)B服渠道且只有登錄和支付功能。則只需接入ONE SDK Main Lib和ONE SDK BaseLib兩個(gè)aar包即可實(shí)現(xiàn)發(fā)行需求。其余的aar則不需要接入項(xiàng)目。b 游戲發(fā)行渠道為國(guó)內(nèi)B服渠道和海外Google渠道。需要使用登錄和支付功能、谷歌積分兌換功能，則需接入ONE SDK Main Lib和ONE SDK BaseLib、ONE SDK Google Ext 3個(gè)aar包。其余的aar不需要接入項(xiàng)目。
1.2.3.2、整體架構(gòu)設(shè)計(jì)
圖片
1、ONE SDK在現(xiàn)有海外發(fā)行SDK、渠道發(fā)行SDK、B服發(fā)行SDK基礎(chǔ)上，對(duì)現(xiàn)有的業(yè)務(wù)進(jìn)行了規(guī)劃與統(tǒng)一，形成了統(tǒng)一的全球發(fā)行業(yè)務(wù)接口。全球發(fā)行業(yè)務(wù)接口主要分為2部分。
a、各個(gè)發(fā)行SDK的獨(dú)有的業(yè)務(wù)，如海外Google渠道的商品積分兌換業(yè)務(wù)、B服發(fā)行SDK的獲取B站好友關(guān)系業(yè)務(wù)等，保留了原有的接口形式對(duì)外提供，降低cp接入時(shí)的理解難度和接入復(fù)雜度。
b、各個(gè)發(fā)行SDK的共有的業(yè)務(wù)，如登錄、支付等，在現(xiàn)有業(yè)務(wù)SDK接口基礎(chǔ)上對(duì)接口參數(shù)取并集，抽象出涵蓋所有渠道的業(yè)務(wù)需求的全球發(fā)行業(yè)務(wù)接口，抹平各個(gè)渠道的業(yè)務(wù)差異性，保證cp一次接入全球通用發(fā)行。
2、根據(jù)發(fā)行計(jì)劃的不同，游戲的使用場(chǎng)景不同。將統(tǒng)一的全球發(fā)行業(yè)務(wù)接口對(duì)外提供形式上進(jìn)行了包體拆分。見上文1.2.3.1、ONE SDK 分包策略。提供了 “聚合標(biāo)準(zhǔn)發(fā)行模型 + 支持高自由度擴(kuò)展”的接入模式。
3、ONE SDK通過對(duì)外的標(biāo)準(zhǔn)接口aar、iOS頭文件和Adapter適配器，將游戲的意圖轉(zhuǎn)發(fā)到具體的業(yè)務(wù)渠道SDK。
a、ONE SDK抽象定義并對(duì)外提供了全球發(fā)行各個(gè)業(yè)務(wù)接口，并且只是業(yè)務(wù)接口，不包含任何具體的業(yè)務(wù)實(shí)現(xiàn)。隔離了游戲和具體業(yè)務(wù)渠道間的耦合。
b、Adapter適配器能夠?qū)⒂螒蛲ㄟ^標(biāo)準(zhǔn)業(yè)務(wù)接口發(fā)出業(yè)務(wù)意圖轉(zhuǎn)發(fā)給各個(gè)具體的業(yè)務(wù)渠道SDK。起到了承上啟下的作用。完美的適配并支持了所有的現(xiàn)有發(fā)行渠道SDK。
c、游戲只需要調(diào)用對(duì)應(yīng)的業(yè)務(wù)接口，就可以實(shí)現(xiàn)對(duì)應(yīng)的業(yè)務(wù)功能。游戲無需關(guān)心各業(yè)務(wù)在各渠道上的差異，具體的業(yè)務(wù)功能實(shí)現(xiàn)由Adapter適配器轉(zhuǎn)發(fā)給具體的發(fā)行渠道SDK，并由具體的發(fā)行渠道SDK完成業(yè)務(wù)功能。
困境1：
一個(gè)自研游戲或者獨(dú)家代理的外部游戲要進(jìn)行全球發(fā)行，和發(fā)行平臺(tái)第一個(gè)協(xié)作就是平臺(tái)接入。全球發(fā)行工作接入階段需要涉及的老版發(fā)行管理系統(tǒng)就有4個(gè)，分別國(guó)內(nèi)游戲發(fā)行管理系統(tǒng)(主要負(fù)責(zé)B站游戲中心渠道、iOS渠道發(fā)行管理)、渠道發(fā)行管理系統(tǒng)(國(guó)內(nèi)安卓渠道發(fā)行管理,例如華為、小米、OPPO）、海外BILI游戲發(fā)行管理系統(tǒng)(海外發(fā)行管理,海外Google/iOS、Mycard、ONEStore)，海外K品牌游戲發(fā)行管理系統(tǒng)。而其他在非接入階段大大小小的管理系統(tǒng)，甚至多達(dá)十幾個(gè)，包括渠道打包、BI系統(tǒng)、活動(dòng)系統(tǒng)、包管理等等。
由于歷史上各個(gè)管理系統(tǒng)可能由不同的團(tuán)隊(duì)負(fù)責(zé)，沒有統(tǒng)籌治理，導(dǎo)致系統(tǒng)間一些相同相似業(yè)務(wù)模型概念對(duì)不齊，業(yè)務(wù)同學(xué)理解使用成本高，最終結(jié)果是很多管理系統(tǒng)只有技術(shù)人員才會(huì)才敢使用。
困境2：
同一款游戲在接入安卓和iOS時(shí)，需要感知的是兩套接入?yún)?shù)，即兩個(gè)game_id。在獨(dú)代游戲情況下，如果存在聯(lián)運(yùn)的業(yè)務(wù)，其所感知的游戲參數(shù)需要三套及以上，隨著發(fā)行品牌和地區(qū)的擴(kuò)展，研發(fā)需要感知的發(fā)行參數(shù)呈指數(shù)遞增。在各種對(duì)接過程中，特別是同時(shí)對(duì)接多SDK甚至多地區(qū)的游戲，多套game_id接入?yún)?shù)差異導(dǎo)致的接入問題對(duì)CP和平臺(tái)技術(shù)有很大困擾，需要花費(fèi)不少的時(shí)間精力去排查問題。
既然是同一個(gè)游戲，同一個(gè)CP，同一個(gè)發(fā)行平臺(tái)，能否實(shí)現(xiàn)一套參數(shù)、一個(gè)后臺(tái)、一次接入的小目標(biāo)？
困境3：
由于渠道多、功能模塊多，接入過程中涉及的大量接入?yún)?shù)/配置項(xiàng)管理也是一個(gè)難題。
以海外Google包為例，內(nèi)部包含Google/iOS登錄，多個(gè)社交分享(facebook/twitter等)、多套市場(chǎng)歸因營(yíng)銷相關(guān)服務(wù)（firebase/appsflyer/adjust）、AIHELP客服等眾多模塊，單包涉及的相關(guān)參數(shù)超過40+。這些參數(shù)來源多個(gè)平臺(tái)，由平臺(tái)運(yùn)營(yíng)發(fā)出申請(qǐng)，由市場(chǎng)、項(xiàng)管、客服等多個(gè)部門去對(duì)應(yīng)平臺(tái)生成，最終可能分多次提供給研發(fā)。其中存在大量的secret/key相關(guān)參數(shù)名，無論是平臺(tái)運(yùn)營(yíng)還是研發(fā)理解心智成本非常大。
圖片
而目前僅一些核心的后端賬號(hào)支付模塊參數(shù)才會(huì)在統(tǒng)一在后臺(tái)管理，大量?jī)H客戶端依賴的參數(shù)，還在依賴人力管理。參數(shù)的流轉(zhuǎn)仍然在依賴傳統(tǒng)的郵件流，流轉(zhuǎn)過程中可能會(huì)產(chǎn)生多個(gè)副本，一旦發(fā)生變更，需要多方確認(rèn)調(diào)整。
整套參數(shù)管理流程不僅影響接入溝通效率，還存在很大規(guī)范問題與安全隱患。
那全球發(fā)行系統(tǒng)如何打破以往僵局？
首先很自然的想法是進(jìn)行多系統(tǒng)聚合。這些發(fā)行系統(tǒng)核心的職責(zé)，本質(zhì)就是安全合規(guī)的將游戲分發(fā)到不同地區(qū)不同渠道。不管是國(guó)內(nèi)BILI游戲中發(fā)行、iOS發(fā)行、國(guó)內(nèi)渠道發(fā)行、海外發(fā)行本質(zhì)做的是一致的業(yè)務(wù)，但是分散的系統(tǒng)必然會(huì)出現(xiàn)業(yè)務(wù)概念的分歧。
那這些系統(tǒng)本質(zhì)區(qū)別在哪里呢？核心點(diǎn)在于支持的【游戲、地區(qū)、品牌、渠道】不同。【地區(qū)】【品牌】【渠道】是前面【統(tǒng)一領(lǐng)域核心術(shù)語】提到的重要但是卻也是非常簡(jiǎn)單、直觀的概念。而【游戲】模型的定義是一個(gè)難點(diǎn)。
嗶哩嗶哩游戲業(yè)務(wù)，以最開始的聯(lián)運(yùn)業(yè)務(wù)開始，隨著發(fā)展的壯大，逐漸搭建出多地區(qū)、多品牌的全球發(fā)行模型。在業(yè)務(wù)底層的建模上，對(duì)于游戲的定義主要分為兩層。
1、game：最底層承擔(dān)的職責(zé)主要包括：游戲?qū)拥腟DK信息、接入秘鑰、支付參數(shù)、渠道上架、APP合規(guī)、運(yùn)營(yíng)控制等等。每個(gè)game_id對(duì)應(yīng)研發(fā)需要感知的接入?yún)?shù)。
2、game_base：基于game之上，構(gòu)建的抽象實(shí)體，其職責(zé)是承接游戲?qū)τ谄放啤⒌貐^(qū)的定義。
其層次和主要職責(zé)示意如下：
圖片
在現(xiàn)有的架構(gòu)設(shè)計(jì)中，對(duì)于一款游戲的實(shí)際定義，是基于對(duì)接的SDK來區(qū)分的，每套SDK對(duì)應(yīng)一套參數(shù)。隨著多品牌、多地區(qū)的發(fā)行策略的落地，研發(fā)需要感知的發(fā)行參數(shù)呈幾何遞增。
實(shí)現(xiàn)“一次接入，全球發(fā)行”，需要囊括所有的品牌和地區(qū)，因此在現(xiàn)有的架構(gòu)定義中，不管是現(xiàn)有的game_id，還是抽象的game_base_id都無法承擔(dān)全球游戲項(xiàng)目的邏輯職責(zé)。
對(duì)外，要實(shí)現(xiàn)“一次接入，全球發(fā)行”的目標(biāo)，勢(shì)必不能再將多套參數(shù)的復(fù)雜度暴露。對(duì)內(nèi)，由于舊游戲模型已經(jīng)應(yīng)用到游戲發(fā)行技術(shù)中的各個(gè)團(tuán)隊(duì)和項(xiàng)目，如果調(diào)整現(xiàn)有架構(gòu)中對(duì)于游戲的定義方式，勢(shì)必影響面巨大，其范圍牽涉整個(gè)游戲發(fā)行技術(shù)中臺(tái)，大面積的變更甚至導(dǎo)致業(yè)務(wù)迭代阻塞。
因此，基于開閉原則，我們?cè)谠杏螒蚰Ｐ突A(chǔ)上做了一些拓展，引入的全球游戲項(xiàng)目GlobalGame的概念，基本不修改原有模型。
圖片
對(duì)外，游戲研發(fā)對(duì)于全球接入?yún)?shù)的感知，將以全球游戲項(xiàng)目(global_game)為基準(zhǔn)，而不是每個(gè)game_id一套；對(duì)內(nèi)，各業(yè)務(wù)部門仍然現(xiàn)有邏輯基本無需改造，當(dāng)然也可以在合適的時(shí)機(jī)去適配全球游戲發(fā)行項(xiàng)目。
當(dāng)我們決定以global_game_id為首，解決全球發(fā)行過程中游戲研發(fā)對(duì)于一次接入的參數(shù)問題，接下來需要面對(duì)的問題是：如何讓發(fā)行技術(shù)平臺(tái)對(duì)于游戲的定義從game_id無縫切換到global_game_id，實(shí)現(xiàn)低成本的平滑過渡？
在這個(gè)問題上，我們的思考方向有兩個(gè)：
其一、SDK到發(fā)行平臺(tái)服務(wù)端，游戲在架構(gòu)初期就設(shè)計(jì)了ONE SDK到SDK群的適配層，在適配層實(shí)現(xiàn)global_game_id到game_id的映射，因此極大的簡(jiǎn)化了現(xiàn)有SDK群到服務(wù)端的工作量 ，同時(shí)保證了在未來研發(fā)繼續(xù)使用現(xiàn)有SDK和使用ONE SDK同時(shí)對(duì)接的可能。
其二、游戲研發(fā)服務(wù)端到發(fā)行平臺(tái)服務(wù)端（包含：發(fā)行服務(wù)端、數(shù)據(jù)、社區(qū)、營(yíng)銷），在無法感知game_id的情況下，與發(fā)行平臺(tái)服務(wù)端對(duì)接的過程中，使用以全球游戲項(xiàng)目Id為首的接入?yún)?shù)與平臺(tái)服務(wù)端對(duì)接。基于分層架構(gòu)，應(yīng)用服務(wù)層（ONE API BFF）接收到全球游戲項(xiàng)目Id為首的請(qǐng)求參數(shù)后，無法實(shí)現(xiàn)對(duì)于下游領(lǐng)域服務(wù)的路由調(diào)用。比如：手游、端游、聯(lián)運(yùn)各自的發(fā)行領(lǐng)域服務(wù)，在原本基于業(yè)務(wù)做了領(lǐng)域服務(wù)垂直拆分的情況下，ONE API BFF如何與下游領(lǐng)域服務(wù)“交互”，變成了平臺(tái)服務(wù)端架構(gòu)兼容的直接問題。同時(shí)，這個(gè)問題在其他的發(fā)行業(yè)務(wù)團(tuán)隊(duì)同樣會(huì)面臨，比如交易、數(shù)據(jù)、廣告、游戲中心、活動(dòng)營(yíng)銷等。
分析第二個(gè)細(xì)分問題，其本質(zhì)是原來粒度較細(xì)的游戲定義方式（簡(jiǎn)稱game_id）在優(yōu)化后的對(duì)接過程中，被收斂為全球游戲項(xiàng)目Id之后，該怎么與現(xiàn)有的發(fā)行平臺(tái)架構(gòu)兼容的問題。我們將這個(gè)問題用公式表達(dá)如下：游戲接入Id（game_id） = 全球游戲項(xiàng)目Id (global_game_id) + 其他？
在這個(gè)環(huán)節(jié)我們一開始想到的解決方式有如下三個(gè)，下文簡(jiǎn)單歸納對(duì)比方案影響面和優(yōu)缺點(diǎn)，以及我們最終在方案選型中的一些思考。
圖片
經(jīng)過分析討論，方案一最終被選擇的主要原因在于概念的統(tǒng)一和明確，基于上文的核心術(shù)語并未再做擴(kuò)展。理解成本在這次討論中被用作重要的參考維度，其主要原因也是由于業(yè)務(wù)屬性所決定，在全球發(fā)行過程中，鏈路較長(zhǎng)，涉及領(lǐng)域知識(shí)很多，在沒有必要的情況下，我們奉行的原則是Less is more。做到不違反直覺，降低外在系統(tǒng)復(fù)雜度，其本身也是一種架構(gòu)設(shè)計(jì)應(yīng)該要具備的利他心理，這也是我們排除方案二和方案三的原因。
基于方案一的 全球游戲項(xiàng)目GlobalGame，結(jié)合【地區(qū)】【品牌】【渠道】，我們?cè)偻显俪橄笠粚樱谑怯辛恕景l(fā)行計(jì)劃】的概念，比如全球游戲項(xiàng)目【FGO】計(jì)劃在【中國(guó)大陸】使用【bilibili】品牌上架【BILI游戲中心】這就是一個(gè)發(fā)行計(jì)劃。
圖片
基于全球游戲項(xiàng)目【GlobalGame】【發(fā)行計(jì)劃】，很自然可以將原本的多套發(fā)行管理系統(tǒng)統(tǒng)一聚合起來，去實(shí)現(xiàn)一套真正的【全球發(fā)行管理系統(tǒng)】。
圖片
參數(shù)管理是接入過程中對(duì)效率影響比較大的一個(gè)部分，主要是以下3個(gè)痛點(diǎn)
問題明確，接下來就是全球發(fā)行系統(tǒng)有針對(duì)性去解決。
參數(shù)多且雜，只能靠笨辦法解決。
我們從參數(shù)歸屬的功能模塊（是什么，what）、參數(shù)來源(誰負(fù)責(zé)在哪生成，from)、參數(shù)使用（誰使用 to）以及額外生成、使用文檔這些方面去全面梳理了各個(gè)渠道各個(gè)模塊需要的參數(shù)，并落到系統(tǒng)使用手冊(cè)。
下面是港澳臺(tái)Google渠道相關(guān)參數(shù)梳理列表。
圖片
參數(shù)梳理完成，自然要在全球發(fā)行系統(tǒng)統(tǒng)一管理。
參數(shù)負(fù)責(zé)人員在對(duì)應(yīng)平臺(tái)生產(chǎn)參數(shù)后，確認(rèn)歸屬的游戲和對(duì)應(yīng)發(fā)行計(jì)劃，即可根據(jù)功能模塊分類錄入進(jìn)全球發(fā)行系統(tǒng)。
統(tǒng)一權(quán)限系統(tǒng)來保障數(shù)據(jù)安全，統(tǒng)一日志平臺(tái)則負(fù)責(zé)記錄每一次變更與查詢。
圖片
如何解決研發(fā)接入?yún)?shù)配置項(xiàng)多的問題？
研發(fā)接入BILI發(fā)行平臺(tái)，真的需要感知這么多SDK內(nèi)部細(xì)節(jié)么？
其實(shí)不需要。我們參考了接入Google、Firebase等平臺(tái)的接入方式，接入物料只需要一個(gè)google-services.json/firebase.json文件，而不必感知被接入服務(wù)過多細(xì)節(jié)。
圖片
那我們?nèi)虬l(fā)行系統(tǒng)就可以根據(jù)配置的參數(shù)生成一個(gè)客戶端SDK需要的配置文件(sdk-service.json)，里面包含各個(gè)模塊相關(guān)配置，交付研發(fā)后，研發(fā)只需要將文件放在指定位置，SDK即可獲取需要的相關(guān)參數(shù)。這個(gè)過程中，研發(fā)無需感知具體模塊相關(guān)參數(shù)。
圖片
參數(shù)治理，參數(shù)封裝是簡(jiǎn)化研發(fā)在對(duì)接過程中非常重要的一部分。完成參數(shù)治理后，全球發(fā)行系統(tǒng)還可以通過內(nèi)部API為全球打包系統(tǒng)的提供渠道打包需要的所有參數(shù)配置，以前大部分耗時(shí)耗力的人工配置流程都可以在此基礎(chǔ)通過自動(dòng)化得到解決。
圖片
1、游戲集成ONE SDK默認(rèn)要求接入B服渠道業(yè)務(wù)（國(guó)內(nèi)bili渠道），方便游戲研發(fā)進(jìn)行接入結(jié)果驗(yàn)證。完成了ONE SDK的集成，游戲產(chǎn)物APK和IAP即可發(fā)布在國(guó)內(nèi)Bili渠道和國(guó)內(nèi)蘋果渠道上。
2、Android端：游戲產(chǎn)物APK稱之為"母包"。母包通過多渠道打包系統(tǒng)，結(jié)合反編譯&回編技術(shù)，將具體的業(yè)務(wù)實(shí)現(xiàn)（國(guó)內(nèi)bili渠道）移除，融合進(jìn)其他業(yè)務(wù)渠道代碼，回編生成具體的業(yè)務(wù)渠道APK。
3、iOS端：無法使用反編譯技術(shù)， 打包系統(tǒng)通過腳本修改游戲原始Xcode工程，實(shí)現(xiàn)業(yè)務(wù)渠道切入
4、通過打包系統(tǒng)，即可實(shí)現(xiàn)游戲一次接入，多渠道多品牌發(fā)行。包括但不限于國(guó)內(nèi)B服、Apple、小米、華為、OV、360、應(yīng)用寶、海外Goolge、海外OneStore、海外Mycard等。
原全球各渠道的接入、打包流程如下圖：
圖片
由于主體不同，上架渠道不同，每個(gè)主體和渠道都有自己的sdk，因此通常情況都是由游戲自行接入需要上架渠道的sdk，如B服，海外渠道的打包流程。
但是對(duì)于我們的獨(dú)代游戲，我們需要幫助游戲發(fā)行到所有的渠道上，這些渠道多達(dá)幾十個(gè)；我們不可能讓渠道接入幾十個(gè)sdk并且自行出包，在這個(gè)業(yè)務(wù)場(chǎng)景下，渠道發(fā)行設(shè)計(jì)了UOSDK，游戲只需要接入一次UOSDK，然后通過我們的渠道打包系統(tǒng)就能完成所有渠道的出包。具體的游戲渠道打包原理和方案可以參考《渠道發(fā)行的Android多渠道打包實(shí)踐》。
如果要統(tǒng)一全球的出包動(dòng)作，那么就要基于現(xiàn)有的渠道打包系統(tǒng)，并且兼容ONE SDK的邏輯設(shè)計(jì)一套新的打包流程，讓CP可以只接入一個(gè)SDK就能完成所有渠道的打包任務(wù)。
由于之前游戲業(yè)務(wù)系統(tǒng)眾多，國(guó)內(nèi)渠道打包系統(tǒng)的數(shù)據(jù)管理采用本地創(chuàng)建、管理的方式，有新游戲接入先在打包系統(tǒng)創(chuàng)建游戲、渠道以及游戲-渠道關(guān)系數(shù)據(jù)。在打包的時(shí)候通過讀取本地?cái)?shù)據(jù)庫(kù)來獲取待出包游戲的渠道列表，提供給用戶選擇、出包。
具體的打包流程如下圖所示：
圖片
多系統(tǒng)打通之后，全球發(fā)行的游戲在所有渠道上的的參數(shù)和配置統(tǒng)一收口，在打包的環(huán)節(jié)可以通過統(tǒng)一的地方獲取到全球所有渠道的參數(shù)以及配置，通過腳本自動(dòng)化生成本地的打包配置，解決的數(shù)據(jù)分散的問題和人工創(chuàng)建配置的成本。
改造后的打包流程如下圖所示：
圖片
為了在游戲開發(fā)中接入或替換其他渠道的SDK，通常需要完成以下步驟：
為了簡(jiǎn)化研發(fā)流程，我們可以使用打包工具自動(dòng)引入或替換渠道SDK，生成參數(shù)文件，并幫助游戲自動(dòng)修改項(xiàng)目配置和依賴項(xiàng)。這樣，研發(fā)同學(xué)只需要關(guān)注SDK接口接入和證書選擇等操作，即可通過一鍵配置工具快速集成SDK，并導(dǎo)出可用的IPA包，從而大大提高研發(fā)效率，同時(shí)也能幫助規(guī)避接入過程中的常見問題。
圖片
未來兩套系統(tǒng)也還會(huì)并存一段較長(zhǎng)的時(shí)間，如何過渡與兼容也是在設(shè)計(jì)之初就考慮的一個(gè)問題。我們期望全球發(fā)行系統(tǒng)的設(shè)計(jì)本質(zhì)上是基于老系統(tǒng)的重新組織、定義、拓展，并非打破重來。
兼容的基本原則：入口層統(tǒng)一，概念統(tǒng)一，數(shù)據(jù)存儲(chǔ)層不做更改，只做少量拓展。
由于底層數(shù)據(jù)的互通，新老系統(tǒng)本質(zhì)上只需要做一下流程映射即可，相互映射的流程理論上完全對(duì)等，數(shù)據(jù)互通，不管在新系統(tǒng)老系統(tǒng)只需要執(zhí)行一遍即可。技術(shù)同學(xué)在新系統(tǒng)開發(fā)過程，基于流程映射表，則需要保障老流程也正常運(yùn)行。
通過這種方式保障兼容性，業(yè)務(wù)同學(xué)可以獲得比較好的過度體驗(yàn)，畢竟新系統(tǒng)推廣與建設(shè)也需要逐步進(jìn)行。
下面是新老系統(tǒng)部分流程映射表，
圖片
老系統(tǒng)中一個(gè)游戲國(guó)內(nèi)、海外各品牌發(fā)行，分別屬于不同的基礎(chǔ)游戲（GameBase），沒有關(guān)聯(lián)，遷移到新系統(tǒng)后需要將本質(zhì)上同一個(gè)游戲不同地區(qū)品牌對(duì)應(yīng)的【基礎(chǔ)游戲GameBase】信息的發(fā)行 歸屬到【全球游戲項(xiàng)目（ GlobalGame）】下，系統(tǒng)會(huì)基于原有的發(fā)行數(shù)據(jù)自動(dòng)生成發(fā)行計(jì)劃。
圖片
如果準(zhǔn)備將出包流程也遷移到全球打包系統(tǒng)，只需要將老系統(tǒng)中客戶端出包依賴但是仍未進(jìn)行系統(tǒng)管理的參數(shù)補(bǔ)充完善即可。
1、《How great leaders inspire action》 https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action/c
2、《人月神話》FrederickP.Brooks.Jr.
3、《Application Boundary》 https://martinfowler.com/bliki/ApplicationBoundary.html
4、《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì) 軟件核心復(fù)雜性應(yīng)對(duì)之道》Eric Evans
5、《渠道發(fā)行的Android多渠道打包實(shí)踐》嗶哩嗶哩技術(shù) Claud. https://mp.weixin.qq.com/s/0zOFNpdaCmghBSyuJ6DKuQ
6、《從效能公式解構(gòu)研發(fā)效能》 https://developer.aliyun.com/article/1120300
7、《對(duì)抗軟件復(fù)雜度的戰(zhàn)爭(zhēng)》 https://mp.weixin.qq.com/s/Dil5Ual1aI_7dsGKV0f6Ig
本期作者
豐富 嗶哩嗶哩資深開發(fā)工程師
孫鵬 嗶哩嗶哩資深開發(fā)工程師
陳震炳 嗶哩嗶哩資深開發(fā)工程師
嚴(yán)林紅 嗶哩嗶哩資深開發(fā)工程師
本文鏈接：http://www.www897cc.com/showinfo-26-15454-0.html游戲全球發(fā)行平臺(tái)的實(shí)踐與探索
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 在Kubernetes中實(shí)現(xiàn)gRPC流量負(fù)載均衡
下一篇： 幾行代碼教你用代碼操作Word
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)