Creator热更新方案，弃用官方方案，采用增量zip方式

Creator 2.x
#21

增量zip是原cocos2dx的热更方案，浪费流量，日活上万的项目CDN费用能让你抓狂

现在的热更方案才是正道，何必倒退回原始社会呢

1赞
#22

不太理解zip为何浪费流量？ 我的理解应该是更小啊，因为如果是现在的方案当你项目迭代文件有几百个文件待更新时，可能文件总下载大小有20M, 如果走了ZIP可能只要5M下载。

1赞
#23

json能http gzip压缩的。。。

散文件更新最大问题还是请求数过多的问题

#24

你说的是传统端游用的增量patch吗？长时间不上，下载的更新比重装游戏还大

我觉得我们说的不是一个东西，还是打住吧

#25

这个问题如果assetbundle在原生端也支持zip就不存在了，现在只有小游戏支持zip，原生官方不知道有计划没

#26

官方方案是好，但是变动文件数量比较多情况下，下载比较慢

#27

对于长时间不上或跨度版本较大的，可以指定版本下载整包解决。

1赞
#29

那要看下载模块怎么写了，用原生接口可以开多线程，最终瓶颈还是在带宽上，文件多不成问题

#30

http 是能用 gzip 的。用了 zip 就算能省一点点，但也是增量更新啊？你不是说你的项目版本迭代比较频繁吗？你确定增量更新不会包含大量无用的中间版本资源？

1赞
#31

http gzip 我再尝试下，对比一下效果。之前主要是在下载连接数过多的情况下比较糟糕。 我们项目属于中大型，资源量也是大的，数据表sheet数量已经有1000+，为了控apk大小，resources动态资源没有打在包里,采用动态下载 , 其他资源打在包里（热更），我的现有想法是，如果版本跨度很大，可以走下载APK流程，这样可以避免无用中间版本下载。

#32

官方的大部分东西 都是想象着来，没做过东西，就想着能用，没太想着更细节的方向。热更新为啥会做成散文件的方式，不光大小有问题，而且每个链接的建立和断开对手机资源的消耗 下载速度 有很严重的影响

2赞
#33

官方的也可以压缩热更新的，就像import文件夹你就可以压缩成Import.zip然后在热更。。你们不会用而已吧

#34

等待分享，表示支持！！！

#35

坐等分享学习

#36

这是开倒车啊同志，增量包更新有个很大的问题就是不能 跨版本更新，如果玩家一个月没上线，他就得挨个把这一个月的所有增量包依次下载更新，远程服务器上也必须保留所有版本的更新包。

#37

我还没听说过有开发商愿意强更的，下载 apk 应该是下下策才对

#38

兄弟你这确实是在开倒车，现在只能说明你的版本改动大，md5每次对比之后，大部分东西都得更新，这个时候，你感觉每次更新用增量zip确实没问题。但是版本稳定之后，md5对比的优势就出来了，又或者长时间不更新，你的热更比重下游戏要的内存都大，md5反而没这个问题。

#39

我来提个改进方案吧，这个方案需要服务端的配合。

  1. 基于官方的散文件进行更新。
  2. 每次更新，服务端负责打包所有散文件为一个 zip，一次性传输给客户端。（例如，从 v1.1 升级到 v1.5，则服务端对比两个版本之间的文件差异，一次性把最终的文件集打成 zip。或者客户端直接把请求的文件列表发给服务端，服务端只要负责无脑压缩 zip 就行。）
  3. 服务端缓存 zip 到 CDN，下次再遇到相同版本的请求则直接转发给 CDN，服务端就不用重新重复劳动，节省 money。

优势：两者兼顾，工作流简单，不用考虑跨版本更新的情况

10赞
#40

我们公司采用的是客户端使用python工具,对比每个版本的差异文件,逐一更具版本号生成zip的方式,比如说:
1.0版本文件:A,B
2.0版本文件:A,B,C,D
3.0版本文件:A,B,C,D,E,F
最终生成的热更文件目录就是:
update
----dir_3.0_1.0.zip(包含文件:C,D,E,F)
----dir_3.0_2.0.zip(包含文件:E,F)

无需服务器配合,工具打包完成自动上传对应ftp上

#41

假设更新了100个版本,想想都可怕~~