前言
本文主要引用cocos关于热更的官方文档，并在此基础上，总结sprout当前热更流程。
什么是热更
热更（新）本质上是从服务器下载需要的资源到本地，并且可以执行新的游戏逻辑，让新资源可以被游戏所使用，它可以使开发者在不发布新版本的情况下，修复 BUG 和发布功能，让开发者得以绕开苹果的审核机制，避免长时间的审核等待以及多次被拒造成的成本。
Cocos 默认的热更新机制并不是基于补丁包更新的机制，传统的热更新经常对多个版本之间分别生成补丁包，按顺序下载补丁包并更新到最新版本。Cocos 的热更新机制通过直接比较最新版本和本地版本的差异来生成差异列表并更新。
cocos热更概述
manifest
了解cocos热更之前，先要了解manifest。在cocos中，manifest是一种文件格式，其对应的文件简称资源描述文件，是用来描述本地或远程包含的资源列表及资源版本。
manifest格式是仿照json格式，其关键字段的含义如下 :
{
"packageUrl" : 远程资源的本地缓存根路径
"remoteVersionUrl" : [可选项] 远程版本文件的路径，用来判断服务器端是否有新版本的资源
"remoteManifestUrl" : 远程资源 Manifest 文件的路径，包含版本信息以及所有资源信息
"version" : 资源的版本
"engineVersion" : 引擎版本
"assets" : 所有资源列表
"key" : 资源的相对路径（相对于资源根目录）
"md5" : md5 值代表资源文件的版本信息
"compressed" : [可选项] 如果值为 true，文件被下载后会自动被解压，目前仅支持 zip 压缩格式
"size" : [可选项] 文件的字节尺寸，用于快速获取进度信息
"searchPaths" : 需要添加到 FileUtils 中的搜索路径列表
}Manifest 文件可以通过 Cocos Creator 热更新范例中的 Version Generator脚本 来自动生成。
工程资源和游戏包内资源的区别
大家在创建一个 Cocos Creator 工程的时候，可以看到它的目录下有 assets 目录，里面保存了你的场景、脚本、prefab 等，对应编辑器中的 assets 面板。但是这些工程资源并不等同于打包后的资源，在使用构建面板构建原生版本时，我们会在构建目录下找到 res 和 src 文件夹，这两个文件夹内保存的才是真正让游戏运行起来的游戏包内资源。其中 src 包含所有脚本，res 包含所有资源。
所以我们的资源热更新自然应该更新构建出来的资源，而不是工程的 assets 目录。
在creator2.4.3中，重构了资源管理模块，采用bundle模块化管理资源。这里分享一个通过uuid来获取资源路径的API
cc.assetmanager.utils.getUrlWithUuid //转换 uuid 为 url,这里返回的url是运行时游戏包内的资源路径searchPaths搜索路径
在谈到热更之前，关于searchPaths的概念，有必要先了解一下。在大多数的时候，我们描述一个文件的路径，都会基于一个”根目录“去给到对应的”相对路径“，并不会直接写死成”绝对路径“，这样更利于维护、迁移。在游戏开发中，其实我们”根目录“也是很难保证其确定性、唯一性。就拿热更功能而言，我们有一个图片，假设其对应bundle目录（默认是resources）的相对路径是 ”./png/icon1.png“，当我们游戏版本更新，需要更新该图片的时候，由于包内的资源是不可写的，那我们只能让其从另外一个地方读取到新的图片，为了保证代码的一致性，如果我们可以改变其对应的”根目录“，那代码中之前的相对路径都不需要修改，就能找到新的图片。
在creator中，其维护勒一套搜索路径的策略。对应的API可以查阅jsb.fileUtils.getSearchPaths、jsb.fileUtils.fullPathForFilename等。这里简述其原理。FileUtils中保存勒一个”根目录“数组，index越低的优先级越高，在查找资源的时候，我们如果指定的是”相对路径“，则其会按照searchPaths里面的”根目录“的优先级，去拼接成”绝对路径“去查找资源，如果路径有效，找到勒文件，则会停止继续寻找。
在游戏包的安装目录，肯定有一个目录是存放我们打包后的各种脚本、资源，我们这里称之为”游戏包目录“，在热更逻辑中，我们需要指定一个”热更目录“来存放我们热更的内容，这两个目录都应该设为搜索路径，并且需要控制版本，使优先级更高的目录，对应的搜索路径优先级也要越高，这样，我们才能找到最新的文件。一般而言，”热更目录“的优先级需要高于”游戏包目录“。
cocos的基础热更流程
这是cocos官网资料的流程图，注意，当前流程是用户安装好 app 后，第一次检查到服务端的版本更新的情况，完整的热更流程会更为复杂一些，后面我们再慢慢补充。
本文主要帮助大家理解热更本身的流程逻辑，其各个细节，如断点续传、下载进度、并发下载、错误检测、解压缩、错误恢复等细节问题，暂不讨论。所以，把上诉流程图，可简单概况为：
根据当前包内的manifest的remoteVersionUrl字段，去下载其当前的版本描述文件，然后根据与本地的版本对比，若需要更新则更新到对应最新版本，不然就不需要更新，继续后续流程。
这里需要对其几个关键点，再细化剖析一下：
_localManifest：当前包内的manifest
首先，”游戏包目录“内应该有一个默认的manifest文件，描述当前游戏版本（"version"字段），这个manifest一般随游戏包卸载、安装来更新。然后在”热更目录“也会有一个manifest文件，描述当前热更目录下的版本信息。我们每次启动游戏的时候都应该判断一下，当前环境下，到底是”游戏包目录“，还是”热更目录“才是最新的版本，来调整其对应在searchPaths的优先级，较新的manifest也就称为当前包内的manifest，代码中用_localManifest来记录。
注意，上述cocos基础热更流程中，并没有这一步，是因为其表示流程是包第一次安装的情况，热更目录下是没有manifest文件，所以_localManifest就是”游戏包目录“，完整的热更流程是需要做这一步判断的。
上诉逻辑对应的代码，请参阅：AssetsManagerEx的init、loadLocalManifest等函数。
先请求远端版本manifest
在manifest的”remoteVersionUrl“字段中，其对应的是远端服务器的版本文件，下面给到官方demo的一个version.manifest，便于大家理解
{
"packageUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/",
"remoteManifestUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/project.manifest",
"remoteVersionUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/version.manifest",
"version":"2.0"
}从上面可以看到，version.manifest有一个“version”字段，这也是我们快速进行版本对比的依据。下载version.manifest，然后再与本地_localManifest的版本对比，来检测当前包是否需要更新，这个过程代码上一般命名为checkUpdate。
临时文件夹的必要性
在热更过程中，因为我们是多个资源依次下载的，这期间很可能出现各种问题，所有，我们需要一个临时文件夹来暂存我们的下载，等到全部文件下载结束后，还需要检测文件是否完整，才能去替换“热更目录”下的旧资源，不要直接在“热更目录”上下载，一旦出现问题，自己也搞不清那部分是新的，那部分是还是旧的。这种思路在程序设计中也可以借鉴体会，我们负责的一些数据、字段的维护，尽量能做到整体的替换更新，而不是到处随意的去修改、赋值。
热更是热更差异化文件，是怎么做到这点的
在manifest文件中，"assets"字段下，记录每个资源的key和md5信息，只需要远端的_remoteManifest下记录的资源进行对比，新的key则是新增资源，没有的key则是需要删除的资源，md5不同的就是需要更新的文件。
对应的代码，请参阅：Manifest的genDiff等函数。
热更好之后，怎么让其生效
当我们热更好了新的资源后，怎么在不需要调整代码的情况下，让其生效？哈哈，刚刚上文已经介绍过了，我们调整我们的searchPaths，让“热更目录”优先级高于“游戏包目录”即可。
上面的流程图中，cocos推荐的是用cc.sys.localStorage把_localManifest对应的路径存储起来，并在后续app启动的开始阶段，就从cc.sys.localStorage读取对应路径，设置到searchPaths中。
上诉方案固然可行，但是就一个完善的客户端框架而言，尤其是针对多子项目的大厅类游戏，个人认为这种动态存储路径、设置路径并不是比较合适的方案。在架构设计上，我们需要先确定好整个客户端的“热更目录”，并确定好优先级，即整个项目的searchPaths都是按照我们设定的逻辑固定好，而不是动态的去调整，这样的好处是，在唯一的地方确定好searchPaths逻辑，之后仅需要根据逻辑，增删对应路径下的资源即可，这样应该是更利于扩展和维护的。但同样需要注意，这种固定好searchPaths的方案，在app安装替换的时候，要维护好新的“游戏包目录”的版本与之前“热更目录”下的版本对比情况，如，app本地安装升级后的版本比之前“热更目录”的版本更高，可以考虑把之前“热更目录”下的资源都清空掉，另外一种更麻烦的逻辑是，app安装升级后的版本还是比“热更目录”版本低，这是要注意，“热更目录”存储的是相对于升级前“游戏包目录”的差异化文件，升级后“游戏包目录”下的文件发生变化，那“热更目录”下的差异化文件就不一定能兼容当前的“游戏包目录”，这种情况也可以把“热更目录”情况，让其重新去对比、热更差异化文件。
旧的版本资源怎么处理
cocos的热更的虽然是差异化文件，但是其manifest脚本是记录勒对应bundle所有的资源，我们是能知道哪些资源已经不需要的，上文genDiff函数也提到过，但是个人认为，旧资源的删除需要谨慎，至少也是确保新资源更新好后，再去删除旧资源。
总结
如果读者在消化勒上诉的一些知识后，利用cocos提供的基础功能函数，是完全可以彻底定制自己的热更流程的。热更，一言以蔽之，下载最新的远端资源替换当前包体内的就资源而已。比如一些小项目，完全可以整包的下载、替换，可以忽略其中版本对比、searchPath调整、文件校验等细节。
以上就是全面讲解CocosCreator热更新的详细内容，更多关于CocosCreator热更新的资料请关注编程网其它相关文章！
