背景

在全公司針對業(yè)務效率提升有嚴格要求的背景下，游戲技術中臺一直在思考，如何提高全球發(fā)行效率？

在游戲技術中臺的眾多產品當中，SDK是賦能游戲研發(fā)的核心產品之一，其核心能力包括賬號、交易、合規(guī)（實名、防沉迷），以及社交、營銷等能力?，F(xiàn)有的SDK群存在22種類型，在過往的高速發(fā)展和歷史慣性中，SDK群劃分的維度主要有3個：

• 發(fā)行品牌：bilibili、白板、D、海外bilibili、海外白板、K；（出于發(fā)行品牌隔離保護需要，下文以代號D/K分別代表國內和海外被保護的發(fā)行品牌）
• 發(fā)行地區(qū)：中國大陸、港澳臺（中國）、韓國、東南亞、歐美等；
• 設備類型：iOS、安卓、PC。

不同發(fā)行品牌、地區(qū)、設備，存在相同定位的API，但是定義和標準不同，導致在不同合作模式（主要分為：獨家代理、聯(lián)合運營；獨家代理簡稱獨代，聯(lián)合運營分為兩種，聯(lián)運和UO，UO為Union Operation的縮寫特指在獨代的前提下，主動與第三方下載渠道合作；聯(lián)運特指在沒有獨家代理的前提下，第三方與bilibili的合作。），研發(fā)需要重復對接多種類型SDK和服務端API；

圖片

藍色部分表示游戲研發(fā)需要感知的SDK和服務端API類型。

另一方面，發(fā)行技術中臺建設早期秉承業(yè)務優(yōu)先思維，專注于各領域基礎能力建設，各系統(tǒng)間缺少聯(lián)動依賴運營 SOP 銜接，伴隨發(fā)行游戲數(shù)量增多，效率問題逐步呈現(xiàn)。為解決這些問題，優(yōu)化全球發(fā)行效率，我們期望為研發(fā)提供一站化體驗，從聯(lián)動性、易用性、自動化等多角度優(yōu)化當前 SDK 與后臺系統(tǒng)，故啟動了 ONE SDK / API 項目。

成果

當我們完成ONE SDK/API項目后，以游戲《Kenny: 和平衛(wèi)士》發(fā)行計劃為例，從以下3個維度：“全球發(fā)行平均接入時間”、“游戲研發(fā)的認知范圍”、“游戲研發(fā)重復開發(fā)次數(shù)”，取得的工作成果現(xiàn)展示如下：

圖片

用5組數(shù)據度量，以對比ONE SDK/API價值

圖片

1、全球發(fā)行平均接入時間：從優(yōu)化前的60天縮短為15天，效率提升了4倍；

2、游戲研發(fā)的認知范圍：從游戲研發(fā)需要認知的參數(shù)數(shù)量，以及實際需要管理參數(shù)兩個維度度量，其概念認知規(guī)模至少降低了90%；

3、游戲研發(fā)重復開發(fā)次數(shù)：從SDK API接入次數(shù)和服務端API接入次數(shù)度量，其重復勞動規(guī)模至少降低了75%。

分析

基于以上背景描述，本節(jié)重點描述，我們對于全球發(fā)行的理解，以及對于目標和行動路線的思考過程。

API標準未統(tǒng)一和孤島系統(tǒng)是全球發(fā)行過程中，比較容易識別的兩個痛點。圍繞業(yè)務效率提升這個大目標，從增效這個角度切入，在本次升級和實踐的行動路線應該是什么樣的？結合本次實踐，我們還可以挖掘的內容還有哪些？值得在項目初期認真思考。

在整體的思考過程中，我們基于SimonO.Sinek的黃金圈法則模型來拆解目標，基于目標尋找方法，建立行動路線。首先，簡單介紹一下黃金圈法則。

圖片

黃金圈法則是一個輔助思考和決策的方法，其思考過程主要包括三個層次：為什么（Why）、方法（How）和行動（What）。

1. 目標（Why）：這一層次是最基礎和核心的層次，它代表著行動的動機和意義所在。在思考問題時，我們首先需要明確問題的根本動機、價值和意義。如果我們只關注做什么，而忽略了為什么做，那么很容易失去目標、方向和動力。
2. 方法（How）：這一層次代表著問題的解決方案和實現(xiàn)途徑。在明確了為什么之后，我們需要思考如何實現(xiàn)目標。這個過程包括了解問題域相關知識、分析解決方案的可行性、確定執(zhí)行計劃和資源等。
3. 行動（What）：這一層次是行動和執(zhí)行層次，代表著具體的行動和操作。在明確了為何和如何之后，我們需要根據具體情況和實際需求，確定具體的操作步驟和行動方案。

Why：提升效率的方向

