获取的包已经是子渠道包了，所以这个Patch理论上应该是不成功的，不知道这个问题如何解决，还请解惑

[sisong]

simonking200：
您好，首先非常感谢您能够分享HDiffPatch这个非常棒的库，我现在使用的是HDiffPatch，目前我也遇到的这样的实际问题，一般渠道会从新组包生成很多子渠道。组包过程原包又是从安装目录中获取的，这时候获取的包已经是子渠道包了，所以这个Patch理论上应该是不成功的，不知道这个问题如何解决，还请解惑

Originally posted by @simonking200 in #12 (comment)

[sisong]

@simonking200
（你的问题和 #12 不是同一个问题）
HDiffPatch是一个纯算法的diff/patch库，对压缩后的数据并不友好（比如apk文件）；另外如果old数据有被修改，那很大的可能是patch失败；

ApkDiffPatch是针对apk(zip)文件格式的一个优化版本实现，考虑到了数据被压缩的情况，原理是将数据抽象成未压缩的数据时调用HDiffPatch进行diff/patch；
关于渠道包造成的old apk文件修改的问题，实现时有部分考虑到，在一定范围内修改是可以兼容的（不保证兼容所有的渠道包方案，需要自己测试是否兼容；我们团队也会针对不同渠道上线不同的apk，但都能使用相同的补丁）；
如果apk使用了v2或v3以上签名的情况，那不管old apk怎样被修改(只要原签名没有被破坏)，ApkDiffPatch都能保证兼容的，patch不会失败；
需要注意patch成功以后，得到的一定是new apk，这时会丢失apk包中的渠道信息（如果有的话），我们团队的方案是apk第一次运行时会另存apk包中的渠道信息；

[simonking200]

恩 目前在尝试ApkDiffPatch因为渠道商比较多，而且不太可能对线上产品进行测试风险比较高。还有个问题需要明确下，您的意思是如果渠道使用的v2和v3签名就能保证使用渠道二次打包后的老包，patch成正确的新包是吗？

[sisong]

我的意思是：签名后的包，渠道在这个包的基础上写入不同渠道自己的信息，并没有破坏掉前面的签名，这时patch就能兼容； 不满足这个条件，不同的渠道就不能使用相同的补丁；

[simonking200]

这个不会的，每个渠道都会有各自的更新差分包，同一个渠道的子渠道共用同一个更新，子渠道的签名是一样的。

[sisong]

apkV2及以上签名是一样就一定能patch成功