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