Android热更新技术总结

1为什么需要热更新？

正常开发流程：

新版本上线，发现问题或用户反馈bug，紧急修复，上线版本，用户重新安装。

图片1.png

存着如下问题：

l 周期长

l 用户下载成本高，app推广成本高昂

l 修复不及时，用户体验差，用户遇到奔溃时失去耐心后直接卸载。

热修复流程：

新版本上线，发现问题或用户反馈，紧急修复，上线补丁，自动修复

图片2.png

存着如下优点：

l 无需重新发版，及时修复问题

l 用户无感知修复，无需下载新应用，代价小

l 修复成功率高，把损失降到最低

但热修复因为大量涉及android底层知识，又因为android本身开源，华为vivo小米几大厂商都可能修改底层相关代码，兼容性困难，所以热修复技术开发维护难度巨大，人力和时间投入不菲。目前主要有腾讯，阿里等几家互联网大厂因自身刚性需求，实现此功能。

目前热修复技术主要有以下几家：

腾讯系：

QQ超级补丁

**tinker **

阿里系：

Xposed (不支持Art虚拟机，已废弃)

Andfix (native hook兼容差，适配机型少)

Sophix 新一代

饿了吗：

amigo

美团：

robust 每个函数插入额外逻辑

以上几家热修复技术都各有优缺点，也各说各的好。因此我们在引入时需要从代码侵入性，修复实时性，兼容，支持力度等几个维度综合评估。

虽然热修复在android生态圈目前呈现百花齐放的态势，但追根溯源热更新实现的基本原理，可以划分为以tinker为代表的multidex类加载法和以阿里andfix为代表的底层替换法，而阿里sophix为了提高热修复的成功率同时采用了上述两种方案，并在兼容性上进行了一定的优化。

2底层替换方案：来自原哥博客http://www.yuange.tech/

2.1我们首先以andfix为例，简答介绍底层替换方案。

底层替换是在已经加载了的类中直接在native层替换掉原有方法，见下图。

图片3.png

图片19.png

Andfix核心函数replaceMehtod，它的参数是在java层通过反射机制得到的method对象对应的jobject。Src对应的是需要被替换的原有方法，dest对应的是新方法。

具体替换以art虚拟机为例，通过替换java对象的数据结构ArtMehtod的所有成员。

图片4.png

Andfix逐个替换方式

图片5.png

Sophix整体替换方式

2.2

由于底层替换原理只支持方法替换，不支持方法的增加和减少，成员字段的增加和减少，所以我们需要知道哪些修改会导致方法，字段的改变，从而底层替换热部署失效。

a 非静态内部类

非静态内部类编译后实际和外部类一样都是顶级类。外部类为了访问内部类的private field method，内部类额外会添加access方法。

b 匿名内部类

匿名内部类编译后名字命名规则为外部类&number ,number根据匿名内部类在外部类出现的先后次序依次累加。如果将匿名内部类的次序调整，我们无法区分修改前后的差异的。

c 静态field 静态代码块

这2块是被编译器翻译在clinit方法中，clinit方法是在类加载阶段调用，导致热部署方案失效。

d final static 域

图片6.png

代码中变量i2, s2这两个静态域没有被初始化在clinit中，而是在dvmInitClass的initSFields方法中，这个方法在clinit之前执行。

此外泛型，lambda函数的修改都有可能导致热部署失效，这些都需要我们对android虚拟机的编译有一定了解，在此我们不再赘述。

所以底层替换方法限制较多，但优点是实现热部署，修改及时生效。

3 Multidex类加载法：

接着我们以tinker为例，简单介绍multidex类加载方案。

3.1 64K事件

在android5.0之前，每个android应用只含有一个dex文件，dex的方法数量被限制在了65535之内，导致apk引入大量第三方sdk后方法数量超过限制无法编译通过。为了解决这个问题，Google推出多dex文件的解决方案multidex，一个apk可以包含多个dex文件。通过Multidex.install(this)完成dex文件的加载。

Tinker方案参考multidex实现原理，在编译时通过新旧两个Dex生成差异patch.dex。在运行时，将差异patch.dex重新和原始安装包的旧Dex合并还原为新的Dex。这个过程可能比较耗费时间与内存，所以tinker单独放在一个后台进程:patch中处理。为了补丁包尽量的小，微信自研了DexDiff算法，它深度利用Dex的格式来减少差异的大小。由于采用ClassLoader机制，所以需要app重启。

图片7.png

3.2 Multidex.install()流程

我们分析下android的Multidex.install()的流程

MultiDex.install()在app最初启动时被调用。

图片8.png

Install() 实现获取DexClassLoader 解压缩dex文件，根据不同的平台版本加载补丁。

图片9.png

来自原哥博客http://www.yuange.tech/

图片10.png

我们以V19.install为例，根据注释我们可以知道它通过反射将多余的dex file 添加到DexPathList的pathList数组字段里。

图片11.png

我们查看DexPathList类确实如此。

图片12.png

那为什么通过添加就能够实现多dex文件的合并呢？

重点我们需要看下makeDexElements这个函数做了什么处理。

图片13.png

这个函数通过反射调用了DexPathList的makeDexElements, 我们继续跟踪makeDexElements具体实现，发现它调用了loadDexFile.

图片14.png

我们继续跟踪loadDexFile, 发现最终它调用DexFile.loadDex(); 我们重点看下该函数的注释如下。

 

图片15.png

我们继续跟踪发现已经到DexFile的C++ 部分，内部是对dexfile处理的具体实现，在此我们不再叙述。

图片16.png 来自原哥博客http://www.yuange.tech/

通过对MultiDex.install()流程的跟踪，我们基本可以了解腾讯tinker的热更新原理。Tinker基于基版本利用自研的DexDiff算法生成差分包，放在后台。App启动时下载差分包，与原dex重新合并，解压缩，并参考MultiDex.install()流程，重新安装app。

我们查看Tinker的核心源码确认基本按照这个思路实现，如下为tinker加载的核心函数。

图片17.png

图片18.png

由于类加载实现原理涉及dex文件的重新解压缩合并等处理，消耗内存大，耗时长，在系统低内存时容易导致热更新失败，腾讯测试成功率大概为95%。实际热部署时，差分包应文件大小最小。

综上没有完美的热更新方案，没有100%的热更新成功率。目前，腾讯tinker基本可以满足app的热更新需求，但随着app用户规模不断增大，业务需求日益复杂，可考虑阿里的sophix商业方案，sophix同时应用类加载和底层替换两种方案，具有底层替换的修改及时性，和类加载方案的兼容性等优点。

注：此文主要介绍底层替换和类加载技术两种方案，但对于热更新我们还需要了解dalvik, art虚拟机下app优化，安装的原理和差异，android类加载PathClassLoader,DexClassLoader原理, android文件校验机制等，在此我们不再赘述。