背景

在全公司针对业务效率提升有严格要求的背景下，游戏技术中台一直在思考，如何提高全球发行效率？

在游戏技术中台的众多产品当中，SDK是赋能游戏研发的核心产品之一，其核心能力包括账号、交易、合规（实名、防沉迷），以及社交、营销等能力。现有的SDK群存在22种类型，在过往的高速发展和历史惯性中，SDK群划分的维度主要有3个：

• 发行品牌：bilibili、白板、D、海外bilibili、海外白板、K；（出于发行品牌隔离保护需要，下文以代号D/K分别代表国内和海外被保护的发行品牌）
• 发行地区：中国大陆、港澳台（中国）、韩国、东南亚、欧美等；
• 设备类型：iOS、安卓、PC。

不同发行品牌、地区、设备，存在相同定位的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）。

1. 目标（Why）：这一层次是最基础和核心的层次，它代表着行动的动机和意义所在。在思考问题时，我们首先需要明确问题的根本动机、价值和意义。如果我们只关注做什么，而忽略了为什么做，那么很容易失去目标、方向和动力。
2. 方法（How）：这一层次代表着问题的解决方案和实现途径。在明确了为什么之后，我们需要思考如何实现目标。这个过程包括了解问题域相关知识、分析解决方案的可行性、确定执行计划和资源等。
3. 行动（What）：这一层次是行动和执行层次，代表着具体的行动和操作。在明确了为何和如何之后，我们需要根据具体情况和实际需求，确定具体的操作步骤和行动方案。

Why：提升效率的方向

在确定以增效为大目标的前提下，我们侧重通过架构设计的优化，流程调整，两个方面去提升全球发行过程效率。参考阿里巴巴对于研发效能的定义公式：个体效率 x 协同效率 x 价值 = 研发效能。MBA知识库，对于效能和效率的定义有很大的区别，本文重点把”效“论述为效率。能够提升研发效能的影响变量有三个，其中价值这一选项，更多的是由业务能力范围决定，本次实践中并无业务增量，因此不是重点分析讨论的方向。基于公式思维，本次实践的目标可以拆解为两个突破方向，提升个体效率和协同效率。

How：如何提升效率

接下来需要思考影响个体效率和协同效率的方法，即黄金圈法则How的问题。

个体效率

分析个体效率，首先需要明确个体的指向是谁？参与全球发行这个过程的主要个体，主要包括3类：游戏研发、发行平台运营、发行平台技术。这三类个体的在发行过程中，影响其个体效率的主要因素如下：

1. 游戏研发：领域知识的认知成本，SDK重复接入（背景提到的问题），文档的可读性，复杂的接入参数管理；
2. 平台运营：领域知识的认知和解释成本，复杂的接入参数管理；
3. 平台技术：领域知识的认知和解释成本，架构设计存在职责模糊，能力复用不够，变更的影响面偏大；

基于以上三类主要个体效率影响分析，其中共性部分在于领域知识的认知和解释成本，其次是架构设计的些许问题，比如参数管理分散，导致的不必要复杂度暴露。这些问题经过整合，发现本质是软件工程领域的大型软件系统的复杂度管理难题。

著名的计算机科学家Fred Brooks在《人月神话》中将软件服务复杂度分为两个大类：

1. 内在复杂度：是由于软件本身的复杂性而导致的。例如，业务领域知识、算法、数据结构、接口设计等都属于内在复杂度。内在复杂度表示的是系统本身的复杂度。
2. 外在复杂度：是由于软件开发环境的复杂性而导致的。例如，多人协作、进度安排、分布式系统等都属于外在复杂度。

相对来说，全球发行基础的业务能力，比如账号、交易、合规、营销等，可理解为在接入过程中的内在复杂度，对这些领域知识的学习是必要的认知成本。对于领域知识的组织和定义方式、文档设计、架构设计，可理解为系统的外在复杂度。针对软件复杂度管理的课题，众多软件工程领域的大师以及行业前辈有过精彩的论述，在本节不做拓展说明。基于复杂度管理的常见策略，经过分析后，我们决定从以下几个方面着手控制全球发行的复杂度，试图提升个体效率。

