游戏全球发行提效-- 发行 iOS SDK的自动化接入探索

游戏SDK作为游戏技术中台赋能游戏研发的核心产品之一，其核心能力包括账号、交易、合规（实名、防沉迷），以及社交、营销等能力。为游戏开发者提供了便捷的方式快速完成底层业务能力的搭建，降低开发和维护的难度。帮助游戏研发更专注于游戏内容的创作，缩短游戏研发周期的同时保障游戏的安全性合规性。

随着游戏业务的发展，游戏SDK的数量也不断增加。在保障游戏业务发展的同时，我们整合了所有海外发行的SDK，游戏在海外发行中不需要根据发行地区接入对应的地区包，只需要接入全球版游戏SDK即可。

这在很大程度上提高了游戏海外发行的效率，但并非最优解，在高效支持游戏差异化发行的同时，我们一直在思考如何更好的提升全球化发行效率。

基于当前的游戏业务情况，我们设想了一个比较理想的SDK接入情景：

1.  一次接入，全球适配：我们希望游戏只需接入一次SDK API，就能够轻松实现全球范围的适配工作。

2. 即拿即用，无需配置：研发无需配置游戏SDK所需要的参数，由工具自动化完成SDK的配置工作。

在当前游戏分主体地区运营策略下，如果能整合所有SDK的接入并且简化接入步骤的话，这对游戏的接入提效无疑是巨大的。

在过往的游戏业务中，我们一度维护超过20款SDK。经过两次业务重构后，SDK已缩减为6个。

由于国服和海外服的业务差异和合规要求，以及发行主体间的合规要求，SDK已无法再缩减。

在当前游戏的全球化发行的路程中，最好情况只需要接入两个SDK，但不能排除接多个SDK的情况。

在当前政策和历史技术的要求下，合并所有SDK已然不是一条能走通的路。

聚合SDK在游戏行业是比较常见的业务模式，在安卓发行中较为常见，它可以帮助开发者减少对接华为、小米、应用宝等渠道SDK的研发成本。

在我们的业务场景中，聚合SDK的任务是统一bilibili游戏业务中的各个游戏SDK，在产品上输出聚合SDK供游戏研发接入。

聚合SDK会根据游戏的发行计划在内部完成相应游戏SDK的接入和调度，原有的游戏SDK则退居二线，研发无需感知具体接入的游戏SDK。

聚合SDK完成所有游戏SDK的功能合并，对外提供统一的API。在游戏完成API接入后，由打包工具完成底层游戏SDK的接入和配置。

虽然各游戏SDK在业务逻辑上处理方案不一致，但对外提供的业务能力大致类似，比如账号体系、支付能力、客服、广告归因等能力都是通用的。这给顶层的聚合SDK——OneSDK的开发提供了先决条件。

在顶层设计上，OneSDK最大可能的合并和简化各个游戏SDK的参数差异，统一各个SDK的API定义，给游戏提供统一全面的API接口。

在业务分工中，OneSDK不直接参与游戏业务，在顶层API和底层业务SDK中充当桥接作用，当调用OneSDK API时，通过AdapterProtocol寻找可以响应API的游戏业务Adapter。

实际游戏SDK业务调用的工作在Adapter层面完成，每个游戏SDK有自己的Adapter，Adapter根据游戏SDK的特性完成参数的转换和适配，最终调用到实际的游戏业务中。

后续游戏在SDK的接入过程中，只需要接入OneSDK即可完成全球范围的发行适配工作，无需感知底层游戏SDK。

我们通过OneSDK完成了的各游戏SDK的聚合，在API层面上完成了统一。但Xcode工程的接入配置中，还是需要实际接入对应的主体游戏SDK，SDK所需要配置仍然是需要的。

如何帮助游戏快速完成底层游戏SDK的接入配置，是我们下一步需要思考的事情。

在接入OneSDK后，在API层面上已经无需感知底层SDK，在配置上我们也需要有相应方案帮助游戏避免繁复的SDK配置工作。

既然SDK接入配置无法避免，我们决定设计一款打包工具，通过脚本替代人工完成所有SDK的配置和接入工作。

在安卓中有着和iOS平台上类似的场景，在安卓中有多渠道发行的场景，一套代码需要发行谷歌、华为、小米、应用宝等不同的渠道。

对于这种情况安卓游戏SDK可以使用官方提供的APKTool工具，反编译替换SDK文件后，再回编译生成各个渠道包。

