由于线上热更随着项目越来越大，散文件热更更新的资源也就越来越多。甚至跨版本更新下载的资源远大于整个安装包大小。所以考虑之下还是选择做了zip热更新。
要解决的痛点：
1.把之前的散文件更新改为下载单个zip包。
2.兼容线上版本，不需要重新下载安装包。
3.跨版本更新不需要重复下载多次某个改动频繁的资源。
所以考虑之下还是选择了版本差异对比的zip包热更新，没有选择版本增量zip更新。
实现思路：
前提操作，每次更新线上后保存对应资源文件，对比这些资源文件的差异，生成每个版本对应的zip包。
热更流程需要由服务器来控制下发的版本和方式。
客户端收到需要走新的热更包更新流程之后，下载zip包，解压到临时文件，拷贝到热更搜索路径。
中间遇到的问题：
win版本单文件超过100M调用jsb.fileUtils.getDataFromFile(localZip);直接闪退。安卓测试没问题的。不确定是否所有平台都支持大文件操作。我们测试是在win下的。
所以索性就拆分zip包为多个。这个步骤是在生成zip文件的脚本实现的。
下载过程中，或者解压，拷贝过程中用户强制删掉app。要做对应的差错处理。这一步只要思路清晰，实现过程还是不复杂的。
更新流程分为四个状态：
Free: 空闲或者更新完成
Download: 下载中
UnPackZip: 解压中
CopyAssets: 拷贝资源
状态切换时，记录下当前状态，以及对应的数据，写到本地。下次启动app时检测下状态，然后做对应的处理。
Free状态不处理。
download就继续下载，然后走之后流程。
UnPackZip就删除之前的解压临时文件，重新解压。然后走之后流程。
CopyAssets: 就重新拷贝。
拷贝完成之后，最后修改本地manifest。
新模式的痛点：
要保留老版本资源文件。
线上版本不能同时存在2个相同版本号的版本。
一旦线上版本多起来之后，每次打包都要对比n个版本，这个是毁灭级别的。
所以我们选择只支持最近10-20个版本做zip更新。其他的版本做散文件更新（极少量用户），或者整包更新，或者直接下载完成的zip资源包拷贝覆盖到搜索路径更新。这个根据用户需要下载的资源大小来通过服务器管控分发。