1. 业务领域知识对齐，明确领域模型术语，核心概念在沟通、设计和实现的保持一致。对齐重要性可参考DDD对于通用语言（UBIQUITOUS LANGUAGE）的论述；
2. 客户端架构升级，通过依赖反转和适配器模式，建立全球发行统一的SDK API标准，屏蔽SDK群的接口差异，降低全球发行过程中开发的认知负担。
3. 服务端明确服务应用边界，能力复用；
4. 统一管理全球发行服务端API，避免长期迭代导致的标准丢失；

协同效率

针对协同效率，我们重点从参与全球发行过程中3类个体，以及关联个体的系统和流程处分析可优化空间。

图片

1、游戏研发与发行技术：二者交互连接的产品是对接文档、SDK、API，以上产品作为发行领域知识的展示窗口，一定程度上影响游戏研发的接入效率。核心领域术语的对齐对于沟通效率的价值是显而易见的。其次、现有的文档主次和业务逻辑表达不够清晰直观，也会影响研发对于SDK和API的理解，这会带来多次沟通确认，影响效率的同时，也影响了工作体验和游戏发行技术品牌。

2、平台技术与平台运营之间，在全球发行过程中的连接产品主要集中在3个方面，全球发行后台游戏入库、研发母包到渠道打包系统、接入参数管理。首先游戏入库是一个复杂的过程，这一块的自动化还有提升空间。其次、在发行过程中全球发行后台与渠道打包系统并未完全融合，会导致存在部分能力的重复建设，以及人为连接带来的工作量。

3、游戏研发与发行平台运营之间，主要的连接部分在于接入参数管理、接入答疑、以及项目管理。现阶段接入参数类型众多，在不同的地区、合规政策、依赖资源等各种背景叠加下，经过整理后，一款待全球发行的接入参数可能多大300+，这些纷繁复杂参数背后的都是基于人力管理。其次、接入过程答疑的主要影响因素在于对接文档、SDK、API的设计，这也是可以优化的方向。

基于以上分析，我们决定从以下几个方面着手，提升协同效率：

• 建立全球发行SDK统一接入层ONE SDK，让游戏研发实现一次接入，
• 全球发行。
•  全球发行系统建设

a. 多套旧版发行管理系统聚合统一，基于全球发行游戏项目与发行计划建设统一的全球发行管理系统。

b. 基于全球发行管理系统，统一、规范管理发行计划的各类参数/配置项；

c. 渠道打包系统架构升级，依托参数统一管理支持Android全球渠道打包，不仅局限于自研游戏在大陆安卓渠道的联运业务。

• 工具支持，自动接入自检、测试；
• 梳理接入流程。

What：提升效率的行动路线

基于黄金圈法则Why和How的分析，最后我们拆解制定的行动路线如下：

图片

挑战

基于以上背景和目标，整体项目挑战将来源于以下4个方面：

1、标准化：多套异构API，如何统一规格，并降低研发的理解成本，同时对外又保持较高的水准；

2、自动化：如何屏蔽不同地区、设备、合作模式下的接入复杂度，提高接入效率；

3、兼容性：游戏业务在过去几年的高速发展中，发行业务逐渐搭建了一套功能完善且复杂度较高的平台级应用架构。随着组织的扩张与分工的精细化，对当前平台架构具有全盘把握者较少，如何做到整体提效的同时，兼容现有架构本身，其难度巨大。

4、影响面：游戏底层模型的变更，几乎牵涉到发行技术中台所有的技术团队和发行业务团队；部分新概念的提出，需要达成平台级的概念共识。

实践

1、个体效率

1.1、复杂度管理

