學習資料：《Android進階解密》

常見的熱修復框架有阿里的AndFix、Dexposed、阿里百川和Sophix，騰訊的微信Tinker、QQ空間的超級補丁和手Q的QFix，其他知名大廠的有美團的Robust、餓了么的Amigo、美麗說蘑菇街的Aceso，以及其他的RocooFix、Nuwa和AnoleFix等等。

熱修復框架的主要分為代碼修復、資源修復和動態鏈接庫修復，每個庫使用修復的原理都有所區別

• 資源修復

  大多熱修復框架的資源修復都參考了Instant Run的資源修復原理

  • Instant Run部署三種方式

    • Hot Swap

      效率最高的部署，代碼的增量改變不需要重啟App，甚至不需要重啟當前的Activity，修改一個現有方法中的代碼時會采用Hot Swap

    • Warm Swap

      App不需重啟，但Activity需要重啟，修改或刪除一個現有的資源文件會采用Warm Swap

    • Cold Swap

      App需要重啟，但不需要重新安裝，采用Cold Swap的情況很多，比如添加、刪除或修改一個字段和方法

  • 原理

    • 創建新的AssetManager，通過反射調用addAssetPath方法加載外部的資源，這樣創建的AssetManager就含有了外部資源
    • 將AssetManager類型的mAssets字段的引用全部替換為創建新的AssetManager

• 代碼修復

  代碼修復主要有三個方案，分別是類加載方案、底層替換方案和Instant Run方案

  • 類加載方案

    類加載方案是基于Dex分包方案，

    • Dex分包

      Dex分包主要是將應用代碼分成多個dex文件，將應用啟動時必須用到的類和這些類的直接引用類放到主Dex中，其他代碼放到其他Dex中，從而解決Dex的65536問題和LinearAlloc限制。

      Dex分包方案主要有兩種，分別是Google官方方案、Dex自動拆包及動態加載方案

    類加載方案需要重啟App后讓ClassLoader重新加載新的類，因為類是無法被卸載的，要想重新加載新的類就需要重啟App，因此采用類加載方案的熱修復框架不能及時生效，采用類加載方案的的框架其實現方式也是有區別的，如QQ空間的超級補丁和Nuwa是按照將補丁包放在Element數組的第一個元素得到優先加載；微信Tinker將新舊Apk做diff，得到patch.dex，再將patch.dex與手機中APK的classes.dex做合并，生成新的classes.dex，然后在運行包時通過反射將classes.dex放在Element數組的第一個元素；餓了么的Amigo則是將補丁包中每個dex對應的Element取出來，之后組成新的Element數組，在運行時通過反射用新的Element數組替換掉現有的Element數組。Element數組指的是DexPathList的findClass方法中用的dexElements

    /libcore/dalvik/src/main/java/dalvik/system/DexPathList.java
    /**
     * Finds the named class in one of the dex files pointed at by
     * this instance. This will find the one in the earliest listed
     * path element. If the class is found but has not yet been
     * defined, then this method will define it in the defining
     * context that this instance was constructed with.
     *
     * @param name of class to find
     * @param suppressed exceptions encountered whilst finding the class
     * @return the named class or {@code null} if the class is not
     * found in any of the dex files
     */
    public Class<?> findClass(String name, List<Throwable> suppressed) {
        for (Element element : dexElements) {
            Class<?> clazz = element.findClass(name, definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }
    
        if (dexElementsSuppressedExceptions != null) {
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }
    
    

  • 底層替換方案

    底層替換方案不會再次加載新類，而是直接在Native層修改原有類，但在原有類上進行修改限制會比較多，不能增減原有類的方法和字段，底層替換方案可以立即生效不用重啟。

    底層方案主要是替換ArtMethod結構體中的字段或者替換整個ArtMethod結構體

    AndFix采用的是替換ArtMethod結構體中的字段，這樣會有兼容問題，因為廠商可能會修改ArtMethod結構體，導致方法替換失敗；Sophix采用的是替換整個ArtMethod結構體，這樣不會存在兼容問題。

    ArtMethod結構體中包含了Java方法的所有信息，包括執行入口，訪問權限、所屬類和代碼執行地址等

  • Instant Run方案

    使用ASM在每一個方法都注入一些代碼

    ASM：是一個Java字節碼操作框架，它能夠動態生成類或者增強現有類的功能。ASM可以直接產生class文件，也可以在類被加載到虛擬機前動態改變類的行為

• 動態鏈接庫的修復

  主要有兩種方案：

  • 將so補丁插入到NativeLibraryElement數組的前部，讓so補丁的路徑先被返回和加載
  • 調用System的load方法來接管so的加載入口