热修复技术

APP提早发出去的包&＃xff0c;如果出现客户端的问题&＃xff0c;实在是干着急&＃xff0c;覆水难收。因此线上修复方案迫在眉睫。

概述

基于Xposed中的思想&＃xff0c;通过修改c层的Method实例描述&＃xff0c;来实现更改与之对应的java方法的行为&＃xff0c;从而达到修复的目的。阿里的基于C/C&＃43;&＃43;层操控method指针的Dexposed,AndFix,以及QQ空间的基于dex分包的HotFix&＃xff0c;后者和前者的热修复方案在原理上截然不同&＃xff0c;可以说各有千秋。而我在查阅资料的时候&＃xff0c;发现很多Blog都不够严谨&＃xff0c;往往标题声称热修复技术但是只解释QQ空间的解决方案&＃xff0c;可以说这种做法是容易误导人的&＃xff0c;虽然不能算错误&＃xff0c;但是不太严谨。

1.Xposed

诞生于XDA论坛&＃xff0c;类似一个应用平台&＃xff0c;不同的是其提供诸多系统级的应用。可实现许多神奇的功能。Xposed需要以越狱为前提&＃xff0c;像是iOS中的cydia。

Xposed可以修改任何程序的任何java方法&＃xff08;需root&＃xff09;&＃xff0c;github上提供了XposedInstaller&＃xff0c;是一个android app。提供很多framework层&＃xff0c;应用层级的程序。开发者可以为其开发一些系统或应用方面的插件&＃xff0c;自定义android系统&＃xff0c;它甚至可以做动态权限管理&＃xff08;XposedMods&＃xff09;。

Android系统启动与应用启动

Zygote进程是Android手机系统启动后&＃xff0c;常驻的一个名为‘受精卵’的进程。

• zygote的启动实现脚本在/init.rc文件中
• 启动过程中执行的二进制文件在/system/bin/app_process

任何应用程序启动时&＃xff0c;会从zygote进程fork出一个新的进程。并装载一些必要的class&＃xff0c;invoke一些初始化方法。这其中包括像&＃xff1a;

• ActivityThread
• ServiceThread
• ApplicationPackageManager

等应用启动中必要的类&＃xff0c;触发必要的方法&＃xff0c;比如&＃xff1a;handleBindApplication&＃xff0c;将此进程与对应的应用绑定的初始化方法&＃xff1b;同时&＃xff0c;会将zygote进程中的dalvik虚拟机实例复制一份&＃xff0c;因此每个应用程序进程都有自己的dalvik虚拟机实例&＃xff1b;会将已有Java运行时加载到进程中&＃xff1b;会注册一些android核心类的jni方法到虚拟机中&＃xff0c;支撑从c到java的启动过程。

Xposed做了手脚

Xposed在这个过程改写了app_process(源码在Xposed : a modified app_process binary)&＃xff0c;替换/system/bin/app_process这个二进制文件。然后做了两个事&＃xff1a;

1. 通过Xposed的hook技术&＃xff0c;在上述过程中&＃xff0c;对上面提到的那些加载的类的方法hook。
2. 加载XposedBridge.jar

这时hook必要的方法是为了方便开发者为它开发插件&＃xff0c;加载XposedBridge.jar是为动态hook提供了基础。在这个时候加载它意味着&＃xff0c;所有的程序在启动时&＃xff0c;都可以加载这个jar&＃xff08;因为上面提到的fork过程&＃xff09;。结合hook技术&＃xff0c;从而达到了控制所有程序的所有方法。

为获得/system/bin/目录的读写权限&＃xff0c;因而需要以root为前提。

Xposed的hook思想

那么Xposed是怎么hook java方法的呢&＃xff1f;要从XposedBridge看起&＃xff0c;重点在 XposedBridge.hookmethod(原方法的Member对象&＃xff0c;含有新方法的XC_MethodHook对象)&＃xff1b;&＃xff0c;这里会调到

private native synchronized static void hookMethodNative(Member method, Class declaringClass, int slot, Object additionalInfo);

这个native的方法&＃xff0c;通过这个方法&＃xff0c;可以让所hook的方法&＃xff0c;转向native层的一个c方法。如何做到&＃xff1f;

When a transmit from java to native occurs, dvm sets up a native stack.
In dvmCallJNIMethod(), dvmPlatformInvoke is used to call the native method(signature in Method.insns).