1.1.1、统一领域核心术语

bilibili多年以来全球发行的业务经验，产生了较多的的领域名词和术语。如果在发行平台内部不能做到核心术语的统一，这其中的沟通和设计复杂度可想而知，更何况大多数时候，我们需要向游戏研发传达相关概念和设计细节。即使对于一个在bilibili国内发行平台有不少工作经验的业务研发同学，理解什么是”无标“和”账号域“已是难事，更何况各种概念之间的关系。因此，整理领域核心术语，及其之间的逻辑关系是执行的基础。经整理设计后的核心概念分层如下图：

图片

常见核心概念主要分为4层：

发行地区

常见的划分方式是以物理地区划分为主，主要区为国内大陆地区、港澳台（中国）、东南亚、欧美等等；

发行品牌

中国大陆地区常用品牌为bilibili、白板、代号D，港澳台和海外常用品牌为代号K、bilibili、以及白板（也称“无标”）；

下载渠道

全球发行过程中提供下载能力的渠道，比如：国内bilibili提供安卓游戏下载，Apple Store 提供IOS游戏下载，国内的UO渠道目前有70+，海外重点Google Play，Apple Store，Mycard，One Store等等；

账号域

海外架构中依赖的概念，账号域决定了应用部署、数据隔离等需求场景，通常和发行地区的法律法规相关。

1.1.2、统一业务词汇/命名风格

Martin Flower在他的演讲和著作中，多次强调命名的重要性，认为好的命名是编写高质量软件的关键因素之一。他认为好的命名实践应该具备的特质是：清晰直观、目的明确、风格统一。有些同学可能会认为这是自然而然的事情，但是对于一个演进了多年的大型系统来说这绝非必然。统一且直观命名，符合直觉和经验对于学习效率的价值是巨大的。

图片

基于以上实践特质，结合统一的领域术语和词汇，我们建立的URL PATH命名约束简洁示意如下：

图片

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

1.2、架构升级/优化

1.2.1、全球发行整体架构如下

图片

1.2.2、服务端架构优化（ONE API）

1、明确应用边界：基于领域驱动应用分层模型，将原有各子领域单独对外提供服务的API，统一收敛到领域服务，对外通过应用服务暴露API与游戏研发交互，统一收口。同时解决部分业务需求评审完成后，代码写在哪里的问题。

2、统一管理ONE API：统一的ONE API代码仓库，对于接口的定义，直接依赖Jar包，防止在后续长期迭代过程中的”走样“。

1.2.3、ONE SDK设计与实现

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完成业务功能。

2、协同效率

2.1、全球发行系统

2.1.1、  老系统的困境

困境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相关参数名，无论是平台运营还是研发理解心智成本非常大。

图片

而目前仅一些核心的后端账号支付模块参数才会在统一在后台管理，大量仅客户端依赖的参数，还在依赖人力管理。参数的流转仍然在依赖传统的邮件流，流转过程中可能会产生多个副本，一旦发生变更，需要多方确认调整。

整套参数管理流程不仅影响接入沟通效率，还存在很大规范问题与安全隐患。

2.1.2、 全球发行系统

那全球发行系统如何打破以往僵局？

首先很自然的想法是进行多系统聚合。这些发行系统核心的职责，本质就是安全合规的将游戏分发到不同地区不同渠道。不管是国内BILI游戏中发行、iOS发行、国内渠道发行、海外发行本质做的是一致的业务，但是分散的系统必然会出现业务概念的分歧。

那这些系统本质区别在哪里呢？核心点在于支持的【游戏、地区、品牌、渠道】不同。【地区】【品牌】【渠道】是前面【统一领域核心术语】提到的重要但是却也是非常简单、直观的概念。而【游戏】模型的定义是一个难点。

2.1.2.1 老发行系统中的‘游戏’模型

