Unity手游版本构建之路

前言

　　从Web转Unity开发也有一段时间，抛开语言上的差异，觉得最大的不同就是版本构建上的区别，前期项目启动的时候，通过Unity自带的构建也能完成简单版本发布，定期将完成的功能编出一个手机版本，同事们下载，安装，体验，流程简单流畅，但到了项目进入稳定阶段后，开始进入日版本的节奏，这样的流程已满足不了要求，每天花在构建上的时间特别长，大大影响工作效率，出了问题还得重新构建，项目组几十号人在等着你电脑桌面上那一动不动的进度条，心里慌得很……

经历了多个日夜的煎熬后，开始对构建流程进行优化改进，经过技术、流程、资源规划等多方面调整后，逐步形成了较成熟的构建方案，下面总结一下整个版本构建的发展历程（下方话唠出没，并且没提供代码方面的东西，主要是方案的介绍）：

 

一、手工业时代（如何构建项目）

　　最基本的版本发布，如前言所说的，我们可以通过Unity自带的构建功能，进行版本发布，通过File > Build Settings，打开Build Settings面板，然后选中我们需要构建的平台，进行必要的设置后，点击"Build"按钮，再通过漫长（视项目而定）的等待，安装包就编出来了，对于iOS平台，Unity只提供导出XCode项目的功能，最终还需要通过XCode进行编译打包。

 

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

 

二、工业时代（如何通过脚本构建项目）

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

//构建脚本伪代码 

[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"这样的开源项目，但在腾讯里，公司已经为我们提供了成熟的研发平台，我们只需要通过简单的申请与配置，即可将项目搭建到对应的平台上。

　　这类持续集成工具都为我们提供了手动构建，定时构建，触发构建等功能，通过简单的配置还能支持分发安装，构建成功与失败提供邮件日报等通知，能满足稳定的版本构建需求。

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

//构建脚本伪代码

//$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保存，另一个项目构建时将库中的AssetBundle拉下来并打包到安装包中，好处在于，当只修改了代码的情况下，只需要构建代码就可以，一般情况下大概只需要5分钟就能完成一个版本的构建，对于需要真机调试，并频繁修改代码的情况时，节省了大量编译时间。

　　2、IIPS：IIPS是Apollo提供了一套更新方案，可以实现版本更新检测，APK全量/增量下载与安装，资源包全量与增量更新等，当前项目除了接入IIPS外，还进一步实现了CDN自动上传+TVersion自助发布，对于构建完的版本，通过运维提供的脚本，可自助上传到CDN中，然后通过TVersion的脚本，进行版本升级等操作，实现一键构建+发布，再加上构建平台提供的定时构建功能，实现了每天睡醒起床打开游戏，提醒安装最新版本游戏，经过快速增量下载安装后，就可以愉快的体验游戏了。

 

五、自动化时代3.0（如何快速安装项目，300M > 40M）

　　在经过了上面的优化后，版本发布的工作已经进入了全自动化的操作，日版本已经不需要进过人为干预。似乎已经美丽的小康生活（$_$）已经到来，但身为不纠结会死星人，还是多多少少发现了一些问题：

　　１、iOS无法实现IPA增量更新：由于开发过程中iOS是通过Apple提供的itms-services协议进行在线安装，该安装方法需要完整的下载安装包后进行覆盖安装（Android可以通过IIPS提供的工具对APK进行增量更新）。虽然资源可以通过IIPS进行增量更新，但由于每天都会改动代码，所以每天安装包都会更新，所以每天还是需要下载300M+的安装包，非常浪费时间。

　　为了解决这个问题，修改了游戏的打包策略，除了支持全量打包外（所有资源都打进安装包内），还支持最小安装包（只打包必要的资源，进游戏后进行二次资源更新），通过该方案打包后，iOS安装包只剩下40M（Android为30M+），实施该方案后，iOS每天只需要下载40M安装包+资源的增量，一般1-2分钟即完成更新进入新版本愉快的玩耍（Android由于支持APK增量更新，可以延用全量打包方案，减少下载步骤）。

　　２、新设备快速体验：即使在已安装的版本中，能够进行快速版本更新，但在测试新设备时，还是需要较长的时间，特别是在只为了测试某些设备上的BUG，或者为了快速演示一下游戏功能。在该需求的驱使下，修改了本地资源加载的相关代码，使之支持远程AB包的加载，在开启了远程AB的模式后（笑称为页游模式），进入游戏时所有资源将直接从CDN进行下载（前面提到了AB包是通过单独任务构建的，构建成功后会上传一份资源到CDN上），在该模式下，新设备只需要安装40M（iOS）/30M（Android）最小安装包，即可体验完整的游戏。

 

六、智能化时代（如何智能构建项目，30分钟 > 5分钟）

　　上面提到的资源与安装包分离打包，可使安装包的打包速度变快，构建时只需要从库拉取打包好的资源到安装包内即可，但对于资源构建的时间并不能有效优化，平均的构建时间在20-30分钟左右（300M左右的资源量），为了优化打包时间，增加了增量打包的功能（5.x的打包参数支持，由于一些原因，项目还在使用4.x的打包API），通过分析库的更新日志决定需要更新的资源种类（理论上可以细化为最终资源，但目前细分到种类），然后只构建对应种类的资源即可，细分种类后每类资源的打包时间在5分钟左右，然后将资源打包的任务设置为"源码更新后自动启动"，最后只要策划、美术、程序同学提交配置、资源，对应的AB包就会在5分钟内构建结束并上传库等待打包。

 

总结

　　至止，从手动到自动，从1小时到10分钟，从全量到增量，实现了一套较"完善而纠结"的构建方案，结合了构建，更新，资源打包等需求，但即使到了最后，相信未来一定会根据项目的发展而不停的继续调整优化改进。

　　希望有朝一日能进入神化时代(╯°□°）╯︵ ┻━┻。