热修复实现原理——MultiDex
一、 MultiDex
1、MultiDex 产生背景
当Android系统安装一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。
但是在早期的Android系统中，DexOpt有一个问题，DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65536个。
而当一个项目足够大的时候：
- 生成的apk在2.3以前的机器无法安装，提示INSTALL_FAILED_DEXOPT
- 方法数量过多，编译时出错，提示：Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536
原因：
- Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M
- 一个dex文件最多只支持65536个方法。
为了解决方法数超限的问题，需要将该dex文件拆成两个或多个，为此谷歌官方推出了multidex兼容包，配合AndroidStudio实现了一个APK包含多个dex的功能。
2、MultiDex的思路
- 通过反射获取PathClassLoader中的DexPathList中的Element数组（已加载了第一个dex包，由系统加载）
- 通过反射获取DexClassLoader中的DexPathList中的Element数组（将第二个dex包加载进去）
- 将两个Element数组合并之后，再将其赋值给PathClassLoader的Element数组
事实上，谷歌提供的MultiDex支持库就是按照这个思路来实现的。
3、MultiDex的实现
I、MultiDex的原理
- apk在Applicaion实例化之后，会检查系统版本是否支持MultiDex，判断二级dex是否需要安装；
- 如果需要安装则会从apk中解压出classes2.dex并将其拷贝到应用的/data/data/ /code_cache/secondary-dexes/目录下；
- 通过反射将classes2.dex等注入到当前的ClassLoader的pathList中，完成整体安装流程。
II、DexClassLoader的动态加载
4、Multidex的方式的局限性或者缺点
在冷启动时因为需要安装DEX文件，如果DEX文件过大时，处理时间过长，很容易引发ANR（Application Not Responding）；
采用MultiDex方案的应用因为需要申请一个很大的内存，在运行时可能导致程序的崩溃，这个主要是因为Dalvik linearAlloc 的一个限制(Issue 78035). 这个限制在 Android 4.0 (API level 14)已经增加了, 应用也有可能在低于 Android 5.0 (API level 21)版本的机器上触发这个限制；
对于应用程序比较复杂的，存在较多的library的项目。multidex可能会造成不同依赖项目间的dex文件函数相互调用，找不到方法。
-
在Android 4.0设备（API Level 14）之前，由于Dalvik linearalloc bug（问题22586），multidex很可能是无法运行的。如果运行在Level 14之前的Android系统版本，需确保完整的测试和使用。
MultiDex最低只支持到1.6；MultiDex 最高只支持到20(Android 4.4W)，更高的版本不能保证正常工作
需要防止类被打上CLASS_ISPREVERIFIED，虚拟机在安装期间为类打上CLASS_ISPREVERIFIED标志是为了提高性能的，强制防止类被打上标志会影响性能；
下一次启动才生效;
-
Dalvik：对启动速度略微有影响（插桩导致对程序运行时的性能产生影响），
Art下：补丁中的类出现修改类变量或者方法，可能会导致出现内存地址错乱的问题。
备注：ART模式英文全称为：Android runtime，谷歌Android 4.4系统新增的一种应用运行模式。ART模式与Dalvik模式最大的不同在于，在启用ART模式后，系统在安装应用的时候会进行一次预编译，在安装应用程序时会先将代码转换为机器语言存储在本地，这样在运行程序时就不会每次都进行一次编译了，执行效率也大大提升。
二、热修复——MultiDex 实现形式
一个ClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件，然后从当前遍历的dex文件中找类，如果找类则返回，如果找不到从下一个dex文件继续查找。
理论上，如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类，如下图：
所以，如果某些类需要修复，我们可以把有问题的类打包到一个dex（patch.dex）中去，然后把这个dex插入到Elements的最前面，如下图
使用该原理的开源方案有：
大众点评Nuwa
https://github.com/jasonross/Nuwa
阿里 HotFix
https://github.com/dodola/HotFix
DroidFix
https://github.com/bunnyblue/DroidFix
Tinker
