還不懂熱修復的原理？看完這篇后帶你手把手寫代碼

Android熱修復原理分析

本文目的是讓大家了解什么是熱修復，具體的實現細節可以聯系我。大家了解了原理后，才能夠順利的帶著手寫代碼了。請大家記住一句話：
紙上得來終覺淺，絕知此事要躬行。
代碼需要大家自己寫出來的那才是自己的代碼，否則的話你看了，背了，最后工作中還是寫不出來優秀的代碼

什么是熱修復

熱修復： 讓應用能夠在無需重新安裝的情況實現更新，幫助應用快速建立動態修復能力。

早期遇到Bug我們一般會緊急發布了一個版本。然而這個Bug可能就是簡簡單單的一行代碼，為了這一行代碼，進行全量或者增量更新迭代一個版本，未免有點大材小用了。而且新版本的普及需要時間，以Android用戶的升級習慣，即使是相對活躍的微信也需要10天以上的時間去覆蓋50%的用戶。使用熱修復技術，能做到1天覆蓋70%以上。這也是基于補丁體積較小，可以直接使用移動網絡下載更新。

熱修復開發流程：

目前Android業內，熱修復技術百花齊放，各大廠都推出了自己的熱修復方案，使用的技術方案也各有所異。其中QZone超級補丁基于的是dex分包方案，而dex分包是基于Java的類加載機制 ClassLoader。

ClassLoader介紹

任何一個 Java 程序都是由一個或多個 class 文件組成，在程序運行時，需要將 class 文件加載到虛擬機 中才可以使用，負責加載這些 class 文件的就是 Java 的類加載機制。 ClassLoader 的作用簡單來說就是加載 class 文件，提供給程序運行時使用。每個 Class 對象的內部都有一個 classLoader字段來標識自己是由哪個 ClassLoader加載的。

class Class<T> {
  ...
  private transient ClassLoader classLoader;
  ...
}

ClassLoader是一個抽象類，而它的主要實現類主要有：

• BootClassLoader
  用于加載Android Framework層class文件
• PathClassLoader
  用于Android應用程序類加載器。可以加載指定的dex，以及jar、zip、apk中的classes.dex
• DexClassLoader
  用于加載指定的dex，以及jar、zip、apk中的classes.dex

  很多博客里說 PathClassLoader只能加載已安裝的apk的dex，但是實際上 PathClassLoader和 DexClassLoader一樣都能夠加載sdcard中的dex。

Log.e(TAG, "Activity.class 由：" + Activity.class.getClassLoader() +" 加載");
Log.e(TAG, "MainActivity.class 由：" + MainActivity.class.getClassLoader() +" 加載");

//輸出：
Activity.class 由：java.lang.BootClassLoader@d3052a9 加載
MainActivity.class 由：dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.enjoy.enjoyfix-1/base.apk"],nativeLibraryDirectories[/data/app/com.enjoy.enoyfix-1/lib/x86, /system/lib, /vendor/lib]]] 加載

它們之間的關系如下：

PathClassLoader與 DexClassLoader的共同父類是 BaseDexClassLoader

public class DexClassLoader extends BaseDexClassLoader {
   public DexClassLoader(String dexPath,String optimizedDirectory,
        String librarySearchPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory),librarySearchPath, parent);
    }
}
public class PathClassLoader extends BaseDexClassLoader {
     public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }

    public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent){
         super(dexPath, null, librarySearchPath, parent);
    }
}

可以看到兩者唯一的區別在于： 創建 DexClassLoader需要傳遞一個 optimizedDirectory參數，并且會將其創建為 File對象傳給 super，而 PathClassLoader則直接給到null。因此兩者都可以加載指定的dex，以及jar、zip、apk中的classes.dex

PathClassLoader pathClassLoader = new PathClassLoader("/sdcard/xx.dex", getClassLoader());

File dexOutputDir = context.getCodeCacheDir();
DexClassLoader dexClassLoader= new DexClassLoader("/sdcard/xx.dex",dexOutputDir.getAbsolutePath(), null,getClassLoader());

optimizedDirectory參數為odex的目錄。實際上Android中的ClassLoader在加載dex時，會首先經過dexopt對dex執行優化，產生odex文件。optimizedDirectory為null時的默認路徑為：/data/dalvik-cache。并且處于安全考慮，此目錄需要使用app私有目錄，如：getCodeCacheDir()

在API 26源碼中，將DexClassLoader的optimizedDirectory標記為了 deprecated 棄用，實現也變為了：

javapublicDexClassLoader(StringdexPath,StringoptimizedDirectory,StringlibrarySearchPath,ClassLoaderparent){super(dexPath,null,librarySearchPath,parent);}

和PathClassLoader一摸一樣了！

雙親委托機制

