改下标题，顶上去
关注+1
关注+1
方案：放弃 version.manifest 的检查（适用于 project.manifest 不是特别大的项目）
version.manifest 的设计是为了优化 project.manifest 过大的问题，而 version.manifest 中是不包含具体的资源信息的，因此在NEW_VERSION_FOUND时没有文件大小信息的，没有这个文件其实也不影响流程。
改动 1：Manifest.h，Manifest.cpp
恢复热更新时，正确计算剩余未下载大小
改动 2：AssetsManagerEx.cpp
a. 跳过 version.manifest 的检查
b. 计算大小， 修改 AssetsManagerEx::prepareUpdate()
恢复更新时
正常更新时
c. NEW_VERSION_FOUND 前计算大小， AssetsManagerEx::parseManidest()
d. 流程改动，AssetsManagerEx::update()
f. 修复计算异常，AssetsManagerEx::batchDownload()
结束，现在可以在正确的获取文件数量及大小
4赞
+1
给大佬点个赞先，感谢分享~
每日一顶~让大佬看到
关注+1
再顶一下，告诉自己别放弃，大佬会看到的
收到，谢谢反馈，我们会考虑重新找人接手热更新模块。
感谢回复，有什么好的方案分享下。这几天在论坛里面看了下，目前我能想到的有三个方案，都不是很理想。
- 不要version文件，直接用md5列表，修改源码，获取大小，也就楼上兄弟分享的这种方式；缺点是，如果游戏重度，project.manifest有一两兆，每次启动都下载，太大了。
- 登陆游戏之前，向后端发送当前的版本号，服务端有最新版本的内容，可以知道大小，传递给客户端；缺点是另外的后端来处理这个逻辑。
- 在版本号中做处理，目前在更新之前，研发可以设置版本对比函数，在对比函数中，会传回两个版本号，版本号一个字符串，在生成manifest时可以指定，可以把每次更新的大小放入到版本号中。这样在对比版本号函数中，就能知道最新这次更新的大小，这个方案也是论坛中另一个帖子的方式。缺点是，这个大小只是争对前一个版本的，如果跨版本了，这个大小就不对了。当然也可以多放几个版本的，但是这个版本的的总大小，就会变得很大了，而且是阶乘的方式增长。
目前我们我们选择的第3种方案，只在版本号中保存了相对于前一个版本的大小，如果有什么好的方案，希望分享下，再次感谢~
实际项目业务要复杂的多，大体更新过程说一下：
- 向服务端请求当前的版本信息，包括应用版本，热更资源版本，数据资源版本，更新地址等等
- 比对本地应用版本，确定是否需要强制更新（渠道有机制的用渠道，自营渠道自己做）
- 比对热更资源版本，确定是否热更新（如果没有更新，project.manifest就不会下载了）
- 比对数据资源版本，确定是否更新数据（业务特殊需求，这步游戏一般没有）
实际上就是把verison事情换了种方式做了。具体细节方面也还有些，列如：
自营渠道的强更（android），还有整包更新（保底更新方式），和差量包更新（类似渠道的省流量更新）策略。
我们已经开始着手了
2赞
疯狂点赞 
大概会在什么版本发布
大概会在什么版本发布
this._am.getTotalBytes()貌似是整个安装包的大小，而不是需要下载资源的大小，请问怎么在未更新之前 获取用户需要下载的资源的大小呢？
你好，是需要下载的资源大小，可以自己断点续传，测试一下。
您好，我的远程资源包只有720KB，但是this._am.getTotalBytes()/1024,等于32M，需要下载的资源，怎么比远程资源总量还大那么多