什么是差量更新

新版本v2.0比旧版本v1.0代码发生的变化部分生成patch包，用户更新app的时候只用下载patch包进行本地合并即可

差量更新的原理

1. 服务器端将旧版本Apk和新版本Apk比较差异，生成补丁patch
2. 用户下载patch文件到手机中
3. 将手机端data/app下面的相应apk复制到SD卡或者cache中，与下载的patch进行组合，生成一个新版本的apk应用
4. 安装应用新版本并删除旧版本和patch

问题描述

差量包上线后，原本的验证思路：diff接口能够返回差量包的地址，确认该地址能够下载差量包，接口返回的差量包的大小，versioncode正确，最后也能成功升级到目标版本，OK！。

本次验证过程中有一个问题：差量包下载完了之后，进度条又走了一遍。确认了一下接口返回的地址能够成功下载差量包之后，就武断的认为是客户端的问题，因此反馈给客户端的同事后，就发了测试通过的确认信

结果，客户端同事发现进度条走两遍是因为请求了两遍，先请求了差量包的地址下载成功后，又重新请求了全量包的地址又进行下载，因此才导致进度条走了两遍

那么，问题来了

1. 为什么进度条走了两遍，第二遍的请求是谁触发的？
2. 其他的差量更新的进度条会走两遍吗？
3. 差量更新验证真的通过了吗？

分析过程

在弄清楚问题的产生原因之前，需要先明确两个逻辑：

1. Android客户端差量更新逻辑：1.0差量升级到版本2.0，客户端下载差量包后，与本地1.0的包进行计算生成2.0完整安装包(将手机端的旧版本data目录下的，先复制到SD卡下，和差量包进行合成)，如果合成完整包出现错误，客户端会去下载完整的2.0安装包。进度条走两次差不多应该就是：合成完成包出错导致的。接下来需要验证服务端的差量包是否正确？

2. 服务端差量更新包是怎么来的？
   • 使用工具，拆分工具bsdiff 和补丁合成工具bspatch 差量更新的拆分工具和合成工具
   • 使用命令：bsdiff oldfile newfile patchfile 和bspatch oldfile newfile patchfile
   • 根据两个不同版本的二进制文件，使用bsdiff生成差量包，将差量包放在服务器上，当用户下载差量包之后，再使用dspatch合成
3. 根据以上分析，验证服务端的diff是否可用
   • 使用bspatch命令，将服务端生成的差量包和本地的安装包进行合并，得到new.apk并进行安装，得出以下错误码
   • 使用1.0版本和2.0版本，使用bsdiff，生成差量包是可以安装成功的 因此，可以确认是服务端差量包的问题

总结

1. 如果了解差量更新的整个过程的话，也许这个问题很快就能被定位。但是接手差量更新这个模块的时候，交接人跟我说：你这样做就可以了，我就深信不疑，从来没有想过为什么要这样做，为什么不要那样做
2. 测试过程中遇到问题的话，如果能够及时对问题进行排查（不管是不是自己的），也许这个问题就不会饶了一圈又回到我这边来。
3. 在发测试确认信的时候，确认所有问题都已经被解决
4. 如果做某功能开发发生变化，这个时候一定要提高警惕