加md5就成全量更新了
不加
我们现在项目1.6G，我给打包机部署到阿里云的服务器上，这样的话可以进行内网传输，节省了上传资源的时间，缺点就是需要花钱买服务器
小点的话，就安心用官方的热更新就行了
像你这个这么大的，还是自己再研究一下吧，真的不合适全量上传了
我现在是放在一个文件夹下，加md5，增量更新。好处是每次更新量小，坏处就是不能回档（理论是可以回档，实际操作有问题）。没有关注version.manifest，还是2dx时代用过的了，现在所有更新都是cocos自动管理的。分文件夹保证同名文件使用的是最新的，尤其是跨版本如何确定文件版本跟最新的是一致的？回档怎么操作？
有个问题，这个方案热更新之后，app清除缓存，会把localStorage.存储的 hotupdate::version 和 hotupdate::searchpaths 数据清除掉，但是 am.getLocalManifest().parseJSONString替换的 manifestUrl文件内容不会还原，这就导致重启后 本地代码时旧的但是 也不会触发自动更新了。
这里清掉之后，本地读到的就是包中的manifest了，就是旧的文件清单，所以会触发更新
清除缓存 我测试不会哦，包中的manifest文件被改了没有还原吧
只有清除 存储空间才行
包中的不会改的
热更新下载的文件是下载到设备中的可写路径下，然后通过搜索路径去加载的
赞~！！！
我们之前是有个后台地址,启动从后台拿取最新的版本号,如果原始版本是1.0.1,现在是2.0.0,就去更新基包,如果不是就普通热更. 本地的AssetsManager新增了接setDownloadUrl接口,直接改成要热更的远程url地址;cdn上,假如是测试服的,就是dev/1.0.1 , dev/2.0.0 …
都差不多
用在线参数控制包的更新，哪些能用哪些不能用，不能用的去更包
能用的去热更
保留每个版本的project.manifest, 新的版本上传，只用对比当前版本与之前所有版本的project.manifest的文件差异，汇总这部分差异文件就可以，可以设置一个最低兼容版本。对比两个manfiest的差异效率很高，基本上不会增加太多的时间。
博主这样还少了一步，当构建打包的时候，生成的构建文件是项目中原本的project.mainfest，而新的是在打包后生成的project.mainfest，然后放到服务器的，其实项目中的project.mainfest 和 打包后的project.mainfest 是有差异的，需要将打包后的project.mainfest覆盖构建生成uuid.project.mainfest
热更新思路没问题的, 但是在实际项目中你会遇到:
1:运维不管那么多,直接上传,导致version.mainfest提前传了.(运维可能同时维护很多项目,不能保证他一次错不犯)
2:QA人员测试目录和线上目录完全分开,QA测的包 物理上不一定是要更新到线上的包
3:version文件会有cdn更新不及时问题(有的云服务加时间戳也拿不到新的)
稍加改进的建议
增加两个http接口,(QA和线上各一个), 接口返回version.mainfest内容,登录时判断是QA包还是线上包,从而得到当前包的project.mainfest地址.
因为线上包版本一定是小于等于QA包版本的,所以QA通过后,直接改版本号就可以了
关键核心
首先，移除掉 Cocos 构建时就需要填写部署地址的做法
然后，改为运行时根据实际情况，访问具体的地址进行热更新检查
当你实现这个核心之后，你就可以做到很多正常的事情了，比如
https://www.yuque.com/dhunterstudio/gg/hot-update#Eutxs
1赞
写的很棒,很全面!
不愧是专业的