創建 ClassLoader需要接收一個 ClassLoaderparent參數。這個 parent為父類加載。即：某個類加載器在接到加載類的請求時，首先將加載任務委托給父類加載器，依次遞歸，如果父類加載器可以完成類加載任務，就成功返回；只有父類加載器無法完成此加載任務時，才自己去加載。這就是雙親委托機制！

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{

    // 檢查class是否有被加載
    Class c = findLoadedClass(name);
    if (c == null) {
        long t0 = System.nanoTime();
        try {
            if (parent != null) {
                //如果parent不為null，則調用parent的loadClass行加載
                c = parent.loadClass(name, false);
            } else {
                //parent為null，則調用BootClassLoader進行加載
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {

        }

        if (c == null) {
            // 如果都找不到就自己查找
            long t1 = System.nanoTime();
            c = findClass(name);
        }
    }
    return c;
}

因此我們自己創建的ClassLoader: newPathClassLoader("/sdcard/xx.dex",getClassLoader());并不僅僅只能獲得 xx.dex中的Class，還能夠獲得其父ClassLoader中加載的Class。

findClass

在所有父ClassLoader無法加載Class時，則會調用自己的 findClass方法。findClass在ClassLoader中的定義為:

protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
}

其實任何ClassLoader子類，都可以重寫 loadClass與 findClass。一般如果你不想使用雙親委托，則重寫 loadClass修改其實現。而重寫 findClass則表示在雙親委托下，父ClassLoader都找不到Class的情況下，定義自己如何去查找一個Class。而我們的 PathClassLoader會自己負責加載 MainActivity這樣的程序中自己編寫的類，利用雙親委托父ClassLoader加載Framework中的 Activity。說明 PathClassLoader并沒有重寫 loadClass，因此我們可以來看看PathClassLoader中的 findClass 是如何實現的。

public BaseDexClassLoader(String dexPath, FileoptimizedDirectory,String
                        librarySearchPath, ClassLoader parent) {
    super(parent);
    this.pathList = new DexPathList(this, dexPath, librarySearchPath,
                                    optimizedDirectory);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
    List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
    //查找指定的class
    Class c = pathList.findClass(name, suppressedExceptions);
    if (c == null) {
        ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" +                                                      name + "\" on path: " + pathList);
        for (Throwable t : suppressedExceptions) {
             cnfe.addSuppressed(t);
        }
            throw cnfe;
    }
    return c;
}

實現非常簡單，從pathList中查找class。繼續查看 DexPathList

public DexPathList(ClassLoader definingContext, String dexPath,
            String librarySearchPath, File optimizedDirectory) {
    //.........
    // splitDexPath 實現為返回 List<File>.add(dexPath)
    // makeDexElements 會去 List<File>.add(dexPath) 中使用DexFile加載dex文件返回 Element數組

this.dexElements =makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                           suppressedExceptions, definingContext);
    //.........
}
public Class findClass(String name, List<Throwable> suppressed) {
     //從element中獲得代表Dex的 DexFile
    for (Element element : dexElements) {
        DexFile dex = element.dexFile;
        if (dex != null) {
            //查找class
            Class clazz = dex.loadClassBinaryName(name,definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }
    }
    if (dexElementsSuppressedExceptions != null) {
        suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
    return null;
}

熱修復

PathClassLoader中存在一個Element數組，Element類中存在一個 dexFile成員表示dex文件，即：APK中有X個dex，則Element數組就有X個元素。

而對于類的查找，由代碼for(Elementelement:dexElements)得知，會由數組從前往后進行查找。

在 PathClassLoader中的Element數組為：[patch.dex , classes.dex , classes2.dex]。如果存在Key.class位于patch.dex與classes2.dex中都存在一份，當進行類查找時，循環獲得 dexElements中的 DexFile，查找到了Key.class則立即返回，不會再管后續的element中的 DexFile是否能加載到Key.class了。

因此，可以將出現Bug的class單獨的制作一份patch.dex文件(補丁包)，然后在程序啟動時，從服務器下載patch.dex保存到某個路徑，再通過patch.dex的文件路徑，用其創建 Element對象，然后將這個 Element對象插入到我們程序的類加載器 PathClassLoader的 pathList中的 dexElements數組頭部。這樣在加載出現Bug的class時會優先加載patch.dex中的修復類，從而解決Bug。QQ空間熱修復的原理就是這樣，利用反射Hook了PathClassLoader中pathList的dexElements數組。

總結

在實現熱修復的過程中，必須掌握的技術包括了反射、類加載機制并且掌握Framewrok層源碼中關于 ClassLoader部分的內容。同時如果需要繼續自動化補丁生成還需要掌握gradle編程等內容。

文章中每一個部分都包含一系列BAT面試的面試點，這些點構建了一個完整的知識體系，熱修復。后面，我會細化里面的知識，如果 大家覺得有問題，可以和我交流~