那边iOS可否像安卓一样修改母包IPA，替换相关代码和资源文件最终生成新的IPA包呢？

很遗憾，这种方法是不可靠的。iOS没有像谷歌一样官方提供的APKTool工具，来执行反编译和回编译的能力。

要想在iOS实现一套代码自动完成多渠道发行的打包，我们可以比安卓更早一步介入打包的流程中。
安卓是在源码编译成APK包体后介入打包的，我们可以在源码阶段介入，通过修改Xcode工程的方式，完成多渠道包的自动化接入。

考虑到游戏的Xcode工程动辄几十G的大小，上传下载十分耗时，以及游戏研发对源码工程泄露的担忧。打包工具在产品形式上以MacOS端的应用交付给游戏研发使用，在本地完成游戏的打包工作。

简而言之，打包工具的主要功能是在完成鉴权后，获取与发行计划对应的打包计划，然后根据该计划完成OneSDK下层的游戏SDK接入和配置。

在应用层面，（被苹果原生MacOS开发框架短暂折磨过之后）我们选择对客户端开发更为亲近的Flutter作为框架，对于轻量级的应用，Flutter统一的API体验、热重载等特性可以帮助我们快速完成应用的搭建。

在偏底层工作的Xcode工程编辑上，Flutter没有十分稳定的类库可以完成Xcode工程的编辑工作，但可以调用脚本完成前述工作。

脚本所要做的工作，可以简单归纳成以下步骤：

1. 删除游戏SDK文件夹以及里面的内容
2. 导入新的游戏SDK文件
3. 修改Info.plist文件，添加业务参数
4. 修改build-settings，添加指定编译指令
5. 导入游戏SDK所依赖的系统库

在脚本框架上，我们使用Xcodeproj模拟在Xcode界面完成的代码、资源的删除&替换操作

Xcodeproj是一个常用的修改Xcode工程的Ruby框架，由我们熟知的Cocoapods团队开发。其内部完整映射了project.pbxproj的Object类型及其对应的属性。将Xcode项目文件解析成一个抽象语法树（AST），通过遍历语法树来获取项目配置信息，并提供相应的API来修改和管理这些信息。通过代码来添加、删除、修改项目中的文件、依赖、编译选项等，以达到自动化接入的目的。

要想通过脚本修改Xcode工程，我们先要了解project.pbxproj文件。

project.pbxproj被包装在xcodeproj文件中，存储着Xcode中所有能看见的公共配置信息。它本质上是一种旧风格的 Property List 文件，历史可追溯到 NeXT 的 OpenStep。

换句话说，我们可以通过修改project.pbxproj来实现我们在Xcode中可以修改的配置。

相信很多人都有因为代码冲突而手动修改过project.pbxproj，也为project.pbxproj繁杂的内容感到眼花缭乱。这是因为project.pbxproj文件的可读性较差且内容较多。实际上project.pbxproj有固定的结构和格式，了解大致结构和分类用途就会对其认知更清晰，project.pbxproj的总体结构如下所示：

project.pbxproj结构

在project.pbxproj我们需要关注的是objects的内容，一般来说，工程越大越复杂，objects的内容就会越多。objects里面实际上是一个元素的Map, 每个Key用一个全文档唯一的uuid来表示。

objects中包含了多个Section, 也就是多种类型的信息。

以上是obejcts的简化数据内容，它包含了许多我们在Xcode中经常会用到的配置内容

1.  PBXProject： 
    - 代表整个 Xcode 项目。
    - 包含项目的全局配置和设置，如项目名称、项目根目录、构建配置等。
    - 包含了项目中的所有 `PBXNativeTarget` 的列表。

2.  PBXNativeTarget：
    -   代表一个构建目标，可以是应用程序、库或其他可执行文件。
    -   包含了该目标的具体配置，如编译器选项、输出路径、依赖关系等。

3.  PBXFileReference：
    -   代表项目中的文件或文件夹。
    -   包含文件的路径、文件类型、引用等信息。

4.  PBXGroup：
    -   用于组织项目中的文件和文件夹，以创建项目的文件结构。
    -   可以包含 `PBXFileReference` 和其他 `PBXGroup`。

5.  PBXBuildFile：
    -  描述编译阶段的文件引用，包括源文件(.m)和资源文件(xib或者storyboard).