哔哩哔哩游戏业务，以最开始的联运业务开始，随着发展的壮大，逐渐搭建出多地区、多品牌的全球发行模型。在业务底层的建模上，对于游戏的定义主要分为两层。

1、game：最底层承担的职责主要包括：游戏对接的SDK信息、接入秘钥、支付参数、渠道上架、APP合规、运营控制等等。每个game_id对应研发需要感知的接入参数。

2、game_base：基于game之上，构建的抽象实体，其职责是承接游戏对于品牌、地区的定义。

其层次和主要职责示意如下：

图片

2.1.2.2 全球发行'游戏'模型：GlobalGame

在现有的架构设计中，对于一款游戏的实际定义，是基于对接的SDK来区分的，每套SDK对应一套参数。随着多品牌、多地区的发行策略的落地，研发需要感知的发行参数呈几何递增。

实现“一次接入，全球发行”，需要囊括所有的品牌和地区，因此在现有的架构定义中，不管是现有的game_id，还是抽象的game_base_id都无法承担全球游戏项目的逻辑职责。

对外，要实现“一次接入，全球发行”的目标，势必不能再将多套参数的复杂度暴露。对内，由于旧游戏模型已经应用到游戏发行技术中的各个团队和项目，如果调整现有架构中对于游戏的定义方式，势必影响面巨大，其范围牵涉整个游戏发行技术中台，大面积的变更甚至导致业务迭代阻塞。

因此，基于开闭原则，我们在原有游戏模型基础上做了一些拓展，引入的全球游戏项目GlobalGame的概念，基本不修改原有模型。

图片

对外，游戏研发对于全球接入参数的感知，将以全球游戏项目(global_game)为基准，而不是每个game_id一套；对内，各业务部门仍然现有逻辑基本无需改造，当然也可以在合适的时机去适配全球游戏发行项目。

2.1.2.3  发行计划

当我们决定以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】【发行计划】，很自然可以将原本的多套发行管理系统统一聚合起来，去实现一套真正的【全球发行管理系统】。

图片

2.1.3、参数管理

参数管理是接入过程中对效率影响比较大的一个部分，主要是以下3个痛点

• 内外部理解成本大
• 缺少系统化管理
• 研发接入参数多，接入成本高

问题明确，接下来就是全球发行系统有针对性去解决。

参数多且杂，只能靠笨办法解决。

我们从参数归属的功能模块（是什么，what）、参数来源(谁负责在哪生成，from)、参数使用（谁使用  to）以及额外生成、使用文档这些方面去全面梳理了各个渠道各个模块需要的参数，并落到系统使用手册。

下面是港澳台Google渠道相关参数梳理列表。

图片

参数梳理完成，自然要在全球发行系统统一管理。

参数负责人员在对应平台生产参数后，确认归属的游戏和对应发行计划，即可根据功能模块分类录入进全球发行系统。

统一权限系统来保障数据安全，统一日志平台则负责记录每一次变更与查询。

图片

如何解决研发接入参数配置项多的问题？

研发接入BILI发行平台，真的需要感知这么多SDK内部细节么？

其实不需要。我们参考了接入Google、Firebase等平台的接入方式，接入物料只需要一个google-services.json/firebase.json文件，而不必感知被接入服务过多细节。

图片

那我们全球发行系统就可以根据配置的参数生成一个客户端SDK需要的配置文件(sdk-service.json)，里面包含各个模块相关配置，交付研发后，研发只需要将文件放在指定位置，SDK即可获取需要的相关参数。这个过程中，研发无需感知具体模块相关参数。

图片

参数治理，参数封装是简化研发在对接过程中非常重要的一部分。完成参数治理后，全球发行系统还可以通过内部API为全球打包系统的提供渠道打包需要的所有参数配置，以前大部分耗时耗力的人工配置流程都可以在此基础通过自动化得到解决。

2.2、全球发行打包系统

2.2.1 、ONE SDK渠道业务融合替换

图片

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等。

