Android?AndFix熱修復原理是什么

這篇“Android AndFix熱修復原理是什么”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Android AndFix熱修復原理是什么”文章吧。

前言

當我們寫了一個方法，那么這個方法是如何被執行的呢？

public int add(){
    int a = 10;
    int b = 20;
    return a + b;
}

其實方法的本質就是arm指令，在Android當中，dalvik或者art虛擬機的執行引擎會執行arm指令 

 add方法是java代碼，java代碼編譯成class文件，還需要一步轉換為dex文件，才能被Android虛擬機執行，dex文件包含了app的所有代碼，因此方法也是存在dex文件中，那么通過dx命令，可以查看方法被編譯成的字節碼指令

1 arm指令集

dx --dex --verbose --dump-to=dex_method.txt --dump-method=Method.add --verbose-dump Method.class

Android中可以通過dx命令將class文件轉換為dex文件，dx.bat位于Android SDK中的build-tools文件夾下，那么可以通過dx命令將class文件翻譯成arm指令集 

可以看一下，打印輸出的arm指令集，ART執行某個方法的時候，執行的就是這個指令集，當apk安裝的時候，dex文件會被dex2oat工具翻譯成本地機器碼（arm指令集）保存在oat文件中，當apk運行的時候oat會被加載到內存中，存在虛擬機的方法區中 

 執行的時候，會構建一個棧幀壓入虛擬機棧中，然后每一個方法在ART中都對應一個ArtMethod（這個后邊會說），ArtMethod中的invoke函數會找到當前方法對應的本地機器碼執行，執行完成之后，棧幀出棧

關注點回到指令集上，在每一行指令前有一個數字，代表程序計數器記錄的行號，精簡之后的指令集（只保留每個行號的最后一個）

Method.add:()I:
regs: 0002; ins: 0001; outs: 0000
 
  0000: const/16 v0, #int 30 // #001e
  0002: return v0
  0003: code-address
  debug info
    line_start: 4
    parameters_size: 0000
    0000: prologue end
    0000: line 4
    0000: line 6
    end sequence
  source file: "Method.java"

另外還有一種方式獲取字節碼，是通過javap獲取，這種跟arm指令有啥區別呢？其實都是字節碼，但是javap獲取的字節碼是JVM執行的字節碼，Android虛擬機是Dalvik或者Art虛擬機，執行的是arm指令集

public int add();
    descriptor: ()I
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: bipush        10
         2: istore_1
         3: bipush        20
         5: istore_2
         6: iload_2
         7: iload_1
         8: iadd
         9: ireturn
      LineNumberTable:
        line 4: 0
        line 5: 3
        line 6: 6

這兩者有什么區別呢？我們看同是執行 10 + 20 ，JVM是先創建一個10變量，然后再創建20 ，最后將兩個相加然后返回；但是從ART機器指令中可以看到是直接計算好了，然后創建v0 = 30，直接返回，所以：Android編譯器在編譯的過程中會做優化，提高執行的效率(這個可以自己去試一下，javac并沒有做優化處理)

當一個class類加載進來之后，class類中有方法、成員變量等，這些類的信息加載的時候是放在方法區，當Java層調用某個方法時，ART虛擬機找到該方法對應的本地機器碼指令，在虛擬機棧中，該方法棧幀入棧，CPU去讀取每行指令，程序計數器＋1，等到方法執行完畢，棧幀出棧。

2 AndFix熱修復原理

之前我們介紹過阿里的AndFix或者Sophix是通過hook native層替換已經加載的類的方法，接下來我們著重看一下，AndFix熱修復是怎么實現的

Method.add:()I:
regs: 0002; ins: 0001; outs: 0000
 
  0000: const/16 v0, #int 30 // #001e
  0002: return v0
  0003: code-address
  debug info
    line_start: 4
    parameters_size: 0000
    0000: prologue end
    0000: line 4
    0000: line 6
    end sequence
  source file: "Method.java"

public class Method {

    public int add(){
        int a = 10;
        int b = 20;
        return a + b;
    }
}
//調用
Method method = new Method();
method.add();

我們看下這個方法，通過Method對象去調用，method是在堆內存中，通過對象可以拿到類信息在方法區中。 

當執行這個方法時，ART執行引擎從方法區中找到方法的本地機器指令，通過CPU執行得到結果，如果add方法中拋出異常導致app崩潰，那么如何修復?

2.1 ArtMethod

既然要做到方法替換，首先必須要了解方法在虛擬機中的形態；其實前面有提到，方法在虛擬機中對應的結構體就是ArtMethod，每個方法在ART中對應一個ArtMethod。

