本期作者
徐晨晨
哔哩哔哩高级开发工程师
1、前言
游戏SDK作为游戏技术中台赋能游戏研发的核心产品之一,其核心能力包括账号、交易、合规(实名、防沉迷),以及社交、营销等能力。为游戏开发者提供了便捷的方式快速完成底层业务能力的搭建,降低开发和维护的难度。帮助游戏研发更专注于游戏内容的创作,缩短游戏研发周期的同时保障游戏的安全性合规性。
2、背景
为了更有效的满足不同地区市场的策略和法规要求,为不同地区提供符合当地玩家喜好的游戏体验,哔哩哔哩游戏在发行上采取差异化的运营和推广策略。
游戏在发行中会按地区和主体分包发行,我们将游戏的主体和地区发行方案称为发行计划。
游戏SDK作为游戏的底层业务支撑,为了适配游戏的发行计划,也提供了与之对应的游戏SDK。
随着游戏业务的发展,游戏SDK的数量也不断增加。在保障游戏业务发展的同时,我们整合了所有海外发行的SDK,游戏在海外发行中不需要根据发行地区接入对应的地区包,只需要接入全球版游戏SDK即可。
这在很大程度上提高了游戏海外发行的效率,但并非最优解,在高效支持游戏差异化发行的同时,我们一直在思考如何更好的提升全球化发行效率。
3、定个小目标
基于当前的游戏业务情况,我们设想了一个比较理想的SDK接入情景:
一次接入,全球适配:我们希望游戏只需接入一次SDK API,就能够轻松实现全球范围的适配工作。
即拿即用,无需配置:研发无需配置游戏SDK所需要的参数,由工具自动化完成SDK的配置工作。
在当前游戏分主体地区运营策略下,如果能整合所有SDK的接入并且简化接入步骤的话,这对游戏的接入提效无疑是巨大的。
4、 方案选择
1、重构现有游戏SDK,合并所有SDK
在过往的游戏业务中,我们一度维护超过20款SDK。经过两次业务重构后,SDK已缩减为6个。
由于国服和海外服的业务差异和合规要求,以及发行主体间的合规要求,SDK已无法再缩减。
在当前游戏的全球化发行的路程中,最好情况只需要接入两个SDK,但不能排除接多个SDK的情况。
在当前政策和历史技术的要求下,合并所有SDK已然不是一条能走通的路。
2、在游戏SDK的上层设计聚合SDK,
通过出包工具自动化接入
聚合SDK在游戏行业是比较常见的业务模式,在安卓发行中较为常见,它可以帮助开发者减少对接华为、小米、应用宝等渠道SDK的研发成本。
在我们的业务场景中,聚合SDK的任务是统一bilibili游戏业务中的各个游戏SDK,在产品上输出聚合SDK供游戏研发接入。
聚合SDK会根据游戏的发行计划在内部完成相应游戏SDK的接入和调度,原有的游戏SDK则退居二线,研发无需感知具体接入的游戏SDK。
聚合SDK完成所有游戏SDK的功能合并,对外提供统一的API。在游戏完成API接入后,由打包工具完成底层游戏SDK的接入和配置。
5、如何做?
5.1、OneSDK统一API
虽然各游戏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的接入配置,是我们下一步需要思考的事情。
5.2、打包工具实现自动化接入
在接入OneSDK后,在API层面上已经无需感知底层SDK,在配置上我们也需要有相应方案帮助游戏避免繁复的SDK配置工作。
既然SDK接入配置无法避免,我们决定设计一款打包工具,通过脚本替代人工完成所有SDK的配置和接入工作。
在安卓中有着和iOS平台上类似的场景,在安卓中有多渠道发行的场景,一套代码需要发行谷歌、华为、小米、应用宝等不同的渠道。
对于这种情况安卓游戏SDK可以使用官方提供的APKTool工具,反编译替换SDK文件后,再回编译生成各个渠道包。
那边iOS可否像安卓一样修改母包IPA,替换相关代码和资源文件最终生成新的IPA包呢?
很遗憾,这种方法是不可靠的。iOS没有像谷歌一样官方提供的APKTool工具,来执行反编译和回编译的能力。
要想在iOS实现一套代码自动完成多渠道发行的打包,我们可以比安卓更早一步介入打包的流程中。
安卓是在源码编译成APK包体后介入打包的,我们可以在源码阶段介入,通过修改Xcode工程的方式,完成多渠道包的自动化接入。
5.2.1、打包工具设计
考虑到游戏的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来修改和管理这些信息。通过代码来添加、删除、修改项目中的文件、依赖、编译选项等,以达到自动化接入的目的。
5.2.2 project.pbxproj 介绍
要想通过脚本修改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结构
// !$*UTF8*$!
{
archiveVersion = 1;
classes = {
};
objectVersion = 46;
objects = {
...
}
rootObject = E6A557831C22979700A81AD5 /* Project object */;
}
在project.pbxproj我们需要关注的是objects的内容,一般来说,工程越大越复杂,objects的内容就会越多。objects里面实际上是一个元素的Map, 每个Key用一个全文档唯一的uuid来表示。
objects中包含了多个Section, 也就是多种类型的信息。
// !$*UTF8*$!
{
archiveVersion = 1;
classes = {
};
objectVersion = 56;
objects = {
/* Begin PBXBuildFile section */
XXXXXXXXXXXXXXXXXXXXXXXXXXX /* AppDelegate.m in Sources */ = {isa = PBXBuildFile; fileRef = 880B73262AE53EFB00027A9F /* AppDelegate.m */; };
/* End PBXBuildFile section */
/* Begin PBXFileReference section */
/* End PBXFileReference section */
/* Begin PBXFrameworksBuildPhase section */
/* End PBXFrameworksBuildPhase section */
/* Begin PBXGroup section */
880B73192AE53EFB00027A9F = {
isa = PBXGroup;
children = (
XXXXXXXXXXXXXXXXXXXXXXXX* DEMO */,
880B73232AE53EFB00027A9F /* Products */,
);
sourceTree = "<group>";
};
/* End PBXGroup section */
/* Begin PBXNativeTarget section */
880B73212AE53EFB00027A9F /* DEMO */ = {
isa = PBXNativeTarget;
buildConfigurationList = 880B733B2AE53EFC00027A9F /* Build configuration list for PBXNativeTarget "DEMO" */;
buildPhases = (
880B731E2AE53EFB00027A9F /* Sources */,
880B731F2AE53EFB00027A9F /* Frameworks */,
XXXXXXXXXXXXXXXXXXXXXXXX /* Resources */,
);
buildRules = (
);
dependencies = (
);
name = DEMO;
productName = DEMO;
productReference = 880B73222AE53EFB00027A9F /* DEMO.app */;
productType = "com.apple.product-type.application";
};
/* End PBXNativeTarget section */
};
rootObject = 880B731A2AE53EFB00027A9F /* Project object */;
}
以上是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配置项的修改,但需要注意将所有影响项一同修改完毕,否则很容易就会导致工程文件错误。
5.2.3、脚本操作之增删改查
在我们脚本操作的第一步是旧SDK包体的删除和新的SDK包体的导入。这些文件的增删、配置的修改都是基于Target修改的,在project.pbxproj中我们修改的是PBXNativeTarget Section。
以下是PBXNativeTarget文件结构
PBXNativeTarget结构
880288D929013C8100802937 /* OneSDKDemo */ = {
isa = PBXNativeTarget;
buildConfigurationList = 880288F329013C8300802937 /* Build configuration list for PBXNativeTarget "OneSDKDemo" */;
buildPhases = (
880288D629013C8100802937 /* Sources */,
880288D729013C8100802937 /* Frameworks */,
880288D829013C8100802937 /* Resources */,
);
buildRules = (
);
dependencies = (
);
name = OneSDKDemo;
productName = OneSDKDemo_GSO;
productReference = 880288DA29013C8100802937 /* OneSDKDemo.app */;
productType = "com.apple.product-type.application";
};
以上面文件为例,要增删Framework,我们就要去修改UUID为880288D729013C8100802937的PBXFrameworksBuildPhase Section,而要增删bundle、图片等资源文件,我们就要修改UUID为880288D829013C8100802937的PBXResourcesBuildPhase。
以删除SDK为例,脚本会去遍历SDK文件夹内的所有内容,然后将其根据文件类型分别在不同的PBXBuildPhase中移除引用,随后删除文件。
需要注意的是:Unity游戏导出的工程有两个Target,代码挂载在UnityFramework Target上,图片等资源文件则是挂载在主Target上。我们在处理Unity工程的时候要区分Target操作。
删除SDK
def delete_group(group)
group.files.each do |file|
if file.real_path.to_s.end_with?('.m', '.mm', '.cpp', '.h', '.swift')
@code_target.source_build_phase.remove_file_reference(file)
delete_path(file.real_path)
file.remove_from_project
elsif file.real_path.to_s.end_with?('.a') || file.real_path.to_s.end_with?('.framework')
@code_target.frameworks_build_phases.remove_file_reference(file)
delete_path(file.real_path)
file.remove_from_project
elsif file.real_path.to_s.end_with?('.plist', '.bundle')
@main_target.resources_build_phase.remove_file_reference(file)
delete_path(file.real_path)
file.remove_from_project
end
end
group.version_groups.each do |child|
if child.real_path.to_s.end_with?('.xcdatamodeld')
@main_target.resources_build_phase.remove_file_reference(child)
delete_path(child.real_path)
child.remove_from_project
else
delete_group(child, delete_files)
end
end
group.groups.each do |child|
delete_group(child)
end
end
5.2.4、脚本操作之参数配置
游戏SDK所需要编辑的参数集中在Info.plist中,这里我们使用Ruby的Plist库来执行对plist文件的修改
Plist文件采用XML格式存储数据,这种格式可读性比project.pbxproj好多了,我们可以很清晰的知道需要修改文件层级和位置。
下面的代码我们演示了如何在Xcode工程中添加权限描述文案。这些权限和描述文案来自游戏运营在发行平台上的配置,打包工具在打包时会获取最新的配置。
添加权限文案
# 增加权限描述字符串
def add_app_permissions(target_name, permissions)
return if permissions.nil?
plist_full_path = info_plist_path(target_name)
info = Plist.parse_xml(plist_full_path)
permissions.each do |key, value|
puts 'key : ', key, 'value:', value
info[key] = value
end
Plist::Emit.save_plist(info, plist_full_path)
end
在游戏的自动化出包流程中,打包脚本还有更多的工作,但大多都是使用Xcodeproj和Plist两个工具完成的工作。了解并掌握project.pbxproj的内容和含义,并使用Xcodeproj和Plist对其编辑修改,就可以完成绝大多数Xcode工程修改的工作。
5.2.5、打包工具概览
在整体设计上,打包工具结合游戏发行系统,获取游戏维度的发行计划,研发无需感知游戏SDK所需要配置的参数。
同时打包工具将SDK版本的接入管理归拢至打包工具中,可以根据游戏的运营状态而差异化下发接入SDK的版本。
打包工具在使用上也很简单,游戏研发在登录游戏发行账号后,只需要完成三步配置即可快速完成发行包的接入。
未来后续打包工具会纳入更多契合业务模式的功能,例如接入合规检测、SDK功能自检等功能,持续为游戏的开发提效。
6、未来规划
当前,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点开奖。如果喜欢本期内容的话,欢迎点个“在看”吧!
往期精彩指路
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...