在確定以增效為大目標的前提下，我們側重通過架構設計的優(yōu)化，流程調整，兩個方面去提升全球發(fā)行過程效率。參考阿里巴巴對于研發(fā)效能的定義公式：個體效率 x 協(xié)同效率 x 價值 = 研發(fā)效能。MBA知識庫，對于效能和效率的定義有很大的區(qū)別，本文重點把”效“論述為效率。能夠提升研發(fā)效能的影響變量有三個，其中價值這一選項，更多的是由業(yè)務能力范圍決定，本次實踐中并無業(yè)務增量，因此不是重點分析討論的方向。基于公式思維，本次實踐的目標可以拆解為兩個突破方向，提升個體效率和協(xié)同效率。

How：如何提升效率

接下來需要思考影響個體效率和協(xié)同效率的方法，即黃金圈法則How的問題。

個體效率

分析個體效率，首先需要明確個體的指向是誰？參與全球發(fā)行這個過程的主要個體，主要包括3類：游戲研發(fā)、發(fā)行平臺運營、發(fā)行平臺技術。這三類個體的在發(fā)行過程中，影響其個體效率的主要因素如下：

1. 游戲研發(fā)：領域知識的認知成本，SDK重復接入（背景提到的問題），文檔的可讀性，復雜的接入參數(shù)管理；
2. 平臺運營：領域知識的認知和解釋成本，復雜的接入參數(shù)管理；
3. 平臺技術：領域知識的認知和解釋成本，架構設計存在職責模糊，能力復用不夠，變更的影響面偏大；

基于以上三類主要個體效率影響分析，其中共性部分在于領域知識的認知和解釋成本，其次是架構設計的些許問題，比如參數(shù)管理分散，導致的不必要復雜度暴露。這些問題經過整合，發(fā)現(xiàn)本質是軟件工程領域的大型軟件系統(tǒng)的復雜度管理難題。

著名的計算機科學家Fred Brooks在《人月神話》中將軟件服務復雜度分為兩個大類：

1. 內在復雜度：是由于軟件本身的復雜性而導致的。例如，業(yè)務領域知識、算法、數(shù)據結構、接口設計等都屬于內在復雜度。內在復雜度表示的是系統(tǒng)本身的復雜度。
2. 外在復雜度：是由于軟件開發(fā)環(huán)境的復雜性而導致的。例如，多人協(xié)作、進度安排、分布式系統(tǒng)等都屬于外在復雜度。

相對來說，全球發(fā)行基礎的業(yè)務能力，比如賬號、交易、合規(guī)、營銷等，可理解為在接入過程中的內在復雜度，對這些領域知識的學習是必要的認知成本。對于領域知識的組織和定義方式、文檔設計、架構設計，可理解為系統(tǒng)的外在復雜度。針對軟件復雜度管理的課題，眾多軟件工程領域的大師以及行業(yè)前輩有過精彩的論述，在本節(jié)不做拓展說明。基于復雜度管理的常見策略，經過分析后，我們決定從以下幾個方面著手控制全球發(fā)行的復雜度，試圖提升個體效率。

1. 業(yè)務領域知識對齊，明確領域模型術語，核心概念在溝通、設計和實現(xiàn)的保持一致。對齊重要性可參考DDD對于通用語言（UBIQUITOUS LANGUAGE）的論述；
2. 客戶端架構升級，通過依賴反轉和適配器模式，建立全球發(fā)行統(tǒng)一的SDK API標準，屏蔽SDK群的接口差異，降低全球發(fā)行過程中開發(fā)的認知負擔。
3. 服務端明確服務應用邊界，能力復用；
4. 統(tǒng)一管理全球發(fā)行服務端API，避免長期迭代導致的標準丟失；

協(xié)同效率

針對協(xié)同效率，我們重點從參與全球發(fā)行過程中3類個體，以及關聯(lián)個體的系統(tǒng)和流程處分析可優(yōu)化空間。

圖片

1、游戲研發(fā)與發(fā)行技術：二者交互連接的產品是對接文檔、SDK、API，以上產品作為發(fā)行領域知識的展示窗口，一定程度上影響游戲研發(fā)的接入效率。核心領域術語的對齊對于溝通效率的價值是顯而易見的。其次、現(xiàn)有的文檔主次和業(yè)務邏輯表達不夠清晰直觀，也會影響研發(fā)對于SDK和API的理解，這會帶來多次溝通確認，影響效率的同時，也影響了工作體驗和游戲發(fā)行技術品牌。

2、平臺技術與平臺運營之間，在全球發(fā)行過程中的連接產品主要集中在3個方面，全球發(fā)行后臺游戲入庫、研發(fā)母包到渠道打包系統(tǒng)、接入參數(shù)管理。首先游戲入庫是一個復雜的過程，這一塊的自動化還有提升空間。其次、在發(fā)行過程中全球發(fā)行后臺與渠道打包系統(tǒng)并未完全融合，會導致存在部分能力的重復建設，以及人為連接帶來的工作量。

3、游戲研發(fā)與發(fā)行平臺運營之間，主要的連接部分在于接入參數(shù)管理、接入答疑、以及項目管理。現(xiàn)階段接入參數(shù)類型眾多，在不同的地區(qū)、合規(guī)政策、依賴資源等各種背景疊加下，經過整理后，一款待全球發(fā)行的接入參數(shù)可能多大300+，這些紛繁復雜參數(shù)背后的都是基于人力管理。其次、接入過程答疑的主要影響因素在于對接文檔、SDK、API的設計，這也是可以優(yōu)化的方向。