在jni这个中间世界里&＃xff0c;类型数据由jni表来沟通java和c的世界&＃xff1b;方法由c&＃43;&＃43;指针结合DVM*系(如dvmSlotToMethod,dvmDecodeIndirectRef等方法)的api方法&＃xff0c;操作虚拟机&＃xff0c;从而实现java方法与c方法的世界。

那么hook的过程是这样&＃xff1a;首先通过dexclassload来load所要hook的方法&＃xff0c;分析类后&＃xff0c;进c层&＃xff0c;见代码XposedBridge_hookMethodNative方法&＃xff0c;拿到要hook的Method类&＃xff0c;然后通过dvmslotTomethod方法获取Method*指针&＃xff0c;

Method* method &＃61; dvmSlotToMethod(declaredClass, slot);

declaredClass就是所hook方法所在的类&＃xff0c;对应的jobject。slot是Method类中&＃xff0c;描述此java对象在vm中的索引&＃xff1b;那么通过这个方法&＃xff0c;我们就获取了c层的Method指针,通过

SET_METHOD_FLAG(method, ACC_NATIVE);

将该方法标记为一个native方法&＃xff0c;然后通过

method->nativeFunc &＃61; &hookedMethodCallback;

定向c层方法到hookedMethodCallback&＃xff0c;这样当被hook的java方法执行时&＃xff0c;就会调到c层的hookedMethodCallback方法。

通过meth->nativeFunc重定向MethodCallBridge到hookedMethodCallback这个方法上&＃xff0c;控制这个c&＃43;&＃43;指针是无视java的private的。

另外&＃xff0c;在method结构体中有

method->insns &＃61; (const u2*) hookInfo;

用insns指向替换成为的方法&＃xff0c;以便hookedMethodCallback可以获取真正期望执行的java方法。

现在所有被hook的方法&＃xff0c;都指向了hookedMethodCallbackc方法中&＃xff0c;然后在此方法中实现调用替换成为的java方法。

从Xposed提炼精髓

回顾Xposed&＃xff0c;以root为必要条件&＃xff0c;在app_process加载XposedBidge.jar&＃xff0c;从而实现有hook所有应用的所有方法的能力&＃xff1b;而后续动态hook应用内的方法&＃xff0c;其实只是load了从zypote进程复制出来的运行时的这个XposedBidge.jar&＃xff0c;然后hook而已。因此&＃xff0c;若在一个应用范围内的hook&＃xff0c;root不是必须的&＃xff0c;只是单纯的加载hook的实现方法&＃xff0c;即可修改本应用的方法。

业界内也不乏通过「修改BaseDexClassLoader中的pathList&＃xff0c;来动态加载dex」方式实现热修复。后者纯java实现&＃xff0c;但需要hack类的优化流程&＃xff0c;将打CLASS_ISPREVERIFIED标签的类&＃xff0c;去除此标签&＃xff0c;以解决类与类引用不在一个dex中的异常问题。这会放弃dex optimize对启动运行速度的优化。原则上&＃xff0c;这对于方法数没有大到需要multidex的应用&＃xff0c;损失更明显。而前者不触犯原有的优化流程&＃xff0c;只点杀需要hook的方法&＃xff0c;更为纯粹、有效。

2.基于C层指针替换的Dexposed和AndFix

这两个热修复的框架&＃xff0c;在底层原理上是基本一致的&＃xff0c;所以我想把他们放在一起探讨&＃xff0c;

他们都做了大致三件事&＃xff1a;
1&＃xff0c;在C/C&＃43;&＃43;层将Java层中出问题的方法修改为native方法
2&＃xff0c;获取问题方法call到C层的指针
3&＃xff0c;通过获取的指针做相应的操作&＃xff1a;调用Java层的回调方法继续处理&＃xff08;DexPosed&＃xff09;或者直接通过反射调用Java层的补丁方法(AndFix)。

以Dexposed为例&＃xff1a;

至于具体的代码解释&＃xff0c;请直接看Android中免Root实现Hook的Dexposed框架实现原理解析以及如何实现应用的热修复

这两种热修复框架的区别在于&＃xff1a;

• Dexposed暂时不支持ART模式&＃xff0c;AndFix支持
• AndFix方案更加成熟&＃xff0c;更加自动化&＃xff08;毕竟是支付宝出的&＃xff09;