# Android 10.0/art/runtime/art_method.h
protected:
 
  GcRoot<mirror::Class> declaring_class_;
  
  std::atomic<std::uint32_t> access_flags_;

  uint32_t dex_code_item_offset_;

  uint32_t dex_method_index_;
  uint16_t method_index_;

  union {
    uint16_t hotness_count_;
    uint16_t imt_index_;
  };

  // Fake padding field gets inserted here.

  // Must be the last fields in the method.
  struct PtrSizedFields {
    // Depending on the method type, the data is
    //   - native method: pointer to the JNI function registered to this method
    //                    or a function to resolve the JNI function,
    //   - conflict method: ImtConflictTable,
    //   - abstract/interface method: the single-implementation if any,
    //   - proxy method: the original interface method or constructor,
    //   - other methods: the profiling data.
    void* data_;

    // Method dispatch from quick compiled code invokes this pointer which may cause bridging into
    // the interpreter.
    void* entry_point_from_quick_compiled_code_;
  } ptr_sized_fields_;

在ArtMethod中，有一個結構體PtrSizedFields，其中一個成員變量為entry_point_from_quick_compiled_code_，這個指針指向的就是在方法區中該方法本地機器碼的內存地址，也就是說，如果想要實現熱修復，那么就將entry_point_from_quick_compiled_code_指向正確的方法機器碼指令地址即可。

除此之外，看下其他成員變量的含義：

• declaring_class_：用來標記當前方法屬于哪個類

• access_flags_：當前方法的訪問修飾符

• hotness_count_：記錄當前方法被調用的次數，如果超過某個限制，那么該方法就被標記為是熱方法，這個與ART的編譯模式相關

對于hotness_count_，這里需要說一下ART的編譯模式，Dalvik的就先不介紹了

2.2 ART編譯模式

在Android 5.0之后，Android編譯器由ART代替了Dalvik，采用了全新的編譯模式AOT，代替JIT；

什么是AOT？就是全量編譯，在APK安裝的時候，會將所有的dex文件編譯成本地機器碼，然后在執行方法時會直接拿到相應的機器碼執行，速度非常快，但是這也帶來一些問題：

（1）安裝時間長

因為在安裝的過程中做全量的編譯，耗時非常嚴重；早先的Android手機我們在安裝的時候，進度條一直在轉但就是裝不上，這種是非常差的用戶體驗

（2）存儲空間

因為全量編譯的時候，dex被編譯成機器碼之后，保存在.oat文件中，10M的dex翻譯成的機器碼內存激增4-5倍，大量的文件保存在手機中會占據內存空間

所以在Android N之后，采用了混合編譯模式，AOP + 解釋 + JIT

全新的混編模式不再在APK安裝的時候進行全量編譯，而是會解釋字節碼，因此安裝的速度很快；此外新增了一個JIT編譯器，會在App運行的時候分析代碼，把結果保存在Profile中，并且在空閑時間分析并編譯這些代碼；

接著上面的hotness_count_，其實用來記錄這個方法被調用的次數，當超過某個閾值之后，這個方法會被標記為熱代碼，這些熱方法在設備空閑的時候做編譯，并保存在名為app_image的base.art文件中，這個art文件會在類加載之前加載到內存中，意味著當調用這個方法的時候，不再需要編譯為機器碼，而是直接執行拿到結果。

2.3 AndFix框架實現

首先創建一個C++的模塊，然后C++版本可選擇個人熟悉的，我對C++ 11的一些特性比較熟悉 

 其實AndFix實現的關鍵，就是找到ArtMethod，在JNI層是能夠實現的，通過JNIEnv的FromReflectedMethod函數

public class AndFixManager {
    //native熱修復方法
    public static native void fix(Method wrong, Method right);
}

//fix對應的JNI接口
extern "C"
JNIEXPORT void JNICALL
Java_com_tal_andfix_AndFixManager_fix(
        JNIEnv *env,
        jclass clazz,
        jobject wrong,
        jobject right) {

    //獲取ArtMethod
    env->FromReflectedMethod(wrong);

}

其實在Java層調用的時候，是需要反射獲取某個方法，也就是說，在Java層反射拿到的方法其實就是ArtMethod，只不過再底層的我們看不到，那現在就能看到了！

try {
    Class<?> clazz = Class.forName("com.tal.demo02.FixDemo");
    Method run = clazz.getDeclaredMethod("run");
    AndFixManager.fix(run,run);
} catch (Exception e) {
    e.printStackTrace();
}

2.3.1 獲取ArtMethod

之前我們看源碼的時候，可以看到ArtMethod.h中存在很多系統的頭文件，全部導入工程中不現實 

 因為我們需要的是ArtMethod的一個結構體的成員變量，所以我們只需要針對性地導入即可，art_method.h如下;

