阅读这篇文章之前，请确保你的项目已经通过cocoscreator实现了大厅-子游戏的分包热更新，如果还没有，请阅读这篇文章
一、代码加密
如果你是使用和我类似的方案实现的大厅-子游戏分包热更新，那么你肯定会遇到代码加密的问题，因为做分包方案的前提是获取setting.js的内容，而如果在构建的时候勾选加密，该文件就会变为setting.jsc的加密文件。
没关系，只要我们解决settings.jsc读取的问题就行了，加密不会造成其他问题。
1、creator的解密工具
不管是creator还是cocos2dx，脚本加密都是使用xxTea，首先大家从网上下载xxTea解密脚本，在本地实现命令行解密，这块资料很多不在这里赘述。
2、在你的分包插件脚本，读取settings.jsc的地方，通过child_process调用命令行进行解密，
const {execSync} = require('child_process');
const output = execSync("python "+Editor.Project.path + "/jsc-endecryptor/edc.py decrypt")
好了，现在你就可以对你的代码进行加密了并且分包了。
二、大厅更新与子游戏更新的关系
仔细观察settings.js文件，会发现如下代码
我们可以发现，fire场景配置是写死在这里的，对creator比较了解的开发肯定知道，如果场景不实现注册好，那么使用cc.loader.loadScene("xxx")是会出错的。
而一般游戏为了用户的转化率，通常都会限制母包的体积，所以母包通常都是不包含任何子游戏的，由用户进入大厅后，点击哪个子游戏则对哪个子游戏进行实时下载，更不用说settings.js会包含子游戏的配置。
这个时候如果直接去下载子游戏A，那么会出现的问题是，虽然所有的资源都下载下来了，但是settings.js并没有子游戏A的配置信息，导致跳转子游戏失败。
fire文件只是一个例子，prefab等其他配置内容是同样的道理。
所以这里直接说结论：在任何子游戏需要进行更新之前，都先进行大厅的更新。即使业务上大厅没有任何代码改动，但是构建出来的配置有改动。
不用担心下载子游戏更新的同时，需要更新大厅会造成什么影响，因为一般大厅更新在启动的第一个场景去做，快速更新完就重新启动，用户对此是无感知的。
三、子游戏的md5列表文件
1、子游戏的md5列表文件，需要跟随母包发出去，当然这个时候的md5列表文件内容是空的。
当然我们要确保母包在第一次进行子游戏1下载的时候，客户端有可以对比的子游戏1md5列表文件，这个好理解，之所以强调这点，是因为很多开发会在发母包的时候，排除其他子游戏的同时，也排除掉md5列表文件。
2、子游戏的md5列表文件，属于子游戏的一部分，换句话说，其文件内容需要包含自身的md5。
这样子就能保证母包子游戏1的md5列表文件，在客户端进行子游戏1更新的时候才改变。
有些开发会因为母包内容包含子游戏的md5列表，在进行大厅更新的时候就更新md5列表文件，这样子就导致，虽然项目还没有下载子游戏，但是它的md5列表却已经变成最新的，再去点击子游戏进行更新的时候，就不会下载任何文件了。
上面两点比较啰嗦也比较绕口，但是十分重要。
