Android線上bug熱修復分析

在Android系統啟動的時候會創建一個Boot類型的ClassLoader實例，用於加載一些系統Framework層級需要的類。由於Android應用裡也需要用到一些系統的類，所以APP啟動的時候也會把這個Boot類型的ClassLoader傳進來。

此外，APP也有自己的類，這些類保存在APK的dex文件裡面，所以APP啟動的時候，也會創建一個自己的ClassLoader實例，用於加載自己dex文件中的類。
下面實際驗證看看：

 @Override
 protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);

      ClassLoader classLoader = getClassLoader();
      Log.i("ClassLoader" , "classLoader " + classLoader.toString());

      while (classLoader.getParent() != null) {
          classLoader = classLoader.getParent();
          if (classLoader != null) {
              Log.i("ClassLoader", "classLoaderParent " + classLoader.toString());
          }
     }
}

輸出結果為：

I/ClassLoader: classLoader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.sunteng.classloader-1/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]
I/ClassLoader: classLoaderParent java.lang.BootClassLoader@2d0a3af7

可以看見有2個Classloader實例，一個是BootClassLoader（系統啟動的時候創建的），另一個是PathClassLoader（應用啟動時創建的，用於加載當前已安裝app裡面的類）。

Android經常使用的是PathClassLoader和DexClassLoader

官方注釋：一個簡單的ClassLoader的實現，工作在本地文件系統中的文件和目錄的列表上，但不嘗試從網絡加載類。 Android使用這個類為它的系統類加載器和應用類加載器。

官方注釋：一個ClassLoader的實現，從.jar和.apk文件內部加載classes.dex。這可以用於執行非安裝程序作為已安裝應用程序的一部分的代碼。

#BaseDexClassLoader
@Override
protected Class findClass(String name) throws ClassNotFoundException {
    List suppressedExceptions = new ArrayList();
    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;
}

#DexPathList
public Class findClass(String name, List suppressed) {
    for (Element element : dexElements) {
        DexFile dex = element.dexFile;

        if (dex != null) {
            Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }
    }
    if (dexElementsSuppressedExceptions != null) {
        suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
    return null;
}

#DexFile 
public Class loadClassBinaryName(String name, ClassLoader loader) {
    return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);

this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory, suppressedExceptions);

一個ClassLoader可以包含多個dex文件，每個dex文件是一個Element，多個dex文件排列成一個有序的數組dexElements，當找類的時候，會按順序遍歷dex文件，然後從當前遍歷的dex文件中找類，如果找類則返回，如果找不到從下一個dex文件繼續查找

ClassLoader特性

如果使用ClassLoader來動態升級APP或者動態修復BUG，都需要重新啟動APP才能生效。

Android中context可以給程序提供組件需要用到的功能，也可以提供一些主題、Res等資源，而現在的各種Android動態加載框架中，核心要解決的東西也正是如何給外部的新類提供上下文環境的問題。

希望最終的效果

技術選型

就一個理念：只有適合當前情況的才是最好的。

插件化和熱修復

前面關於Android中ClassLoader的介紹，Android使用PathClassLoader作為其類加載器，DexClassLoader可以從.jar和.apk類型的文件內部加載classes.dex文件。

如果大家對於插件化有所了解，其實Android應用的插件化，就可以利用DexClassLoader來動態加載非安裝應用的類來實現，當然也就可以做到只有單用戶點擊相應插件模塊，才會從網絡獲取相應插件文件，再通過DexClassLoader實現類加載。

而熱修復可以利用BaseDexClassLoader中的pathList對象，pathList中包含一個DexFile的集合dexElements，我們可以在這個dexElements中去做一些事情，比如在這個數組的第一個元素放置我們的patch.jar，裡面包含修復過的類。

這樣的話，當遍歷findClass的時候，我們修復的類就會被查找到，從而替代有bug的類。不過這樣處理還存在一個CLASS_ISPREVERIFIED的問題。

熱修復具體實施

上面分析了Android中的類的加載的流程，可以看出：
* DexPathList對象中的dexElements列表是類加載的一個核心，一個類如果能被成功加載，那麼它的dex一定會出現在dexElements所對應的dex文件中。
* exElements中出現的順序也很重要，在dexElements前面出現的dex會被優先加載，一旦Class被加載成功，就會立即返回。
* 我們的如果想做hot fix，一定要保證我們的pacth dex文件出現在dexElements列表的前面。

要實現熱修復，就需要我們在運行時去更改PathClassLoader.pathList.dexElements，由於這些屬性都是private的，因此需要通過反射來修改。

另外，構造我們自己的dex文件所對應的dexElements數組的時候，我們也可以采取一個比較取巧的方式：
* 通過構造一個DexClassLoader對象來加載我們的dex文件
* 調用一次dexClassLoader.loadClass(dummyClassName)方法
* 這樣dexClassLoader.pathList.dexElements中就會包含我們的dex

通過把dexClassLoader.pathList.dexElements插入到系統默認的classLoader.pathList.dexElements列表前面，就可以讓系統優先加載我們的dex中的類，從而可以實現熱修復了。

自己的思考

通過分析三者的差異化對比，以及思考到底什麼才是合適的，通過hook方法的方式實現起來確實最直接，但是問題卻也很明顯，首先成功覆蓋率和穩定性是個問題，而且操作起來復雜性比較高。

而通過classloader考慮的是從系統動態加載的特性入手，所以理所當然以局限於系統的特性，比如由於對於已經加載的類，類加載器不會再調用loadClass方法，所以想要修復要等到下次啟動程序才行。

Android項目中，動態加載技術按照加載的可執行文件的不同大致可以分為兩種：
1.動態加載so庫；
2.動態加載dex/jar/apk文件（通常都是這種）

所以理解起來就是：
1.動態調用外部的Dex文件則是完全沒有問題的。
2.在APK文件中往往有一個或者多個Dex文件，我們寫的每一句代碼都會被編譯到這些文件裡面。
3.Android應用運行的時候就是通過執行這些Dex文件完成應用的功能的。
4.雖然一個APK一旦構建出來，我們是無法更換裡面的Dex文件，但是我們可以通過加載外部的Dex文件來實現。

外部文件可以放在外部存儲，或者從網絡下載。

因此最極端的情況就是，直接把APK自身帶有的Dex文件當做空殼，只是作為一個程序的入口，所有的功能都通過從服務器下載最新的Dex文件完成。
當然，一般來說只要利用Android動態加載技術，通過動態加載新的dex的方式，完成對有bug類的“替換”，來達到避免調用存在bug的代碼，這也就是所謂的Hot Fix。

總體的思路就是這樣，至於具體的實現，就有很多環節需要細化的，因為Android本身也有很多自身的特性。

接下來就是考慮實際編碼實現了。