基于以上分析，我們決定從以下幾個方面著手，提升協(xié)同效率：

• 建立全球發(fā)行SDK統(tǒng)一接入層ONE SDK，讓游戲研發(fā)實現(xiàn)一次接入，
• 全球發(fā)行。
•  全球發(fā)行系統(tǒng)建設

a. 多套舊版發(fā)行管理系統(tǒng)聚合統(tǒng)一，基于全球發(fā)行游戲項目與發(fā)行計劃建設統(tǒng)一的全球發(fā)行管理系統(tǒng)。

b. 基于全球發(fā)行管理系統(tǒng)，統(tǒng)一、規(guī)范管理發(fā)行計劃的各類參數(shù)/配置項；

c. 渠道打包系統(tǒng)架構升級，依托參數(shù)統(tǒng)一管理支持Android全球渠道打包，不僅局限于自研游戲在大陸安卓渠道的聯(lián)運業(yè)務。

• 工具支持，自動接入自檢、測試；
• 梳理接入流程。

What：提升效率的行動路線

基于黃金圈法則Why和How的分析，最后我們拆解制定的行動路線如下：

圖片

挑戰(zhàn)

基于以上背景和目標，整體項目挑戰(zhàn)將來源于以下4個方面：

1、標準化：多套異構API，如何統(tǒng)一規(guī)格，并降低研發(fā)的理解成本，同時對外又保持較高的水準；

2、自動化：如何屏蔽不同地區(qū)、設備、合作模式下的接入復雜度，提高接入效率；

3、兼容性：游戲業(yè)務在過去幾年的高速發(fā)展中，發(fā)行業(yè)務逐漸搭建了一套功能完善且復雜度較高的平臺級應用架構。隨著組織的擴張與分工的精細化，對當前平臺架構具有全盤把握者較少，如何做到整體提效的同時，兼容現(xiàn)有架構本身，其難度巨大。

4、影響面：游戲底層模型的變更，幾乎牽涉到發(fā)行技術中臺所有的技術團隊和發(fā)行業(yè)務團隊；部分新概念的提出，需要達成平臺級的概念共識。

實踐

1、個體效率

1.1、復雜度管理

1.1.1、統(tǒng)一領域核心術語

bilibili多年以來全球發(fā)行的業(yè)務經驗，產生了較多的的領域名詞和術語。如果在發(fā)行平臺內部不能做到核心術語的統(tǒng)一，這其中的溝通和設計復雜度可想而知，更何況大多數(shù)時候，我們需要向游戲研發(fā)傳達相關概念和設計細節(jié)。即使對于一個在bilibili國內發(fā)行平臺有不少工作經驗的業(yè)務研發(fā)同學，理解什么是”無標“和”賬號域“已是難事，更何況各種概念之間的關系。因此，整理領域核心術語，及其之間的邏輯關系是執(zhí)行的基礎。經整理設計后的核心概念分層如下圖：

圖片

常見核心概念主要分為4層：

發(fā)行地區(qū)

常見的劃分方式是以物理地區(qū)劃分為主，主要區(qū)為國內大陸地區(qū)、港澳臺（中國）、東南亞、歐美等等；

發(fā)行品牌

中國大陸地區(qū)常用品牌為bilibili、白板、代號D，港澳臺和海外常用品牌為代號K、bilibili、以及白板（也稱“無標”）；

下載渠道

全球發(fā)行過程中提供下載能力的渠道，比如：國內bilibili提供安卓游戲下載，Apple Store 提供IOS游戲下載，國內的UO渠道目前有70+，海外重點Google Play，Apple Store，Mycard，One Store等等；

賬號域

海外架構中依賴的概念，賬號域決定了應用部署、數(shù)據隔離等需求場景，通常和發(fā)行地區(qū)的法律法規(guī)相關。

1.1.2、統(tǒng)一業(yè)務詞匯/命名風格

Martin Flower在他的演講和著作中，多次強調命名的重要性，認為好的命名是編寫高質量軟件的關鍵因素之一。他認為好的命名實踐應該具備的特質是：清晰直觀、目的明確、風格統(tǒng)一。有些同學可能會認為這是自然而然的事情，但是對于一個演進了多年的大型系統(tǒng)來說這絕非必然。統(tǒng)一且直觀命名，符合直覺和經驗對于學習效率的價值是巨大的。

圖片

基于以上實踐特質，結合統(tǒng)一的領域術語和詞匯，我們建立的URL PATH命名約束簡潔示意如下：

圖片

最終我們的PATH如下：/one/user/session.verify、/one/trade/order.query、/one/security/censor

1.2、架構升級/優(yōu)化

1.2.1、全球發(fā)行整體架構如下

圖片

1.2.2、服務端架構優(yōu)化（ONE API）