#ifndef DEMO02_ART_METHOD_H
#define DEMO02_ART_METHOD_H
#endif //DEMO02_ART_METHOD_H
#include "stdint.h"
namespace art{
    namespace mirror{
        class ArtMethod final {
        public:
            uint32_t declaring_class_;
            std::atomic<std::uint32_t> access_flags_;
            uint32_t dex_code_item_offset_;
            uint32_t dex_method_index_;
            uint16_t method_index_;
            union {
                uint16_t hotness_count_;
                uint16_t imt_index_;
            };
            struct PtrSizedFields {
                void* data_;

                void* entry_point_from_quick_compiled_code_;
            } ptr_sized_fields_;

        };

    }
}

最終在Java層調用JNI方法，執行到JNI層，獲取到ArtMethod

extern "C"
JNIEXPORT void JNICALL
Java_com_tal_andfix_AndFixManager_fix(
        JNIEnv *env,
        jclass clazz,
        jobject wrong,
        jobject right) {

    //獲取ArtMethod
    ArtMethod *artMethod = reinterpret_cast<ArtMethod *>(env->FromReflectedMethod(wrong));
}

這里通過斷點可以看到，ArtMethod已經拿到了，而且關鍵信息entry_point_from_quick_compiled_code_，也就是arm指令集的內存地址拿到了！ 

2.3.2 方法替換

public class FixDemo {

    public void run(){
        throw new IllegalArgumentException();
    }
}

public class FixDemo {
    public void run(){
        Log.e("TAG","已經被修復了");
    }
}

現在有一個場景就是，當執行FixDemo的run方法時拋出異常導致崩潰，這種場景下，使用熱修復技術怎么修復呢，就是方法替換，arm指令集替換

public class AndFixManager {

    public static void bugFix(){
        try {
            Class clazz = Class.forName("com.take.andfix.FixDemo");
            Method wrong = clazz.getDeclaredMethod("run");
            //正確的方法
            Class clazz1 = Class.forName("com.take.andfix.fox.FixDemo");
            Method right = clazz1.getDeclaredMethod("run");
            AndFixManager.fix(wrong, right);
        }catch (Exception e){

        }
    }
    public static native void fix(Method wrong, Method right);
}

拋出異常的類是andfix包下的，當線上需要修復時，下發patch包，然后加載fox包下的方法，調用native fix方法

extern "C"
JNIEXPORT void JNICALL
Java_com_tal_andfix_AndFixManager_fix(JNIEnv *env, jclass clazz, jobject wrong, jobject right) {

    //獲取ArtMethod
    ArtMethod *wrongMethod = reinterpret_cast<ArtMethod *>(env->FromReflectedMethod(wrong));
    ArtMethod *rightMethod = reinterpret_cast<ArtMethod *>(env->FromReflectedMethod(right));

    //方法替換
    wrongMethod->declaring_class_ = rightMethod->declaring_class_;
    wrongMethod->access_flags_ = rightMethod->access_flags_;
    wrongMethod->dex_code_item_offset_ = rightMethod->dex_code_item_offset_;
    wrongMethod->dex_method_index_ = rightMethod->dex_method_index_;
    wrongMethod->method_index_ = rightMethod->method_index_;
    wrongMethod->ptr_sized_fields_.data_ = rightMethod->ptr_sized_fields_.data_;
    wrongMethod->ptr_sized_fields_.entry_point_from_quick_compiled_code_ = rightMethod->ptr_sized_fields_.entry_point_from_quick_compiled_code_;
}

然后再次執行run方法

binding.sampleText.setOnClickListener {
    AndFixManager.bugFix()
    val fixDemo = FixDemo()
    fixDemo.run()
}
打印出的結果：E/TAG: 已經被修復了

其實現在阿里的AndFix和Sophix已經不維護了，但是這種熱修復的思想我們是需要了解的，尤其是通過hook native底層替換方法，能夠幫助我們更好地了解JVM虛擬機和Android虛擬機。

2.4 AndFix動態化配置

在上面簡單的demo中，我們是知道那個類的哪個方法發生異常，在代碼中寫死的，但真正的線上環境中，其實是不知道哪個類會報錯，一般我們都會使用bugly，像crash跟anr都能夠實時監控到 

 當app某個方法拋異常之后，通過bugly上報到后臺，比如com.take.andfix.FixDemo這個類中的run方法拋出了異常，那么我們需要針對這個類的方法做修復，如果做到動態化，需要使用注解修飾這個修復類

