Unity3D 手游版本构建之路

发表于2016-10-31
评论23 1.05w浏览

前言
  从Web转Unity开发也有一段时间,抛开语言上的差异,觉得最大的不同就是版本构建上的区别,前期项目启动的时候,通过Unity自带的构建也能完成简单版本发布,定期将完成的功能编出一个手机版本,发到RTX上,同事们下载,安装,体验,流程简单流畅,但到了项目进入稳定阶段后,开始进入日版本的节奏,这样的流程已满足不了要求,每天花在构建上的时间特别长,大大影响工作效率,出了问题还得重新构建,项目组几十号人在等着你电脑桌面上那一动不动的进度条,心里慌得很……
  经历了多个日夜的煎熬后,开始对构建流程进行优化改进,经过技术、流程、资源规划等多方面调整后,逐步形成了较成熟的构建方案,下面总结一下整个版本构建的发展历程(下方话唠出没,并且没提供代码方面的东西,主要是方案的介绍):

一、手工业时代(如何构建项目)
  最基本的版本发布,如前言所说的,我们可以通过Unity自带的构建功能,进行版本发布,通过File > BuildSettings,打开Build Settings面板,然后选中我们需要构建的平台,进行必要的设置后,点击"Build"按钮,再通过漫长(视项目而定)的等待,安装包就编出来了,对于iOS平台,Unity只提供导出XCode项目的功能,最终还需要通过XCode进行编译打包(IPA最终需要到 RDM 平台进行企业证书签名才能在非越狱的设备上安装)。


       
 这也是Unity为我们提供的最基础的,最“快捷简便”的版本构建方案。

二、工业时代(如何通过脚本构建项目)
  上面的方法能满足较的小团队或者个人开发者,可随心所欲的进行版本发布,但对于较大的项目,版本构建时经常需要进行一些设置,像编译参数,版本号设置,文件增删改等,大量琐碎的操作增加了复杂度与出错概率,为了解决这个问题,我们可以通过调用Unity提供构建API,对项目发起构建,并在构建前通过代码进行相关的设置,最终只需要点一下菜单,版本就编出来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//构建脚本伪代码
[MenuItem("Build/BuildForAndroid", false, 0)]  
public static void BuildForAndroid()
{
    //进行一些业务中的设置
    ...
    ...
    ...
    //进行一些构建的配置
    EditorPrefs.SetString("AndroidSdkRoot", "...");
    EditorPrefs.SetString("AndroidNdkRoot", "...");
    PlayerSettings.Android.keystoreName = "xxx.keystore";
    PlayerSettings.Android.keystorePass = "xxx";
    PlayerSettings.Android.keyaliasName = "xxx";
    PlayerSettings.Android.keyaliasPass = "xxx";
    BuildPipeline.BuildPlayer(scenes, "xxx.apk", BuildTarget.Android, options);
}


三、自动化时代(如何自动构建项目)
  虽然已经做到了一键构建版本,但对于处于日版本节奏的项目,每天人为进行版本发布,效率还是很低,特别是负责版本构建的同学电脑还被占用(或者是专门用于构建的电脑),时刻关注构建的进度与结果,最后还需要进行人工分发。这时我们可以使用"持续集成工具",一般的情况下,使用比较多的是像"Jenkins"这样的开源项目,但在腾讯里,公司已经为我们提供了像RDMSODA等成熟的研发平台,我们只需要通过简单的申请与配置,即可将项目搭建到对应的平台上(搭建的方法在KM上已经有比较详细的介绍,还可以@RDM小秘书 或 @互娱研发小助手 了解)。
  RDMSODA都为我们提供了手动构建,定时构建,触发构建等功能,还带分发安装,iOS还支持自动进行企业证书签名,构建成功与失败提供邮件日报等通知,能满足稳定的版本构建需求。

  另外Unity也提供了命令行的调用方式,可以通过命令行直接调用我们准备好的构建命令(如上面第二部份提供的伪代码),iOS平台也能通过XCode提供的命令直接打包为IPA文件。

1
2
3
4
5
6
//构建脚本伪代码
//$UNITY_PATH Unity安装路径
//$PROJECT_PATH 项目路径
//BuildClass.BuildMethod 提供构建命令的类与方法
//$LOG_PATH 日志路径
$UNITY_PATH -batchmode -projectPath $PROJECT_PATH -executeMethod BuildClass.BuildMethod -quit -logFile $LOG_PATH
对于需要日版本的项目来说,使用定时构建的功能,每天到公司,就能下载到最新的游戏。

