热修复实现原理(一)

2017-02-28 本文已影响0人墨留痕

热修复实现原理——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模式后，系统在安装应用的时候会进行一次预编译，在安装应用程序时会先将代码转换为机器语言存储在本地，这样在运行程序时就不会每次都进行一次编译了，执行效率也大大提升。