熱修復框架HotFix源碼解析

wzrm7461 8年前發布 | 6K 次閱讀安卓熱修復 Android開發移動開發

講起 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 :

public class HotfixApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        File dexPath = new File(getDir("dex", Context.MODE_PRIVATE), "hackdex_dex.jar");
        // 把 assets 中的 hackdex_dex.jar 復制給 dexPath
        Utils.prepareDex(this.getApplicationContext(), dexPath, "hackdex_dex.jar");
        HotFix.patch(this, dexPath.getAbsolutePath(), "dodola.hackdex.AntilazyLoad");
        try {
            this.getClassLoader().loadClass("dodola.hackdex.AntilazyLoad");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }

    }
}

在 onCreate() 方法中，代碼量很少。一開始使用 Utils.prepareDex 把 assets 中的 hackdex_dex.jar 復制到內部存儲中：

/**
 * 把 assets 中的 hack_dex 復制到內部存儲中
 * @param context
 * @param dexInternalStoragePath
 * @param dex_file
 * @return
 */
public static boolean prepareDex(Context context, File dexInternalStoragePath, String dex_file) {
    BufferedInputStream bis = null;
    OutputStream dexWriter = null;

    try {
        bis = new BufferedInputStream(context.getAssets().open(dex_file));
        dexWriter = new BufferedOutputStream(new FileOutputStream(dexInternalStoragePath));
        byte[] buf = new byte[BUF_SIZE];
        int len;
        while ((len = bis.read(buf, 0, BUF_SIZE)) > 0) {
            dexWriter.write(buf, 0, len);
        }
        dexWriter.close();
        bis.close();
        return true;
    } catch (IOException e) {
        if (dexWriter != null) {
            try {
                dexWriter.close();
            } catch (IOException ioe) {
                ioe.printStackTrace();
            }
        }
        if (bis != null) {
            try {
                bis.close();
            } catch (IOException ioe) {
                ioe.printStackTrace();
            }
        }
        return false;
    }
}

復制完后調用了 HotFix.patch ：

public static void patch(Context context, String patchDexFile, String patchClassName) {
    if (patchDexFile != null && new File(patchDexFile).exists()) {
        try {
            if (hasLexClassLoader()) {
                injectInAliyunOs(context, patchDexFile, patchClassName);
            } else if (hasDexClassLoader()) {
                injectAboveEqualApiLevel14(context, patchDexFile, patchClassName);
            } else {
                injectBelowApiLevel14(context, patchDexFile, patchClassName);
            }
        } catch (Throwable th) {
        }
    }
}

在 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 方法：

private static void injectAboveEqualApiLevel14(Context context, String str, String str2)
    throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
    PathClassLoader pathClassLoader = (PathClassLoader) context.getClassLoader();
    // 合并 DexElements[] 數組
    Object a = combineArray(getDexElements(getPathList(pathClassLoader)),
        getDexElements(getPathList(
            new DexClassLoader(str, context.getDir("dex", 0).getAbsolutePath(), str, context.getClassLoader()))));
    // 得到當前 pathClassLoader 中的 pathList
   Object a2 = getPathList(pathClassLoader);
    // 把合并后的 DexElements[] 數組設置給 PathList 中的 dexElements
    setField(a2, a2.getClass(), "dexElements", a);
    pathClassLoader.loadClass(str2);
}

得到當前 context 內部的 pathClassLoader ，然后調用 combineArray(getDexElements(getPathList(pathClassLoader)), getDexElements(getPathList(new DexClassLoader(str, context.getDir("dex", 0).getAbsolutePath(), str, context.getClassLoader())))) 。這個 combineArray 方法中嵌套了很多層方法，我們一個一個來看。首先是 getPathList 方法：

private static Object getPathList(Object obj) throws ClassNotFoundException, NoSuchFieldException,
    IllegalAccessException {
    // 得到當前 PathClassLoader 中的 pathList 屬性
    return getField(obj, Class.forName("dalvik.system.BaseDexClassLoader"), "pathList");
}

private static Object getField(Object obj, Class cls, String str)
    throws NoSuchFieldException, IllegalAccessException {
    Field declaredField = cls.getDeclaredField(str);
    declaredField.setAccessible(true);
    return declaredField.get(obj);
}

從上面的源碼中知道，其實 getPathList 就是獲取 BaseDexClassLoader 類的對象中的 pathList 屬性。

PathClassLoader 類繼承自 BaseDexClassLoader：

得到了 pathList 之后，調用了 getDexElements 。顧名思義，就是獲得了 pathList 中的 dexElements 屬性。

private static Object getDexElements(Object obj) throws NoSuchFieldException, IllegalAccessException {
    // 得到當前 pathList 中的 dexElements 屬性
    return getField(obj, obj.getClass(), "dexElements");
}

所以在 combineArray 方法中傳入的參數都是 Elements[] 。一個是當前應用程序中的 dexElements，另一個是 hackdex_dex.jar 中的 dexElements 。

下面來看看 combineArray 中的源碼：

