热修复设计之热修复原理（三），kotlin 后端框架

**阿里 P7 移动互联网架构师进阶视频（每日更新中）免费学习请点击：[https://space.bilibili.com/474380680](

)**本篇文章将先从热修复原理来介绍热修复设计:

Android 热修复

在 Android 的热修复中主要用来替换类，资源，so 的过程；

Java 虚拟机

栈架构指令集的主要缺点是执行速度相对来说稍微慢一些;基于堆栈的机器需要更多指令，（内存）

Android 虚拟机

而基于寄存器（硬件在 CPU 内部）的机器指令更长

速度： CPU - > 寄存器 -> 内存 -> 外存

[http://blog.csdn.net/ljtyzhr/article/details/39859659](

)

Android 目前有 2 中虚拟机， Dalvik 和 ART 虚拟机；

Android 虚拟机和编译加载顺序

Android 热修复其实主要是针对 Android 虚拟机加载类的一个过程，所以首先先我们应该知道 Android 常用的虚拟机是 Dalvik 虚拟和 ART 虚拟机；

Android 4.0 之前是主要是的 Dalvik 虚拟机。 Android 4.4 之后开始支持 ART 虚拟机（可选）， Android 5.0 之后就是 ART 虚拟机；

Android 4.0 --> Android 4.4 --> Android 5.0 ---> Android 7.0

Dalvik 虚拟机在 Android 2.2 的时候引入了 JIT (Just in time), 也就是一边运行，一边编译成机器码在运行；这种编译成机器码的过程在应用重启的时候需要重新编译成机器码再运行，有点浪费性能（不是持久化），重复翻译，编译，运行；

在 Android 5.0 之后就使用完全使用 ART 虚拟机；因为在 AOT (ahead of time) 的操作在安装的时候把 dex 优化成 odex; 在 Android N (7) 之前是全量 dex 优化成 odex, 这样导致安装 apk 的时候，或者系统更新重启的时候非常耗时，特别的慢；

所以在 Android N 后引入了 JIT 和 AOT 的混合模式; 可以理解为“全时段的编译”（All-Of-the-Time compilation， 也叫 AOT；是不是发现有 2 个 AOT, 一开始我也很懵逼的；其实和 Android 5.0 中的 AOT 是不太一样的；还有要注意的是 Android N 之后的 JIT 和 Davlik 虚拟机中的 JIT 是不一样的，简单理解就是高级版的 JIT；这个高级版本的 JIT 过程会把处理后的 odex 缓存到 base.art （有些地方也叫 image ） 中；等下次 app 启动的时候，就先直接把这个优化后的 base.art 加载到内存中；这样就不会重复的 JIT 了；

混合模式的理解

ART 初期是使用全量的 AOT (ah

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

eader of time) 变成机器码（指令）; 因为耗安装时间和系统升级后的启动时间；所以在 ART 的时候，先把 dex 解释成中间态的，不编译成机器码。在运行的时候，或者充电的时候，只编译“热代码”

引用 infoq 的一篇文章?[http://www.infoq.com/cn/news/2016/04/android-n-aot-jit](

)

Android N（7.x）开发者预览版包含了一个混合模式的运行时。应用在安装时不做编译，而是解释字节码，所以可以快速启动。ART 中有一种新的、更快的解释器，通过一种新的 JIT 完成，但是这种 JIT 的信息不是持久化的。取而代之的是，代码在执行期间被分析，分析结果保存起来。然后，当设备空转和充电的时候，ART 会执行针对“热代码”进行的基于分析的编译，其他代码不做编译。为了得到更优的代码，ART 采用了几种技巧包括深度内联。

对同一个应用可以编译数次，或者找到变“热”的代码路径或者对已经编译的代码进行新的优化，这取决于分析器在随后的执行中的分析数据。这个步骤仍被简称为 AOT，可以理解为“全时段的编译”（All-Of-the-Time compilation）。

源码类到机器执行的文件过程

主要过程： java - (dex, class) - opt/oat -- odex;

Davlik 虚拟机: java - dex - opt -- D 类型的 odex （优化过后的还是需要翻译）; JIT

ART 虚拟机: java -- dex -- oat -- A 类型的 odex （机器码类型文件）; AOT ( Ahead of time)

混合模式： java -- dex -- oat -- (D 类型的 odex, base.art: 热缓存，image) JIT（高级的 JIT）; AOT （All-Of-the-Time compilation）可以理解为“全时段的编译” ,profile

注意以上的 A 类型 odex 和 D 类型的 odex，只是用来代码 2 种是不同的 odex，便于理解；

补丁包

补丁包主要有 class， 资源文件，so 的改动；

1. 资源文件方案；替换 AssertManager， ---> 加载 resources.arsc

2. os 还不清楚，没研究过, 可能使用 classLoader 加载放入 so 目录

3. 类 ：底层替换和类加载器方案

本文主要诉说类加载器的方案；

类补丁生效原理

1. 底层替换方案 （阿里系）AndFix，

2. 类加器载方案 （腾讯系）QFix, tinker(粒度太细了), Sophix 使用类的替换（粒度大一点）

因为 Android 有 2 款虚拟机，所以应该针对 2 款虚拟机加载过程进行分析和处理；

Davlik 虚拟机的限制

Android 在编译的时候有个 65536 （2 的 16 次方）问题。受限于 Dlv 虚拟机的限制；不只是方法名有限制，其实字段也是有限制的；

Davlik Class resolved by unexpected DEX: 限制和处理方式

[Davlik 类加载处理 源码](

)

[手 Q 的方案](

)