转载请标明出处：http://www.cnblogs.com/zblade/

0x01 目的

在实际的游戏开发中，对于游戏都需要进行打补丁的操作，毕竟，测试是有限的，而bug是无法预估的。那么在手游中，unity对于打补丁的方式就是提供热更新。本文主要针对assetbundle的热更新流程进行设计探讨，抛砖引玉，希望有更优的解决方案。

0x02 基本流程

在实际的游戏开发中，常常会被assetbundle的热更新折腾的无法入眠，每次在进行热更新的时候都需要反复测试，因为这牵涉着实际的上线游戏运行。

为了提高热更新的鲁棒性，优秀的做法，就是将热更新放在平时的开发中，伴随着开发中进行每天的热更新校验，让开发人员，策划人员，测试人员，甚至美术人员，都参与到实际的热更新中，这样可以在平时就测试出可能出现的Bug，从而避免在游戏需要热更新时候的紧急测试。

为了实现即时开发即时热更新的机制，我们就需要设计好热更新流程，明晰的设计方案，可以指导实际的开发工作。对于流程设计，我主要分为两个部分进行分别探讨：

1、如何快速打出assetbunle包

要实现ab的热更新，那么unity打ab就是一个关键点。在以前的项目开发中，打ab包，是一个很头疼的事情，特别是在资源量迭代增大之后，在后期的开发中，打ab包就是一个极为费时的步骤。

分析其费时的原因，是由于在每次打ab包的时候，如果每次都是重新打ab包，那么自然每次都是极为费时的。Unity提供了一种增量打包的方式，具体可以查看相关API，只要在固定的输出路径中进行增量打包，那么每次打ab包的时候，只会对变化（增删）和新增的ab进行重新打ab，所以只要分析好资源的依赖关系，然后设置好ab对应的name，剩下的增量打包操作只需要交给unity去执行即可。

2、基于快速打ab包，快速在真机上验证资源的更新

完成快速的ab打包后，只需要上传到资源机/cdn上，在手机上即可实现实时的ab更新，那么日常开发中如果对于美术资源在手机上的效果需要即刻测试，那么只需要提交资源，然后执行打ab操作，上传到资源机/cdn等上，然后更新到手机上快速验证效果。

3、基于快速打ab包，实现小包的打包方式

在日常开发中，每次打游戏包，都会带来安装包包体较大，特别是在游戏后期，资源量大，对应的游戏包包体极大，每次测试在安装的时候，下载包体就很费时。而快速打ab包，可以将这部分工作进行优化。每次打游戏包的时候，可以区分是否携带ab资源。如果不携带ab资源，那么整体的游戏包只需要进行代码编译和相关打包，而游戏中使用的资源，可以通过ab更新的方式，实时更新，每次有资源替换就更新ab资源，这样测试每天开启测试工作的时候，只需要少量更新，即可快速测试。

这样的小包模式，适合版本功能测试的分支开发中，如果Lua文件也用热更新的方式，那么一个小包可以较为持续的测试对应功能，当功能测试完成后，即可合并到主分支。

既然有小包，那么对应的就会有大包。这儿所谓的大包，就是将该版本的ab资源一起打入在游戏安装包中。在平时的资源提交中，都会触发对应的ab资源打包，所以当执行打打包的时候，耗费在ab中的实际不会很长，这样可以整体优化打安装包的时间。

0x03 如何利用jenkins来执行日常资源打ab包

说完快速打ab的优点后，说说怎么利用jenkins来实现快速打ab包。

日常简单的build工作，可以分配一台单独的资源打包机执行打资源ab包即可。利用开源的jenkins，可以较为快速的实现打ab操作。

jenkins可以配合Git/SVN实现相关的hook，在每次Git/SVN的服务器中，有push tag/post-commit操作的时候，都可以调用jenkins的API来执行相关的job。在相关job中调用unity的命令行来实现打ab操作。

如果存储空间允许，可以将工程切分为不同平台，利用Jenkins的pipeline实现并发打ab操作，实现高效的打ab包操作。

简易的效果图如下：

0x04 整体示意图

综上所述，可以画出整体示意图，懒得画了，就随手拍一张手绘吧 (忽略我的灵魂画法):D