热更新压缩包

Creator 2.x
#6

关于解压进度，安卓可以使用zip4j，这个开源解压代码。在github上面有，可以获取到解压进度，同时支持更多解压格式，并且可以附带解压带密码的压缩包。通过java回调js去同步压缩进度。不过要注意，解压的时候放在UI线程解压，不然会卡住整个游戏画面

public static void unZipPackDemo(final String inputString, final String outputString, final String passWord) {
        Cocos2dxHelper.getActivity().runOnUiThread(new Runnable() {
            @Override
            public void run() {
                try {
                    String localPath = m_activity.getFilesDir().getAbsolutePath();
                    String example_inputString = "/zips/BPcak.zip";
                    String example_outputString = "/blackjack-remote-asset";
                    Zip4jUtils.unZip(localPath + "/" + inputString, localPath + outputString, passWord);
                } catch (Exception e) {
                    Log.e(TAG, "ZipUtilsErr: ", e);
                    return;
                }
            }
        });
    }
#7

这个方案，是另一种新方法吗？和官网上的热更新方案不太一样。官网上是用jsb.assetManager，下载都是内部封装好，不需要我去loadRemote。哪种会好点？

#8

都一样，只不过2种方式侧重点不一样。
官方的方案是本地对比服务器的差异文件，不过前提是你每次更新都得把打包好的资源全部上传服务器，如果更新过于过于太多的时候，速度肯定比不上压缩包，同时浪费的流量也比压缩包多，好处就是省事，懒人模式开启。

压缩包方案就是在本地对比好差异文件，然后将差异文件打成一个压缩包，客户端只需无脑的下载最新的压缩包，然后解压就完事了。

网络越垃圾的的地方压缩包方案更吃香，但是你得自己支持断点续传

#9

好的，非常感谢你的解答，我想要结合一下这两个方面，写一个程序来生成差异压缩包，然后用官网的方式去热更这个压缩包，就是不知道能不能成功，也不知道怎么获取解压的进度。

我看到一些文章上说，官网的热更方法，跟新压缩包后会自动解压，所以我不知道是不是真的，也不知道怎么获取压缩的进度，所以发个帖子询问一下。

你给了我另一个方案，如果方案一走不通，我就可以用你这个方案。

#10

你这样不行的，你还没有理解官方的热更方式。
官方的热更是这样的 apk携带一个mainfest文件 远程服务器携带一个mainfest文件。客户端需要热更的时候将服务器的mainfest文件下载下来，然后对比本地的mainfest文件，根据md5码差异提取出需要下载资源的url地址。然后一个一个去下载，下载完之后将本地的mainfest文件替换为服务器的mainfest文件。

压缩包热更是在这样的。 本地构建之后，通过工具对比。提取出有差异的文件，保留这些文件的相对路径，然后将这些文件压缩成压缩包上传至服务器。客户端只需无脑的下载这1个压缩包，然后解压就可以了。

#11

我想先试试，主要看官方的能不能直接热更压缩包解压，不行的话，那就用你教我的方法用原生封装一下。

#12

我不理解你说的官方这个词。
如果官方指cocos这个软件，可以
如果官方指 jsb.AssetsManager + 压缩包，不可以

#13

太关键了，，赶紧mark。。

#14

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

#15

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

#16

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

#17

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

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

#18

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

#19

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

#20

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

Manifest 格式

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

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

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

#22

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

#23

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

#24

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

#25

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