Cocos热更新打包规范流程整理如下：
主要流程是参照官方文档http://docs.cocos.com/creator/manual/zh/advanced-topics/hot-update.html?h=%E7%83%AD，但有些在实际操作中对于自己的项目跑不通，所以自己整理了一下对于自己项目中遇到的问题和解决办法。
一、首先，为什么要热更新？ 对于已发布的游戏，在游戏内通过从服务器动态下载新的游戏内容，来时刻保持玩家对游戏的新鲜感，是保持一款游戏长盛不衰非常重要的手段。当然热更新还有一些其他的用途，不过在此不再深入讨论。
二、对于热更新的整体思路，由于cocos引擎中的 AssetsManager 模块对热更新的支持。它有个非常重要的特点：
服务端和本地均保存完整版本的游戏资源，热更新过程中通过比较服务端和本地版本的差异来决定更新哪些内容。这样即可天然支持跨版本更新
主要是对比版本文件差异，在AssetsManager 中通过mainfest文件来对比本地端和服务端的差异，mainfest文件包含以下几个重要信息；
1.远程资源包的根路径
2.远程 Manifest 文件地址
3.远程 Version 文件地址（非必需）
4.主版本号
5.文件列表：以文件路径来索引，包含文件版本信息，一般推荐用文件的 md5 校验码来作为版本号
6.搜索路径列表
其中 Version 文件内容是 Manifest 文件内容的一部分，不包含文件列表。由于 Manifest 文件可能比较大，每次检查更新的时候都完整下载的话可能影响体验，所以开发者可以额外提供一个非常小的 Version 文件。AssetsManager 会首先检查 Version 文件提供的主版本号来判断是否需要继续下载 Manifest 文件并更新。
以下是脚本文件需要的参数配置说明node version_generator.js -v 1.0.0 -u http://your-server-address/tutorial-hot-update/remote-assets/ -s native/package/ -d assets/
-v 指定 Manifest 文件的主版本号。（客户端下载的版本号）
-u 指定服务器远程包的地址，这个地址需要和最初发布版本中 Manifest 文件的远程包地址一致，否则无法检测到更新。
-s 本地原生打包版本的目录相对路径。（新版本的资源存放的位置相对于bat脚本文件的位置）
-d 保存 Manifest 文件的地址。（新版本资源mainfest）
在我的项目中有一个project.mainfest和一个version.mainfest,生成在assets资源目录下，用于客户端版本信息的保存，生成这两个文件是通过cocos官网给的脚本 version_generator.js 文件来生成的，它将项目中的res和src资源信息生成资源的size信息和md5值的信息，热更新的时候来对比这两个信息来判断那些是需要更新的，那些是不需要更新的。
在客户端版本和服务器版本的packageUrl（服务器版本资源的位置）、remoteManifestUrl（服务器版本project.manifest的位置） 和 remoteVersionUrl（服务器版本version.manifest的位置）要一致
在新版本推出的时候，用户打开游戏，首先会自动检测本地version.mainfest和服务端的version.mainfest是否一致，一致就直接启动，不一致就开始走热更新脚本HotUpdate.ts
热更新脚本HotUpdate.ts执行的时候，首先找一个地方存放热更新资源的位置jsb.fileUtils.getWritablePath()我这里get到的路径是cocos模拟器存放资源的位置。热更新下载资源的时候并不会直接把资源下载到模拟器跑的时候用到的资源目录下面，而是在同级目录下新建一个目录把证在下载的资源和要跑的资源分开放，这样做的好处是避免下载的时候出现问题影响原始的版本文件，当资源下载好了后会校验其完整性，如果是好的，就将整个目录一起替换过去，这样就稳了。
接下来可以构建原生版本了，构建成功后，在原生包的的main.js 附加上搜索路径设置的逻辑：
// 在 main.js 的开头添加如下代码
if (cc.sys.isNative) {
var hotUpdateSearchPaths = cc.sys.localStorage.getItem(‘HotUpdateSearchPaths’);
if (hotUpdateSearchPaths) {
jsb.fileUtils.setSearchPaths(JSON.parse(hotUpdateSearchPaths));
}
}
或者直接使用项目仓库根目录下的 main.js 覆盖原生打包文件夹内的 main.js。注意，每次使用 Cocos Creator 构建后，都需要重新修改 main.js。
修改一下服务端的版本号 ，再运行客户端就可以检测到更新了。
最后注意，我们打出来的ipa或者apk这种应用包客户下载安装在手机上的时候是无法改变的，所以热更新机制中，我们只能更新本地缓存到手机的可写目录下（应用存储空间或者 SD 卡指定目录），并通过 FileUtils 的搜索路径机制完成本地缓存对包内资源的覆盖。
有什么不对的地放，或者我的描述有偏差的地方还请大家指教
请教下 关于manifest文件的生成
manifest文件 应该是在项目构建好之后，通过那个命令行生成的吧？在构建之前，我的项目中是不是没有manifest文件？我还需要将生成的manifest文件重新放在项目里面，再构建一次项目吗？
1赞
mainfest 是通过version_generator.js脚本把res和src文件生成的布局文件 放在远程服务端 用来对比mainfest文件知道哪些是需要热更新的
main.js里面加了代码吗
加了 保存的字段也检查过了 和代码里面是一样的
我是v2.0.1版本的，致命的是热更新完成重启后无效，和没更新一样，你有遇到这个情况吗？
检查一下重启之后main.js里面的路径是否是和热更新缓存的一样