一，背景

在我们项目上架到各大应用市场平台后,这时我们的APP修改了一下bug后,这时一般我们需要重新上架新版本,或者在APP应用内从服务器下载新的APP,重新安装APP,这叫 全量更新 . 全量更新有以下缺点:
1,小功能或者小bug产品频繁迭代.
2,服务器及客户端下载耗流量.

比如:一个APP的V1.0.0版本的大小为20MB,现在需要发布V1.0.1版本的大小为22MB,我们对这两个版本的apk文件差分对比,他们的差异包只有2Mb,如果我们使用增量更新这时只需要下载2MB,而全量更新就需要下载22MB大小的apk。

二，增量更新原理

增量更新图.png

1、增量更新主要分为两步：
1）服务端拿新版本A和旧版本B做差分，生成差分包C‘
2）客户端检测到可增量更新的差分包，下载差分包C‘之后，和本地旧版本B做合成，生成新版本A。

image.png

2、步骤详细展开：

服务器端：服务端的同学拿到客户端同学开发的新版本A，跟已发布的旧版本B1，B2，B3…做了差分生成相应的差分包C1，C2，C3…，并生成相应差分包的MD5值，当然全量包的签名、MD5值也是需要的，这样客户端需要的所有数据就OK了。

客户端：用户手动更新或程序主动请求检测更新：
1）客户端用MD5值和版本号作为参数向服务端请求更新数据，若服务端没有差分包则返回全量包下载URL、MD5值、签名值。
2）若服务端存在相应的差分包则返回差分包下载URL，全量包签名值、全量包和差分包MD5值，全量包签名值和MD5值。把差分包下载到本地之后（C1），先做MD5值校验，确保下载的差分包数据的完整性，校验失败则走全量更新逻辑，校验无误和本地现有安装的旧版本（B1）进行差分合并生成新版本（A），之后进行合成版本的MD5值校验和签名校验，确保合成文件的完整性和签名信息的正确性。校验无误进行安装。

3、需要考虑的一些问题：

1）服务端生成的差分包大小接近新包大小，或者直接超过新包大小，就没必要进行差分更新；

2）下载到本地之后是否需要进行签名校验依赖各自情况，若有和系统方进行合作的，系统方一般会拿APK进行二次签名之后作为系统内置应用。

3）下载文件当然也需要支持断点续传，考虑再细点，下载APK的过程中有可能被劫持或者被运营商重定向，如果是全量更新下载，可以和服务端约定每段下载数据的校验逻辑规则，在HTTP头中附加校验字段数据，确保万无一失；

4）服务端是否根据客户端的更新请求实时生成差分数据？从目前生成差分包的测试数据来看，这个实现是不靠谱的。最好就是有新版本之后，在服务端先把差分包数据准备好，而不是等到请求更新的时候再生成差分包。

原著来自：https://www.jianshu.com/p/6cda8fd3464a

三，BSDiff/BSPatch、HPatch、XDelta工具测试数据对比

差分包工具对比.png

四，Android 增量更新的完整实现步骤

转载： https://www.jianshu.com/p/f1f9d1c8bb4e

五，PC端生成差分包步骤

1， 准备工具
开源框架：http://www.daemonology.net/bsdiff/
依赖bzip2库：https://sourceforge.net/projects/gnuwin32/files/bzip2/

下载后的工具:(有需要可联系我发给你们)

客户端生成差分包工具.png
BSDiff核心思想.png

2, 解压bsdiff-v4.3-win-x64.zip ,在当前文件夹输入一下命令生成差异包patch.

TIM图片20190226162815.png

六, Android端实现合成

1, 创建一个NDK的AS项目,如果你原有的项目没有NDK文件,可以把新创建的NDK项目把以下文件拷贝到老项目中.

image.png

在build.gradle中添加:

  externalNativeBuild {
            cmake {
                cppFlags ""
            }
        }

  externalNativeBuild {
        cmake {
            path "CMakeLists.txt"
        }
    }

参考: https://blog.csdn.net/qq_34106574/article/details/84298944

2,执行bsPath合成

image.png
image.png
image.png
image.png
image.png
image.png