0x00
讲起 Android 的热修复,相信大家对其都略知一二。热修复可以说是继插件化之后,又一项新的技术。目前的 Android 热修复框架主要分为了两类:
- 基于 Native Hook:使用 JNI 动态改变方法指针,比如有 Dexposed 、AndFix 等;
- 基于 Java Dex 分包:改变 dex 加载顺序,比如有 HotFix 、Nuwa 、Amigo 等;
Native Hook 方案有一定的兼容性问题,并且其热修复是基于方法的;而 Java Dex 分包的方案具有很好的兼容性,被大众所接受。其实早在去年年末,HotFix 、 Nuwa 就已经出现了,并且它们的原理是相同的,都是基于 QQ 空间终端开发团队发布的《安卓App热补丁动态修复技术介绍》文中介绍的思路来实现的。如果没有看过这篇文章的童鞋,强烈建议先阅读一遍。
虽然现在 HotFix 框架已经被作者 dodola 标注了 Deprecated ,但是这并不妨碍我们解析其源码。那么下面我们就开始进入正题。
0x01
首先来看一下 HotFix 项目的结构:
可以看到项目中主要分为四个 module :
- app : 里面有一个 HotFix 用法的 Demo ;
- buildSrc : 用于编译打包时代码注入的 Gradle 的 Task ;
- hackDex : 只有一个 AntilazyLoad 类,独立打成一个 hack.dex ,防止出现 CLASS_ISPREVERIFIED 相关的问题;
- hotfixlib : 热修复框架的 lib ;
我们就先从 app 入手吧,先来看看 HotfixApplication :
1 | public class HotfixApplication extends Application { |
在 onCreate()
方法中,代码量很少。一开始使用 Utils.prepareDex
把 assets 中的 hackdex_dex.jar 复制到内部存储中:
1 | /** |
复制完后调用了 HotFix.patch
:
1 | public static void patch(Context context, String patchDexFile, String patchClassName) { |
在 patch
方法中,分为了三种情况:
- 阿里云系统;
- Android 系统 API Level >= 14 的;
- Android 系统 API Level < 14 的;
其实阿里云的热修复和 Android系统 API < 14 的代码是差不多的,就是把 .dex 修改为了 .lex 。在这里就不分析,主要来看看 Android 系统 API >= 14 和 Android 系统 API < 14 两种情况。
Android 系统 API Level >= 14
先来分析 injectAboveEqualApiLevel14
方法:
1 | private static void injectAboveEqualApiLevel14(Context context, String str, String str2) |
得到当前 context
内部的 pathClassLoader
,然后调用 combineArray(getDexElements(getPathList(pathClassLoader)), getDexElements(getPathList(new DexClassLoader(str, context.getDir("dex", 0).getAbsolutePath(), str, context.getClassLoader()))))
。这个 combineArray
方法中嵌套了很多层方法,我们一个一个来看。首先是 getPathList
方法:
1 | private static Object getPathList(Object obj) throws ClassNotFoundException, NoSuchFieldException, |
从上面的源码中知道,其实 getPathList 就是获取 BaseDexClassLoader 类的对象中的 pathList 属性。
PathClassLoader 类继承自 BaseDexClassLoader:
得到了 pathList 之后,调用了 getDexElements
。顾名思义,就是获得了 pathList 中的 dexElements 属性。
1 | private static Object getDexElements(Object obj) throws NoSuchFieldException, IllegalAccessException { |
所以在 combineArray
方法中传入的参数都是 Elements[] 。一个是当前应用程序中的 dexElements,另一个是 hackdex_dex.jar 中的 dexElements 。
下面来看看 combineArray
中的源码:
1 | private static Object combineArray(Object obj, Object obj2) { |
主要干的事情就是把传入的两个 dexElements 合并成一个 dexElements 。但是要注意的是第二个 obj2 中的 dex 要排在 obj 前面,这样才能达到热修复的效果。
最后我们回过头来看看 injectAboveEqualApiLevel14
方法中剩下的代码:
// 得到当前 pathClassLoader 中的 pathList
Object a2 = getPathList(pathClassLoader);
// 把合并后的 DexElements[] 数组设置给 PathList
setField(a2, a2.getClass(), "dexElements", a);
// 先加载 dodola.hackdex.AntilazyLoad.class
pathClassLoader.loadClass(str2);
这几行代码相信大家都能看懂了。这样 injectAboveEqualApiLevel14
整个流程就走完了。剩下,我们就看看 injectBelowApiLevel14
吧。
Android 系统 API Level < 14
injectBelowApiLevel14
方法代码:
1 | @TargetApi(14) |
我们发现在 API Level < 14 中,流程还是那一套流程,和 API Level >= 14 的一致,只不过要合并的属性变多了。主要因为 ClassLoader 源代码有变更,所以要分版本作出兼容。在这里就不分析了,相信看完 injectAboveEqualApiLevel14
之后对 injectBelowApiLevel14
也一定理解了。
0x02
在 MainActivity 中,进行了热修复,相关代码:
1 | //准备补丁,从assert里拷贝到dex里 |
惊奇地发现 MainActivity 中热修复的代码和上面 HotfixApplication 中加载 hackdex_dex.jar 的代码是一模一样的。没错,都是用的同一套流程,所以同样的道理就很容易理解了。
0x03
HotFix 整个逻辑就是上面这样了。但是我们还有一个问题要去解决,那就是我们怎样把 AntilazyLoad 动态引入到构造方法中。HotFix 使用 javassist 来做到代码动态注入。具体的代码就是在 buildSrc 中:
1 | /** |
0x04
HotFix 框架总体就是这样的了,还是比较简单的。现在作者重新写了一个 RocooFix 框架,主要解决了 Gradle 1.4 以上无法打包的问题。如果有兴趣的童鞋可以关注一下。
那么今天就到这里了,bye bye !
0x05
References