原帖地址：http://forum.cocos.com/t/cocos-creator/35639html
使用前先在cocos creator 项目-》构建发布-》进行非web平台的构建和编译！！！node
# 资源热更新教程python
## 前言git
之因此这篇文档的标题为教程，是由于目前 Cocos Creator 资源热更新的工做流尚未完全集成到编辑器中，不过引擎自己对于热更新的支持是完备的，因此借助一些外围脚本和一些额外的工做就能够达成。github
本篇文档的范例工程能够从 Github 仓库288获取。web
## 使用场景和设计思路浏览器
资源热更新的使用场景相信游戏开发者都很是熟悉，对于已发布的游戏，在游戏内经过从服务器动态下载新的游戏内容，来时刻保持玩家对游戏的新鲜感，是保持一款游戏长盛不衰很是重要的手段。固然热更新还有一些其余的用途，不过在此再也不深刻讨论，咱们下面将主要讨论 Cocos Creator 对热更新支持的原理和手段。服务器
Cocos Creator 中的热更新主要源于 Cocos 引擎中的 AssetsManager 模块对热更新的支持。它有个很是重要的特色：编辑器
[color=#ff0000]服务端和本地均保存完整版本的游戏资源[/color]，热更新过程当中经过比较服务端和本地版本的差别来决定更新哪些内容。这样便可自然支持跨版本更新，好比本地版本为 A，远程版本是 C，则直接更新 A 和 C 之间的差别，并不须要生成 A 到 B 和 B 到 C 的更新包，依次更新。因此，在这种设计思路下，新版本的文件以离散的方式保存在服务端，更新时以文件为单位下载。测试
除此以外，因为 WEB 版本能够经过服务器直接进行版本更新，因此资源热更新只适用于原生发布版本。AssetsManager 类也只在 jsb 命名空间下，在使用的时候须要注意判断运行环境。
## Manifest 文件
对于不一样版本的文件级差别，AssetsManager 中使用 Manifest 文件来进行版本比对。本地和远端的 Manifest 文件分别标示了本地和远端的当前版本包含的文件列表和文件版本，这样就能够经过比对每一个文件的版原本肯定须要更新的文件列表。
Manifest 文件中包含如下几个重要信息：
[list=1][li]远程资源包的根路径[/li][li]远程 Manifest 文件地址[/li][li]远程 Version 文件地址（非必需）[/li][li]主版本号[/li][li]文件列表：以文件路径来索引，包含文件版本信息，通常推荐用文件的 md5 校验码来做为版本号[/li][li]搜索路径列表[/li][/list]
其中 Version 文件内容是 Manifest 文件内容的一部分，不包含文件列表。因为 Manifest 文件可能比较大，每次检查更新的时候都完整下载的话可能影响体验，因此开发者能够额外提供一个很是小的 Version 文件。AssetsManager 会首先检查 Version 文件提供的主版本号来判断是否须要继续下载 Manifest 文件并更新。
[b]
[/b]
在这篇教程中，将提出一种针对 Cocos Creator 项目可行的热更新方案，不过咱们将在 Cocos2d-x 的将来版本中开放 Downloader 的 JavaScript 接口，届时用户能够自由开发本身的热更新方案。
在开始详细讲解以前，开发者能够看一下 Cocos Creator 发布原生版本后的目录结构，这个目录结构和 Cocos2d-x JS 项目的目录是彻底一致的。之前没有接触过 Cocos2d-x 的用户能够参考项目结构文档68。对于 Cocos Creator 来讲，全部 JS 脚本将会打包到 src 目录中，其余 Assets 资源将会被导出到 res 目录。
基于这样的项目结构，本篇教程中的热更新思路很简单：
[list=1][li]基于原生打包目录中的 res 和 src 目录生成本地 Manifest 文件。[/li][li]建立一个热更新组件来负责热更新逻辑。[/li][li]游戏发布后，若须要更新版本，则生成一套远程版本资源，包含 res 目录、src 目录和 Manifest 文件，将远程版本部署到服务端。[/li][li]当热更新组件检测到服务端 Manifest 版本不一致时，就会开始热更新[/li][/list]
教程所使用的范例工程是基于 21 点范例修改而来的，为了展现热更新的过程，将工程中的 table 场景（牌桌场景）删除，设为 1.0.0 版本。并在 remote-assets 目录中保存带有 table 场景的完整版本，设为 1.1.0 版本。游戏开始时会检查远程是否有版本更新，若是发现远程版本则提示用户更新，更新完成后，用户从新进入游戏便可进入牌桌场景。
在范例工程中，咱们提供了一个 version_generator.js 文件75，这是一个用于生成 Manfiest 文件的 NodeJS 脚本。使用方式以下：
命令 ： node version_generator.js -v 1.0.0 -u http://your-server-address/tutorial-hot-update/remote-assets/ -s native/package/ -d assets/解释：http://your-server-address/tutorial-hot-update/remote-assets/ 这个是远程仓库的地址, 好比你在A文件下用命令运行 python -m http.server 8080 设置成远程服务器，里面又有个文件名叫 remote-assets你能够在浏览器输入：http://localhost:8080/remote-assets搭建远程服务器 http://blog.csdn.net/u011229456/article/details/77200278 native/package/ 这个是打包出来原生版本的相对路径好比个人项目路径是 F:\tanktooles\assets\assets （version_generator 这个生成文件你须要放在这个路径下）（这些都是建立引擎自带的F:\tanktooles\assets\assets\libraryF:\tanktooles\assets\assets\localF:\tanktooles\assets\assets\packagesF:\tanktooles\assets\assets\settingsF:\tanktooles\assets\assets\build 这个是生成原生版本才有的.....）我发布的是windownative/package/ 这个就是等于build/jsb-default (F:\tanktooles\assets\assets\build\jsb-default) 也就是生成原平生台下的res 和src相对于项目的路径 assets/ 这个是生成出来的文件，须要拷贝到远程服务器上，这个路径就是本帖说的A文件目录下或者A文件下remote-assets 这是个人命令node version_generator.js -v 1.0.0 -u http://192.168.1.123:80/remote-assets/ -s build/jsb-default/ -d remote-assets/
下面是参数说明：
-v 指定 Manifest 文件的主版本号。-u 指定服务器远程包的地址，这个地址须要和最初发布版本中 Manifest 文件的远程包地址一致，不然没法检测到更新。-s 本地原生打包版本的目录相对路径。-d 保存 Manifest 文件的地址。
在范例工程中，热更新组件的实现位于 assets/scripts/module/HotUpdate.js87 中，开发者能够参考这种实现，也能够自由得按本身的需求修改。
除此以外，范例工程中还搭配了一个 Canvas/update 节点用于提示更新和显示更新进度供参考。
为了让游戏能够检测到远程版本，能够在本机上模拟一个远程服务器，搭建服务器的方案多种多样（好比 Python SimpleHTTPServer18），这里不作讨论，开发者可使用本身习惯的方式。搭建成功后，访问远程包和 Manifest 文件的地址与范例工程中不一样，因此须要修改如下几个地方来让游戏能够成功找到远程包：
assets/project.manifest：游戏的本地 Manifest 文件中的 packageUrl、remoteManifestUrl和remoteVersionUrlremote-assets/project.manifest：远程包的 Manifest 文件中的 packageUrl、remoteManifestUrl和remoteVersionUrlremote-assets/version.manifest：远程包的 Version 文件中的 packageUrl、remoteManifestUrl和remoteVersionUrl
下载完成范例工程后，能够用 Cocos Creator 直接打开这个工程。打开构建发布面板，构建原生版本，建议使用 Windows / Mac 来测试。
构建成功原生版本以后，打开原生发布包的地址，给 main.js 附加上搜索路径设置的逻辑：
// 在 main.js 的开头添加以下代码
if (cc.sys.isNative) {
var hotUpdateSearchPaths = cc.sys.localStorage.getItem('HotUpdateSearchPaths');
if (hotUpdateSearchPaths) {
jsb.fileUtils.setSearchPaths(JSON.parse(hotUpdateSearchPaths));
}
}
// 这是为了解决一个重启的 bug 而添加的
cc.director.startAnimation();
或者直接使用项目仓库根目录下的 main.js 覆盖原生打包文件夹内的 main.js。注意，每次使用 Cocos Creator 构建后，都须要从新修改 main.js。
这一步是必需要作的缘由是，热更新的本质是用远程下载的文件取代原始游戏包中的文件。Cocos2d-x 的搜索路径刚好知足这个需求，它能够用来指定远程包的下载地址做为默认的搜索路径，这样游戏运行过程当中就会使用下载好的远程版本。另外，这里搜索路径是在上一次更新的过程当中使用 cc.sys.localStorage（它符合 WEB 标准的 Local Storage API9）固化保存在用户机器上，HotUpdateSearchPaths 这个键值是在 HotUpdate.js中指定的，保存和读取过程使用的名字必须匹配。
此外，打开工程过程当中若是遇到这个警告能够忽略：loader for [.manifest] not exists!。
若是一切正常，此时运行原生版本的范例工程，就会发现检测到新版本，提示更新，更新以后会自动重启游戏，此时可进入 table 场景。