/**
 * 修復類需要使用這個注解
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface andfix {
    String clazz();
    String method();
}

public class FixDemo {
    @andfix(clazz = "com.tal.andfix.FixDemo",method = "run")
    public void run(){
        Log.e("TAG","已經被修復了");
    }
}

這樣在熱修復時，能夠知道這個修復類要修復線上環境中那個類的哪個方法

2.4.1 dex打包

在打包dex的時候，需要把整個包名路徑下的class文件一起打包，通過命令行完成dex打包

dx --dex --output fix.dex /xxxx/Desktop/dx

 將打包成功的dex修復包，放到sd卡中 :

2.4.2 dex文件加載

dex文件的加載，通過DexFile實現，如果不熟悉可以看下源碼，art虛擬機會將dex轉換為odex，因此加載dex文件的時候，需要傳入一個odex文件的緩存路徑。

將dex文件加載到內存之后，可以獲取到dex文件中全部的類，通過DexFile.loadClass就可以將這個類通過類加載器加載。

/**
* dex文件加載，將dex文件加載到內存
* @param context
* @param dexFile
*/
private static void loadFixDex(Context context, File dexFile) {
   try {

       DexFile odex = DexFile.loadDex(
               dexFile.getAbsolutePath(),
               new File(context.getCacheDir(), "odex").getAbsolutePath(),
               Context.MODE_PRIVATE
       );
       Enumeration<String> entries = odex.entries();
       while (entries.hasMoreElements()){
           //全類名
           String clazzName = entries.nextElement();
           //加載類
           Class aClass = odex.loadClass(clazzName, context.getClassLoader());
           //處理類
           if(aClass != null){
               processClass(aClass);
           }
       }


   } catch (Exception e) {
       e.printStackTrace();
   }
}

這里會有一個問題，就是既然拿到了全類名，為什么不能通過方式1獲取，而是需要通過方式2獲取？原因就是，Class.forName是從當前apk中查找這個類，但是這個類是在dex文件中，是從服務端下發的，并沒有放在apk中，因此通過Class.forName是找不到的，通過DexFile.loadClass才是真正加載類到了內存中

//方式1
Class.forName("xxxxxxxxxx")
//方式2
odex.loadClass(clazzName, context.getClassLoader())

2.4.3 動態替換方法

拿類之后，通過反射能夠拿到修復類中的方法，當然不是每個方法都是需要被修復的，我們需要判斷的是，上面是否有我們自定義的注解，如果有，那么就能夠通過反射，拿到拋出異常的這個方法，因為注解上有我們傳入的類名和方法名，最終調用JNI的接口實現動態替換方法

private static void processClass(Class aClass) {
    //獲取方法上的注解
    Method[] methods = aClass.getMethods();
    for (Method method:methods){
        andfix annotation = method.getAnnotation(andfix.class);
        if(annotation != null){
            //如果存在這個注解，那么就執行方法替換
            String clazz = annotation.clazz();
            String method1 = annotation.method();
            //獲取wrong方法
            try {
                Class<?> wrongMethodClass = Class.forName(clazz);
                //這里注意，修復類的方法，要和被修復的方法，參數一致！！！！！
                Method wrongMethod = wrongMethodClass.getDeclaredMethod(method1,method.getParameterTypes());
                //動態方法替換
                fix(wrongMethod,method);
            } catch (Exception e) {
                e.printStackTrace();
            }

        }
    }
}

2.4.4 文件訪問問題

一切準備就緒之后，可以通過加載dex補丁包來修復

binding.sampleText.setOnClickListener {

//            AndFixManager.bugFix()
    AndFixManager.loadFixDex(
        this,
        File(System.getenv("EXTERNAL_STORAGE"), "fix.dex")
    )
    val fixDemo = FixDemo()
    fixDemo.run()
}

這里可能會碰到一些加載SD卡中文件報錯的問題，比如：

No original dex files found for dex location /sdcard/fix.dex

這里需要添加文件的讀寫權限，才能夠保證有效的熱修復，除此之外，在Android 10以上的版本，需要在清單文件中添加android:requestLegacyExternalStorage屬性

android:requestLegacyExternalStorage="true"

通過這種hook native底層的方式，最大的優勢在于能夠真正實現熱修復，不需要重新啟動app就能夠修復，但是存在的弊端也是比較明顯的，就是兼容性問題，每個Android的版本，native層都會有變化，比如art_method.h，其實每個版本都是不一樣的，我這次使用的就是Android 10中的art_method頭文件，有興趣的可以看看之前Android版本的頭文件，其實還是有差別的，所以在做兼容性問題的時候，需要根據版本來適配不同的頭文件

以上就是關于“Android AndFix熱修復原理是什么”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。