记一个热更的坑

Creator 3.x
#21

没遇到过uuid冲突，理论上现有的uuid生成规则生成两个相同uuid的几率低到发指……

#22

我认为 你应该向官方提交错误试试 如果按你说的这样 这不是典型的手动构造本地配置文件，但不起作用的情况了吗 这是个严重的错误了 ，但如果是这么明显的问题，那估计早就暴露出来了 其他人也不会正常才对的

#23

你自定义的 manifest 版本号，有比最后下载的更新包的版本号高吗？确认下

#24

肯定不会啊，后来我只有每次调用前删除掉storepath下的project.manifest就能正常工作，不删除就会永远提示无需更新(ALREADY_UP_TO_DATE)

#26

具体模式为，我的远程版本为 http://test.com/v1/project.manifest（版本1），这个project.manifest里面的remoteManifestUrl地址也是http://test.com/v1/project.manifest，每次检测更新的时候，我会加载本地的project.manifest，然后修改本地project.manifest里面的remoteManifestUrl为http://test.com/v2/project.manifest（版本2）后进行更新，但是这样就会导致更新一次后，loadCustom方式不生效，原因是loadCustom后，底层又去读了storePath下的project.manifest，此时会导致storePath下的manifest里面的地址还是版本1地址，所以导致对比一致，不更新

#27

localCustom 传入的 manifest 和热更新缓存的 project.manifest 的两个版本号截图发一下？

#28

我这边的操作都是修改完后，覆盖掉
image

#29

热更新缓存的版本号和loadCustom的版本号一致，你可以这样理解，每次缓存的project.manifest里面的存储的远程热更地址时v1，而远程v1里面的project.manifest和本地缓存的project.manifest一模一样，所以需要更新的时候，我会显手动读取缓存的project.manifest，然后将里面的地址改为远程v2，然后再通过loadCustom方式传入assetmanager

#30

对的，你这种方式是可以的，但是我实际上不是读取热更缓存的project.manifest来修改，我是读取项目内的project.manifest(通过bundle.load读取项目路径)

#31

按照目前设计，这个方法会用自定义的 manifest 替代本地缓存中的 project.manifest，如果自定义的 manifest 的版本号等于缓存的 manifest，这样始终会加载缓存的 project.manifest，下面有修正方法可以参考下。

this.am.loadLocalManifest(manifest, this.storagePath);

可以把版本号的判断代码做下处理，将下面位置的代码

https://github.com/cocos/cocos-engine/blob/ea38500f0a584c0cbabd3ac5342ed98639affcd2/native/extensions/assets-manager/AssetsManagerEx.cpp#L201

改成

    // Compare with cached manifest to determine which one to use
    if (cachedManifest) {
        bool localNewer = _localManifest->versionGreaterOrEquals(cachedManifest, _versionCompareHandle);
        if (!localNewer) {
            CC_SAFE_RELEASE(_localManifest);
            _localManifest = cachedManifest;
        }
    }

到这里就可以将自定义 manifest 替代本地缓存中的 project.manifest 的逻辑修复，其他的热更新规则没有变动。

1赞
#32

嗯，改底层C++代码我们还不如直接重写缓存的project.manifest了，或者直接删除缓存的project.manifest

#33

这个方法也是可以的，没问题