四、自动化时代2.0(如何快速构建项目,1小时 > 5分钟)
  一般的情况下,项目到了第三部份后,已经能满足大多情况下的版本构建需求,但在项目研发过程中,还是出现了一些问题:
  1、构建时间过长:项目体积慢慢变大,对于构建安装包在300M左右的项目时,整体的构建时间在40分钟至1小时左右(根据需要处理的资源量情况而定,对于新Checkout的项目时间更长)。
  2、安装时间过长:安装包上2/300M后,在公司的无力WIFI下,下载+安装需要10+分钟,iOS抽风的话,半个小时装不上一个版本也是常有的事。
  3、版本杂乱:每位同事安装的版本杂乱,有的同事可能几天不更新,出了问题后需要频繁确认版本情况。

  为了解决上面的问题(当然也是项目需要),进行了再次优化,优化点分别是AssetBundle打包与IIPS接入:
  1、全资源AssetBundle打包+分项目构建:当前项目中使用了全资源打包方案,除了代码外,所有资源都进行AssetBundle打包,并且,在构建平台里,将资源与应用程序分为二个项目,一个项目将资源构建为AssetBundle并上传至SVN保存,另一个项目构建时将SVN上的AssetBundle拉下来并打包到安装包中,好处在于,当只修改了代码的情况下,只需要构建代码就可以,一般情况下大概只需要5分钟就能完成一个版本的构建,对于需要真机调试,并频繁修改代码的情况时,节省了大量编译时间。
  2、IIPS:IIPS是Apollo提供了一套更新方案,可以实现版本更新检测,APK全量/增量下载与安装,资源包全量与增量更新等,当前项目除了接入IIPS外,还进一步实现了CDN自动上传+TVersion自助发布,对于构建完的版本,通过运维提供的脚本,可自助上传到CDN中,然后通过TVersion的脚本,进行版本升级等操作,实现一键构建+发布,再加上构建平台提供的定时构建功能,实现了每天睡醒起床打开游戏,提醒安装最新版本游戏,经过快速增量下载安装后,就可以愉快的体验游戏了。

五、自动化时代3.0(如何快速安装项目,300M > 40M)
  在经过了上面的优化后,版本发布的工作已经进入了全自动化的操作,日版本已经不需要进过人为干预。似乎已经美丽的小康生活($_$)已经到来,但身为不纠结会死星人,还是多多少少发现了一些问题:
  1、iOS无法实现IPA增量更新:由于开发过程中iOS是通过Apple提供的itms-services协议进行在线安装,该安装方法需要完整的下载安装包后进行覆盖安装(Android可以通过IIPS提供的工具对APK进行增量更新)。虽然资源可以通过IIPS进行增量更新,但由于每天都会改动代码,所以每天安装包都会更新,所以每天还是需要下载300M+的安装包,非常浪费时间。
  为了解决这个问题,修改了游戏的打包策略,除了支持全量打包外(所有资源都打进安装包内),还支持最小安装包(只打包必要的资源,进游戏后进行二次资源更新),通过该方案打包后,iOS安装包只剩下40M(Android为30M+),实施该方案后,iOS每天只需要下载40M安装包+资源的增量,一般1-2分钟即完成更新进入新版本愉快的玩耍(Android由于支持APK增量更新,可以延用全量打包方案,减少下载步骤)。
  2、新设备快速体验:即使在已安装的版本中,能够进行快速版本更新,但在测试新设备时,还是需要较长的时间,特别是在只为了测试某些设备上的BUG,或者为了快速演示一下游戏功能。在该需求的驱使下,修改了本地资源加载的相关代码,使之支持远程AB包的加载,在开启了远程AB的模式后(笑称为页游模式),进入游戏时所有资源将直接从CDN进行下载(前面提到了AB包是通过单独任务构建的,构建成功后会上传一份资源到CDN上),在该模式下,新设备只需要安装40M(iOS)/30M(Android)最小安装包,即可体验完整的游戏。

六、智能化时代(如何智能构建项目,30分钟 > 5分钟)
  上面提到的资源与安装包分离打包,可使安装包的打包速度变快,构建时只需要从SVN拉取打包好的资源到安装包内即可,但对于资源构建的时间并不能有效优化,平均的构建时间在20-30分钟左右(300M左右的资源量),为了优化打包时间,增加了增量打包的功能(5.x的打包参数支持,由于一些原因,项目还在使用4.x的打包API),通过分析SVN的更新日志决定需要更新的资源种类(理论上可以细化为最终资源,但目前细分到种类),然后只构建对应种类的资源即可,细分种类后每类资源的打包时间在5分钟左右,然后将资源打包的任务设置为"源码更新后自动启动",最后只要策划、美术、程序同学提交配置、资源,对应的AB包就会在5分钟内构建结束并上传SVN等待打包。
总结
  至止,从手动到自动,从1小时到10分钟,从全量到增量,实现了一套较"完善而纠结"的构建方案,结合了构建,更新,资源打包等需求,但即使到了最后,相信未来一定会根据项目的发展而不停的继续调整优化改进。
  希望有朝一日能进入神化时代(╯°□°)╯︵ ┻━┻。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引