1、明確應用邊界：基于領域驅動應用分層模型，將原有各子領域單獨對外提供服務的API，統(tǒng)一收斂到領域服務，對外通過應用服務暴露API與游戲研發(fā)交互，統(tǒng)一收口。同時解決部分業(yè)務需求評審完成后，代碼寫在哪里的問題。

2、統(tǒng)一管理ONE API：統(tǒng)一的ONE API代碼倉庫，對于接口的定義，直接依賴Jar包，防止在后續(xù)長期迭代過程中的”走樣“。

1.2.3、ONE SDK設計與實現(xiàn)

ONE SDK設計遵循依賴反轉（Dependency inversion principle）原則，通過ONE SDK抽象定義全球發(fā)行背景下的API接口。

ONE SDK通過適配層兼容現(xiàn)有的SDK群，達成能力復用，同時實現(xiàn)ONE SDK與SDK群在過渡期的共存。

1.2.3.1、ONE SDK 分包策略

圖片

1、ONE Android SDK以aar架包，ONE iOS SDK以framework的形式提供給游戲研發(fā)。

2、Android按照各個業(yè)務差別劃分為7個子aar。其中ONE SDK Main Lib和ONE SDK BaseLib為核心組件，包含核心登錄和支付功能，游戲必須接入。剩余的5個的AAR為選接項。

3、iOS按照業(yè)務區(qū)別以拆分頭文件的形式將功能劃分為5個模塊，同樣的ONE SDK Main Lib作為核心組件，包含核心登錄和支付功能，游戲必須接入。其他為選接項。

4、ONE SDK以多aar和多頭文件形式提供，避免游戲接入冗余業(yè)務組件，降低了SDK項目耦合性，提高了游戲代碼的效率。

5、在實際使用過程中，游戲可根據自己的發(fā)行計劃和實際需要使用的業(yè)務功能，選擇接入對應的aar和iOS頭文件到游戲中。

舉個例子：a 游戲只發(fā)行國內B服渠道且只有登錄和支付功能。則只需接入ONE SDK Main Lib和ONE SDK BaseLib兩個aar包即可實現(xiàn)發(fā)行需求。其余的aar則不需要接入項目。b 游戲發(fā)行渠道為國內B服渠道和海外Google渠道。需要使用登錄和支付功能、谷歌積分兌換功能，則需接入ONE SDK Main Lib和ONE SDK BaseLib、ONE SDK Google Ext 3個aar包。其余的aar不需要接入項目。

1.2.3.2、整體架構設計

圖片

1、ONE SDK在現(xiàn)有海外發(fā)行SDK、渠道發(fā)行SDK、B服發(fā)行SDK基礎上，對現(xiàn)有的業(yè)務進行了規(guī)劃與統(tǒng)一，形成了統(tǒng)一的全球發(fā)行業(yè)務接口。全球發(fā)行業(yè)務接口主要分為2部分。

      a、各個發(fā)行SDK的獨有的業(yè)務，如海外Google渠道的商品積分兌換業(yè)務、B服發(fā)行SDK的獲取B站好友關系業(yè)務等，保留了原有的接口形式對外提供，降低cp接入時的理解難度和接入復雜度。

      b、各個發(fā)行SDK的共有的業(yè)務，如登錄、支付等，在現(xiàn)有業(yè)務SDK接口基礎上對接口參數(shù)取并集，抽象出涵蓋所有渠道的業(yè)務需求的全球發(fā)行業(yè)務接口，抹平各個渠道的業(yè)務差異性，保證cp一次接入全球通用發(fā)行。

2、根據發(fā)行計劃的不同，游戲的使用場景不同。將統(tǒng)一的全球發(fā)行業(yè)務接口對外提供形式上進行了包體拆分。見上文1.2.3.1、ONE SDK 分包策略。提供了 “聚合標準發(fā)行模型 + 支持高自由度擴展”的接入模式。

3、ONE SDK通過對外的標準接口aar、iOS頭文件和Adapter適配器，將游戲的意圖轉發(fā)到具體的業(yè)務渠道SDK。

      a、ONE SDK抽象定義并對外提供了全球發(fā)行各個業(yè)務接口，并且只是業(yè)務接口，不包含任何具體的業(yè)務實現(xiàn)。隔離了游戲和具體業(yè)務渠道間的耦合。

      b、Adapter適配器能夠將游戲通過標準業(yè)務接口發(fā)出業(yè)務意圖轉發(fā)給各個具體的業(yè)務渠道SDK。起到了承上啟下的作用。完美的適配并支持了所有的現(xiàn)有發(fā)行渠道SDK。

      c、游戲只需要調用對應的業(yè)務接口，就可以實現(xiàn)對應的業(yè)務功能。游戲無需關心各業(yè)務在各渠道上的差異，具體的業(yè)務功能實現(xiàn)由Adapter適配器轉發(fā)給具體的發(fā)行渠道SDK，并由具體的發(fā)行渠道SDK完成業(yè)務功能。

