痛点：
1.当一个APK大到接近30MB，或者更大的时候，比如有些游戏可能就几百M，全量更新是一件特别浪费流量和时间的行为，而实际上你非常清楚，你也就改了几百行或是添加了几个资源文件，甚至可能就是一行bug修复，这些变动对于整个包大小来说太微不足道，而这个时候你还要下个30M的包，挺不值得的、
2.传统的bsdiff/bspatch算法，对于某些apk包来讲，是有一些用的，毕竟确实降低了包大小，但当修改内容少于3M时候，意义就不大了，但实际上呢，增量包还能更小的
因为：
1.apk在打包生成的时候是有混淆打包压缩的，这个时候把一个整体来diff,是不恰当的，因为压缩算法就破坏了现场，正确的做法应该将解压后的源体 进行diff/patch。
以下是积于解压后源体对比生成的diff。
对比老的bsdiff/patch 小得太太太多了。
以下是对我们产品作的diff patch
通过图例，对比bsdiff/或是源包 新的patch 真的非常滴小，(上述是基于1M=1000K来算的，实际1M=1024k 就是说实际更小)
用户更新最小下载个 91KB大小的patch文件就可以完成新版本的安装。
最多也就2.5M，这样带来的体验会好很多。