热更新压缩包

太关键了，，赶紧mark。。

目前ccc的传统热更是差异下载的，不管跨越多少版本，通过mainfest md5 比较只下载差异文件。按楼主的说法，有两种方式：1 压缩最新包的所有文件，对所有需要更新的客户端做覆盖更新，这样每次下载的体积会很大（虽然只有一次请求）。2: 需要保存所有历史版本包体，新包对每个历史版本生成差异的zip压缩文件，然后客户端通过版本请求对应差异 zip包，这样只请求一次且包体也小，但是维护难度随版本增多增加。所以还是传统的热更简单明了。

1、官方热更zip可自动解压的，看源码就行。
2、mainfest对比差异只需保证结果只有一个zip差异以及新版本删除的文件即可。（也就是解压后和官网方案结果一样）
3、解决历史版本过多可动态可配zip热更版本数量，超出的都走官网方案。实在太久远的可考虑直接让玩家下载最新包
4、方案2的改法对引擎层面0侵入(因为我懒，走的全部是官方标准流程，稳定性高)

有谁看明白第二种方案的规则了吗 给说说？
本地对比好差异文件？ 怎么对比？ 可能已经有100多个版本了 那么要完成每个版本到最新版本的对比差异，然后再打成包？ 这个工作夸张到没边了都
如果说官方原始的方案流量会大 但官方原始的方案也可以用压缩方式的 为什么会导致流量大？ 官方原始的方案既可以用压缩 也不用管中间的任何版本 非常合理到位的 管理起来也很方便 没觉得有什么问题的

一般只提供20个差异版本上限，由脚本完成对比上传服务器，超过20个版本那就提示玩家重新下载APP。因为你20个压缩包的流量极有可能超过下载整个APP的流量和时间了，所以干脆重新下载最新的APP。

常用用户一般都是紧跟着版本更新的，不会超过3个版本。如果超过了3个版本，大部分都是僵尸用户，不用考虑他们了。

第一点可以具体说说吗，官方热更自动解压

20个差异?
不要说维护20个版本的差异，维护2个版本的差异 我觉得都是个烦人容易出错的工作，
典型的自己给自己找麻烦的事情，
为什么不是总是面对最终最新的版本呢 就一个版本 维护起来多简单 多容易，
所以你说的方案比官方的只面对维护最新的版本的方式 已经差了一个数量级了 甚至几个数量级，因为你要照顾之前的版本还
然后流量问题 官方方案支持压缩方式也 你的这种方案 也没有体现出流量优势，
如果让我说 你的方案和官方的比 没有任何优势，还有劣势，因为你多了一个要维护多个版本相互差异的工作，
这个是所有运营和开发人员最忌讳的工作算是

官方已经说的很清楚了 不是吗。

Manifest 格式

Manifest 格式是我们用来比较本地和远程资源差异的一种 json 格式，其中保存了主版本信息、引擎版本信息、资源列表及资源信息等：

{
    "packageUrl" :          远程资源的本地缓存根路径
    "remoteVersionUrl" :    [可选项] 远程版本文件的路径，用来判断服务器端是否有新版本的资源
    "remoteManifestUrl" :   远程资源 Manifest 文件的路径，包含版本信息以及所有资源信息
    "version" :             资源的版本
    "engineVersion" :       引擎版本
    "assets" :              所有资源列表
        "key" :             资源的相对路径（相对于资源根目录）
        "md5" :             md5 值代表资源文件的版本信息
        **"compressed" :      [可选项] 如果值为 true，文件被下载后会自动被解压，目前仅支持 zip 压缩格式**
        "size" :            [可选项] 文件的字节尺寸，用于快速获取进度信息
    "searchPaths" :         需要添加到 FileUtils 中的搜索路径列表
}

好的谢谢老哥，之前没认真看文档，原来还有这么个字段，也就是说我构建完把每个文件夹再压缩成zip再生成热更文件也能正常更新解压使用是吧，热更配置文件里面的信息就是我每个压缩包的信息

可以解压 需要注意的是 官方的解压是同步的 压缩包太大会假死 而且没有解压进度

明确告诉你 不是这样，你可以按这个操作流程做个测试，但结果会让你惊讶 至于原因 你先做完测试再说吧

我的想法是把import 和 native 进行压缩这样每个压缩包应该不会很大吧

。。。文档没错的话这样应该没问题呀，老哥别打谜语呀，在线等原因

不是我在打谜语，是官方在打谜语 官方只告诉你可以用压缩 但却没告诉你怎么用压缩，
所以 你按照流程去测试一下 就知道问题了 至于怎么解决 问官方吧 还是

你自己试试就知道了 我一直这么用没有出现问题

好我找个时间试一下谢了，压缩我准备在构建流程里面构建完成事件里面使用nodejs的库进行压缩

官方用压缩的话 每次都得更新全部资源 你想想资源量多大 而且流量优势肯定是有很大的 基于你更新的大小 不然也不好基本大型游戏都是这种方案

那只能说你操作的过程中有错误的步骤导致的，
官方用压缩的方式 一样可以做到需要更新哪些就下载哪些文件 而且下载的形式还是压缩的，
我认为官方的这个方式整体上看没有任何问题，

你的意思是每个文件都压缩？

可以每个文件都压缩 也可以按目录压缩，但无论哪种方式
也绝对不是你说的每次都得更新全部资源的结果 我只是针对这个来说的
或者你能讲讲为什么官方方案用了压缩 每次都要全部更新吗？