2、協(xié)同效率

2.1、全球發(fā)行系統(tǒng)

2.1.1、  老系統(tǒng)的困境

困境1：

一個自研游戲或者獨家代理的外部游戲要進行全球發(fā)行，和發(fā)行平臺第一個協(xié)作就是平臺接入。全球發(fā)行工作接入階段需要涉及的老版發(fā)行管理系統(tǒng)就有4個，分別國內游戲發(fā)行管理系統(tǒng)(主要負責B站游戲中心渠道、iOS渠道發(fā)行管理)、渠道發(fā)行管理系統(tǒng)(國內安卓渠道發(fā)行管理,例如華為、小米、OPPO）、海外BILI游戲發(fā)行管理系統(tǒng)(海外發(fā)行管理,海外Google/iOS、Mycard、ONEStore)，海外K品牌游戲發(fā)行管理系統(tǒng)。而其他在非接入階段大大小小的管理系統(tǒng)，甚至多達十幾個，包括渠道打包、BI系統(tǒng)、活動系統(tǒng)、包管理等等。

由于歷史上各個管理系統(tǒng)可能由不同的團隊負責，沒有統(tǒng)籌治理，導致系統(tǒng)間一些相同相似業(yè)務模型概念對不齊，業(yè)務同學理解使用成本高，最終結果是很多管理系統(tǒng)只有技術人員才會才敢使用。

困境2：

同一款游戲在接入安卓和iOS時，需要感知的是兩套接入參數(shù)，即兩個game_id。在獨代游戲情況下，如果存在聯(lián)運的業(yè)務，其所感知的游戲參數(shù)需要三套及以上，隨著發(fā)行品牌和地區(qū)的擴展，研發(fā)需要感知的發(fā)行參數(shù)呈指數(shù)遞增。在各種對接過程中，特別是同時對接多SDK甚至多地區(qū)的游戲，多套game_id接入參數(shù)差異導致的接入問題對CP和平臺技術有很大困擾，需要花費不少的時間精力去排查問題。

既然是同一個游戲，同一個CP，同一個發(fā)行平臺，能否實現(xiàn)一套參數(shù)、一個后臺、一次接入的小目標？

困境3：

由于渠道多、功能模塊多，接入過程中涉及的大量接入參數(shù)/配置項管理也是一個難題。

以海外Google包為例，內部包含Google/iOS登錄，多個社交分享(facebook/twitter等)、多套市場歸因營銷相關服務（firebase/appsflyer/adjust）、AIHELP客服等眾多模塊，單包涉及的相關參數(shù)超過40+。這些參數(shù)來源多個平臺，由平臺運營發(fā)出申請，由市場、項管、客服等多個部門去對應平臺生成，最終可能分多次提供給研發(fā)。其中存在大量的secret/key相關參數(shù)名，無論是平臺運營還是研發(fā)理解心智成本非常大。

圖片

而目前僅一些核心的后端賬號支付模塊參數(shù)才會在統(tǒng)一在后臺管理，大量僅客戶端依賴的參數(shù)，還在依賴人力管理。參數(shù)的流轉仍然在依賴傳統(tǒng)的郵件流，流轉過程中可能會產生多個副本，一旦發(fā)生變更，需要多方確認調整。

整套參數(shù)管理流程不僅影響接入溝通效率，還存在很大規(guī)范問題與安全隱患。

2.1.2、 全球發(fā)行系統(tǒng)

那全球發(fā)行系統(tǒng)如何打破以往僵局？

首先很自然的想法是進行多系統(tǒng)聚合。這些發(fā)行系統(tǒng)核心的職責，本質就是安全合規(guī)的將游戲分發(fā)到不同地區(qū)不同渠道。不管是國內BILI游戲中發(fā)行、iOS發(fā)行、國內渠道發(fā)行、海外發(fā)行本質做的是一致的業(yè)務，但是分散的系統(tǒng)必然會出現(xiàn)業(yè)務概念的分歧。

那這些系統(tǒng)本質區(qū)別在哪里呢？核心點在于支持的【游戲、地區(qū)、品牌、渠道】不同?！镜貐^(qū)】【品牌】【渠道】是前面【統(tǒng)一領域核心術語】提到的重要但是卻也是非常簡單、直觀的概念。而【游戲】模型的定義是一個難點。

2.1.2.1 老發(fā)行系統(tǒng)中的‘游戲’模型

嗶哩嗶哩游戲業(yè)務，以最開始的聯(lián)運業(yè)務開始，隨著發(fā)展的壯大，逐漸搭建出多地區(qū)、多品牌的全球發(fā)行模型。在業(yè)務底層的建模上，對于游戲的定義主要分為兩層。

1、game：最底層承擔的職責主要包括：游戲對接的SDK信息、接入秘鑰、支付參數(shù)、渠道上架、APP合規(guī)、運營控制等等。每個game_id對應研發(fā)需要感知的接入參數(shù)。

2、game_base：基于game之上，構建的抽象實體，其職責是承接游戲對于品牌、地區(qū)的定義。

其層次和主要職責示意如下：

圖片

2.1.2.2 全球發(fā)行'游戲'模型：GlobalGame

在現(xiàn)有的架構設計中，對于一款游戲的實際定義，是基于對接的SDK來區(qū)分的，每套SDK對應一套參數(shù)。隨著多品牌、多地區(qū)的發(fā)行策略的落地，研發(fā)需要感知的發(fā)行參數(shù)呈幾何遞增。

實現(xiàn)“一次接入，全球發(fā)行”，需要囊括所有的品牌和地區(qū)，因此在現(xiàn)有的架構定義中，不管是現(xiàn)有的game_id，還是抽象的game_base_id都無法承擔全球游戲項目的邏輯職責。

對外，要實現(xiàn)“一次接入，全球發(fā)行”的目標，勢必不能再將多套參數(shù)的復雜度暴露。對內，由于舊游戲模型已經應用到游戲發(fā)行技術中的各個團隊和項目，如果調整現(xiàn)有架構中對于游戲的定義方式，勢必影響面巨大，其范圍牽涉整個游戲發(fā)行技術中臺，大面積的變更甚至導致業(yè)務迭代阻塞。

因此，基于開閉原則，我們在原有游戲模型基礎上做了一些拓展，引入的全球游戲項目GlobalGame的概念，基本不修改原有模型。

圖片

對外，游戲研發(fā)對于全球接入參數(shù)的感知，將以全球游戲項目(global_game)為基準，而不是每個game_id一套；對內，各業(yè)務部門仍然現(xiàn)有邏輯基本無需改造，當然也可以在合適的時機去適配全球游戲發(fā)行項目。

2.1.2.3  發(fā)行計劃

當我們決定以global_game_id為首，解決全球發(fā)行過程中游戲研發(fā)對于一次接入的參數(shù)問題，接下來需要面對的問題是：如何讓發(fā)行技術平臺對于游戲的定義從game_id無縫切換到global_game_id，實現(xiàn)低成本的平滑過渡？

在這個問題上，我們的思考方向有兩個：

其一、SDK到發(fā)行平臺服務端，游戲在架構初期就設計了ONE SDK到SDK群的適配層，在適配層實現(xiàn)global_game_id到game_id的映射，因此極大的簡化了現(xiàn)有SDK群到服務端的工作量 ，同時保證了在未來研發(fā)繼續(xù)使用現(xiàn)有SDK和使用ONE SDK同時對接的可能。

其二、游戲研發(fā)服務端到發(fā)行平臺服務端（包含：發(fā)行服務端、數(shù)據、社區(qū)、營銷），在無法感知game_id的情況下，與發(fā)行平臺服務端對接的過程中，使用以全球游戲項目Id為首的接入參數(shù)與平臺服務端對接?；诜謱蛹軜?，應用服務層（ONE API BFF）接收到全球游戲項目Id為首的請求參數(shù)后，無法實現(xiàn)對于下游領域服務的路由調用。比如：手游、端游、聯(lián)運各自的發(fā)行領域服務，在原本基于業(yè)務做了領域服務垂直拆分的情況下，ONE API BFF如何與下游領域服務“交互”，變成了平臺服務端架構兼容的直接問題。同時，這個問題在其他的發(fā)行業(yè)務團隊同樣會面臨，比如交易、數(shù)據、廣告、游戲中心、活動營銷等。

分析第二個細分問題，其本質是原來粒度較細的游戲定義方式（簡稱game_id）在優(yōu)化后的對接過程中，被收斂為全球游戲項目Id之后，該怎么與現(xiàn)有的發(fā)行平臺架構兼容的問題。我們將這個問題用公式表達如下：游戲接入Id（game_id） = 全球游戲項目Id (global_game_id) + 其他？

在這個環(huán)節(jié)我們一開始想到的解決方式有如下三個，下文簡單歸納對比方案影響面和優(yōu)缺點，以及我們最終在方案選型中的一些思考。

圖片

經過分析討論，方案一最終被選擇的主要原因在于概念的統(tǒng)一和明確，基于上文的核心術語并未再做擴展。理解成本在這次討論中被用作重要的參考維度，其主要原因也是由于業(yè)務屬性所決定，在全球發(fā)行過程中，鏈路較長，涉及領域知識很多，在沒有必要的情況下，我們奉行的原則是Less is more。做到不違反直覺，降低外在系統(tǒng)復雜度，其本身也是一種架構設計應該要具備的利他心理，這也是我們排除方案二和方案三的原因。

基于方案一的 全球游戲項目GlobalGame，結合【地區(qū)】【品牌】【渠道】，我們再往上再抽象一層，于是有了【發(fā)行計劃】的概念，比如全球游戲項目【FGO】計劃在【中國大陸】使用【bilibili】品牌上架【BILI游戲中心】這就是一個發(fā)行計劃。

圖片

基于全球游戲項目【GlobalGame】【發(fā)行計劃】，很自然可以將原本的多套發(fā)行管理系統(tǒng)統(tǒng)一聚合起來，去實現(xiàn)一套真正的【全球發(fā)行管理系統(tǒng)】。

圖片

2.1.3、參數(shù)管理

參數(shù)管理是接入過程中對效率影響比較大的一個部分，主要是以下3個痛點

• 內外部理解成本大
• 缺少系統(tǒng)化管理
• 研發(fā)接入參數(shù)多，接入成本高

問題明確，接下來就是全球發(fā)行系統(tǒng)有針對性去解決。

參數(shù)多且雜，只能靠笨辦法解決。

我們從參數(shù)歸屬的功能模塊（是什么，what）、參數(shù)來源(誰負責在哪生成，from)、參數(shù)使用（誰使用  to）以及額外生成、使用文檔這些方面去全面梳理了各個渠道各個模塊需要的參數(shù)，并落到系統(tǒng)使用手冊。

下面是港澳臺Google渠道相關參數(shù)梳理列表。

圖片

參數(shù)梳理完成，自然要在全球發(fā)行系統(tǒng)統(tǒng)一管理。

參數(shù)負責人員在對應平臺生產參數(shù)后，確認歸屬的游戲和對應發(fā)行計劃，即可根據功能模塊分類錄入進全球發(fā)行系統(tǒng)。

統(tǒng)一權限系統(tǒng)來保障數(shù)據安全，統(tǒng)一日志平臺則負責記錄每一次變更與查詢。

圖片

如何解決研發(fā)接入參數(shù)配置項多的問題？

研發(fā)接入BILI發(fā)行平臺，真的需要感知這么多SDK內部細節(jié)么？

其實不需要。我們參考了接入Google、Firebase等平臺的接入方式，接入物料只需要一個google-services.json/firebase.json文件，而不必感知被接入服務過多細節(jié)。

圖片

那我們全球發(fā)行系統(tǒng)就可以根據配置的參數(shù)生成一個客戶端SDK需要的配置文件(sdk-service.json)，里面包含各個模塊相關配置，交付研發(fā)后，研發(fā)只需要將文件放在指定位置，SDK即可獲取需要的相關參數(shù)。這個過程中，研發(fā)無需感知具體模塊相關參數(shù)。

圖片

參數(shù)治理，參數(shù)封裝是簡化研發(fā)在對接過程中非常重要的一部分。完成參數(shù)治理后，全球發(fā)行系統(tǒng)還可以通過內部API為全球打包系統(tǒng)的提供渠道打包需要的所有參數(shù)配置，以前大部分耗時耗力的人工配置流程都可以在此基礎通過自動化得到解決。

2.2、全球發(fā)行打包系統(tǒng)

2.2.1 、ONE SDK渠道業(yè)務融合替換

圖片

1、游戲集成ONE SDK默認要求接入B服渠道業(yè)務（國內bili渠道），方便游戲研發(fā)進行接入結果驗證。完成了ONE SDK的集成，游戲產物APK和IAP即可發(fā)布在國內Bili渠道和國內蘋果渠道上。

2、Android端：游戲產物APK稱之為"母包"。母包通過多渠道打包系統(tǒng)，結合反編譯&回編技術，將具體的業(yè)務實現(xiàn)（國內bili渠道）移除，融合進其他業(yè)務渠道代碼，回編生成具體的業(yè)務渠道APK。

3、iOS端：無法使用反編譯技術， 打包系統(tǒng)通過腳本修改游戲原始Xcode工程，實現(xiàn)業(yè)務渠道切入

4、通過打包系統(tǒng)，即可實現(xiàn)游戲一次接入，多渠道多品牌發(fā)行。包括但不限于國內B服、Apple、小米、華為、OV、360、應用寶、海外Goolge、海外OneStore、海外Mycard等。

2.2.2、Android 全球渠道打包系統(tǒng)

2.2.2.1、打包能力整合

原全球各渠道的接入、打包流程如下圖：

圖片

由于主體不同，上架渠道不同，每個主體和渠道都有自己的sdk，因此通常情況都是由游戲自行接入需要上架渠道的sdk，如B服，海外渠道的打包流程。

但是對于我們的獨代游戲，我們需要幫助游戲發(fā)行到所有的渠道上，這些渠道多達幾十個；我們不可能讓渠道接入幾十個sdk并且自行出包，在這個業(yè)務場景下，渠道發(fā)行設計了UOSDK，游戲只需要接入一次UOSDK，然后通過我們的渠道打包系統(tǒng)就能完成所有渠道的出包。具體的游戲渠道打包原理和方案可以參考《渠道發(fā)行的Android多渠道打包實踐》。

如果要統(tǒng)一全球的出包動作，那么就要基于現(xiàn)有的渠道打包系統(tǒng)，并且兼容ONE SDK的邏輯設計一套新的打包流程，讓CP可以只接入一個SDK就能完成所有渠道的打包任務。

2.2.2.2、原國內渠道打包系統(tǒng)

由于之前游戲業(yè)務系統(tǒng)眾多，國內渠道打包系統(tǒng)的數(shù)據管理采用本地創(chuàng)建、管理的方式，有新游戲接入先在打包系統(tǒng)創(chuàng)建游戲、渠道以及游戲-渠道關系數(shù)據。在打包的時候通過讀取本地數(shù)據庫來獲取待出包游戲的渠道列表，提供給用戶選擇、出包。

具體的打包流程如下圖所示：

圖片

2.2.2.3、基于ONE的全球打包系統(tǒng)

多系統(tǒng)打通之后，全球發(fā)行的游戲在所有渠道上的的參數(shù)和配置統(tǒng)一收口，在打包的環(huán)節(jié)可以通過統(tǒng)一的地方獲取到全球所有渠道的參數(shù)以及配置，通過腳本自動化生成本地的打包配置，解決的數(shù)據分散的問題和人工創(chuàng)建配置的成本。

改造后的打包流程如下圖所示：

圖片

2.2.3、iOS  全球渠道打包系統(tǒng)

為了在游戲開發(fā)中接入或替換其他渠道的SDK，通常需要完成以下步驟：

1. 導入SDK資源：將SDK的資源文件導入到項目中，例如靜態(tài)庫、源代碼、配置文件等。
2. 接入SDK接口并填寫SDK入參：調用SDK提供的API接口，并根據SDK的要求填寫必要的參數(shù)，以便實現(xiàn)對應的功能。
3. 配置工程相關參數(shù)：根據SDK文檔中的要求配置項目相關參數(shù)，例如編譯選項、鏈接選項、Build Settings等。
4. 配置SDK依賴項：如果SDK需要依賴其他庫或框架，需要將這些依賴項添加到項目中，并設置正確的路徑和編譯選項。
5. 配置開發(fā)者證書，并導出IPA包：將項目打包成IPA包，并使用正確的開發(fā)者證書簽名，以便在設備上安裝和運行。

為了簡化研發(fā)流程，我們可以使用打包工具自動引入或替換渠道SDK，生成參數(shù)文件，并幫助游戲自動修改項目配置和依賴項。這樣，研發(fā)同學只需要關注SDK接口接入和證書選擇等操作，即可通過一鍵配置工具快速集成SDK，并導出可用的IPA包，從而大大提高研發(fā)效率，同時也能幫助規(guī)避接入過程中的常見問題。

圖片

3、方案兼容

3.1、 管理系統(tǒng)兼容

未來兩套系統(tǒng)也還會并存一段較長的時間，如何過渡與兼容也是在設計之初就考慮的一個問題。我們期望全球發(fā)行系統(tǒng)的設計本質上是基于老系統(tǒng)的重新組織、定義、拓展，并非打破重來。

兼容的基本原則：入口層統(tǒng)一，概念統(tǒng)一，數(shù)據存儲層不做更改，只做少量拓展。

由于底層數(shù)據的互通，新老系統(tǒng)本質上只需要做一下流程映射即可，相互映射的流程理論上完全對等，數(shù)據互通，不管在新系統(tǒng)老系統(tǒng)只需要執(zhí)行一遍即可。技術同學在新系統(tǒng)開發(fā)過程，基于流程映射表，則需要保障老流程也正常運行。

通過這種方式保障兼容性，業(yè)務同學可以獲得比較好的過度體驗，畢竟新系統(tǒng)推廣與建設也需要逐步進行。

下面是新老系統(tǒng)部分流程映射表，

圖片

3.2、 低成本遷移全球發(fā)行系統(tǒng)

老系統(tǒng)中一個游戲國內、海外各品牌發(fā)行，分別屬于不同的基礎游戲（GameBase），沒有關聯(lián)，遷移到新系統(tǒng)后需要將本質上同一個游戲不同地區(qū)品牌對應的【基礎游戲GameBase】信息的發(fā)行 歸屬到【全球游戲項目（ GlobalGame）】下，系統(tǒng)會基于原有的發(fā)行數(shù)據自動生成發(fā)行計劃。

圖片

如果準備將出包流程也遷移到全球打包系統(tǒng)，只需要將老系統(tǒng)中客戶端出包依賴但是仍未進行系統(tǒng)管理的參數(shù)補充完善即可。

參考

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、《領域驅動設計 軟件核心復雜性應對之道》Eric Evans

5、《渠道發(fā)行的Android多渠道打包實踐》嗶哩嗶哩技術 Claud. https://mp.weixin.qq.com/s/0zOFNpdaCmghBSyuJ6DKuQ

6、《從效能公式解構研發(fā)效能》 https://developer.aliyun.com/article/1120300

7、《對抗軟件復雜度的戰(zhàn)爭》 https://mp.weixin.qq.com/s/Dil5Ual1aI_7dsGKV0f6Ig

本期作者

豐富 嗶哩嗶哩資深開發(fā)工程師

孫鵬 嗶哩嗶哩資深開發(fā)工程師

陳震炳 嗶哩嗶哩資深開發(fā)工程師

嚴林紅 嗶哩嗶哩資深開發(fā)工程師