3.基于Dex分包的HotFix

这个解决方案很巧妙&＃xff0c;基于Google推出的的Multidex方案&＃xff0c;以ClassLoader的方式完成问题类的替换。所以这个问题一定会先谈Android的分包方案&＃xff1a;为了解决Android4.x系统中65536的方法数限制&＃xff0c;Android推出Multidex方案&＃xff0c;将一个完整的APK中的Dex拆分成好几个dex&＃xff0c;通过PathClassLoader 这个加载器来加载。

当点开程序的时候&＃xff0c;PathClassLoader 会把分包的多个dex添加到父类中的一个DexPathList 中

DexPathList 详情如下&＃xff1a;

public class BaseDexClassLoader extends ClassLoader {private final DexPathList pathList;
&＃xff5d;

/*package*/ final class DexPathList {private static final String DEX_SUFFIX &＃61; ".dex";private static final String JAR_SUFFIX &＃61; ".jar";private static final String ZIP_SUFFIX &＃61; ".zip";private static final String APK_SUFFIX &＃61; ".apk";/** class definition context */private final ClassLoader definingContext;/** list of dex/resource (class path) elements 也就是dex列表咯*/private final Element[] dexElements;/** list of native library directory elements */private final File[] nativeLibraryDirectories;

那么当需要加载某个类的时候&＃xff0c;是怎么加载的呢&＃xff1f;

//BaseDexClassLoader: &＃64;Override protected Class findClass(String name) throws ClassNotFoundException { List suppressedExceptions &＃61; new ArrayList(); Class c &＃61; pathList.findClass(name, suppressedExceptions); if (c &＃61;&＃61; null) { ClassNotFoundException cnfe &＃61; new ClassNotFoundException("Didn&＃39;t find class \"" &＃43; name &＃43; "\" on path: " &＃43; pathList); for (Throwable t : suppressedExceptions) { cnfe.addSuppressed(t); } throw cnfe; } return c; }

findClass()方法如下&＃xff1a;

public Class findClass(String name, Listsuppressed) { for (Element element : dexElements) { DexFile dex &＃61; element.dexFile; if (dex !&＃61; null) { Class clazz &＃61; dex.loadClassBinaryName(name, definingContext, suppressed); if (clazz !&＃61; null) { return clazz; } } } if (dexElementsSuppressedExceptions !&＃61; null) { suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions)); } return null; }

如你所见&＃xff0c;当需要加载一个类的时候&＃xff0c;会在pathList中去寻找&＃xff0c;并且是通过顺序遍历各个dex包的方式&＃xff0c;一旦找到目标类&＃xff0c;则停止遍历。

这就给了我们一个想法&＃xff0c;有没有可能把打了补丁的dex插入到pathList中&＃xff0c;当需要加载有问题的类的时候&＃xff0c;根据遍历&＃xff0c;首先查到已经修复的类&＃xff0c;遍历结束&＃xff0c;也就完成了修复。&＃xff08;当然了&＃xff0c;这个想法是腾讯空间Android工程师想到的&＃xff09;

有了想法&＃xff0c;也得有合适的加载器啊。结果你猜怎么着&＃xff1f;Android还真提供了这样的机会。

在Android中也有三个类加载器&＃xff0c;分别是UrlClassLoader,PathClassLoader,DexClassLoader.

• UrlClassLoader 从Url列表中加载相关的jar文件&＃xff0c;但是dalvik无法直接识别jar&＃xff0c;so…..

• PathClassLoader 它只会去读取 /data/dalvik-cache 目录下的 dex 文件&＃xff0c;就是已安装的apk,

• DexClassLoader 可以用来从.jar和.apk类型的文件内部加载classes、dex文件。而且&＃xff0c;它和PathClassLoader继承自共同的父类。显然&＃xff0c;这是最合适的加载器。
  

• 如何防止自己的类被打上 CLASS_ISPREVERIFIED标志
  这个标志是虚拟机的一种优化手段&＃xff0c;打上这个标志之后&＃xff0c;就不会引用其他dex中的类&＃xff0c;如果引用了&＃xff0c;则报错。解决方案也很简单&＃xff0c;就是在类中引用其他dex包的引用&＃xff0c;具体方法请直接Google。