请问下，重新签名后patch反而变大了。没有重新签名直接生成的patch是400多k，重新签名后生成的反而是1.2M。比google的archive-patcher 的patch包大，与您这边的测试结果好像不符合。使用的是v2签名的Apk

[super-h-c]

请问下，重新签名后patch反而变大了。没有重新签名直接生成的patch是400多k，重新签名后生成的反而是1.2M。比google的archive-patcher 的patch包大，与您这边的测试结果好像不符合。使用的是v2签名的Apk

Originally posted by @super-h-c in https://github.com/sisong/ApkDiffPatch/issues/73#issuecomment-836486651

[sisong]

旧版本Apk和新版本Apk都执行了ApkNormalized和重新签名？

[sisong]

另外，也不是一定就比archive-patcher的补丁小。 只是已有多个用例的测试情况来看，平均比archive-patcher的结果小

[super-h-c]

第一次不执行ApkNormalized 生成的patch是470K，合成时安装出错，合成的包签名信息不对 第二次只针对newApk执行ApkNormalized和重新签名，生成的patch是1.2M，合成的包能够正常安装 第三次针对newApk和oldApk都执行ApkNormalized和重新签名，生成的patch也是1.2M，合成的包能够正常安装

[super-h-c]

另外，也不是一定就比archive-patcher的补丁小。 只是已有多个用例的测试情况来看，平均比archive-patcher的结果小

如果不进行ApkNormalized和重新签名，验证了几个apk，patch都是比archive-patcher要小的；执行ApkNormalized和重新签名会导致patch变大吗

[sisong]

按原理来说，ApkNormalized不会影响补丁包大小；你的情况我也不知道发生了什么。

[sisong]

方便的话，可以给我你的测试apk，我来试试

[super-h-c]

方便的话，可以给我你的测试apk，我来试试

好的，把测试Apk发送到你的邮箱HouSisong@gmail.com中了， 4个Apk分别是新包，进行ApkNormalized和重新签名的新包，老包，进行ApkNormalized和重新签名的老包

[sisong]

确实产生了较大的补丁，看原因是重新签名时破坏了部分文件的normallized状态，（即重新生成的签名文件本身被完整放入了补丁包，而因为apk包中的文件数较多，造成v1签名文件较大，所有补丁较大）； 原理上，只能用绕过的方法，比如签名时设置 --v1-signing-enabled false 参数可以绕过这个问题，补丁包变小。 但这时就要求安卓7及以上才能安装这个apk了。

[sisong]

另外的绕过方案： 如果签名使用 --v1-signing-enabled true --v2-signing-enabled false 参数（没有了v2，v3签名），然后ApkNormalized后，就不需要重新签名了；这样也能得到较小的补丁包。

[sisong]

ps: 广告，我正在开发一个不需要重新签名的方案sfpatcher, PC上用你的重新签名后的2个apk测试：diff用时23.49秒创建补丁：486325字节；多线程执行patch打补丁时间0.39秒。

[super-h-c]

好的，感谢感谢，sfpatcher这个方案我跟我们应用商店的同事说了，正在研究。我们这个项目主要是做自升级可能patch包大小是个比较重要的因素