热更新AssetManagerEx的bug （根据v1.4）

Creator 2.x
#1
  1. updateEntry判断完全不知道啥意思，会引起更新流程都跑不正常
    2.判断updateSuceed的时机不对，不能放在queueDownload会造成 updateSucc被调用N次，因为最后n个文件下载完成的时候都是队列为空
    3.tempManifest下载过程中 没有保存到本地，这样 下载一半 杀进程再进来，还是要从头开始下载
    4.Manifest中的 size的读取代码字段用错了Compress（怀疑复制粘帖 根本没有测试），如果size为整形那么，size是读不出来的
    5.删除文件应该放到最后 解压缩完成之后，一开始就删会造成 如果更新中途失败，原有体系中的文件丢失 再也无法恢复
    6.download file有时会出现下载的文件是不完整的也会onSucc回调，因为最后 md5检测失败 重新下载 就会好
2赞
#2

谢谢反馈，这部分代码还在调试，我会一一处理

#3

麻烦问一下 updateEntry 那边引擎的更新流程问题具体是什么呢？该怎么重现？

#4

现象是 当版本更新 时 parseVersion里 因为oldUpdateEntry的比对 不会进到 downloadManifest

#5

2-5 我都确认了，谢谢

  1. 我审查了一下这里的逻辑没有什么问题，也没有重现你说的情况，我先解释一下这里的逻辑，在 parseVersion 的时候：

    • 先记录下当前的 updateEntry（可能是 CHECK_UPDATE，DO_UPDATE，NONE）
    • dispatch 过程中可能会修改 updateEntry，如果发现之前的 version 下载失败，那么会把 updateEntry 改为 NONE
    • 如果是 CHECK_UPDATE 说明用户调用的是 checkUpdate 函数，那么不需要继续更新逻辑，不会进 downloadManifest
    • 如果是 DO_UPDATE 说明用户调用的是 update 函数，那么继续进入下载逻辑
    • 如果是 NONE 说明是之前的 version 下载有问题

这里理论上是不需要记录 oldUpdateEntry，因为只有 DO_UPDATE 的状态不会被改变，之前出现问题的情况下，这里的状态都不会是 DO_UPDATE，所以直接检查 _updateEntry 是可以的。

第六个问题有 md5 校验应该是可以解决的，md5 校验的引擎函数还没有准备好，可以自己添加一个

1赞
#6

好的 那可能1的问题 我对流程的需求不一样 造成误解了

#7

能详细说下么？如果是你调用 update，version.manifest 下载也正常，是不应该打断更新流程的，否则可能有我没意识到的 bug

#8

因为我的流程是等project.manifest也parse完之后 再弹窗让用户确认要不要更新 ，因为这时才能知道 具体要更新多少文件，多少M，跟你的流程有点不一样了，你的流程是比对完version.manifest就确认要不要更新是吧？

#9

哦，是这样的

#10

还有一个隐患就是 有些文件 的命名并不是以md5码命名的，比如src下的那些文件，这些文件下载过程中会被一个个替换，如果没有更新完全完成时，中途退出也会有隐患。我目前处理是先全都下载下来存的文件名加个后缀 ，等updatesucc时再全部重命名过来

#11

你说的是 uuid 吧，下载过程中都是以临时文件存在的，比如

project.dev.js 在下载过程中是 project.dev.js.temp

只有下载完成才会重命名为正式的文件名，如果中途退出，下载停止了，那么文件不会删除，在下次进入的时候，断点续传功能会启动，判定这个文件正在下载，并且服务器支持断点续传的话，就会从当前文件大小的位置开始请求后续的内容。

之前的版本感觉问题比较多的原因有几个：

  1. 文件下载状态没有正确保存
  2. 安卓平台断点续传没有考虑服务器不支持的情况
  3. 下载完成后没有机会校验文件

这些问题都会修复

#12

下载过程中确实是 .temp 但文件校验是在 onSuccess这里执行， 这时旧的文件已经被替换，如果这时问题6的情况发生 就算再进行md5校验，原来的文件也已经被替换掉了

#13

2-5 的修复

https://github.com/cocos-creator/cocos2d-x-lite/pull/491

我明白你的意思了，不过既然已经开始更新，说明即使有原来的文件，它的版本也是旧的，那么现在被错误的文件覆盖的同时，我也让这个文件进入了 failedUnits，以便重新下载，这样问题应该不大。目前重命名是 Downloader 那边做的工作，而文件校验是放在 AssetsManager 里面，不过也可以考虑放进 Downloader

2赞
#14

完整 的走 如果进了failedUnits是没问题，但如果project.dev.js被错误的文件替换了，但同时用户杀进程，那下次启动的时候project.dev.js就是错误的文件，极有可能就开启直接黑屏了，也进不了更新流程了，因为更新的开启是js主导触发的

#15

说得有道理，我看看怎么调整

#16

目前这个版本热更新会闪退

粘贴的图像774×127 5.4 KB

#17

可以给一些更完整的信息吗？

#18

这个是基于以前的热更新的测试，是这样会闪退。你们说的新的API目前还没有学习的例子，还没有用起来。但老的是从能用变为不能用了
完整的log是这样的
https://pan.baidu.com/s/1dEQ7b4t

#19

还有个问题就是这样闪退以后，下次再进游戏竟然就不用热更了，里面的内容当然也是不正常的

#20

新的热更新没有改动 API，旧代码还是可以跑的

你遇到的闪退是稳定重现还是概率性的？从 log 看，不能确定是热更新引起的，也有可能是 localStorage。

另外，能不能把闪退的时候 storagePath 中的 project.manifest.temp 发给我看一下