热更新
在App开发过程中，当一个App发布之后，突然发现了一个严重bug需要进行紧急修复，这时候公司各方就会忙得焦头烂额：重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。热更新就是动态下发代码，它可以使开发者在不发布新版本的情况下，修复 BUG 和发布功能，让开发者得以绕开苹果的审核机制，避免长时间的审核等待以及多次被拒造成的成本。
Cocos Creator热更新
相对于app开发，游戏开发中游戏更新相对较频繁，之前在iOS开发时，JSPatch有一套很成熟的框架来实现iOS的热补丁。
Cocos Creator也提供了一种不成熟的方案，可以实现热更新。具体可以参考官方文档：
资源热更新教程
热更新管理器 AssetsManager
在 Cocos2d-x 中，开发方式是以代码来驱动，游戏中的数据大多也是在代码中存储，除非开发者构建了自己的数据驱动框架。在 Cocos Creator 框架中，所有场景都会被序列化为纯数据，在运行时使用这些纯数据来重新构建场景，界面，动画甚至组件等元素。这种开发模式，为我们热更新提供了便利。
详细的数据驱动可以参考官方文档：2. 数据驱动
子游戏下载
主程序的修改，可以通过热更新来更新，那么为了安装包较小，可不可以把所有的子模块都动态下载呢，举个例子：JJ斗地主、网易成都棋牌都是在进入游戏时才对游戏下载。
第一种思路：
就是在Cocos Creator的一个项目中，分成不同的模块进行开发，然后使用热更新来下载每个子游戏，这样可以直接套用官方的模式。
但是一个很明显的缺点就是，多个小游戏之间耦合性太高，而且非常不利于多人协作开发
第二种思路：
因为整个项目都是数据文件，是否可以下载多个项目，通过main.js入口文件来进行跳转，答案是肯定的。
先看一下项目结构，在构建的时候会生成build文件夹，里面有main.js，是项目的入口文件，frameworks是各个平台的文件，res是资源文件，src是js代码生成的源文件
jsb_polyfill.js 文件是 JS 引擎编译出来的，包含了对 C++ 引擎的一些接口封装和 Entity Component 层的代码。在不同版本的引擎中，它的代码会产生比较大的差异，而 C++ 底层也会随之发生一些改变。
project.js，所有的js代码会打包到project.js文件中，在非调试模式时是project.dev.js
setting.js文件是所有资源文件的配置文件，通过uuid进行索引
如果子项目不包括原生代码的话，project.js setting.js 以及res文件夹就包含了所有代码和资源，如果加上main.js的入口文件，那么把这些文件整个打包下载下来，就可以实现子游戏的热更新，但是需要对部分js文件进行修改
具体实现方案
子游戏修改：
1.修改子游戏的main.js文件，并放入 build-templates/jsb-default/src 文件夹中，该文件为跳转入口文件，但是并不替换子游戏的 main.js，因此子游戏独立运行并没有影响
main.js文件的主要改动是从子游戏的路径中读取配置文件等
2.通过Cocos Creator提供的热更新方法，打包文件后， 把src和res文件夹通过version_generator.js生成manifest文件，把生成的两个文件以及src和res文件夹上传到远端服务器中
主程序修改：
1.修改大厅 jsb_polyfill.js 文件，并放入 build-templates/jsb-default/src 文件夹中，jsb_polyfill.js文件和 Creator 的版本有关，因为升级 Creator 时需要重新修改
jsb_polyfill.js修改的目的是，为了实现大厅和子游戏资源文件的共享，因为 cc.AssetLibrary 的实现是会覆盖之前的资源映射关系，因此需要修改系统文件，这样在子游戏中也可以调用大厅的资源文件了
2.也要修改main.js文件
3.实现热更新的方法，具体可以参考官方实现
Demo：https://github.com/wf96390/CocosHotupdateDemo
Demo部署：
1. 可以使用subgame.sh进行打包，打包文件生成到hotupdate目录中
2. 如果部署到本地的话，默认是http://127.0.0.1/subgame/目录，你也可以进行修改（打包路径+代码中的热更新路径修改），把上一步生成的src, res, project.manifest, version.manifest复制到服务器subgame文件夹中
参考：
http://forum.cocos.com/t/topic/54899
http://forum.cocos.com/t/topic/53115