3.1 项目层次结构设计 10

3.1.1 终端项目层级结构设计 10

3.1.2 后台项目层级结构设计 11

3.2 Java文件对比打包模块 12

3.2.1 MD5计算 13

3.2.2 文件查找 14

3.2.3 解压与压缩 14

3.3 字节码注入模块 14

3.3.1 字节码解析 16

3.3.2 编译时插件 16

3.4 补丁推送模块 17

3.4.1 文件推送 18

3.4.2 状态记录 20

3.4.3 数据统计 20

3.5 补丁包管理模块 21

3.5.1 单独存储 22

3.5.2 加载工具包 22

3.5.3 检查更新 23

3.6 dex插入模块 24

3.6.1 反射工具 26

3.6.2 顺序管理 28

3.6.3 异常捕捉 28

第四章  系统实施结果 29

4.1 文件对比打包模块实施 29

4.1.1 MD5生成 29

4.1.2 打包源程序并编译 29

4.2 字节码注入模块实施 29

4.2.1 编译时插件 29

4.2.3 字节码注入 30

4.3 推送模块 31

4.3.1 文件推送 31

4.3.2 状态记录与流量统计 31

4.4 补丁包管理模块 32

4.4.1 单独存储 32

4.4.2 加载工具包 32

4.4.3 检查更新 32

4.5 最终效果 33

第五章  问题汇总及解决方案 35

总结与展望 39

致   谢 40

参考文献 41

第一章  绪论

1.1 开发背景及意义

长期以来，各个服务提供商对自己的移动端更新能力一直很弱，往往只能进行一些资源的更新或者做一些HTML化的操作，当遇到更新源代码的时候只能选择重新安装。但这些方式不仅具有局限性，并且用户体验很差。

当一个这样的传统应用发布之后，在用户使用过程中，如果出现了严重的问题就必须进行一系列不友好的方式提示用户重新下载并覆盖安装。这不仅增加公司本不需要的负荷。如果是刚刚发布的版本，再次对用户进行推送更新也会对用户造成极大的困扰。

因此Android热补丁应运而出。在15年底到16年中，不断有公司推出自己的热补丁框架。其中比较完善的有AndFix、Tinker、QQ空间热补丁。这三种框架使用了三种完全不同的原理。

(1)AndFix是阿里巴巴于2015年9月15日首次上传至Github开源。原理是通 过改变Dalvik虚拟机的Zygote(孵化)进程，并使用一些框架来hook一 方法， 并在被hook的方法中并注入补丁代码。这种框架在打入补丁时不需要重启。但 由于这种方法直接跳过了类的初始化，将一个类直接设置为初始化完毕，所以像 是静态函数、静态成员、构造函数这些需要进行初始化的变量和函数都会出现问 题，有些类甚至会直接闪退。

(2)Tinker是微信团队于2016年9月21日首次上传至Github开源。不同于 AndFix的底层修改。Tinker的实现原理和multidex很相似，不同的是每一次添 加新的dex就会与原本的dex进行融合，生成一个新的dex使用。在Tinker下 打补丁后并不会影响应用的性能，但是在新旧dex进行融合时会占用较高的内存 并且这个全量插入的dex中需要删除一些过早加载的类，不然同样会报 CLASS_ISPREVERIFIED异常。

(3)QQ空间热补丁至今还没有开源的策略。QQ空间热补丁同样和multidex很相 似。但是不同于Tinker，QQ空间热补丁并不会融合新旧dex，反而把补丁包提前 加载以达到覆盖旧dex的目的。采用这种手段会导致整个应用的启动时间变长， 但是这种手段更新补丁的成功率是所有热补丁中最高的。

虽然QQ空间仍没有开源代码，但是已经公布了基本的补丁原理，本次框架就是基于QQ空间热补丁基本原理制作。

1.2 系统设计的主要内容

框架包括字节码注入、dex插入、推送、补丁包管理及java文件对比自动打包五大模块。主要内容如下：

自动打包模块：对比与上次发布应用的class文件变化，对文件进行Dex化。