用官网的列子，跑通了热更新， 但是奇怪的是
var percent = event.getPercent(); 这个返回一直是0
var percentByFile = event.getPercentByFile(); 这个能返回正常。
更新也是正确的，下载也正常，这个可能是什么问题？
因为 byte percent 在一段时间内是获取不到的（最坏的情况下，直到最后一个文件请求才能获取到）。原理是这样的：我们在请求文件头的时候，会收集每个文件的 size，然后计算出总和，才能知道 byte percent。虽然文件请求是并发的，但是并不能保障我很快获取到文件头，这个过程不可控，所以在请求到所有文件的文件头之前，percent 都是 0。
我们游戏热更新的流程是这样的。先弹窗告知用户有多少M要下载。看你上面的描述，有api先获取总和么？然后再走下载流程。。
一种做法是在manifest 的 assets中在算md5的时候把文件的size也记录上，这样下载的时候就能知道总量了。
这样就不需要等待请求文件头。
现在的手游一般都是先提示要下载的总量是多少，然后才让用户选择是否要下？ ， 下完才知道下了多少M，显然对用户不太友好。
嗯，我理解，只是首先通过额外的一次网络请求获取总量，那么会造成 http 请求 * 2，基于这个原因，当时没有这样做。1.3 中我会优化一下 AssetsManager 的实现，不知道关于下载进度你们建议怎么做
如果没有别的方案，可以按照楼上的方案，在生产manifest的时候多加一个size字段，这样本地计算一下，提供一个获得总量的api就可以了@panda
嗯，这个是可以加的
热更新现在文档几乎没有。
我现在有几个问题，有时间请解答一下
1、热更新是并发的，那么能否设置并发数量限制，如果更新300个文件，那估计会崩溃。事实上已经测试过了是卡住了
2、热更新是并发的那么文件下载完毕的顺序是否也是不可控的。如果我的补丁是p1.0.1，p1.0.2，p1.0.3，是需要顺序解压缩的，要怎么解决。还需要知道到底哪些文件更新过，目前似乎没有可以查询的api
3、如果有多语言的需求，比如简体和繁体，那么可以生成chsProject.manifest, chtProject.manifest,但问题是就算是服务器上文件名是这个，经过assetmanager以后，会自动改名成project.manifest。假如app提供切换语言的功能，会使用上次那个语言的project.manifest，因为这个文件被assetmanager自动改名。如果在这个之前，我去掉searchPath里热更新的目录，也是不能完全解决问题，因为这样就等于倒退回最初的版本，所有更新要重新下载。所以，1.3请允许指定assetmanager生成的project.manifest,version.manifest的名字。或者就直接和服务器下载过来的名字保持一致@panda
1赞
我认为并发数量限制应该是需要的，因为比如用户下的程序是1.0.0这个版本，现在是1.0.39，那么中间存在39个版本，按照目前的状态，就是39个文件一起并发下载。这样估计会卡死吧。当然还有种做法是任何版本的用户都去下载那个最新的补丁，这样这个补丁文件就越来越大了。另外这个是可以通过更新平台上的那个版本来解决的，但是现在平台更新版本都要重新备案。。。
如有可能请做一个版本控制工具。比如对比1.0.0，1.0.1，1.0.2这样的文件夹自动生成zip补丁文件。还需要一个扩展包的补丁文件，扩展包是为了减小包体大小为设定的，设定为这个标志的文件，不会被打包发布功能拷到assets目录里。
好像说的有点多，但是请考虑一下
嗯，这个应该有
是的，顺序无法控制，实际上这是对热更新机制的误解，热更新机制更像 Web 浏览器对服务器内容的更新机制，你的服务端只需要放置最新版本就可以了，至于用户当前版本和服务端版本的差异，会动态生成差异列表，并不需要逐步更新补丁包，所以不依赖顺序，这点和 Web 端的并发下载逻辑也是类似的。你所说的补丁包模式，是另一种更新机制，需要自己实现。
manifest 是可以有多个的，通过路径来区分，所以，你只需要在目录中提供多个文件夹来容纳多个 manifest 即可。当然了，你说的需求也可以考虑，不过目前的设计并不支持这样，所以我要在重构时想一想。