private static Object combineArray(Object obj, Object obj2) {
    // 得到 DexElements[] 數組的 class
    Class componentType = obj2.getClass().getComponentType();
    // 得到補丁包中 DexElements[] 數組的長度
    int length = Array.getLength(obj2);
    // 全長
    int length2 = Array.getLength(obj) + length;
    Object newInstance = Array.newInstance(componentType, length2);
    for (int i = 0; i < length2; i++) {
        if (i < length) {
            // obj2 中的 Element 順序在 obj 前面
            Array.set(newInstance, i, Array.get(obj2, i));
        } else {
            Array.set(newInstance, i, Array.get(obj, i - length));
        }
    }
    return newInstance;
}

主要干的事情就是把傳入的兩個 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 方法代碼：

@TargetApi(14)
private static void injectBelowApiLevel14(Context context, String str, String str2)
    throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
    PathClassLoader obj = (PathClassLoader) context.getClassLoader();
    DexClassLoader dexClassLoader =
        new DexClassLoader(str, context.getDir("dex", 0).getAbsolutePath(), str, context.getClassLoader());
    // why load class str2
    dexClassLoader.loadClass(str2);
    setField(obj, PathClassLoader.class, "mPaths",
        appendArray(getField(obj, PathClassLoader.class, "mPaths"), getField(dexClassLoader, DexClassLoader.class,
                "mRawDexPath")
        ));
    setField(obj, PathClassLoader.class, "mFiles",
        combineArray(getField(obj, PathClassLoader.class, "mFiles"), getField(dexClassLoader, DexClassLoader.class,
                "mFiles")
        ));
    setField(obj, PathClassLoader.class, "mZips",
        combineArray(getField(obj, PathClassLoader.class, "mZips"), getField(dexClassLoader, DexClassLoader.class,
            "mZips")));
    setField(obj, PathClassLoader.class, "mDexs",
        combineArray(getField(obj, PathClassLoader.class, "mDexs"), getField(dexClassLoader, DexClassLoader.class,
            "mDexs")));
    obj.loadClass(str2);
}

我們發現在 API Level < 14 中，流程還是那一套流程，和 API Level >= 14 的一致，只不過要合并的屬性變多了。主要因為 ClassLoader 源代碼有變更，所以要分版本作出兼容。在這里就不分析了，相信看完 injectAboveEqualApiLevel14 之后對 injectBelowApiLevel14 也一定理解了。

0x02

在 MainActivity 中，進行了熱修復，相關代碼：

//準備補丁,從assert里拷貝到dex里
File dexPath = new File(getDir("dex", Context.MODE_PRIVATE), "path_dex.jar");
Utils.prepareDex(this.getApplicationContext(), dexPath, "path_dex.jar");
//                DexInjector.inject(dexPath.getAbsolutePath(), defaultDexOptPath, "dodola.hotfix
// .BugClass");

HotFix.patch(this, dexPath.getAbsolutePath(), "dodola.hotfix.BugClass");

驚奇地發現 MainActivity 中熱修復的代碼和上面 HotfixApplication 中加載 hackdex_dex.jar 的代碼是一模一樣的。沒錯，都是用的同一套流程，所以同樣的道理就很容易理解了。

0x03

HotFix 整個邏輯就是上面這樣了。但是我們還有一個問題要去解決，那就是我們怎樣把 AntilazyLoad 動態引入到構造方法中。 HotFix 使用 javassist 來做到代碼動態注入。具體的代碼就是在 buildSrc 中：

/**
 * 植入代碼
 * @param buildDir 是項目的build class目錄,就是我們需要注入的class所在地
 * @param lib 這個是hackdex的目錄,就是AntilazyLoad類的class文件所在地
 */
public static void process(String buildDir, String lib) {

    println(lib)
    ClassPool classes = ClassPool.getDefault()
    classes.appendClassPath(buildDir)
    classes.appendClassPath(lib)

    //下面的操作比較容易理解,在將需要關聯的類的構造方法中插入引用代碼
    CtClass c = classes.getCtClass("dodola.hotfix.BugClass")
    if (c.isFrozen()) {
        c.defrost()
    }
    println("====添加構造方法====")
    def constructor = c.getConstructors()[0];
    constructor.insertBefore("System.out.println(dodola.hackdex.AntilazyLoad.class);")
    c.writeFile(buildDir)



    CtClass c1 = classes.getCtClass("dodola.hotfix.LoadBugClass")
    if (c1.isFrozen()) {
        c1.defrost()
    }
    println("====添加構造方法====")
    def constructor1 = c1.getConstructors()[0];
    constructor1.insertBefore("System.out.println(dodola.hackdex.AntilazyLoad.class);")
    c1.writeFile(buildDir)

}

0x04

HotFix 框架總體就是這樣的了，還是比較簡單的。

來自：http://yuqirong.me/2016/11/06/熱修復框架HotFix源碼解析/

本文由用戶 wzrm7461 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1478486530315.html

安卓熱修復 Android開發移動開發