增量更新
概述
简单点来说就是两个文件：old和new，可通过差分工具生成它们的差分包patch，当我们需要时，再可以通过另外一个合成工具在只有old和patch的情况下，恢复生成new文件。这在Android中有什么用呢？它的应用场景很广泛，拿一个常见的场景来举例，利用这个技术，可以省流量更新我们手机上已安装的App，目前各大应用市场基本都实现增量更新。我们安装在手机上的App在我们的存储卡上都保留有对应的安装包，可以理解为old文件，它位于“/data/app/”文件夹下。当我们进行版本迭代时，会上传给应用市场一个完整的安装包，应用市场会更据以前的安装包跟最新的安装包生成对应的差分包对用户进行下发，在用户端再进行差分包与原有版本的合成，达到省流量的目的。当然这其中过程中还涉及到对文件完整性MD5校验与签名校验，以及可能出现差分包比原始包更大的情况，需要采取合适的下发策略。不仅是应用市场，我们的应用内更新也可以采取相同方案。此处不再赘述。
增量更新与全量更新
增量更新 就是根据历史某一个节点和最新的一个节点，对二者进行一个差分包的生成，然后再合成的一个方案。通常我们在发布某一版本的App时，前面已经发布了很多的版本，服务端可根据最近的几个版本分别做一下差分包进行下发，更远的版本可不用考虑，直接给一个完整的安装包。
全量更新 可以理解为我们直接给一个完整的安装包，当我们生成的差分包文件很大或者版本太多，差分包的管理太繁琐时，可采用全量更新策略
增量更新与热修复
很多人对增量更新与热修复的概念比较模糊，这里着重强调一下，增量更新是在版本更新时，根据差分包生成一个新的安装包然后再安装，会有一个安装的过程。热修复是用来修复bug的，比如QQ控件热修复方案，利用dx命令对某个出现bug的类打包成dex补丁包，然后再利用类加载机制，通过hook技术替换已加载的类达到修复的目的，这个过程是无感知的，不会重新安装apk,本质上安装在手机里的还是原来版本的apk。
常用差分、合成工具
网上有文章对BSDiff/Patch、HDiffPatch和XDelta三种差分包实现方案做对比测试，在Android APK的差分更新实现上，XDelta差分方案实现是最优的。但是BSDiff/Patch 实现方案是最多的，网上一大堆都是这个方案的实现，Android系统也整合了这个实现，所以这里也使用它作为实例讲解怎么使用。
BSDiff
它是基于二进制来比较两个文件的大小，与文件格式无关，所以生成的安装包大小也不稳定。官网下载网址为
http://www.daemonology.net/bsdiff/
下载完后可以看到如下文件
在window环境下可以通过CLion来编译生成exe，当然用vs也可以，喜欢的同学可以自己去探究
bsdiff
bsdiff是用来生成差分包的，可以通过如下命令来生成
C:\Users\XXX\Desktop\bsdiff>bsdiff old.apk new.apk patch.apk
介绍下上面命令的用法：
bsdiff：固定写法
old.apk：旧文件名称
new.apk： 新文件名称
patch.apk ：生成的差分包名称，可随便取名
最终生成
old、new是我们的历史版本与最新版本，patch.apk就是我们生成的目标文件
bspatch
下面介绍下，我们Android端怎么使用bspatch来合成我们的安装包，上面演示的是在windows环境下生成差分包，但我们Android是基于linux的，自然不能使用exe文件，我们得把源码拿过来在我们的App内生成so库再使用。关于NDK基础部分我们略过。
1.新建c/c++工程，并把源码拷贝过来，配置好cmake文件
2.编写native方法
其中图中的executePatch方法为源文件中的main方法，只是这里为了方便辨识，给改了个名字而已
3.合成差分包并安装
最终在activity中调用patch方法即可进行安装包的合成
patch包在这里由手动放在data/data/packagename/cache/目录下的来模拟从服务器请求的情况，app.apk即为我们生成的目标文件，通过安装它来更新App
demo源码链接如下：
https://github.com/xuchengpu/BSPatch.git
Dex文件简析
Dex文件是Android系统的可执行文件，包含应用程序的全部操du作指令以及运行时数据。 当java程序编译成class后，还需要使用dx工具将所有的class文件整合到一个dex文件，目的是其中各个类能够共享 数据，在一定程度上降低了冗余，同时也使文件结构更加紧凑，实验表明，dex文件是传统jar文件大小的50%左 右。dex 文件可以分为3个模块，头文件、索引区、数据区。头文件概况的描述了整个 dex 文件的分布，包括每一个索 引区的大小跟偏移。索引区表示每个数据的标识，索引区主要是指向数据区的偏移。
从图中可以看出，像String_ids、Type_ids等这些每个文件共有的信息，都被整合到一起，减少文件体积大小。
我们可以使用010Editor查看工具打开一个dex来同步分析。
Header
是dex文件的头部，记录整个dex文件的相关属性，长度为112个字节。
头文件里包含以下部分：
magic(魔数)：每个文件的头文件里前8个字节，代表文件的格式
checksum: 文件校验码，使用 alder32 算法校验文件除去 maigc、checksum 外余下的所有文件区域，用于 检 查文件错误。 signature: 使用 SHA-1 算法 hash 除去 magic、checksum 和 signature 外余下的所有文件区域， 用于唯一 识别本文件 。 file_size: dex 文件大小 header_size: header 区域的大小，固定为 0x70 endian_tag: 大小端标签，dex 文件格式为小端，固定值为 0x12345678 map_off: map_item 的偏移地址，该 item 属于 data 区里的内容，值要大于等于 data_off 的大小，处于 dex 文件的末端。
其他 xx_off ， xx_size 成对出现，表示数据的偏移与数据个数。
这里以16进制方式来查看magic为例：
这几个数值转换为字符串为dex.035,被称为文件签名。dex代表文件格式，035代表版本号。
索引区
StringIds : 描述了 dex 文件中所有的字符串。记录的数据只有一个偏移量，偏移量指向了 数据区Data中 的一 个字符串
type_ids : 类似数据索引，记录了每个类型的字符串索引
proto_ids : 原型数据索引，记录了方法声明的字符串，返回类型字符串，参数列表
field_ids : 字段数据索引，记录了所属类，类型以及方法名
method_ids ：类方法索引，记录方法所属类名，方法声明以及方法名等信息
class_defs ：类定义数据索引，记录指定类各类信息，包括接口，超类，类数据偏移量
数据区
保存了各个类的真实数据