6. PBXBuildPhase:
    - 描述编译阶段. 是一个抽象概念，实际出现的是下面具体的项目；BuildPhase对应的是Xcode图形化界面上的Build Phase配置.
    - PBXCopyFilesBuildPhase: 拷贝文件阶段.PBXFrameworksBuildPhase: Framework编译阶段
    - PBXHeadersBuildPhase: 头文件编译阶段.
    - PBXResourcesBuildPhase: 资源文件拷贝编译阶段.
    - PBXShellScriptBuildPhase: 脚本执行阶段.
    - PBXSourcesBuildPhase: 源文件编译阶段.

7.  PBXContainerItemProxy：
    -   用于管理依赖关系和跨项目引用，通常在多项目工程中使用。

8.  XCBuildConfiguration：
    -   包含特定构建配置的设置，如编译器选项、链接选项等。
    -   `XCBuildConfiguration` 对象通常属于 `PBXNativeTarget`。

9.  XCConfigurationList：
    -   用于管理构建配置列表，每个 `PBXNativeTarget` 都有一个 `XCConfigurationList

这些内容在Xcode界面中有与之类似的配置项，命名也大多近似。针对这些Section修改可以完成Xcode配置项的修改，但需要注意将所有影响项一同修改完毕，否则很容易就会导致工程文件错误。

在我们脚本操作的第一步是旧SDK包体的删除和新的SDK包体的导入。这些文件的增删、配置的修改都是基于Target修改的，在project.pbxproj中我们修改的是PBXNativeTarget Section。

以下是PBXNativeTarget文件结构

PBXNativeTarget结构

以上面文件为例，要增删Framework，我们就要去修改UUID为880288D729013C8100802937的PBXFrameworksBuildPhase Section，而要增删bundle、图片等资源文件，我们就要修改UUID为880288D829013C8100802937的PBXResourcesBuildPhase。

以删除SDK为例，脚本会去遍历SDK文件夹内的所有内容，然后将其根据文件类型分别在不同的PBXBuildPhase中移除引用，随后删除文件。

需要注意的是：Unity游戏导出的工程有两个Target，代码挂载在UnityFramework Target上，图片等资源文件则是挂载在主Target上。我们在处理Unity工程的时候要区分Target操作。

删除SDK

游戏SDK所需要编辑的参数集中在Info.plist中，这里我们使用Ruby的Plist库来执行对plist文件的修改

Plist文件采用XML格式存储数据，这种格式可读性比project.pbxproj好多了，我们可以很清晰的知道需要修改文件层级和位置。

下面的代码我们演示了如何在Xcode工程中添加权限描述文案。这些权限和描述文案来自游戏运营在发行平台上的配置，打包工具在打包时会获取最新的配置。

添加权限文案

在游戏的自动化出包流程中，打包脚本还有更多的工作，但大多都是使用Xcodeproj和Plist两个工具完成的工作。了解并掌握project.pbxproj的内容和含义，并使用Xcodeproj和Plist对其编辑修改，就可以完成绝大多数Xcode工程修改的工作。

在整体设计上，打包工具结合游戏发行系统，获取游戏维度的发行计划，研发无需感知游戏SDK所需要配置的参数。

同时打包工具将SDK版本的接入管理归拢至打包工具中，可以根据游戏的运营状态而差异化下发接入SDK的版本。

打包工具在使用上也很简单，游戏研发在登录游戏发行账号后，只需要完成三步配置即可快速完成发行包的接入。

未来后续打包工具会纳入更多契合业务模式的功能，例如接入合规检测、SDK功能自检等功能，持续为游戏的开发提效。

当前，OneSDK已交付给游戏使用，研发需要接入的SDK从最少2个减少至最多1个。打包工具将在年内上线供研发使用，在结合使用OneSDK和打包工具的情况下，预计可以帮助游戏减少60%的接入耗时。

提高效率是一个不断迭代的过程，未来，我们会站在全球发行的角度，不断完善和丰富OneSDK和打包工具，简化游戏的接入步骤，同时提供更多有用的工具帮助研发提升效率。

参考文献：

https://www.rubydoc.info/gems/xcodeproj

https://github.com/patsplat/plist

https://muhuashanjin.github.io/2017/10/09/2017-10-09-Project.pbxproj/

在开发中，你做过哪些比较有意思的提效工具，达到了什么效果呢？欢迎在留言区告诉我们。转发并留言，小编将选取1则最有价值的评论，送出小电视校园系列金属徽章两只（见下图）。1月30日中午12点开奖。如果喜欢本期内容的话，欢迎点个“在看”吧！