不是提供了一个专门针对apk包的apkdiffpatch吗？
sisong opened this issue · 5 comments
apkdiffpatch： https://github.com/sisong/ApkDiffPatch
这个库我看到了，使用的人比较少，由于我们是做平台的，需要处理很多第三方APK，我担心在稳定性上会不如hdiffpatch，特别是在于V2版本签名的处理，感觉风险比较大。还有一个原因是hdiffpatch完全可以满足我目前的业务需求了，对差分包大小我们没有非常严苛的追求，因为我们之前是采用bsdiff实现的，hdiffpatch帮了一个大忙，真的非常感谢您的分享！
嗯 apkdiffpatch最适合的场景是能自己签名的apk升级（含v1、v2签名）；
如果是平台要支持第三方APK（含v1、v2签名），需要使用 谷歌play商店的 https://github.com/andrewhayden/archive-patcher 这样的实现；
我有时间的话有可能也实现一个支持类似场景的版本，也就是 sisong/ApkDiffPatch#12 现在该issue的优先级比较靠后（因为我们做应用，不做平台），主要时间还是集中在更新HDiffPatch；技术上并不难，但需要花费时间开发和维护
赞！膜拜下，最近打算抽时间先了解一下算法的实现原理，取取经，看了你的博客，发现需要先理解一些概念，请问如果想完全理解实现原理的话，需要什么样的学习路线？
“了解一下算法的实现原理” 你想自己实现一个版本？
如果不是我十几年前自己实现过一个版本，现在也肯定不会自己继续写一个开源版本（最近快要完成的hdiffpatch的v3.0版本在功能上终于不输当年的Delphi版本了）；
二进制diff里，除了hdiffpatch外常见的开源实现还有 http://www.daemonology.net/bsdiff/ 、 https://github.com/jmacd/xdelta 、 https://github.com/google/open-vcdiff 、https://sourceforge.net/projects/jojodiff 等，你可以参考
原理上简单来说，就是解决如何把old数据当作参考字典来压缩new目标数据的问题！
我简略说一下hdiffpatch的思路，有两个算法实现：
hdiffz -m 参数时，思路是 old和new建立一个虚拟oldSize*newSize的二维bool数组E，每个元素的值E(i,j)=(old[i]==new[j])，然后在E中寻找true形成的斜线...（有了这些斜线自然就有了算法，这些斜线有些还可以合并...，参考我的blog文章）
-m运算时占用内存过大，很难处理超大文件，所以库又提供-s参数的一个实现，这个的实现思路是利用Rsync Rolling的核心想法来做本地diff的一个实现；
嗯嗯，我肯定不想自己实现，先不说难度，你这个库已经这么优秀了，应该站在巨人的肩膀上哈哈。只是应用在项目中，需要由独立维护和扩展的能力。而且学习价值也是非常高啊，我也非常好奇为什么大名鼎鼎的bsdiff在你实现的这个版本中全面落于下风！