2.2.2、Android 全球渠道打包系统

2.2.2.1、打包能力整合

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

图片

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

但是对于我们的独代游戏，我们需要帮助游戏发行到所有的渠道上，这些渠道多达几十个；我们不可能让渠道接入几十个sdk并且自行出包，在这个业务场景下，渠道发行设计了UOSDK，游戏只需要接入一次UOSDK，然后通过我们的渠道打包系统就能完成所有渠道的出包。具体的游戏渠道打包原理和方案可以参考《渠道发行的Android多渠道打包实践》。

如果要统一全球的出包动作，那么就要基于现有的渠道打包系统，并且兼容ONE SDK的逻辑设计一套新的打包流程，让CP可以只接入一个SDK就能完成所有渠道的打包任务。

2.2.2.2、原国内渠道打包系统

由于之前游戏业务系统众多，国内渠道打包系统的数据管理采用本地创建、管理的方式，有新游戏接入先在打包系统创建游戏、渠道以及游戏-渠道关系数据。在打包的时候通过读取本地数据库来获取待出包游戏的渠道列表，提供给用户选择、出包。

具体的打包流程如下图所示：

图片

2.2.2.3、基于ONE的全球打包系统

多系统打通之后，全球发行的游戏在所有渠道上的的参数和配置统一收口，在打包的环节可以通过统一的地方获取到全球所有渠道的参数以及配置，通过脚本自动化生成本地的打包配置，解决的数据分散的问题和人工创建配置的成本。

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

图片

2.2.3、iOS  全球渠道打包系统

为了在游戏开发中接入或替换其他渠道的SDK，通常需要完成以下步骤：

1. 导入SDK资源：将SDK的资源文件导入到项目中，例如静态库、源代码、配置文件等。
2. 接入SDK接口并填写SDK入参：调用SDK提供的API接口，并根据SDK的要求填写必要的参数，以便实现对应的功能。
3. 配置工程相关参数：根据SDK文档中的要求配置项目相关参数，例如编译选项、链接选项、Build Settings等。
4. 配置SDK依赖项：如果SDK需要依赖其他库或框架，需要将这些依赖项添加到项目中，并设置正确的路径和编译选项。
5. 配置开发者证书，并导出IPA包：将项目打包成IPA包，并使用正确的开发者证书签名，以便在设备上安装和运行。

为了简化研发流程，我们可以使用打包工具自动引入或替换渠道SDK，生成参数文件，并帮助游戏自动修改项目配置和依赖项。这样，研发同学只需要关注SDK接口接入和证书选择等操作，即可通过一键配置工具快速集成SDK，并导出可用的IPA包，从而大大提高研发效率，同时也能帮助规避接入过程中的常见问题。

图片

3、方案兼容

3.1、 管理系统兼容

未来两套系统也还会并存一段较长的时间，如何过渡与兼容也是在设计之初就考虑的一个问题。我们期望全球发行系统的设计本质上是基于老系统的重新组织、定义、拓展，并非打破重来。

兼容的基本原则：入口层统一，概念统一，数据存储层不做更改，只做少量拓展。

由于底层数据的互通，新老系统本质上只需要做一下流程映射即可，相互映射的流程理论上完全对等，数据互通，不管在新系统老系统只需要执行一遍即可。技术同学在新系统开发过程，基于流程映射表，则需要保障老流程也正常运行。

通过这种方式保障兼容性，业务同学可以获得比较好的过度体验，毕竟新系统推广与建设也需要逐步进行。

下面是新老系统部分流程映射表，

图片

3.2、 低成本迁移全球发行系统

老系统中一个游戏国内、海外各品牌发行，分别属于不同的基础游戏（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

本期作者

丰富 哔哩哔哩资深开发工程师

孙鹏 哔哩哔哩资深开发工程师

陈震炳 哔哩哔哩资深开发工程师

严林红 哔哩哔哩资深开发工程师