如果你初次接触热更新相关的知识，建议先看看这篇文章
本文仅授人以渔，会将实现所涉及到的关键知识点全部列出来，笔者分享的方案是有项目实例的，并且在线上稳定运营，而不是简单做个demo就分享出来，所以可以大胆运用。
零、cocoscreator的热更实现
你正在看这边文章，那就代表你对cocoscreator有所了解。cocoscreator的热更实现，在官网上有完整案例，建议在了解大厅、子游戏分包方案之前，先阅读官方文档。
一、传统大厅子游戏分包项目结构说明
可以看到，「大厅」「子游戏」文件夹下面放着各自所有的代码、资源和md5。如果我们需要发布热更新，那么我们直接把assets文件夹拷贝一份到服务器上。
当用户启动游戏的时候，首先进入大厅，接下来的流程与传统md5热更方式一样，整个流程走完，大厅的代码就更新为最新的了。
接下来当用户点击子游戏，又针对子游戏进行热更的流程，这就是基于传统热更方案的大厅子游戏分包方案。
最后总结下，传统大厅-子游戏分包方案，重点是：
1、大厅、子游戏代码与资源按照各自的目录结构放置
2、生成各自的md5列表
二、cocoscreator使用传统方案将要面对的问题
初入到cocoscreator进行开发，目录结构也按照上面的摆放，一切都顺风顺水，但是当我们进行构建操作的时候，问题来了。
1、我们开发的时候写了很多脚本文件，并且这些脚本文件都放在属于他们的结构内，但是构建以后，creator将我们所写的所有脚本，全部放到了一个文件内 project.js。
2、所有的资源文件，都被重命名、并且破坏了原来的目录结构，格式化成下面的样子。
现在我们知道了，最终发布出去的内容，并不是开发期间，搭建好目录结构的那套资源，而是构建完成后上图所示的这套资源，所以最终我们面临的问题是：如何针对构建完毕的资源，生成大厅子游戏各自的md5列表？
下面我们来解决它。
三、基于creator构建后的资源，生成大厅-子游戏的md5
1、创建该项目的插件脚本
我们无法完全基于命令行来实现分包（没错，jenkins部署别想了），如果你还不会写creator插件，请阅读这里。
2、将构建出来的资源，反推成路径
var path = Editor.assetdb.uuidToUrl(id)
// 所以现在我们知道为什么无法通过命令行来实现，因为上面的函数是基于GUI的
在插件脚本内，通过这个函数，可以获得像这样的路径 ：db://assets/game/ddz/res/btn_anniu_04.png，没错，这就 是开发过程中资源摆放的路径。
对大厅-子游戏分包方案熟的朋友，现在肯定想到了，对这个路径做字符串匹配 “game/ddz”,就能够确认它是模块ddz的资源了。但是还不够，我们还需要知晓，这些id从何而来？
3、uuidToUrl的uuid从何而来
没错，就是它了，看到这里你是不是觉得自己已经实现了md5列表生成？ 别急，通过这种方式只能得到部分资源的路径。
4、resources的路径获取
大家肯定对这个很熟悉，但是很遗憾，通过上面的方式是没办法获取到这个文件夹里面的所有内容的。
由于官方认定resources下面的资源通过cc.loader.loadres加载的，也就是说不像其余资源会在prefab或者scene文件内找到强绑定的映射关系，所以我们并无法通过uuidToUrl获取到path，但是相应的，官方对这些无法判定在何时会使用到的资源，统一记录在了settings.js内，直接上代码：
看，路径直接告诉我们了，所以我们直接读取settings.js文件取到相应字段就行了
5、生成最终的md5列表
至此我们将所有的资源对应的路径获取到了，从而该资源隶属于哪个模块也就知道了。根据我们获取到各个模块内的资源数组，我们全部存放在一个文件内，即为各个模块的md5列表。
四、一点建议
1、很多人习惯将各个模块的资源单独抽出来放在一个文件夹内，个人建议不要这么做，直接把构建出来的资源放服务器上作为更新资源就行了
我们拿到md5列表就代表我们知道该模块的每个文件，隶属总资源的哪位位置，没必要再把构建出来的总资源做拆分。
2、有些小伙伴可能阅读过一些关于cocoscreator热更新的文章，做法是直接将大厅和子游戏建立不同的项目来实现，这里更加不建议这么做，大家试想一下，假如大厅用到了1张图片，同样子游戏1需要用到这张图片，那么难道我们把相同的资源复制一份到子游戏1吗？那是一个注定会被淘汰的方案。
3、看完这篇文章，即使笔者没有直接放源码，但是你肯定也知道该如何自己去实现，但你仍然可能有些问题需要解决，请看这里。如果你有些疑问仍然没能在笔者的文章得到解决，欢迎私信联系，如有必要笔者会提供点技术支持。
